Several detection rules (SNORT, F5, …) are being published these days to detect exploitation of vulnerability MS15-034.
If you are making or modifying such detection rules, I want to share some observations with you.
MS15-034 can be exploited with a GET request with a specially crafted Range header.
Here is the example we’ll use: Range: bytes=2-18446744073709551615
Referring to RFC 2616 section 14.35.1, you can see that this is not the only way to specify a range. Here is the BNF:
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit “=” byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos “-” [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
suffix-byte-range-spec = “-” suffix-length
suffix-length = 1*DIGIT
First of all, whitespace is allowed. So Range: bytes = 2 – 18446744073709551615 is valid (and also caused a BSOD on my test machine).
Second, numbers can have leading zeroes. So Range: bytes=2-018446744073709551615 is valid (and also caused a BSOD on my test machine).
Third, multiple ranges are allowed. So Range: bytes=2-3,4-18446744073709551615 is valid (this did not cause a BSOD on my test machine).
If you are using rules that don’t detect these cases properly, then attackers can easily evade detection. One space character could be all it takes to evade detection. If the rule looks for string “-18446744073709551615″, then using string “- 18446744073709551615″ in the attack (extra space character added) will evade detection.
'취약점 정보1' 카테고리의 다른 글
Web 사이트를 OS마다 강제 종료시키는 공격 코드 확인 (MS15-034) (0) | 2015.04.19 |
---|---|
Adobe 제품군 신규 취약점 보안 업데이트 권고 (0) | 2015.04.19 |
Microsoft Windows NTLM automatically authenticates via SMB when following a file:// URL (0) | 2015.04.17 |
크롬업데이트 권고 (0) | 2015.04.17 |
Adobe Releases Security Updates for Flash Player, ColdFusion, and Flex (0) | 2015.04.17 |