Fun with NTVDM

The other day I discovered by accident that you can actually execute plain text files (or any file with arbitrary binary content for that matter) in Windows or, more exactly, in the 16-bit MS-DOS subsystem provided by the system file NTVDM.exe in 32bit Windows systems. I assumed Windows would check the magic number (first bytes) of a file before executing it, to make sure it is an executable before actually executing it but it seems this is not the case: it will happily interpret as binary code any file, be it a real executable or not.

Not that this piece of knowledge is particularly useful (you don't want to execute ASCII files anyway) but I had some fun with it and it may save you some time if you can recognize the error messages. The bottom line is: if you're trying to execute what you think is an executable and you're getting weird error messages, consider the possibility that what you are executing is not an executable after all.

Anyway, this is the story. I had been given a .EXE file that was supposed to be a malicious program for Windows. I copied it over to a lab Windows machine and tried to execute it, first by double-clicking its icon in Windows Explorer and then by invoking it from a command prompt window (cmd.exe), with identical result: an error message like the one shown in the following picture.


NTVDM (NT Virtual DOS Machine) is a process that "simulates a 16-bit Windows environment complete with all of the DLLs called by 16-bit Windows applications". That's how 16 bit Windows/DOS applications are run in modern (32/64 bit) Windows releases.

OK, but why the illegal instruction? It turns out the file was the wrong file. Actually, it was a copy of a simple ASCII text file, renamed to .EXE by mistake, and yet the system had tried to interpret it as a real EXE file. No wonder it found an illegal instruction! However, depending on the contents of the ASCII file the result might have been different.

Then, just for fun, I tried the following. I created a few simple ASCII files using notepad.exe, each containing just one word (not even a carriage return) and I named each file by the word it contained and I added the extension ".exe" to all of them. Like this:
---
C:\test>type Hello.exe
Hello
C:\test>type David.exe
David
C:\test>type Raul.exe
Raul
C:\test>type Jorge.exe
Jorge
C:\test>type Problem.exe
Problem
C:\test>
---

Then I executed them, with a variety of results:
---
C:\test>Hello.exe
[NOTE: Pop-up error message like the one shown above (illegal instruction)]
C:\test>David.exe

C:\test>Raul.exe

[NOTE: For David.exe and Raul.exe, no output, just a carriage return and the prompt again]
C:\test>Jorge.exe

Divide overflow

C:\test>Problem.exe
[NOTE: Here the command prompt window freezes]
---

David.

Podcasting: Radio Killed the Reading Star

It's seems pretty obvious that lack of time is one of the key factors in today's society. This becomes really critical in a profession like ours, information security.

What tools or methods do you use to keep your security knowledge and skills up to date? Just to name a few, I (try to) read lots of articles and whitepapers, a few books per year, I'm subscribed to several mailing-lists, I like to review the security conferences presentations and videos, I'm also subscribed to several Blogs (I'll cover this in a future post), I'm a frequent visitor of specific Web pages, I'm author and reviewer of security training material..., but, to sum up, all these activities require reading from (or watching at) a traditional piece of paper or my laptop screen, therefore, they require spare time. Conclusion: I don't have enough time to do it as much as I'd like!

Fortunately enough, some time ago I discovered podcasts (or the offline e-radio), but it really was a year ago when I got hooked on podcasts, almost at the same time the first episode of Pauldotcom Security Weekly saw the light. The main advantage of the audio format is that you can listen it using your MP3 player anytime, anywhere, such as when commuting, shopping, walking or waiting... . The following is the current list (in no specific order) of security podcasts I currently listen to in a weekly basis:

• Pauldotcom Security Weekly
• Cyberspeak
• Blue Box: The VoIP Security Podcast
  
• Crypto-Gram Security Podcast
• The Security Roundtable
  
• Security Now!
  

I specially like the most technical ones. In order to select your favourite security podcats list (everyone has their own), I strongly recommned listen to 2-3 episodes and judge them by yourself, mainly based on your current preferences and needs.

If you're a security podcast listener, what are your favourite ones? I encourage you to share your podcasts (or any other innovative "information gathering method") with the RaDaJo community by writting a comment to this post. Thanks!

The Origin of Vulnerabilities

One of the most common tasks when doing penetration testing is enumeration. Enumeration consists in making queries to a system in order to obtain information about its user names or other resources that can be used as targets in the process. It is usually easier to get access to a system or application with a valid user than with a sophisticated exploit.
The canonical way to enumerate users in a UNIX system was to use finger, but if sendmail was running in the system it is far more popular to use the SMTP commands VRFY (verify) and EXPN (expand) together with a dictionary of user names. Both commands will confirm or deny the existence of a user account with the provided name.
If a web application is one of the targets in the penetration test, enumeration is done in a different way because its users aren't the same as the system users. Many of those web applications have a sign up page that allow the user to subscribe in order to get access to the service. Some of those applications allow the user to select a user name, which has to be verified to confirm that no other user exists with that name already. That verification can be used to enumerate users using the same user name dictionary used with the sendmail commands.
In a traditional web app the user name will be verified when the user has filled up the form and pressed the submit button. Additionally those applications that want to avoid automatic user registration, like email accounts, use a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) that requires the user to introduce some letters that are displayed in distorted image. If there is no CAPTCHA then each user can be verified sending the required HTTP request with the username. Some AJAX web applications make this process even easier. As in the alternative offered by the web programmer guru Reuven M. Lerner in his ATF October 2006 column, if an asynchronous request is done to verify the user before allowing him to submit the data, the same URL can be used to enumerate the users. The solution to both cases is to use the CAPTCHA for the verification also, instead of using it only for the registration. If the CAPTCHA is not solved the server refuses to verify the user.
Another attack that can be avoided using a CAPTCHA is the brute forcing of web applications. If an attacker is trying to obtain access to a web application that uses known email accounts as user names or whose users have already been enumerated, one possible next step is to perform a brute force attack. If the application doesn't have a mechanism to restrict the maximum number of attempts, then the attacker will be able to use a dictionary to guess the password. Most modern systems (Linux, Windows 2003, ...) have some kind of restriction in the number of attempts, such as blocking the account temporary or indefinitely. However, this philosophy hasn't been applied to many web applications yet. There are some exceptions, though. Gmail does a good job at avoiding brute force attacks using CAPTCHAS after some unsuccessful attempts.
If you have done penetration testing for a while now, you might be thinking that those vulnerabilities are old and you would be right. But the fact is that these vulnerabilities have evolved to persist in a new environment. They are probably the stronger vulnerabilities because they can survive in every environment with an effective disguise that makes them invisible to its natural predator, the programmer.