March 27, 2010

Security Book Review: The IDA PRO Book

The IDA PRO Book
Author: Chris Eagle
Editorial: No Starch Press
Publication date: August 12, 2008
ISBN-10: 1593271786
ISBN-13: 978-1593271787


Summary: Do you really want to master the art of disassembly? Start here!

Score: 5/5

Review:
Honestly, when picking up a book that is focused on a single tool, as in this case, my main concerns are: how linked (and limited) the content is
to the tool and its capabilities, if the book can become obsolete soon with new versions of the tool, and what else the material offers to the specific field out of the tool.

In this case, it is fair to say that IDA Pro (http://www.hex-rays.com/idapro/) is the most popular disassembly tool (and debugger now) in the market during the last decade, so covering it is like going deeper into the field of malware analysis, software reverse engineer and
vulnerability research. Beginners can start playing with the evaluation version, while professionals have been using the Pro version for a long time.

Apart from that, the moment I realize Chris Eagle was the book author, it added some excitement to the mix. I know Chris when we released the Scan of the Month 32 challenge on the Honeynet Project (http://old.honeynet.org/scans/scan32/), back in 2004. The challenge was focused on analyzing a home-made malware binary, called RaDa, and Chris was the winner (http://old.honeynet.org/scans/scan32/sols/1-Chris_Eagle/); he even developed an IDA Pro script to unpack the binary and solve it.

Therefore, the book title does not make any justice to its contents :), as this is not only The IDA PRO Book or the unofficial guide, but the modern software disassembly
(static binary analysis) masterpiece and The IDA Pro Bible.

The first two chapters are a must for anyone starting in the world of reversing and disassembly. Something I really liked about the introductory chapters is how the author establishes the relationships between the different functionality available in IDA, and other (more traditional) single tools offering similar capabilities.

Then, the book goes in depth into IDA, getting started, covering the interactive interface and navigation capabilities, including the well-known and the most hidden features, explaining how to manage data types, structures and projects, the beauty of cross-references and graphs, and how to extend and customize IDA for extra advanced analysis (libraries, IDC scripts, plugins, modules, etc). It offers the advance readers the required skills and tools to move their analysis activities to the next level.

Every chapter is preceded by a great introduction explaining what is it about, and when and why this chapter is important for the analyst. Chapters do not simply move over the different menus and capabilities of IDA Pro, but describe them within a context based on the author experience after years of binary analysis, going in depth into the essence and goal of a given feature, the way to use it and the common drawbacks. Chris also uses his experience to highlight what is the most typical finding and tool output in various scenarios and why.

The book ends up with a few chapters that challenge the reader to put in action the skills learned throughout the book into real-world applications. Finally, it covers the new debugging capabilities (dynamic binary analysis) available since IDA version 4.5. For those starting in the field, appendix A points out the differences between the free and the commercial IDA version, and how these may influence your interest on specific book chapters.

The book is highly recommended to both beginners and intermediate/advanced users and professionals, and definitely it is a dense (like the tool it covers) but very easy to read book that becomes a reference in your bookshelves the minute it reaches your hands. Besides that, its contents won't easily become obsolete with new IDA Pro version. It is not a book to read in a couple of nights; this is the kind of "practical" book that I strongly recommend to read with a computer and a running copy of IDA handy, so that you can test all the tips and tricks and practice the topics being discussed.

UPDATE: Amazon review.

Labels: , ,

December 13, 2009

Assessing and Exploiting Web Applications with the open-source Samurai Web Testing Framework

This week, December 10, I participated in the first OWASP international conference cellebrated in Spain, and specifically, in Iberia. IBWAS'09, the Iberic Web Application Security Conference, by the Spanish and Portuguese OWASP chapters, promoted the need of (web) application security controls and I predict it will be the conference of reference in upcoming years in the region. It was interesting to start by listening to Bruce Schneier talking about the present and future of the information security industry.

As an active member of the Samurai-WTF project, my presentation described Samurai-WTF main purpose plus its recent additions, available from the official SVN repository. I ended up with a hacking demo to demonstrate the power of integrating multiple attack tools in a single platform for web-app pen-testing exercises:

The Samurai Web Testing Framework (WTF) is an open-source LiveCD focused on web application security testing. It includes an extensive collection of pre-installed and pre-configured top penetration testing and security analysis tools, becoming the perfect environment for assessing and exploiting web applications. The tools categorization guides the analyst through the web-app penetration testing methodology, from reconnaissance, to mapping, discovery and exploitation.
This talk describes the actively developed Samurai WTF distribution, its tool set, including the recently created Samurai WTF Firefox add-ons collection (to convert the browser in the ultimate pentesting tool), the advanced features provided by the integration of multiple attack tools, plus the new tool update capabilities.

If you are interested on the project, start by checking the "Assessing and Exploiting Web Applications with the open-source Samurai Web Testing Framework" presentation, and join the project in sourceforge.net (and the mailing list).

Become a Samurai!

Labels: ,

December 12, 2009

Hacking Challenges: Have Fun Improving Your Skills!

Last week, December 3, I was presenting an @Night event during the SANS London 2009 conference, focused on hacking challenges and how they can be used to improve your skills and knowledge while having fun:

Hacking and security challenges are a great and effective training tool. They provide a platform to improve everyone's skills by forcing all candidates to devise an offensive or defensive tactic, apply different techniques, and squeeze the available tools to succeed. The acquired knowledge can be later on applied to real-world ventures.

This interactive session will guide the audience through some scenarios associated to penetration testing and hacking challenges published over 2009. Apply your technical skills and knowledge to solve these challenges while having fun!


The interactive session was very fun and people actively participated, and performed really well, to solve a compact version of the "Prison Break" challenge in one hour. This has been the first event where we have announced the birth of a new security company, called Taddong, focused on advanced security services. More details about it in the upcoming weeks...


The presentation is available here: "Hacking Challenges: Have Fun Improving Your Skills!".

During the session, on purpose, the last portion of the challenge remained unsolved, that is... what is the input required to generate the Scylla validation code (you already know it is a hash)?

6189db841f01413a05a53b7135137a17

For those attending the session in London, I recommend you to open the presentation, review the challenge details, and try to figure out how to generate the code without using Google ;), and before reading the official solution.

Have fun! Taddong is coming...

Labels: ,

November 02, 2009

Security Book Review: Chained Exploits

Chained Exploits: Advanced Hacking Attacks from Start to Finish
Author: A. Whitaker, K. Evans, J. B. Voth
Editorial: Addison-Wesley Professional
Publication date: March 9, 2009
ISBN-10: 032149881X
ISBN-13: 978-0321498816



Summary: A multi-scenario hacking adventure novel focused on combined real-world attacks.

Score: 5/5

Review:
The penetration testing (and criminal) field has focused during the last years on increasing the foothold on compromised systems, proving advanced pivoting and post-exploitation techniques that might help to expand the compromise to other systems or critical resources. This book is a novel that describes these reality by telling hacking stories where multiple
techniques, tools and vulnerable input vectors are exploited in order to accomplish a variety of clearly defined attacks and goals.

Each chapter is a well structured story describing multiple attack scenarios. From credit card theft, to insider threat, going through corporate espionage focused on stealing confidential intellectual property, the launch of a DoS attack in a key point in time, the risk and exploitation of inter-corporation network connections, physical access to healthcare records, up to social networking and wireless break-ins.


The book is a modern fictional narrative with technical touches, covering attacks from start-to-finish in elaborated stories (my score evaluates the book from this perspective). However, by reading the book description, you might expect a deeply technical book that will teach you how to perform those attacks, and... it is not.

Every attack story is introduced by setting the stage and the overall attacker approach. Besides that, it is surrounded by a few final defensive tidbits and conclusions, describing
countermeasures to mitigate the various attacks covered. This book may act as an excellent eye opener for managers and top level positions (see recommended audience below) in order to understand how small security investments and tweaks can definitely help to increase the overall protection of a target environment substantially.

Unfortunately, from a technical perspective, some of the technical details have not been thoroughly reviewed, such as the output of nmap (order of ports), the unexplained switching of target systems from Vista to XP, the targeting of RDP while not on the port scan (chapter 4) , or the coverage of some tools. Some attacks are a bit outdated, such as the silent winpcap installation to capture traffic from a target box. However, I must admit this book inspired some of the components of a recent "Prison Break" hacking challenge I released this summer (2009).

Specific portions of the book and, overall, the story plot, is well written from a novel perspective, and as
particular attacks are progressing, it made me feel the common excitement we get when we are involved in a real penetration test and successfully progressing through the targets, getting the adrenalin going.

This book is highly recommended for people entering in the security field, and for experienced technical security pros in two ways. On the one hand, it's an enjoyable and entertaining novel for a weekend or vacation period. On the other hand, it is a very good reference to give to managers and CxO positions so that they can get a feeling of how real-world attacks look like nowadays and the kind of targeted threats they may face.

UPDATE: Amazon review.

Labels: ,

October 19, 2009

Samurai Web Testing Framework (WTF) Firefox Add-ons Collection

On June 2009 Mozilla released the add-ons collections feature on their add-ons web site. As a member and contributor to the SamuraiWTF project, I would like to announce the release of the SamuraiWTF Firefox add-ons collection!

The Samurai Web Testing Framework (WTF) is a LiveCD focused on web application testing. It contains a pre-installed collection of the top web application penetration testing tools, becoming the perfect environment for testing applications.

The goal of this Firefox collection is to include the best add-ons for web application penetration testing and offensive security analysis, to convert your browser in the ultimate pen-testing tool. It is aligned with the Samurai Web Testing Framework (WTK) LiveCD distribution. I plan to keep the collection updated with new web-app pen-testing add-ons, but I would like to carefully evaluate new additions (or replacements) so that the list doesn't grow to limits where it becomes unmanageable. It includes 19 add-ons at this time.

As of today, it seems it is not possible to install all add-ons from a collection with a single click. The current SamuraiWTF add-ons collection can be installed on the latest Firefox version, v3.5, with the exception of the "Add N Edit Cookies" add-on. Although this add-on works in Firefox 3.5.*, it cannot be directly installed. There is a quick hack you can apply to install it on Firefox 3.5 until the official version is updated by its developer:
  • Go to the "Add N Edit Cookies" add-on webpage with a compatible old Firefox version, or with a different browser like Internet Explorer, and download the add-on (XPI file).
  • Change the XPI extension on the file to ZIP.
  • Extract the "install.rdf" file from the ZIP archive.
  • Edit the "install.rdf" file and replace the following line (maximum version):
  •         <em:maxversion>3.0.*</em:maxversion>
  • by:
  •         <em:maxversion>3.5.*</em:maxversion>
  • Put (drag & drop) the new "install.rdf" file back into the ZIP archive, and it will automatically replace the old version of the file.
  • Change back the ZIP extension on the file to XPI.
  • At this point, you can install the recently modified XPI add-on in Firefox 3.5.
Once you install all the add-ons within the SamuraiWTF collection, one by one, the look and feel of your Firefox browser will notably change. I recommend you to hide the add-ons toolbars visible by default. You can individually enable them at any time, such as when you are going to use each specific add-on:
  • Go to the "View" menu and select "Toolbars".
  • Deselect "Access Me Toolbar", "Web Developer Toolbar", and (specially) "HackBar".
Finally, the "DOM Inspector" add-on has been added to the collection as it is a requirement to enable all the capabilities of the "Web Developer" add-on.

Please, take a look at the collection, feel free to share your thoughts/comments (send me an e-mail), vote for this collection if you find it useful, and enjoy it!

Labels:

October 12, 2009

Prison Break - Breaking, Entering & Decoding - Challenge Answers & Winners

The answers and winners for the EH-net "Prison Break (Breaking, Entering & Decoding)" challenge (August 2009) have been published today.

The answers for this challenge were released in scoop to The Informer subscribers a few days ago. In Johnny Long words, "The Informer is a fund raising effort run by Hackers For Charity. It is designed to give subscribers a "backstage pass" to the world of Information Security. For $54 per year, subscribers get early, exclusive access to all sorts of goodies donated by the top names in the INFOSEC world. The industry's most recognized names will post blog entries here before they even post them to their own sites." The EH-Net contribution will be the answers to the Skillz H@ck1ng Challenges a few days before they are revealed on EH-Net.

It is an honor for me to drive this initiative, with the support of Don Donzal (EH-Net) and Ed Skoudis (Challenge Master), and start posting the official answers of this challenge on The Informer.

The “Prison Break – Breaking, Entering & Decoding” challenge winners have been announced on EH-net, and the answers are contained in a single PDF file (27 pages) plus three associated screencasts:
Thanks to everybody for participating on the challenge, and to Ed and Don for the opportunity. I hope you enjoyed working on it as much as I enjoyed designing and writing it!

Labels: ,

October 09, 2009

Sqlninja & Metasploit Demo

Last week I run the "Web App Pen-Testing" SANS webcast to provide a sneak preview of the SEC542 "Web Penetration Testing and Ethical Hacking" course I will be teaching in London later this year. At the end of the webcast I run a Sqlninja & Metasploit demo over the Hacme Bank vulnerable site using the recently released sqlninja patch.

This post includes a screencast of that demo (15:40 minutes):



You can access the archived version of the full SEC542 webcast from the SANS portal. Hope to see some of you, RaDaJo readers, in London!

Labels:

September 25, 2009

Sqlninja & Metasploit

Sqlninja is one of the best open-source tools to automate SQL injection exploitation against MS SQL Server databases. If you combine it with the best open-source network penetration testing framework, Metasploit, you get an extremely powerful web application pen-testing toolkit for total database p0wnage!

This week I have been preparing a sqlninja demo focused on its integration with Metasploit for next week "Web App Pen-Testing" SANS webcast, scheduled for October 1. During the webcast I'll cover a sneak preview of the SEC542 "Web Penetration Testing and Ethical Hacking" course I will be teaching in London later this year, and run a demo using the latest publicly available sqlninja version, 0.2.3-r1, including the quick fix detailed below (0.2.3-r1p).

Sqlninja is a Perl-based tool that can make use of Metasploit capabilities to upload and run a Meterpreter or VNC server payload on the target MS SQL server through SQL injection flaws on the target web application. The integration of these tools accepts both direct and reverse TCP connections to/from the database server and the pen-tester system. It uses the "msfpayload" tool to generate the payload that will be executed on the database server (metxxxxx.exe), and the "msfcli" tool to establish (or wait for) a connection with that payload.

Due to the extensive number of modules available in Metasploit nowadays, the msfcli execution takes around 20 seconds in a BTv4 virtual machine to load the whole Metasploit module tree:

# ./msfconsole -v
Framework Version: 3.3-dev
# ./msfconsole
=[ msf v3.3-dev [core:3.3 api:1.0]
+ -- --=[ 404 exploits - 248 payloads
+ -- --=[ 21 encoders - 8 nops
=[ 188 aux
...

# time /pentest/exploits/framework3/msfcli
[*] Please wait while we load the module tree...
...
real 0m18.568s
user 0m13.402s
sys 0m4.683s
#

As a result, the current sqlninja Metasploit module may fail due to a race condition mainly on reverse mode, and specifically, due to timing issues of when the module initiating the connection(client role) executes versus the module listening for the connection (server role).

The patch released in this post fixes this race condition by adding specific (client & server) timeouts to the bind_tcp and reverse_tcp connections. The timers for the bind case try to ensure that the server (msfpayload) starts before the client (msfcli) tries to establish a connection. The timers for the reverse case try to ensure that the server (msfcli) starts before the client (msfpayload) initiates the reverse connection. The values for the timers are conservative and set a difference of 25 seconds between the server and the client initialization.

Due to the fact the reverse Metasploit payload does not retry the client connection, if the other end is not listening when the connection is initiated, the connection never succeeds and cannot be established. Additionally, I've seen the CPU of the target DB system going up to near 100% (a non-desirable DoS condition during a professional pen-test).

The patch can be applied by renaming the original 0.2.3-r1 "sqlninja" Perl file to "sqlninja.original" and running:

$ patch sqlninja.original -i sqlninja.patch -o sqlninja

The new timers ($client_delay (30 secs) and $server_delay (5 secs)), defined at the beginning of the sqlninja main file, can be changed to accommodate future Metasploit startup delays, or even be converted into sqlninja configuration options within the sqlninja.conf file. The patch changes the sqlninja version to 0.2.3-r1p, to indicate the patch has been applied.

Enjoy it, (sql) ninja pen-testers!

Labels:

July 27, 2009

Ethical Hacker Challenge: Prison Break - Breaking, Entering & Decoding

DISCLAIMER
Since our last post half a year ago, we have not forgotten, RaDaJo readers! No excuses :( It has been very hard for us to find time to publish new posts, as we have been involved in three very large projects, plus a few extra security services, during the first half of the year. We hope one of the projects becomes a relevant step towards the security of embedded devices and service provider infrastructures. It is just the beginning... "That's one small step for a man, a giant leap for mankind." The other two projects have been large, really enjoyable, and interesting penetration tests. Meanwhile, we had to deal with some presentations, training events, collaborations, new discovered vulns, ISC shifts, and small pen-tests. In the background, we have also found time to work out things like the one we present you in this new and long time awaited RaDaJo post...


A few months back, by the time I sent my submission to the "Santa Claus is Hacking to Town" challenge, Ed Skoudis gave me the opportunity to write one of his famous and always interesting security challenges. I couldn't say no ;)

As a result, a new challenge has been published on The Ethical Hacker Network. The challenge is adapted from the Prison Break TV show, and it has two main goals. On the one hand, the offensive one, improve your penetration testing skills, tool set, and force you to solve various real-world scenarios I have found along my pen-testing activities. On the other hand, the defensive one, make you think like an attacker, analyze some of the tools and offensive capabilities available today, and figure out ways to put in place countermeasures to mitigate this type of attacks.


I hope you enjoy thes new "Prison Break - Breaking, Entering & Decoding" security challenge during summer. It is ready right before BlackHat & Defcon, so you can try to solve it after the common depression following these two conferences. Go to the Ethical Hacker Network website, digest the challenge and... participate! (Submit your answer by August 31, 2009)
--
Raul Siles
www.raulsiles.com

Prison Break image obtained from “http://www.shockya.com/news/wp-content/uploads/prison_break_ver4_poster.jpg”.

Labels: ,

January 22, 2009

Penetration Testing Challenge: Santa Claus is Hacking to Town

This past holidays Ed Skoudis published one of his always interesting, amusing, and educational thematic security challenges at the Ethical Hacker Network: "Santa Claus is Hacking to Town". The last one I participated in was in mid-late 2006, although I was a huge fan of them since 2003. This time the challenge was penetration testing focused, rather than incident handling based, so I decided to play and enjoy it. Honestly, from all the security services I offer, penetration testing has taken an increasingly significant percentage of my time during the last years. There is a clear need in the industry for more pen-testers.

I suggest you to read the challenge wording and try to solve it before reading the official solution and answers. You can get some hints by reading the first paper referenced at the end of this post (Ed told me he published them there on purpose to help people out with the challenge), although it is funniest to solve it from scratch :)

You can find my submission here. I also generated (out of the contest) a second version of the paper that includes the challenge text, my official solution, and an appendix with a simpler and direct solution to the challenge, plus the reasons why it was not included as my final submission. Definitely, I could have been stealthier by providing the "-n" option to all the netcat relay instances in order to disable DNS resolution.

Complementary, my Inguardian's friends recently released two penetration testing papers you might be interested in: "Secrets of America's Top Pentesters" (Ed) and "Vista Wireless Power Tools for the Penetration Tester" (Joshua). I strongly recommend both!
--
Raul Siles
www.raulsiles.com

Labels: ,

July 08, 2007

Challenge Solution: Cracking the Password

The password challenge has come to an end, and we have a winner :) The main goal of the challenge was not to show up your brute force capabilities, but to show up your analysis skills and real-world use of common cracking tools.

First of all, thanks everybody that took the time to participate. We have received multiple submissions and enjoyed reviewing all them while going through the reasoning and procedures you follow to guess/crack the password.

In order to obtain the cleartext password from the system/application after the compromise, and provide other details about this hash, you first need to identify what type it is. You can try to guess it based on its length (24 chars) and character set used (probably a daunting task), or you can try to use tools like John the Ripper (under Unix or Windows).

Please, find below the official RaDaJo answer.

Questions & Answers:

1. What is the system or application that use this kind of password string and for what purpose?

We have found ourselves confronted against this type of hashes in several occasions during our pen-test activities, and it is used by HP-UX in Trusted System mode. HP's proprietary Unix version has always used the /etc/password file to store the user credentials, and when other Unixes started to use /etc/shadow file to avoid local access to the hashes by non-privileged users, HP implemented the Trusted System mode, where the hashes are stored in a directory structure under /tcb/files/auth, only readable by root, using multi-DES hashes. These hashes use the bigcrypt() function (versus the standard Unix DES crypt() function).

Fortunately, nowadays HP-UX also supports the usage of the standard /etc/shadow mechanism and MD5 hashes.


2. What is the format and crypto algorithm(s) used on this password string?

This type of hash uses a format similar to the standard Unix DES hashes, but it extends the hash length. The standard Unix DES hashes are implemented on the crypt() function and generate an output of 13 characters. The first two characters are a random salt used to encrypt the user password. Specifically only 6 bits from these two character are used, for a total of 12 bits, or 4096 possible combinations (2^12). The next 11 characters represent a standard Unix hash generated using the DES algorithm (25 times), taking as input: the 12-bit salt, an all-zeros input block, and the user password truncated to 8 characters and taking only 7-bits per character – this conforms the 56-bit DES key. The output, salt plus final ciphertext, is encoded into a base 64 printable string.

Therefore, in the example, "VOhRrmhZvX7lEG9KvuF/6FVA", the first portion, "VOhRrmhZvX7lE", is a standard Unix hash that corresponds to the first 8 characters of the password, where "VO" is the salt and the rest, “hRrmhZvX7lE”, is the DES generated hash.

When the bigcrypt function is used, the first two bytes of the first hash ("hR" in this case) are used as the salt for the second part of the password, so these two characters plus the remaining 11 characters conform another standard Unix DES hash, "hR + G9KvuF/6FVA". This second portion corresponds to the last 8 characters (or less) of the password. The final hash is just the concatenation of the first hash portion plus the second portion. You can get all the details on the man page for bigcrypt().

This means we really have two shorter standard Unix DES hashes to break, instead of a longer one. Is this hash format somehow familiar to you? It starts with an "L" and ends with an "M". Yes!, the Microsoft Windows LM (LANMAN) hashes use a similar algorithm, splitting the original password in two 7 bytes portions and appending the output hashes. LM even converts the original password to uppercase, but that's another story...

It seems HP designed the algorithm this way in order to make it reversible. You can easily unconvert an HP-UX system from Trusted System mode to standard Unix mode. No action is required by the administrator on the users’ passwords after converting the system, because the operating system automatically leaves just the first portion of the hash as the user password (truncated to 8 characters) after the conversion, as in any standard Unix DES system.

Theoretically, it seems there are no limits on applying this algorithm, that is, on the number of hashes you can append, although the HP-UX password man page recommends a maximum of 40 character passwords. However, it works with passwords over that limit; we tested it with a 50 character password and it generated a valid seven parts hash.


3. What is the clear-text password of your critical system? Please, detail the process you followed and the tools you used to obtain the password.

What do you think it is much more complex to guess, one number between one and one million, or two numbers between one and one thousand? If you review the math, the right response is the first one, therefore, trying to crack this password hashing schema (two 8 character passwords) is much easier than expected, that is, cracking a 16 character password.

The 14 character password from where the "VOhRrmhZvX7lEG9KvuF/6FVA" hash was derived is "winniethepooh9".

By default, John the Ripper cannot crack the two part hash even if you have the complete password in your dictionary. The reason is that it tries to crack both parts individually, so it uses the same dictionary words (starting with the first character of each word) for both parts, independently.

In order to run John against this hash successfully, you simply need to create a new file, called "password" in the examples, containing a valid Unix username/password entry, such as:

root:VOhRrmhZvX7lEG9KvuF/6FVA


If you run John with the default options, you immediately will get the following results:

$ john password
Loaded 2 password hashes with 2 different salts (Traditional DES [24/32 4K])
winnieth (root:1)

If you wait for the prompt to return back, depending on your CPU power, you can wait for hours till John finds the complete password using brute force techniques. The main hints to guess the hashing algorithm are the indications that John provides about the existence of multiple hash portions, with the "Loaded 2 password hashes with 2 different salts" message, and with the ":1" appended at the end of the username, indicating it found the first part of a hash.

With the knowledge of how the hashing algorithm works, you can create a new dictionary where you split the words that are bigger than 8 character on your dictionary, in multiple 8 character (or less) words, so that "winniethepooh" will become "winnieth" (first 8 characters) and "epooh"(remaining characters). The first word will be used and succeed breaking the first part of the hash, and the second word will be used to break the second part. Easy, isn't it? (elegance versus brute force)

This basic Perl script, "split_dict.pl", splits a dictionary file to be used against this type of hashes. It reads your dictionary file from the standard input and generates the new "splitted" dictionary on the standard output:

- On windows:

C:\>perl split_dict.pl <> password_splitted.lst

- On Unix:

$ cat password.lst | ./split_dict.pl > password_splitted.lst

Now, it is time to start auditing the strength of your HP-UX Trusted Systems passwords!

For the challenge example, John is able to provide the results immediately, without using any of its brute forcing capabilities, because "winniethepooh" is a word (apart from being a bear ;) ) included in the default John's dictionary file, called "password.lst" (nowadays, with 3107 word entries). We wanted you to solve the challenge without requiring a huge dictionary file, so we used the default one :) The single digit number at the end of the password is tried by one of the default John's rules.

Using John after processing and splitting the dictionary file, the results are:

$ john password
Loaded 2 password hashes with 2 different salts (Traditional DES [24/32 4K])
winnieth (root:1)
epooh9 (root:2)
guesses: 2 time: 0:00:00:00 100% (2) c/s: 119000 trying: tabatha9 - action9

Unfortunately, this type of hash is used in very critical environments world-wide, and breaking them is like breaking several individual traditional Unix hashes, no matter how long the password is.

Finally, John the Ripper by default cannot crack these hashes if they are bigger than 16 characters, or two-portion bigcrypt() hashes, but this doesn't mean you cannot modify John's source code to recursively apply the same algorithm on bigger hashes, using our "splitted "dictionary file.


The results:

The winner is Pieter Danhieux from Belgium. Congratulations Pieter! To win the challenge, all skills are useful, technical and social. Pieter could partially validate his technical submission by knowing some social details about our past/current professional life. I really enjoyed your submission ;) The autographed copy of Ed Skoudis' "Counter Hack" book is on your way!

An honorable mention goes to Rafael Serrada from Spain. Rafa, thanks for sending an image showing how Winnie (PEZ) finally surrendered and provided you the password :) (see below) Great job gathering most of the details!

I hope you all enjoyed this challenge and I encourage you to participate on new future RaDaJo challenges.



Labels:

May 25, 2007

Challenge: Cracking the Password

It is late at night and it has been a very tough day. You discovered early in the morning that one of your main critical systems was compromised. You found that someone accessed it with a privileged user, using a service or application that requires authentication. You wondered if there was a new 0-day vulnerability, or if someone got the password for this user? It seems the logs gave you the response, because they registered the IP address (an internal machine) from where the connection to the critical system was established. You had time to investigate that internal box, and found a file called "password" containing the following string:

VOhRrmhZvX7lEG9KvuF/6FVA

Questions:
  1. What is the system or application that use this kind of password string and for what purpose?
  2. What is the format and crypto algorithm(s) used on this password string?
  3. What is the clear-text password of your critical system? Please, detail the process you followed and the tools you used to obtain the password.

Please, submit your answers to radajo@gmail.com by June 29, 2007. The official answers and the winner (most accurate and elegant answer) will be published by the beggining of July. The winner will receive an autographed copy of Ed Skoudis' "Counter Hack" book (the classic best-seller first edition), also signed by the whole RaDaJo crew.

NOTE: Look in the comments section of this post for tips to solve this challenge. They will be published only if no successful responses are received by June 29, 2007.

Labels:

May 01, 2007

GDB hints for dancing in the stack

If, as an incident handler, you want to understand how systems are attacked, sooner or later, you will have to confront the stack. Also there is an age for script kiddies to become real hackers and the first step in that way, right after their first words in assembly language, is to understand how the stack works.

The stack is the Rosetta Stone for understanding the hidden secrets of buffer overflows and format string attacks. And it is a prerequisite for understanding heap overflows.

Fortunately for those of you that have to take that path, some really helpful documents, like the deservedly famous "Smashing The Stack For Fun And Profit", will take you by the hand through that hostile way.

However, if you want to go through some additional examples or fight against your first buffer overflow exploit with GDB, you start feeling clumsy. Running individual processor instructions and then printing the esp, ebp, and eip registers, show the contents of the top of the stack, and displaying the next instruction to be executed while singing the GDB song is, to say the least, tedious. But GDB has been designed with those tasks in mind and it includes some functionality to make our lives easier. Namely the user defined commands (a.k.a. canned sequences of commands).

The purpose of this post was to make your life easier with a couple of user defined commands that I use within GDB, but let me please remind you first that if you want to dance in the stack in recent versions of Linux there is something you need to do first. One of the countermeasures applied to reduce the effectiveness of memory attacks (buffer overflows, format strings, and heap overflows) is to introduce some amount of randomization in the virtual addresses every time a program is run, so it becomes harder to predict the right address to jump to.

To disable this feature you just have to (as root):
echo 0 > /proc/sys/kernel/randomize_va_space
Having done that, you have your stack ready to dance, so let's go back to the GDB user defined commands.

The first thing you need to know about the GDB user defined commands is that they should be stored in your .gdbinit file that can be either in your home directory (if you want GDB to process it before the command line options) or in the current working directory (allowing you to have different .gdbinit files for different projects).

In order to avoid the tedious routine that I mentioned before, the most useful thing that a defined command can do is show you the contents of the stack. This can be achieved with the following command:
define stack
info reg ebp esp eip
echo * -- Stack -- *\n
if $argc == 0
x/16w $esp-16
end
if $argc == 1
x/$arg0w $esp-16
end
echo * -- Stack -- *\n
echo Next instruction:\
x/i $eip
end

This newly defined stack command does all these tasks:

  • Print the registers ebp (base or frame pointer), esp (stack pointer), and eip (instruction pointer).
  • Print a string to show the beginning of the stack information.
  • If it is invoked with no arguments it prints twelve words of the top stack (32 bits each) preceded by 4 words that aren't part of the stack. If an argument is provided it is used as the number of total words. Notice that in any case, the top of the stack will be located at the beginning of your 2 line of stack information.
  • Print a string to show the end of the stack information.
  • Show the next processor instruction in assembly language.
Since this is usually done after having run one processor instruction with si or ni, it would also be interesting to have a modified version of those instructions that run the instruction and print the desired information. I will call these commands sis (step instruction and stack) and nis (next instruction and stack) and they are defined with this code:
define sis
si
stack 20
end
define nis
ni
stack 20
end

I hope that with these three new commands for GDB it will be easier for you to play with the stack. Enjoy!

Labels:

March 31, 2007

Common Misconceptions About ARP Cache Poisoning

In this article I comment on a few misconceptions about ARP cache poisoning that I come across from time to time, even from people who know what ARP cache poisoning is and (more or less) how it works.

If you don't know what ARP cache poisoning is, this article won't help you. A good place to start may be this article by Steve Gibson or this other article by Yuri Volobuev , more advanced and which includes the source code for send_arp (send_arp.c), a tool I'll be naming below.

*** DISCLAIMER ***
If you perform an attack based on the information contained in this article it will be your sole responsibility. Make sure you have appropriate authorization before doing anything that might get you into trouble and please understand that manipulating network traffic is something that can get you into trouble. You've been warned.
*** END OF DISCLAIMER ***

So, on to the misconceptions:


  1. You need very advanced and complicated tools to perform ARP cache poisoning

  2. ARP cache poisoning only works against hosts of specific operating systems (OS)

  3. You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.

  4. An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN

  5. Some switches hung when you send one of those fake ARP replies through


1.- You need very advanced and complicated tools to perform ARP cache poisoning

It depends on what you mean by advanced and complicated. All you need is a simple tool capable of sending ARP replies that let you choose the source and destination IP addresses and MAC addresses. My favorite is "send_arp", the source code of which you can find in this article by Yuri Volobuev . You invoke send_arp like this:

send_arp IP1 MAC1 IP2 MAC2

That command will send a single ARP reply stating "IP1 is at MAC1" targeted at system with IP address IP2 and MAC address MAC2.

The rest will depend on what you want to do. If you want the traffic to flow through your box you will need to enable IP forwarding in it. In Linux this can be done with the following command:

echo "1" > /proc/sys/net/ipv4/ip_forward

If you want to sniff the redirected traffic you will obviously need a sniffer (e.g. WireShark or tcpdump), and so on for the different things you want to do, but strictly speaking, for the "ARP cache poisoning" part, you really don't need anything other than send_arp.

2.- ARP cache poisoning only works against hosts of specific operating systems (OS).

Maybe, but I still have to find one OS which it doesn't work against :-). Per the ARP protocol specification itself a host must accept ARP replies at some point or another. The only exception is hosts where ARP is deactivated and static MAC-to-IP translations are used. Those hosts are protected against ARP cache poisoning, but of course they are a pain in the neck to manage, so not many people use it in the real world.

A palliative solution implemented on some OS (I believe this is the case at least in Solaris) is ignoring gratuitious ARP replies, meaning that the host will only accept ARP replies for queries it previously sent. That certainly makes the life of the attacker harder, but just a little bit. It's a race condition: when the system sends an ARP request it will accept the first reply to come back. If the reply from the attacker comes faster than that from the real host it will be accepted. Of course the attacker may improve his/her chances by continuously sending replies till one gets lucky. Once the "poisoned" translation is in the ARP cache it will stay there, undisturbed :-), until it times out and a new ARP query is sent (default is 10 min in Solaris, IIRC).

3.- You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.

Well, yes and no. It's true that ARP cache poisoning is a LAN only thing, so only hosts on the same LAN of the attacker can be poisoned, but routers are also "hosts" in this context: they too can be ARP-cache-poisoned. In general, any traffic exchanged between two MAC addresses in the LAN can be redirected through the attacker's system. The case of two local hosts talking to each other is the most obvious, but an attacker can also sniff traffic going from HOST1 to some system outside the LAN by convincing HOST1 that the MAC address of its default router is that of the attacker's system and convincing the default router that the MAC address of HOST1 is that of the attacker's.

4.- An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN.

Not true. If the attacker disrupts any communication it will be their own fault (or intent), not the technique's per se.

Quite often the problem is that people performing the attack forget to turn on IP forwarding on their system and then all traffic that should go _through_ their system ends up being _absorbed_ by it and yes, all communication between the poisoned systems becomes impossible and people won't appreciate it (been there, done that :-/). Worse, if you choose to poison every system on the LAN and you make a mistake like this forgetting to enable IP forwarding you will get nothing less than total chaos (again, not proud of it, but been there, done that :-/ ).

A final word of caution about automated tools, if you let me. If you're going to use them, make sure you know them well. Some automated tools may poison all systems in the LAN by default and then forget to turn on IP forwarding, or do the forwarding themselves just fine at the beginning but then die miserably half way through... and it's not pretty. I've been burnt before and thus I prefer to use good old send_arp to send just the few ARP packets I need and good old Linux kernel for IP forwarding. Call me chicken...

5.- Some switches hung when you send one of those fake ARP replies through.

Well, I can't say I've tried every switch out there so maybe there's some switch that will die if you try to do ARP cache poisoning through it. Yet, chances are that if that happens the reason be that the ARP reply being sent wasn't the right one.

Here is the thing. As long as all the fake ARP replies the attacker sends always say "whatever_IP is at my_real_MAC" (my_real_MAC being the real MAC address of the attacker's system) the switch should never complain. As far as he is concerned those replies match what he knows about the attacker's system: its MAC address (my_real_MAC) is connected to the port it is really connected to. Note that the switch doesn't care about IP addresses so the IP addresses in the ARP reply are simply ignored by it.

However, the attacker may get into trouble if he/she tries to revert the wrongdoing after being finished with the attack by sending a gratuitious ARP reply to the target system containing this time the real IP-to-MAC translation instead of the poisoned one. That will confuse the switch because this packet will mean to it that the MAC address of the spoofed system is connected to your port, but that MAC was already connected to some other port!. That will leave the switch with a duplicate entry on its MAC-to-port translation table (one MAC in two different ports). Different switches will react differently to this anomaly, but none will be "happy" with it, if you know what I mean ;-).

David.

Labels:

January 14, 2007

The Beauty and the Beast

The Chaos Computer Club (CCC) is a very well known European hacker team. And their last congress, that took place last December in Berlin, has provided us with a lot of interesting material that is worth viewing.

The paper that attracted me the most was one about AJAX, that could be previously found here (this one doesn't work now) and it is still available from here. The name of the paper was Subverting AJAX and is written by Stefano di Paola and Giorgio Fedon. They talk about a very powerful technique to attack an AJAX application that they call XSS Prototype Hijacking. Believe me, there is beauty in this attack.

Prototype Hijacking consists in overwriting the methods of the XMLHttpRequest object, that is the one that takes care of the asynchronous communications with the server, actually intercepting the calls to those methods and, thus, being able to do things such as reading all the private information before it is encrypted by the TLS layer or replacing the information that is send. This is new but the results are similar to the DLL injection: the attacker becomes a dangerous beast.

In order to overwrite the methods, they use Cross-Site Scripting (XSS) and even explain some advanced techniques to do so. The basic idea is quite simple though: you force the application to run the code that is needed to overwrite the methods.

This is quite powerful, let me give you a couple of examples where this attack could be used:
  • A webmail application that doesn't control the contents of each mail to filter out XSS attacks. With the overwritten methods every communication with server can be eavesdropped (that means having access to every mail received or sent).
  • An Internet shop, preferably one that allows its users to review the products. Payment information can be intercepted and used on line.
My recommendation: try this and keep it in your pentest toolbox.

Labels: