PHP Serialized Object Vulnerabilities
PHP Serialization Object serialization has always been a tricky subject. Using serialization as a design pattern can always lead to catastrophic consequences such as remote code execution when user input isn't properly validated. In the past we have released an article covering several PHP serialization related 0-day vulnerabilities and how those were effectively mitigated using those "PHP object serialization injection attempt" signatures: https://devcentral.f5.com/s/articles/php-7-unserialize-mechanism-0-days-24588 Recently Released CVEs In the past week we've witnessed several more PHP serialization vulnerabilities (CVE-2017-12932, CVE-2017-12933, CVE-2017-12934), which are not covered by our existing signatures. By inspecting proof-of-concept code related to these vulnerabilities, techniques targeting additional attack surfaces are becoming apparent: Not only PHP serialized object presents a threat, but a PHP serialized array as well. A malformed serialized object presents a threat. The malformed data leads PHP into unexpected behavior such as "heap use after free" and "buffer over-read". As of now, there is no public exploit that demonstrates direct connection to remote code execution using this technique. Mitigation Using ASM An Attack Signature Update containing signatures designed to mitigate these vulnerabilities has already been released. The relevant signatures are: 200004268 - PHP array serialization injection attempt (Parameter) 200004269 - PHP array serialization injection attempt (Header) 200004270 - PHP array serialization injection attempt (URI) 200004271 - PHP short object serialization injection attempt (Parameter) 200004272 - PHP short object serialization injection attempt (Header) 200004273 - PHP short object serialization injection attempt (URI) The following images demonstrate how ASM blocks those exploits:
Turn off Specific ASM Signatures for a Cookie
Running 12.1.x and am trying to figure out how to turn off specific signatures from firing for values of a specific cookie. The cookie in question is placed by third party performance monitoring software and often times what is put in those cookies contains information about the URLs or other objects on the page, causing a variety of path traversal and XSS signatures to go off. This cookie can be placed under various circumstances for various URLs and gets sent on a variety of requests (form data, JSON, multi-part, etc) always with the same name. It does not appear on every request. I tried setting up the cookie name as a parameter and turning off the signatures that way but that of course doesn't work since its not really a posted or URL parameter. I'm not going to disable this wide swath of signatures for the entire site, so that's not an option. I saw previous DevCentral responses for 11.x stating that you could use Content Profiles. I set up a JSON profile and associated it with the * URL to be turned on when the cookie is present and confirmed that this will stop those signatures from firing. However this doesn't really work since the requests with that cookie can be any type of content in the post and I can't set a profile for normal post data, additionally this turns it off for all fields instead of just for the cookie. I'd also like to avoid using LTM policy to switch ASM policies based on the cookie presence and have to manage multiple policies for something seemingly this simple. Is there any official non-kludgy way of turning off specific ASM attack signatures for a specific cookie?ASM Signature Update 02/08/2019 Contains Incorrect Command Execution Signatures
The 2/8/19 signature update available on F5 Downloads (shows a create date of 1/22/19 in the F5 UI) has some questionable updates for Command Execution signatures on parameters that cause a large amount of false positives. Instead of properly checking to see if a parameter contains a real command execution attempt, it is just firing on anything containing a the string that matches the command name. It's so bad that the sig for g++ will go off every time there is a " g " in a parameter being posted. This has been confirmed on 12.1.X I would suggest skipping this update until they address. If installed, my suggestion would be to disable all signatures with the string "execution attempt" in the title that relates to parameters (likely leave URL and Header sigs active, not getting false positives on those but ymmv) and contain a command that resembles a human word or is 3 characters or less. If not too labor intensive it would likely be better to disable on a parameter basis. Even if you have these signatures in staging, you may not get all possible values in your staging traffic so the next time you get a user with the name of "Pico", they could be blocked. Because we are on 12.x we had been setup to not put update signatures into staging because we didn't want to loose coverage, after years of that working perfectly for us, this update came and basically locked out our applications. Working with support on this, will update.
Logging and identify the violations from staged signatures
I am trying to fix a signature update issue for ASM v12.1.0 here. Signatures are not updated from some time. I wanted to do this in a phase manner now. 1) Enabling signature staging for the policy, enable signature staging for updated/new signatures 2) Run a manual update 3) Get through the Enforcement Readiness period of 7 days 4) Check for any violations for staged signatures and enforce the new/updated signatures respectively. Regx point 4, will need some guidance on checking for any violation for staged signatures. We are sending logs to splunk and how do i identify from the log data, if the alert was on a staged signature. Pasting some log snippets below. 30/08/2018 11:07:54.000 Aug 30 11:07:54 xxxx.net.au ASM: f5_asm=Splunk-F5-ASM,attack_type="",date_time="2018-08-30 11:07:54",dest_ip=x.x.x.x,dest_port=xxxx,geo_info="US",http_class="/Common/VS_Test",ip_addr_intelli="N/A",ip_client=x.x.x.x,ip_route_domain="x.x.x.x%0",is_trunct=truncated,manage_ip_addr=x.x.x.x,method="POST",policy_apply_date="2018-05-31 10:08:09",policy_name="/Common/VS_Test",protocol="HTTP",query_str="",req_status="passed",resp_code="200",route_domain="0",session_id="4353fdsad4dd",severity="Informational",sig_ids="",sig_names="",src_port="27603",sub_violates="",support_id="17873574374868071705",unit_host="xxxxxxxxxxxxxxxx",uri="/abc/xyz",username="N/A",violate_details="44f3d1e143060702-000000000000000044f3d1e143060702-000000000000000044f3d1e143262702-0000000000000000000040c100240000-0000000000000000
F5 ASM attack signature detection
the asm is detecting an sql injection and you can see in the below image when I when to check the detail of the violation, we can see that its a color code that's being rejected. Do you think that's an error? How do you just allow that particular color code for that virtual server ? I am new to ASM, in the below image its showing http illegal response ie 500 code.but there is no option to learn it. The question is when we see a violation and violation on staged entities , is the connection getting rejected because of the http violation or the attack signature violation in the staged entity??
