|
ASN.1 attacks are nothing new, neither is MS04-007. But they are still popular and I figure it may be interesting to look at a recent attack in a bit more detail and to show a couple tools to quickly figure out whats going on.
The traffic was collected at a development server of mine. It is connected to a cable modem via a firewall. The firewall logs every packet to/from the server which provides for nice detailed logs. I am only able to quote excerpts here as the packet is long/messy. In order to allow you to follow along, I made the packets of interest available here. The packet of interest is the GET request: GET / HTTP/1.0This particular authorization method is defined in RFC 4559, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows". The "long messy string" is the authentication token, and the web server should use it to authenticate the user. The RFC states that it is a "companion to the HTTP/1.1 specification", so the use of HTTP/1.0 is at least "odd" in the sample above. MS04-007 details a vulnerability in Microsoft's ASN.1 parser. This parser is used by a number of subsystems in Windows, one of which is the decoding of these authentication tokens. The same vulnerability can be exploited via SMB or HTTP, using essentially the same exploit. In the HTTP case, the exploit has to be Base64 encoded. Only after decoding the token is it passed to the vulnerable ASN.1 parser. So lets look at the decode of the authentication token. To decode it, I used a little perl script: use MIME::Base64; Sure, there are probably existing tools to decode this, but I try to limit the size of my tool box and tend to use these one liners for simple stuff like that. Let's pipe the output of this script through "xxd" and we get: 0000000: 6082 107a 0606 2b06 0105 0502 a082 106e `..z..+........n Nice! We got the payload of the exploit nicely decoded without haveing to speak too much opcode. Essentially the exploit attempts to run 'ftp' on my system to pull a second stage from the infecting host. The IP address is not obfuscated here. I assume whoever wrote this particular bot messed up coding the source IP and ended up with 0.0.0.0. And ftp server was listening on port 24706 at the attacking host. But it appeared to be too busy to let me download 'Updater.exe'. The attacking host was notified and has been cleaned. Error Log:The current snort ruleset uses this rule to detect MS04-007 over http: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS Note that this rule would not detect the particular version of the exploit shown here. If you run the packet capture posted above through snort, you will get however one alert from the http_inspect preprocessor: [**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**] (note that you have to use the '-k none' switch to ignore bad checksums). content:"Authorization|3A|"; content: "Negotiate"; \ Which would just look for overly long 'Authorization: Negotiate' lines. I split up the 'Authorization: Negotiate' string to allow for various spaces and such. "nocase" may be another option to chose to make this rule safer. The RFC at first glance does not specify a maximum length for the authentication tokens, so your mileage may vary. With http_inspect enabled, you will get two alerts. One from your rule, and one from http_inspect. |
Johannes 3393 Posts ISC Handler |
| Reply Subscribe |
Jul 28th 2006 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!
