August 2005

An Online MD5 Hash Database

MD5 Hashes protect a verity of content types such as in the case of pass phrases, session ids, etc the logic behind it is that to compute an equivalent of MD5 of all possible plain text would be a computational nightmare.

This computational nightmare has been brought one step closer to becoming an hackers’/crackers’ best friend with the introduction of the “Online MD5 Hash Database“. The Online MD5 Hash Database does exactly as it names says, stores in excess of 12 Million different MD5 values and their corresponding plain text equivalents.

How good the engine you say? will it was able to crack this MD5 Hash in near “real-time”: 1870a829d9bc69abf500eca6f00241fe (wordpress). How did it do it? well it some user has inputted the word wordpress into its Hash database.

I did the same for the words: security (e91e6348157868de9dd8b25c81aebfb9), securiteam (1d167077e74e969b9b7d34b2d901d697) and SecuriTeam (0a6b8933fcc5ea8234d49769de76cddc).

Smells FISH(y)

I’m an administrator of a VPS (Virtual Private Server). A few days ago I noticed something weird on the VPS : a weird process running a Perl script, that redirects its output to the O mighty black hole: /dev/null. The prompt variable of Bash (PS1) was set to be empty and the script itself was written like a VBA code (without indentation or line breaks). When I made a quick glance at the script, I saw that one Regex inside was looking for a command such as rmdir (for example), and it will unlink a directory.

Sounds like a back door that someone wrote, and all that it needs now is to open a shell for you and get over with it …

Well NO! This script was used by KDE (in this case) for simple SSH connection, that mimics the behavior of sftp, but over a simple ssh connection. The owner of the VPS used the KDE’s way (Konqueror ?) to login into the server… and KDE installed the script for the user.
Now when the user logged in, the commands “users” and “who” will not show you the user itself (“who -a” will show something, but not who is the user or the IP of the connected user). “last” also will not give you much information about the login, and if you try to hide the process, then even “ps” will not help (I first saw that issue using ps)…
Oh btw the script also read and wrote information to and from /var/log/messages.

BTW, this script implements the FISH protocol.

How do I know that you ask? Well thats what the Perl script says 😛 .
It seems that KDE (and other clients) try to help their users by implementing a sftp like actions without leaving the ssh client.

Sounds cool ? well I guess so… but then again, it IS a back door. That is if someone will be able to make the “server” talk with him without any need for authentication.

People should stop being lazy, and start using the right tool for the right job. Using FISH, can be exploited the same way that rlogin, telnet and NULL Session are .

The NULL Session Saga

NULL Session is by far the most notorious Windows vulnerability around. What NULL session basically means is that it is possible to connect to your IPC$ administrative share with no username and no password and gain some juicy data. To demonstrate this, simply run cmd and type:
net use \\host /user:"" ""

Where host is the IP/name of any machine on the network. If you get ‘The command completed successfully.’ you’re connected to a machine without providing any credentials.

NULL sessions are more than just information leakage. At least one worm has been known to spread by exploiting both NULL sessions and a vulnerability in RPC.

NULL session is so bad that SANS has been constantly including it in their SANS Top 20.

The discussion if this is a security vulnerability or a feature has been going on forever. Instead of arguing, let’s see how we can solve it for the people that actually wants it solved!

Well… It ain’t that simple… Take a deep breath, this is going to be long.

Windows NT 4.0 / Windows 2000:
The problem is known from the days of NT4. In the good ol’ days all that was needed is some spit and nails to solve the problem, or in other words:
Under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA change the item: RestrictAnonymous from 0 to 1

Problem solved! Not exactly. This only restricts the information gained from NULL session, and does not actually block the connection. Specifically, if you set this to 1, the unauthenticated user can’t enumerate SAM accounts, but it’s still possible to learn a lot about the users on the machine and the network structure.

So, in Windows 2000 Microsoft added another level to RestrictAnonymous. If you set RestrictAnonymous to 2 you actually block ALL unauthenticated access to the IPC$ share. And peace came to the land.

Well… This is swell, if you don’t count some pesky bits of software that actually MUST access the IPC$ with no username and password. I know of at least one accounting program that was written 10 years ago, and no one actually plans to patch it. Even worse, this also blocks anonymous connections from localhost! So if a poor programmer wants to run NetGroupAddUser for example from a local program, it must be done with a username and password!

But, the security freaks were once again calm, they have no NULL session in their machines once and for all. Well, until Windows XP that is.

Windows XP / 2003:
After customer complaints that RestrictAnonymous = 2 made them work hard, Microsoft decided to make life intolerable, er, simpler. In windows XP we now have 3 different keys controlling the NULL session ‘feature’. Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA :
1. Good old RestrictAnonymous is still there, but setting it to 1 or 2 yields the same result, NULL connections can still be created, less information leaks.
2. RestrictAnonymousSam controls anonymous access to SAM accounts (in the past that what RestrictAnonymous = 1 did).
3. EveryoneIncludesAnonymous When set to 0 (default factory setting), this little piggy prevents anonymous connections to be in the ‘Everyone’ group and access resources allowed to everyone.

So what do we get from all these changes? NULL connections can’t get SAM accounts, are not in any group, and generally are unwelcome. But! Cries the purist, they can still make an anonymous connection!
That’s right, in Windows XP, no setting allows the poor administrator to completely block those dreaded NULL connections!

So what can the poor administrator do? First thought comes to mind is of course: Use a firewall!

Disable File and Printer Sharing / Filter traffic and IPSec:
1. So why can’t we just disable all access to the IPC$, who needs it anyway?
The simplest way to solve this, is just uncheck ‘File and Printer Sharing for Microsoft Windows’ on every network interface on the machine! Yup. That works. If you don’t need shared directory, shared printers, remote registry or anything of the sort…
Not a very valid solution in many cases.

2. OK, let’s firewall the damn thing. Just block all incoming traffic on 445/139. Nice try. Microsoft puts so many services on these two poor ports that it can make your eyes bleed. Just as an example: Computer Browser, Workstation, Server, Remote Registry, File / Printer Sharing, DCOM and so on…
OK, I’ll just allow authenticated connection, reject all unauthenticated. I’m sure my firewall can do that!
Not exactly, at least not the firewall built-in 2000 / XP / 2003 (IPSec or the Windows XP Service Pack2 firewall). These guys only talk in source and target ports. No way to tell an authenticated connection from anonymous one. What now?

3. IPSec policy. You heard right, enforce Kerberos (or any equivalent) authentication on all SMB connections. Make everyone authenticate with the Active Directory server before even accessing the port!
That’s actually a very nice solution, the only problem is that it’s a bit awkward. You need an Active Directory server, have all workstations and servers authenticate via that server, and don’t forget to manage and harden your brand new Active Directory server, otherwise you’re back in square 1.
Not to mention that this kind of system takes time to build, check and finally maintain. But, this solves NULL session on XP, 2003 and probably on any new Microsoft Windows system.

Bottom Line:
If you understand the implications if NULL session in your organization, I strongly recommend you to start thinking about how to solve, or at least minimize the problem. IPSec is by far the ‘comlpete’ solution, but it requires configuration and investment in a working authentication server. In the meantime, harden the registry where possible, and enforce good network separation between subnets.

Getting Further with Lotus Domino Password Disclosure

We recently reported a Lotus Domino vulnerability: Default Configuration Information Disclosure in Lotus Domino (Including Password Hashes). This vulnerability on its surface looks pretty harmless, but a quick investigation uncovers just how dangerous this vulnerability really is.

The advisory discusses the possibility of a Lotus Domino users’ hashed passwords being retrieved by an unauthenticated/unprivileged user where the attacker simply accesses the Lotus Domino’s “Public Address Book”. This address book not only contains the list of all users with their phone number, email, pager :P, department code, room number, etc but also their password.

The password can’t be seen unless you view the source of the page and capture the value found after the HTTPPassword variable, for example <input name=”HTTPPassword” type=”hidden” value=”(…)”>. The hashed value (Rc4) can then be broken by using the patch for John the Ripper provided at http://www.cr0.net:8040/misc/john-1.6.37-bigpatch-11.diff.gz and specifying to John that you are interested in breaking Lotus5 hashes.

The brute forcing mechanism is pretty quick, on an Intel Pentium 4 with a 2.80GHz CPU John will try around 150,000 c/s.

Using Google I was able to locate a few vulnerable sites, and crack their users password in a few seconds (some were very simple passwords: password – passpass – enter – default – 123456), demonstrating that this vulnerability is a very serious one.

Zotob.A Exploits PnP Vulnerability

A new worm has been found in the wild – Zotob.A. This new worm exploits a recently published Microsoft vulnerability. The vulnerability involves exploiting Windows’ PnP service.

This new worm is quite interesting as Microsoft released MS05-039 on August 9, 2005, an exploit for this vulnerability was released 3 days afterwards on August 12, 2005 and now a worm has been set loose, all in less than 5 days.

I think this is a new record for the “vulnerability -> patch -> exploit -> worm” cycle.

Time will tell how widespread this worm will be, you can learn more on this worm in the following post: Zotob.A.