Tag Archives: penetration test

Pivot Mercilessly!

Posted by Jon Janego on March 17, 2010 No comments

I just returned from a great trip to SANS 2010, in Orlando, where I was taking SEC 560 – Penetration Testing.  Our instructor, Ed Skoudis (an amazing guy, by the way), repeatedly hammered into our brains the mantra “Pivot Mercilessly!”

This concept is something that a penetration tester or vulnerability assessor needs to always keep in mind – look for the easy toehold into a system, and then see where you can go from there.  “Pivot” throughout the environment using the weak link as a starting point.

I was performing an assessment recently on a Solaris system that demonstrated this concept very effectively.  One of the boxes was vulnerable to a relatively old telnet vulnerability , which we exploited with pleasure – granting us root access to the machine.  From there, we examined the trust relationships inside the network and noticed that this box had “r service” trust relationships set up with many other machines in the network.  So, we used rsh to connect to numerous other boxes, all with root level access, and from those boxes to others… quickly we had the entire system PWNED.

All of this was made possible by a single box with one weak spot.  This is likely the case with most systems out there – maybe you’ll have one or two boxes vulnerable to exploits, especially in a well-managed corporate network.  From there, it’s up to you to pivot your way through the rest of the system!

An Introduction to Protocol Fuzzing

Posted by Ben Hagen on December 30, 2008 No comments

I have been considering running a basic level of protocol fuzzing on some known/unknown services for some recent projects. These are mostly penetration tests, but with particularly locked down or limited points of entry. I look at fuzzing as a way to both demonstrate more value in the penetration test and to potentially find new holes in an environment where known vulnerabilities don’t work or don’t exist.

“Fuzz testing” or “Fuzzing” is the process of taking an expected input or output and mux’ing it up with unexpected data. It began as a software testing method, but is now commonly used to detect potential security problems. It’s easiest to understand protocol fuzzing when testing Web applications:

In a typical web application login process you submit a username and password over the network. Fuzzing this communication would likely involve replacing a normal username/password pair with random data of random (and often long) lengths, but might also involve changing other HTTP response data.

The goal is to discover checks in the services programming which don’t parse the data they receive correctly. Under typical expected conditions they work fine, but in the process of fuzzing you try and discover conditions under which they do not work fine. These can lead to the discovery of new buffer overflows, cross site scripting, and other vulnerabilities.

There are a lot of fuzzing tools and frameworks out there, most of them targeting the web application space (I’ll be dedicating a later post to these). Here are a few which can be used in arbitrary protocol fuzzing:

  • ProxyFuzz – A python based proxy which will will randomly change the contents of either side of a communication stream.
  • Taof – A python based GUI proxy with a somewhat easy to use interface to select which parts of a communication are fuzzed. It can also bind itself to a locally running process to better determine when a process is having issues with fuzzed data.

There are many advantages to fuzzing:

  • You can discover interesting vulnerabilities without having a clear understanding of a protocol
  • Fuzzing can operate at all levels of the OSI model. Most fuzzers are built at the application, network, and transport levels, but fuzzing principles can work on any level.
  • Applicable to both the server and client ends of a protocol.
  • Many of the vulnerabilities discovered through fuzzing are buffer overflows and can lead to the execution of arbitrary machine code.

And several disadvantages:

  • If you don’t have much knowledge of the protocol structure, it becomes a more or less a brute-force approach.
  • Encrypted protocols are difficult to fuzz. Most fuzzer’s operate as intermediary or proxy applications and would need to either decrypt communications on the fly or have the client program’s cooperation in mux’ing the traffic.
  • As an automated method of attack, there is often a lot of work involved in finding out what exactly went wrong when an anomaly is detected and how to exploit it in a controlled manner.

Fuzzing is a big topic and an area I’ll be exploring more later.