Which of These Scripting Languages Is More Appropriate for Pen-Testing

Which of these scripting languages is more appropriate for pen-testing?

You probably want Ruby, because it's the native language for Metasploit, which is the de facto standard open source penetration testing framework. Ruby's going to give you:

• Metasploit's framework, opcode and shellcode databases
• Metasploit's Ruby lorcon bindings for raw 802.11 work.
• Metasploit's KARMA bindings for 802.11 clientside redirection.
• Libcurl and net/http for web tool writing.
• EventMachine for web proxy and fuzzing work (or RFuzz, which extends the well-known Mongrel webserver).
• Metasm for shellcode generation.
• Distorm for x86 disassembly.
• BinData for binary file format fuzzing.

Second place here goes to Python. There are more pentesting libraries available in Python than in Ruby (but not enough to offset Metasploit). Commercial tools tend to support Python as well --- if you're an Immunity CANVAS or CORE Impact customer, you want Python. Python gives you:

• Twisted for network access.
• PaiMei for program tracing and programmable debugging.
• CANVAS and Impact support.
• Dornseif's firewire libraries for remote debugging.
• Ready integration with WinDbg for remote Windows kernel debugging (there's still no good answer in Ruby for kernel debugging, which is why I still occasionally use Python).
• Peach Fuzzer and Sully for fuzzing.
• SpikeProxy for web penetration testing (also, OWASP Pantera).

Unsurprisingly, a lot of web work uses Java tools. The de facto standard web pentest tool is Burp Suite, which is a Java swing app. Both Ruby and Python have Java variants you can use to get access to tools like that. Also, both Ruby and Python offer:

• Direct integration with libpcap for raw packet work.
• OpenSSL bindings for crypto.
• IDA Pro extensions.
• Mature (or at least reasonable) C foreign function interfaces for API access.
• WxWindows for UI work, and decent web stacks for web UIs.

You're not going to go wrong with either language, though for mainstream pentest work, Metasploit probably edges out all the Python benefits, and at present, for x86 reversing work, Python's superior debugging interfaces edge out all the Ruby benefits.

Also: it's 2008. They're not "scripting languages". They're programming languages. ;)

Is Python or Ruby good for penetration testing?

Any language that has good, easy string handling capabilities is a good match for penetration testing. This is why you see scripting languages as the most used languages in this sort of tasks.

To answer your question, they're just as good.

Which part of python do I need to master for penetration testing and security

Agree with the other commenters that this is an overly broad question and a duplicate of https://security.stackexchange.com/questions/15705/using-python-for-security, but the best security-related python book i've read is Grey Hat Python. I'd spend a lot of time reading OSS code, and playing with projects like Volatility, W3AF, and Scapy.

Penetration testing tools

There are a couple different directions you can go with automated testing tools for web applications.

First, there are the commercial web scanners, of which HP WebInspect and Rational AppScan are the two most popular. These are "all-in-one", "fire-and-forget" tools that you download and install on an internal Windows desktop and then give a URL to spider your site, scan for well-known vulnerabilities (ie, the things that have hit Bugtraq), and probe for cross-site scripting and SQL injection vulnerabilities.

Second, there are the source-code scanning tools, of which Coverity and Fortify are probably the two best known. These are tools you install on a developer's desktop to process your Java or C# source code and look for well-known patterns of insecure code, like poor input validation.

Finally, there are the penetration test tools. By far the most popular web app penetration testing tool among security professionals is Burp Suite, which you can find at http://www.portswigger.net/proxy. Others include Spike Proxy and OWASP WebScarab. Again, you'll install this on an internal Windows desktop. It will run as an HTTP proxy, and you'll point your browser at it. You'll use your applications as a normal user would, while it records your actions. You can then go back to each individual page or HTTP action and probe it for security problems.

In a complex environment, and especially if you're considering anything DIY, I strongly recommend the penetration testing tools. Here's why:

Commercial web scanners provide a lot of "breadth", along with excellent reporting. However:

• They tend to miss things, because every application is different.

• They're expensive (WebInspect starts in the 10's of thousands).

• You're paying for stuff you don't need (like databases of known bad CGIs from the '90s).

• They're hard to customize.

• They can produce noisy results.

Source code scanners are more thorough than web scanners. However:

• They're even more expensive than the web scanners.

• They require source code to operate.

• To be effective, they often require you to annotate your source code (for instance, to pick out input pathways).

• They have a tendency to produce false positives.

Both commercial scanners and source code scanners have a bad habit of becoming shelfware. Worse, even if they work, their cost is comparable to getting 1 or 2 entire applications audited by a consultancy; if you trust your consultants, you're guaranteed to get better results from them than from the tools.

Penetration testing tools have downsides too:

• They're much harder to use than fire-and-forget commercial scanners.

• They assume some expertise in web application vulnerabilities --- you have to know what you're looking for.

• They produce little or no formal reporting.

On the other hand:

• They're much, much cheaper --- the best of the lot, Burp Suite, costs only 99EU, and has a free version.

• They're easy to customize and add to a testing workflow.

• They're much better at helping you "get to know" your applications from the inside.

Here's something you'd do with a pen-test tool for a basic web application:

1. Log into the application through the proxy

2. Create a "hit list" of the major functional areas of the application, and exercise each once.

3. Use the "spider" tool in your pen-test application to find all the pages and actions and handlers in the application.

4. For each dynamic page and each HTML form the spider uncovers, use the "fuzzer" tool (Burp calls it an "intruder") to exercise every parameter with invalid inputs. Most fuzzers come with basic test strings that include:

   • SQL metacharacters

   • HTML/Javascript escapes and metacharacters

   • Internationalized variants of these to evade input filters

   • Well-known default form field names and values

   • Well-known directory names, file names, and handler verbs

5. Spend several hours filtering the resulting errors (a typical fuzz run for one form might generate 1000 of them) looking for suspicious responses.

This is a labor-intensive, "bare-metal" approach. But when your company owns the actual applications, the bare-metal approach pays off, because you can use it to build regression test suites that will run like clockwork at each dev cycle for each app. This is a win for a bunch of reasons:

• Your security testing will take a predictable amount of time and resources per application, which allows you to budget and triage.

• Your team will get maximally accurate and thorough results, since your testing is going to be tuned to your applications.

• It's going to cost less than commercial scanners and less than consultants.

Of course, if you go this route, you're basically turning yourself into a security consultant for your company. I don't think that's a bad thing; if you don't want that expertise, WebInspect or Fortify isn't going to help you much anyways.

Which cross platform scripting language should we adopt for a group of DBAs?

If you want a dynamic language and there already a lot of Java developers in your company, then Groovy seems an obvious choice, as it's very easy for Java developers to pick up (also, you said you have some Groovy experience yourself).

Groovy runs on the JVM and has excellent support for working with XML. It also has provides a very straightforward syntax for working with relational databases.

It comes with a console and a shell (though I never use the shell) which make it really easy to test/run scripts or snippets of Groovy code.

FastCGI C++ vs. A Script Language (PHP/Python/Perl)

Several years ago, I more or less learned web app programming on the job. C was the main language I knew, so I wrote the (fairly large-scale) web app in C. Bad mistake. C's string handling and memory management is tedious, and together with my lack of experience in web apps, it quickly became a hard-to-maintain project.

C++ would be significantly better, mainly because std::string is much nicer than char*.

However, now I'd use Python every time (though PHP is not a terrible choice, and perhaps easier to get started with). Python's string handling is awesome, and it handles Unicode seamlessly. Python has much better web tools and frameworks than C++, and its regex handling and standard libraries (urllib, email, etc) work very well. And you don't have to worry about memory management.

I'd probably only use C or C++ for a web app if I was severely RAM-constrained (like on an embedded micro) or if I worked at Google and was coding a search engine that was going to have to respond to thousands of queries per second.

What is the best way to use a console when developing?

I am thinking more along the lines of Ruby, ...

Well for Ruby the irb interactive prompt is a great tool for "practicing" something simple. Here are the things I'll mention about the irb to give you an idea of effective use:

• Automation. You are allowed a .irbrc file that will be automatically executed when launching irb. That means you can load your favorite libraries or do whatever you want in full Ruby automatically. To see what I mean check out some of the ones at dotfiles.org.

• Autocompletion. That even makes writing code easier. Can't remember that string method to remove newlines? "".ch<tab> produces chop and chomp. NOTE: you have to enable autocompletion for irb yourself

• Divide and Conquer. irb makes the small things really easy. If you're writing a function to manipulate strings, the ability to test the code interactively right in the prompt saves a lot of time! For instance you can just open up irb and start running functions on an example string and have working and tested code already ready for your library/program.

• Learning, Experimenting, and Hacking. Something like this would take a very long time to test in C/C++, even Java. If you tried testing them all at once you might seg-fault and have to start over.

  Here I'm just learning how the String#[] function works.

  joe[~]$ irb
  >> "12341:asdf"[/\d+/]
  # => "12341"  
  >> "12341:asdf"[/\d*/]
  # => "12341"  
  >> "12341:asdf"[0..5]
  # => "12341:"  
  >> "12341:asdf"[0...5]
  # => "12341"  
  >> "12341:asdf"[0, ':']
  TypeError: can't convert String into Integer
    from (irb):5:in `[]'
    from (irb):5
  >> "12341:asdf"[0, 5]
  # => "12341"  
  

• Testing and Benchmarking. Now they are nice and easy to perform. Here is someone's idea to emulate the Unix time function for quick benchmarking. Just add it to your .irbrc file and its always there!

• Debugging - I haven't used this much myself but there is always the ability to debug code like this. Or pull out some code and run it in the irb to see what its actually doing.

I'm sure I'm missing some things but I hit on my favorite points. You really have zero limitation in shells so you're limited only by what you can think of doing. I almost always have a few shells running. Bash, Javascript, and Ruby's irb to name a few. I use them for a lot of things!

---

Related Topics