Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: penetration testing

Getting your message across: Screenshots

2 Comments Posted by on April 7, 2012

Since I’ve finally started doing something with pentestreports.com I thought it was time to write-up some interesting content. Seeing as this one has been bugging me for a while, I thought it would make an interesting starting point. As always, comments are welcomed and encouraged!

Getting the message across in a penetration testing report isn’t always the easiest thing. Explain in 500 words or less, to somebody who may or may not know what TCP is, how you used a forged HTTP request header to inject falsified log requests into their database and perform stored cross-site scripting on administrators… yeah, it’s not easy. So, a picture is worth a thousand words, and we’re going to need to use all the options available to us to convey the issue at hand.

The problem is… people don’t always spend as much time thinking about that picture as they would writing 500 words! and they should! Here’s a few of the screenshot-crimes I’ve seen over the last 10 years or so in technology. These aren’t restricted to Penetration Testing… so should be applicable for any graphical representation!

The lazyboy

Well I guess it gets the message across… but I’m not really sure what that message really is! A screenshot is designed to help get a message across and prove that something was achieved. This kind of screenshot does nothing more than show that you can press a few keys and take a screenshot. Did I perform an XSS in your website, was it reflective? stored? second-order? Who knows…

This screenshot shows nothing.

Full-on

Is that bigfoot? Nope, it’s hard to see, but that’s actually a screenshot! Crop people… no, don’t think, just crop. At least you’re getting more of the message across than the lazyboy, but you’re not helping yourself here. Make sure that when you take a screenshot everything you NEED to show is in a small area that will be easily visible and readable when the screenshot is cropped. A full screen capture is fine for note taking, but the final version needs to be cropped and annotated if needed.

The OTT

OMG where do I look first! 3 screenshots layered one on top of the other… does it tell a story? without any annotation or further information then it’s just a jumbled mess of text. This is a perfect candidate for multiple screenshots, or at the very least a few boxes to focus the reader in on the places where the REAL information is!

Side-note: Screenshots of code are mostly a waste of time… copy/paste the effected code and highlight the section effected.

Click Happy

You may think I’ve gone off the deep-end on this one… but I’m afraid not. Some people actually think that photos are a replacement for a good, well-formed screenshot! Sometimes you just can’t avoid a photo, but think carefully. Easy to do badly! Hard to pull off.

Exceptions to this last one are obvious really. Physical security tests/results, or anything that can’t be screenshotted. Just remember, if you can use a screenshot, it’s going to look a whole lot better than a photo.

Note: If you NEED to do photos… don’t use your phone! Buy a digital camera and learn how to use it!

Conclusion

Take time to think out your screenshots. Not only if you need one, but how you can best show the issue(s) and how a reader will view it. The viewer may not have your technical knowledge, and may not know what the issue really is. Make that screenshot count!

Penetration Test, Security , , ,

Metasploit SAP Management Console AUX Modules

1 Comment Posted by on January 9, 2011

It’s been a tough few months, not only with Christmas, new years and the inevitable travelling that brings, but also dealing with what I can only assume is one of the worst written and conceived programs I’ve ever had to install (more about that in another post though!). I can only guess this is how SAP deter security researchers… by making it a weeks work just to get a single SAP test instance up and working 😉

Anyway, where was I. Oh yeah. Although the basic premise of my research was quick to formulate, I’ve had to invest a lot of the time (more than I care to admit) in fighting to the death setting up a couple of test SAP servers (SuSE Linux and Windows-based) to fully test what was possible and what wasn’t through the SAP Management Console. It’s been an interesting journey!

The auxiliary modules  I’m releasing today are based on an information disclosure bug I noticed while conducting some SAP research back in November 2010. During the time it took me to write-up and release these modules, the main issue was also discovered and reported by researchers at Onapsis (a company known for it’s SAP security research). I know it’s not unusual for multiple researchers to find the same issue at the same time, so I guess I’ll just need to be faster next time 😉

I see no ethical issue in releasing the information gathering modules that take advantage of this bug, as quite honestly, anybody with an SAP system and tcpdump could find this in a few minutes seconds. I’ve not looked further into the Onapsis DoS condition mentioned in Onapsis-2011-002, but will add it to the list of things to look at in the next phase of my research.

Although the Onapsis advisory only mentions Information Disclosure and a single DoS condition, I think there is more gold here to be found here, so keep an eye out for some further SAP Management Console modules in the future. I’ve already got a few ideas what’s coming next. It’s just getting the time to implement these ideas in Metasploit.

Auxiliary Modules:

Note: To use these modules with your current Metasploit install, place them into your ~/.msf3/modules folder (retaining the directory structure above… e.g. auxiliary/scanner/sap).

sap_mgmt_con_version.jpg

You can find out more detailed information about the modules and download copies of the .rb files (they are not currently available in the Metasploit SVN) by following the below links, or viewing them through the Tools/Scripts Menu.

Demo Video:

Note:

These are my first Metasploit modules, so as a non ruby programmer (and non programmer in general) please excuse the odd bad practice when it comes to coding. Any feedback (good or bad) is always gratefully received!

Links:

updated [10.01.11] – Reworded my sleep deprived version for something that actually makes sense!

Metasploit, Security , , , , ,

99 problems, but root ain’t one!

9 Comments Posted by on October 30, 2010

It’s been a while since I’ve really had a rant about the state of the penetration testing industry, and it’s certainly not because there’s nothing to rant about that’s for sure! There’s a whole heap of issues, so many in fact that at times they all seem to blur together into an impossible mess. I don’t know if there’s 99 problems, but I know for sure there are enough to keep us, as an industry, busy for years to come.

Here’s my, probably uneducated and naive, attempt to cover the big points. Who knows, this might even spur some discussion and maybe, just maybe, some solutions too.

The big issues (as I see it) .:

  • Communication
  • Relevance
  • Accountability
  • Standards
  • Repeatability

Communication

I know it’s been said before, but it deserves to be said again. As an industry, we plain suck at communicating with the business. Chris Nickerson and others have spoken a lot about how we as security professionals don’t make things “business relevant”. The CEO doesn’t care if you get shell, he cares if you get the recipe for the secret sauce that drives his business.

As an industry we love technology and that shows in everything that we do. We spend 4 times as much time doing the technical side of things than we do writing about our findings, even though they’re the most important part! How does that compute? We also spend infinitely more time doing technical training than we ever do learning how to communicate effectively with the business. Just take a look at the range of classes offered from people like SANS, EC-Council, and others. There are elements of reporting and communication in some of the SANS classes, but nothing that spends nearly enough time really talking about the issues and helping people fine tune their skills. When’s the last time you saw people asking for peer review of their reporting templates or risk analysis?

Ideas: Better training for penetration testers on business communication. I’d love to see a 2/4 day SANS class on Technical reporting, communications and risk management!

Relevance

Some of the issues here go hand in hand with communication. Showing how that shell you got on the SQL server is relevant to the business, for example. However looking beyond this, there are other issues where testing lacks relevancy.

It’s hard to define what is and isn’t relevant for a customer, especially if they’re asking for a pentest or a redteam test, when you know they really need a vulnerability scan. Penetration testing really comes into its own for finding how your defenses stand up to a real attacker. If you have no defenses, no incident response plan, or god forbid, no security staff at all, then the client is just paying for a penetration tester to have fun for a while and come present at the end on how bad things are. There are plenty of testing companies that live off jobs like that! If we sell that kind of test to a customer, we’re doing them a dis-service!

Some issues are however outside the direct control of testers. Scoping for example, is and probably always will be an issue. Without educating the client on the real risks, the scope will always be an issue. Still, the only way to educate clients, is to build a relationship. Sometimes the first step is to play the game they want, build up that trust, before suggesting what might be a better fit for their maturity.

Ideas: Client guidance – from vulnerability scan through to highly focused penetration testing (Step, by step guide)

Accountability

Accountability in penetration testing is one of those tricky subjects that could either help to either legitimize or kill the industry dead. Let me explain my thinking here…

Current situation: The business pay for a penetration test, vulnerability scan, or whatever else they need. The testers come in, do there tests (whatever they might be) and write a (usually) poor report of the things they found. They leave, end of story.

X amount of time later, the business gets hacked through a vulnerability the testers didn’t find (or possibly even test for!). A penetration test is a moment in time, there are no guarantees made and no liability (at least none that I’ve seen tested in court). The worst that usually happens is the tester (company or individual) won’t get any further work from the business. For some companies, that’s the way they work anyway! As an industry we have our fair share of charlatans. Still, lets not go down that rabbit hole!

So how could accountability help? It should help to ensure that the testers are doing what the should be doing without needing to tie their hands and prevent creativity within the testing process. It could help businesses to know that they’re getting the testing quality they’re paying for.

Still, there’s another side to this too. Any accountability would have to be accompanied by increased costs, better standards to test against, and would have to be driven by the customers. There are a whole lot of issues here… far too many to write about right now. There’s a whole slew of things here that could cause problems, but without accountability of some sort, there’s little to drive businesses to continue throwing money into the black-hole of penetration testing.

Ideas: Name and shame – public feedback on testing companies

Standards

Yeah, I can’t believe I said that either. Standards stifle creativity and create boundaries that could reduce the effectiveness of some testing. Still, right now in penetration testing terms, we’re the equivalent of the wild west. We ride into town shooting our guns (mouths) off, saying we own this town, with nothing to back it up.

There are more than a few companies out there who think a Nessus scan is a penetration test. I’ve nothing against Nessus, as it serves it’s purpose very well. However, without some kind of standard to say what the minimum is, then some companies will always sell bad or unsuitable services to clients.

Standards would also be the first step in legitimizing penetration testing in the eyes of some businesses. InfoSec is still a young industry, and as fun as it is to hack things without needing to think about standards and compliance, it’s inevitable for the industry as a whole.

Ideas: Standard naming terms, Minimum testing standards for WebApp (OWASP Top10?) / Infrastructure

Repeatability

I guess it’s easy to understand, that without standards, accountability and the things I’ve listed above, there’s no way to make a test repeatable. If you send 5 testers to check an application, you’ll end up with 5 different reports, 5 different views on things, and 5 different opinions on the risk. How can businesses effectively track their security program if every time they test things, they get a different approach and a different test. Did we fix the vulnerabilities, or did the tester just not test it correctly?

Until it’s repeatable, it’s still too subjective to be 100% useful. I don’t want to reduce the creativity that goes into testing, after all that’s what makes this job so great. However without repeatability, we’re still just kids playing in the sandbox!

Ideas: Creation of test cases for discovered vulnerabilities

——

Well, there you have it, for better or worse. I don’t expect everybody to agree with these points. I also don’t expect these points to cover everything that’s bad or unmanaged in the penetration testing arena. What I do expect though is people to talk about things. Shout, stamp your feet, call me out and tell me I’m wrong… but do something other than nodding your heads and saying “yeah he’s right”.

Agreeing is nice. Arguing is good. Discussing is great… Doing is better!

With this in mind I’d like to setup a series of 5 podcasts to discuss each of the points above. As nobody wants to hear me talk about things alone for 30 minutes, I’m inviting you (yes, you…) to come on and talk. May your feelings known!

Shoot me an email at podcast [AT] c22 [DOT] cc if you want to be a part of it!

Penetration Test, Security , ,

Python OCR… or how to break CAPTCHAs

7 Comments Posted by on October 12, 2010

After my little stint writing the scr.im PoC script, a few people on Twitter reminded me of a blog post that Andreas Riancho from Bonsai-sec wrote back in February. Andreas (the creator of the excellent W3AF tool) wrote a short Python script to take a CAPTCHA image and perform an OCR on it. As a geek, this piqued my interest, but the one problem I had with it was that the script relied on the pytesser Python library, which is Windows only!

There were a few issues with that.

  1. It’s Windows only and I prefer to avoid Windows unless there’s no other choice
  2. The project only ever reached version 0.0.1
  3. The project has been abandoned since May 2007

So, not wanting to give up on something that looked fun, and also useful, I started a search for an alternative. I quickly found that the pytesser Python library is a wrapper around the tesseract-ocr project, and that there had been some work on another Python library called Python-Tesseract that looks like it does the job (and isn’t platform dependent).

After installing tesseract-ocr (apt-get install tesseract-ocr on Backtrack) I downloaded the Python-tesseract files and modified the script from Andreas Riancho a little (the actual changes to make things work are minimal). I also changed a few things to get the script to reasonably accurately decode scr.im captcha images.

#!/usr/bin/python

# [PoC] tesseract OCR script - tuned for scr.im captcha
#
# Chris John Riley
# blog.c22.cc
# contact [AT] c22 [DOT] cc
# 12/10/2010
# Version: 1.0
#
# Changelog
# 0.1> Initial version taken from Andreas Riancho's \
#      example script (bonsai-sec.com)
# 1.0> Altered to use Python-tesseract, tuned image \
#      manipulation for scr.im specific captchas
#

from PIL import Image

img = Image.open('captcha.jpg') # Your image here!
img = img.convert("RGBA")

pixdata = img.load()

# Make the letters bolder for easier recognition

for y in xrange(img.size[1]):
 for x in xrange(img.size[0]):
 if pixdata[x, y][0] < 90:
 pixdata[x, y] = (0, 0, 0, 255)

for y in xrange(img.size[1]):
 for x in xrange(img.size[0]):
 if pixdata[x, y][1] < 136:
 pixdata[x, y] = (0, 0, 0, 255)

for y in xrange(img.size[1]):
 for x in xrange(img.size[0]):
 if pixdata[x, y][2] > 0:
 pixdata[x, y] = (255, 255, 255, 255)

img.save("input-black.gif", "GIF")

#   Make the image bigger (needed for OCR)
im_orig = Image.open('input-black.gif')
big = im_orig.resize((1000, 500), Image.NEAREST)

ext = ".tif"
big.save("input-NEAREST" + ext)

#   Perform OCR using tesseract-ocr library
from tesseract import image_to_string
image = Image.open('input-NEAREST.tif')
print image_to_string(image)

A majority of this code is preparation, the actual OCR job is performed in the final lines using the image_to_string call. Simple isn’t it!

The above script is tuned to the scr.im captcha image. As can be seen by the below examples:

As you can see, after running it through some filters (thanks Andreas), the CAPTCHA becomes a lot clearer, and significantly easier to OCR. Even in this case however, tesseract-ocr sometimes returns the value as W6BHP instead of W68HP. Still, that’s an easy mistake to make… and I’m sure with more tweaking, the preparation could be perfected!

So, next time somebody says “we implemented a CAPTCHA to prevent scripted attacks“, you can take it with a pinch of salt!

Links:

  • [PoC] scr.im.tesseract.py script –> here
  • Breaking Weak CAPTCHA in 26 Lines of Code –> bonsai-sec.com
  • Pytesser –> here
  • Tesseract-OCR –> here
  • Python-Tesseract –> here
Penetration Test, Security , , , , , , ,

← Older posts