When Ax1024 isn’t enough

Recently, h07 published a vulnerability in Easy File Sharing FTP Server. Apparently a simple buffer overflow in the PASS command. This vulnerability is a nice example where fuzzing won’t cut it.

But the catch in the vulnerability is a comma. Only passwords starting with a comma (0x2c) can be overflowed. Why is this so important?

A fuzzer will usually take a legal FTP session, and will try to overflow interesting sections. The password field is a prime candidate, but the problem is, if you test for a simple overflow you’ll just send many ‘A’ characters or something similar. This is because fuzzers tend to look for the coin under the street-light.

Fuzzers today are sophisticated enough to look for many different types of programmer errors, but will usually look for the poster-child of each. For example, to find a format string, just send many %x. This is not done due to programmer lazyness, this is due to the sheer amount of possibilities to check. FTP is a relatively simple protocol, but with vendor extensions it has dozens of commands. Checking every command for vulnerabilities could take a long time, and with network considirations we’re talking weeks and months of continous bombardment on the target server.


Plain life is just not random enough

While trying to generate a gpg keypair on a remote server, I discovered I lack entropy. Eventually I had to physically type on the keyboard in order to generate enough random bytes.
A short research led me to the following startling thread in the Linux kernel mailing list; Someone suggested to disable the entropy gathering from network cards: http://marc.theaimsgroup.com/?l=linux-kernel&m=114684809230875&w=2
* Note that in stock kernel version, entropy is still gathered from network cards.

I see this as an extremely bad move. ‘Headless’ servers with no keyboard and mouse have very few ways to create random entropy.
Web servers are an extreme example. There are few disk events that can contribute to the amount of entropy, and on the other hand SSL connection requires a lot of randomness.

This decision, if indeed accepted, is completely absurd. If someone decides to cancel network card as a source to random number generation, at least leave it as an option to the kernel module, a /proc entry or something. Why just diff it out??

To make things worse, Intel used to provide an onboard random number generator. This initiative was torpedoed, and the chip no longer exists in modern boards. There goes another source of random entropy out the window.

Modern day servers requires more sources of entropy than ever. We use VPNs, SSH and HTTPS. Let’s face it, SSL is ubiquitous.

As an example, try to run 4 simultaneous ssh connections to a dedicated web server (for some time, at least 4-5 hours), and try to generate a GPG keypair. 9 out of 10 times you’ll be out of entropy.

Suggested solutions like gathering entropy from the sound card don’t cut it for production servers.
There are the of course the dedicated PCI cards: http://www.broadcom.com/collateral/pb/5802-PB05-R.pdf

But then we could also ask for a Schrödinger’s cat that sits in a conveniently located alternate universe to establish SSL handshakes for us.

Attacks on PRNGs are well documented. Today no one believes that clock interrupts are cryptographically random. For example, look at: http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf

I would love to hear your opinions and suggestions from security point of view.

Skype – The new NMAP?

In Blackhat Europe 2006 Philippe BIONDI presented his work on Skype.
Skype is famous for the level of obscurity taken to protect the code and protocol from prying eyes.

This outstanding work unveils Skype’s inner workings, reverse engineering the application and the network protocol and provides code samples.

The author poses and later answers three questions:

  1. Is Skype a backdoor?
  2. Can one detect and block Skype traffic?
  3. Is Skype safe enough for Business use?

Several security related issues are brought to light:

  • Several heap overflows were found during the research.
  • Skype can be DoSed by a single packet
  • Skype can be abused as anything from a port scanner to a botnet and covert channels in P2P

For the rest of this excellent work get the full paper at:

Account Hijackings Force LiveJournal Changes

Cross site scripting vulnerability allowed attackers to steal LiveJournal’s user cookies. This sounds like the normal scenario that gets no attention from anyone, only this time attackers used this vulnerability to steal tens of thousands of accounts.
This incident forced LiveJournal to replace their logging mechanism.
Just to show large scale phishing isn’t limited to banking and credit cards.


No more **** passwords?

A nice solution built by MERL to prevent shoulder surfing is to display a flickering picture and provide glasses that would be able to filter out these flickers resulting in a dual image:

This means that the display that can only be viewed with magic glasses.

Although the solution is simple, you can use this to “encrypt/hide” data quite well – i.e. show someone one picture while the person with the special glasses sees another one.

The only draw back is that the glasses need to be wired to the screen, making the solution not very portable.

This would also give a whole new meaning to “I can’t work today as forgot my glasses at home” :-)

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.


If you attended Blackhat Briefings 2005 you might missed it, but there are 20 or so pages missing in your Blackhat book. This video shows why.

Calling Cisco’s reaction ‘aggressive’ gets a whole new meaning after watching the movie. Cisco, with the aid of Blackhat organizers, tore Lynn’s slides from the Blackhat Briefings book to protect their precious secret.
Didn’t help much though – as expected, the original slides are mirrored all over the web, and the problem blew up in their face.
Cisco actually requested Lynn to wait a year (!) before releasing the details of the vulnerability.

It took Lynn one month to discover how the vulnerability can be fully exploited. While I’m not underestimating Lynn’s skills, his work was mostly based on FX’s discoveries. I think we all learned that ‘silent’ bug fixes are never silent.