CEF Extensions
HTTP request information
Agents collect metadata information automatically from HTTP requests to the server. This gives useful forensics on cyberattacks for analysis by security experts on the source of the attack, HTTP endpoints exploited in the server and useful web user information. The following CEF extensions show web user information and these are logged with any Execute Rule security event for every rule, apart from the ARMR Patch rule. Whenever there is an attack, an Execute Rule event is logged by agents.
| Key Name | Description |
|---|---|
httpRequestUri | HTTP request endpoint that was targeted. |
internalHttpRequestUri | HTTP request endpoint that was last processed internally by the server at the time of the attack. In most cases, this will be equal to httpRequestUri, but sometimes servers internally redirect requests to other endpoints for specific processing. This value should be used to whitelist URIs for a particular security feature. |
httpRequestMethod | HTTP method of the request that was sent. |
remoteIpAddress | The IP address of the client or last proxy that sent the request. |
httpRemoteUser | The login of the user making this request, if the user has been authenticated. |
httpSessionId | The session identifier of a user across multiple page requests or visits to a website. |
httpCookies | A list of all the HTTP request cookies the client sent with the request. |
Example of HTTP request CEF extensions in attacks:
On the example below the HTTP requests targeted /spiracle/xss.jsp and the server did no further internal processing as it can be seen that httpRequestUri and internalHttpRequestUri are the same. The request carried a single cookie JSESSIONID: E654F722AAFA3BF44F0D0BD4FB91134C which carries the unique session ID. Finally, the request originated from localhost by user test.
httpSessionId=E654F722AAFA3BF44F0D0BD4FB91134C
httpRequestUri=/spiracle/xss.jsp
internalHttpRequestUri=/spiracle/xss.jsp
httpRequestMethod=GET
httpCookies=JSESSIONID\=E654F722AAFA3BF44F0D0BD4FB91134C
remoteIpAddress=127.0.0.1
httpRemoteUser=test
On the next example the internal processing can be seen in the server where the user’s HTTP request targeted /dialogs_samples_2_0/signupwizard/wizard-userpage.jsp but the attack actually happened while processing /dialogs_samples_2_0/signup.
httpRequestUri=/dialogs_samples_2_0/signupwizard/wizard-userpage.jsp
internalHttpRequestUri=/dialogs_samples_2_0/signup
httpRequestMethod=GET
httpCookies=JSESSIONID\=f8Q6ZY+zPND4PPdyyuwJXVOa
remoteIpAddress=127.0.0.1
httpSessionId=f8Q6ZY+zPND4PPdyyuwJXVOa
HTTP request information for tainted data
Tainted data is data that is external to the server, (e.g. parameters or cookies) carried by an HTTP request or a result to a database query. Such data accounts for the majority of remote exploits, and tainting is a key feature used by many ARMR rules for identifying attacks.
It is useful to differentiate between two different cases of HTTP requests: the request when user data is passed to a server, and the request that actually triggers an exploit with this data. An HTTP request that passes user data that is tainted and malicious and to a server may not necessarily be the request on which the exploit occurs. The tainted data may instead persist and be used by subsequent requests in a malicious way. Consider an attack that could reuse tainted data that was injected hours or even days beforehand, or over different users and IP addresses.
If a security event is triggered from a request that is using persisted tainted data supplied from a previous request, the HTTP request information for both requests is captured in the CEF event. The HTTP request information that originated from the initial request that supplied the tainted data uses the following prefix in the CEF extension keys: taintData. If the CEF extension value for both requests is identical then the agent omits the taintData prefixed extensions for brevity.
The following examples illustrate the 2 step approach for these attacks in a stored XXS scenario where data is first inserted into an in-memory database and only used later:
httpRequestUri=/chipchat/rooms.jsp
taintDataHttpRequestUri=/chipchat/chat.jsp
internalHttpRequestUri=/chipchat/rooms.jsp
taintDataInternalHttpRequestUri=/chipchat/chat.jsp
httpRequestMethod=GET
httpCookies=JSESSIONID\=EA5D45D3B7135D964FEEC6040A3F2155
remoteIpAddress=127.0.0.1
httpSessionId=EA5D45D3B7135D964FEEC6040A3F2155
The example above shows that an XSS attack occurred on the /chipchat/rooms.jsp HTTP request endpoint but tainted data came in from another HTTP request: /chipchat/chat.jsp. This is when data was actually stored in the database. Since the session and IP address used were exactly the same, no further CEF extensions prefixed with taintData are recorded in the log entry.