10 April 2009

In this post we will go through the steps to create a VBA (Visual Basic for Applications) payload using Metasploit Framework and stick that into a Microsoft Office Word 2003 document. When the target users open up the document we will get a command line prompt. The process is divided in four parts.

Part3 - Wrap bait into Office Word documenta. First, we need to copy the contents of file win.sh_rev_tcp.1.108-5000.txt, generated in Part1 over to our Windows machine. Having a web server at the Linux site is always handly, we just opening up Firefox and pointing to http://192.168.1.108/win.sh_rev_tcp.1.108-5000.txtb. Now, create a new MS Office Word 2003 document, named it StaffSalaries2009.doc.c. Open the new document, go to Tools | Macro | Visual Basic Editord. On the left hand side, double click on the ThisDocument icon, the area where you should paste the code will popup in the middle of the screene. Paste the code from win.sh_rev_tcp.1.108-5000.txtf. Save the script into the document by clicking the Save icon at the toolbar, do File | Close and Return to Microsoft Wordg. Add some data to your fishie document so to look genuine, Save and Exith. Distribute the document and hold back

* The above also apply for Office Excel documents, however please note that the generated Visual Basic code should be saved into ThisWorkbook item instead of ThisDocument, as per instruction d.

Part4 - Distribution etcHaving done all these, you can send the file as an attachment or save to a shared area where your victims can spot it and fire it up, if their Macro Security (Tools | Macro | Security... ) level is set to low your goal will be achieved instantly. In any other case the users will get a friendly message telling them "The macros in this project are disabled. Please refer to the online help or documentation of the host application to determine how to enable macros." with an OK and Help button, pressing the Help button tells them exactly where to click so to enable macros.

According to Wikipedia on April 6th 2007, GAIM's project development team changed the name of the popular IM to Pidgin, as a result of their settlement with AOL and latter's trademarked acronym AIM. So we downloaded Pidgin's latest version 2.5.5 and installed it in our VMware Windows box. We happily added our demo username and password (for our test it does not matter if you tick the box saying remember password, or not, as there is no change in the result of our experiment). Then we dumped Pidgin's process memory, saved it to a file in our Samba share, the file consumed about 50MB of space. From there, using the strings command we searched for sequences of printable characters; by grep-ing for our set password we found three instances of it in different places (all of them of course in plaintext).

We changed our account password a few times and repeated the process again and again, last we concluded that: 1. every time the password was stored three times in the process memory 2. one of the locations is very easily spotted in the dump (if you view the file with a Hex editor you will see that there is always a large block of random data then the string =p&=, then some random numbers (which they do not always appear) and finally our password). As you understand even if you do not know the secret password you can find it by trial and error in just a few tries.

I guess that other IM clients is very likely to store your passwords amongst other information in clear. I can not tell you do not use program X or program Y because they do not properly encrypt your passwords or do not scrub the memory, but I can advise you to take under serious consideration which ones you do use at home and work, and think how much exposed you are.

6 April 2009

It was around 2003-2004 years when one day I started playing with the way popular Instant Messengers (IM) clients store user's sensitive information in RAM. I was fan of the opensource Gaim IM, so that was my first nominate.

The procedure I had followed was as follows: 1. Installed Gaim on a Windows box 2. Logged in with a fake MSN account 3. Dump the memory contents of a running process to a file using the PMDump by Arne Vidstrom from ntsecurity group. 4. Opened up the file with a Hex editor and presto the password was there in plaintext, I think it was found in two different places.

Doing a little of search with Google, you can find more memory content extractors, see:APsoft's memdump - this tool gets you the whole system memoryMetasploit's MemDump - added a few months, offers similar functionalities as the tool PMDumpMicrosoft's userdump - generates a user dump of a process by shutting it down, by throwing an exception or by making it stop responding, yes it is a bit aggressive.

Later found, that this is a very common bad-practice, followed by software developers who accidentally or unknowingly fail to scrub the password from a memory buffer after authentication, and sadly many software applications fall to this category; to name a few but not limited to these see PuTTY v0.53b, ActivCard, standalone Flash programs and other IMs.

I think it worths noting here that the problem is even bigger with applications that store user's credentials permanently on the physical disk in unencrypted form, see for exampe the recent Intel BIOS Disclosure and regular security posts regarding web server traversals which may result in arbitrary file access.

Now 5 years or so later, I have decided to repeat the experiment and see if things have changed since then, will blog-post the findings soon.

1 April 2009

Ok folks, I assume all of you have heard about the Microsoft Internet Explorer Uninitialized Memory Remote Code Execution Vulnerability also known as ms09-022 which has been published on Feb 10 2009. This vulnerability allows remote attackers to execute arbitrary code on Windows systems that are running IE7, the range of the affected systems varies from WinXP SP2 up to Win2K8 (the Server Core installation option is not affected) releases.

As in many classic client-side attacks, end user's interaction is vital so to take control of his system and all our victim needs to do is visit the malicious page. The specific flaw exists in the handling of document objects. In particular, when an object is appended and deleted in a specific order, memory corruption occurs; successful exploitation leads to remote compromise of the affected system under the credentials of the currently logged in user.

Some of you may have already played with it extensively in your labs or in real environments as metasploit, Core Impact, Immunity CANVAS and other frameworks have included this exploit since the early days of its disclosure, however, some others may have difficulties with this one. Ok, enough with the theory, the guys from TippingPoint and the Zero Day Initiative who discovered the vulnerability did the hard work for us, and now have left us to experiment with our creativity. The exploit looks like the code below, the only thing you need to add is the payload in URL encoding scheme which easily can be generated using msfpayload from metasploit framework:

Then save the page in html, prepare your netcat listener on port 4444 and trick your victim to open the html file. If you prefare, you can always use more advanced payloads such as meterpreter, in addition, if you target more than one users you should consider using the multi/handler module.

Depending on the type of attack we are performing, ie targeted (T) or non-targeted (NT), we can try the following phishie methods against our targets:

Send an email to the victim asking to visit a link.

Send an email to the victim having the malicious file attached into.

Leave near the company a couple of USB pendrives loaded with your juicy files, a VBA macro embedded in a MSOffice Word document, a trapped PDF file, a single HTML page that triggers an known vulnerability the list can easily go on.

If company's employees are using social networks you can join the group, create a good fictitious scenario and ask them to visit your link.

If you have access to an open shared directory you can leave your file there, give it a nice attractive name, or masquerade its icons, or merge the file into another naive file.

For those cases where you have to distribute your malicious files via a link, you can:

Host your files on your own machine

Host the files into an already compromised box

Use TinyURL to soft-hide destinations of the link from unsuspecting users

Use an online file hosting provider such as RapidShare

If in a LAN environment, you can create a UNC shortcut which points to your files in the web.

If you know their mobile numbers you can always text them the link, or using some social engineering you can pretend that you are one of their colleagues who has just changed mobile number and you just asking the victim to check fileXYZ which is located in their open shared directory if it loads OK blah blah...you get the idea.

Read the book "The Art of Deception" to get an idea how the users can be tricked and understand the saying "your weakest link is the human factor".