Penetration testing blog

If you were ever involved in the process of scoping out a source code audit project, you have probably run into the situation where you have to figure out how to count the code. There are several things involved:

• What tool are you going to use to count it?
• Should the tool be able to understand the language?
• Or will you simply use a line counting tool such as wc -l?
• What will you consider in your count? Code lines, blank lines, what about comments?

I’m going to go ahead and cover each of the points I mention above, based in my own experience. I therefore invite you to submit and share your comments based on your own xperiences as well.

I believe in providing [potential] customers with accurate information and I understand that some times that may not even be possible - but when it comes to counting lines of source code I rather use a tool that can parse the code than simply running a “wc -l” - However any functional bugs within the tool you use may end up impacting your estimate considerably and for that reason you need to test the tool first (or make sure it’s got some testing already.) The main benefit you would get from parsing the source code other than simply counting raw lines within a file is the ability of identifying source code comments (the way of specifying comments varies according to each language.)

Now, why would you be interested in identifying source code comments? Good question! And it is up to how you perform your scoping. The reasons I can think of are:

• You have a certain metric for source code lines and a different one for comments (in average, comments should be easier/faster to read.)
• You want to exclude comments from the estimate. You are ok with working an extra bit to cover for any comments.
• You want to exclude comments from the estimate. You will simply blink, look away, close your eyes whenever you go through a commented line while performing the review.
• You simply want to provide your client with a break down containing lines of source code and comments.

I have been in both sides of the court, considering comments within the estimate and excluding them. But either way, I have always looked at comments while reviewing code! You could argue that comments don’t get compiled/run, that there could be plenty of dead code laying around - but comments not only can be fun! they are a window into the programmer’s mind and what’s more valuable than that?! Yes, you can find dead code - but why is that code even there? From a version to the other dead becomes alive and boom! And flexibility is the key! If you do know of a directory just filled with dead code, why not look carefully or talk to your client and about excluding that piece from your estimation?

So it is up to whether you decide to include comments in your time estimate or not - but it shouldn’t be your choice to decide whether to review them or not.

So this all ends up being:

source_code_lines = lines_in_file - blank_lines - comment_lines | comment_lines = lines_in_file - source_code_lines - blank_lines | total = source_code_lines + comment_lines

I have recently found a very nice tool called CLOC (http://cloc.sourceforge.net/) - which deals with a wide set of programming languages. Test it out!

Later.

I was looking for resources on how to test personal firewall solutions which are so frequent these days. Here are some of the things I found which may come in handy to someone looking 4 the same thing.

History and Advances in Windows Shellcode (The part for: Uploading file with debug.exe and VBS)
http://www.phrack.org/issues.html?id=7&issue=62

Bypassing Windows Personal FW’s
http://www.phrack.org/issues.html?issue=62&id=13 

Firewall leak tester (a collection of scripts for testing personal firewalls)
http://www.firewallleaktester.com/

Defeating Windows Personal Firewalls
http://www.thehackademy.net/madchat/windoz/win32inc/defeating_windows_personal_firewalls.pdf

Hope those help! I need to add those to the directory.

-AV

I went crazy yesterday looking for a tool that would easily let me remove every single e-mail from my Gmail account. I really find it hard to believe that even though I get the “E-mails deleted” message, they are not being kept somewhere for some agency’s convenience. Nonetheless, I wanted to take a measure of removing everything and quickly (I don’t have anything to hide really, it’s just for learning!.)

By quickly I mean that if you have thousands of e-mail conversations, the largest amount of e-mails/threads that you could list within Gmail are 100. Therefore an hour clicking select-all and delete would have been incredibly insane.

I started googling. I found a script in perl that some guy wrote which simply connected to Gmail’s IMAP service and looped through the threads removing everything with IMAP commands.

Then I found a series of threads about people trying to do the same thing, which is automating the e-mail deletion process, and a discussion on how certain Firefox GreaseMonkey (http://www.greasespot.net/) plugins could fake your button clicks, pretty much like a single sign on session.

I also found python libraries from 2005, nothing really convincing.

That is when I went back to the Gmail interface and selected all 100 threads on screen, and all of a sudden this amazing “Select all 4015 conversations in Inbox” link appeared! It had already been implemented by Gmail, stupid me trying to look somewhere else for the response!

Clicking on that link provided me with a way of selecting everything I had in my Inbox, then again on my Sent e-mails and by clicking on the Delete button I moved everything to the Trash. You then have to go to the Trash and delete everything forever.

Hope that saves you some time!

I just retrieved this from Ed Skoudis’s presentation that I just mentioned in my previous post (look it up!)

Windows’ shell scripting is really in the dark, at least for me. I’m constantly looking for new ways of creating smart batch scripts and it really gets to be a pain in the ass to find something useful.

It is therefore a must to store the following one. It will open a file, the delimiter character is fictional, the idea is that you wont really use it - which forces windows not to parse the command using spaces as the default delimiter, the run the command and finally dump the output to a file!

c:\> for /L %i in (1,0,2) do (for /f “delims=^” %j in (commands.txt) do cmd.exe /C %j >> output.txt & del commands.txt) & ping -n 2 127.0.0.1

Goodbye!

I’m watching the following Webcast by Ed Skoudis which was hosted by Core Security Technologies:

Penetration Testing Ninjitsu Part II: Crouching Netcat, Hidden Vulnerabilities with Ed Skoudis at CORE Security

Ed talks about the importance of being aware of your ISP filtering policies at the time of conducting a pentest, which sounds obvious but then again it’s easy to forget.

He also discusses some techniques for replacing the netcat client in Linux and Windows, and provides examples for creating reverse shells using /dev/tcp and creating port scanners both in linux/windows, among other things.

In my personal opinion, the windows port scanning options are not worth it he sure works around the limitations imposed by Windows’ telnet and ftp clients, and I believe he mentions them for a specific case in which you may have no other ways of performing an automated portscan.

You can leave it on and hear him speak while you do something else, won’t be a waste of time.

Source code reviewing is the act of reviewing source code (what a definition!) For that to happen, a consultant needs to have access to the source code of the application/framework/module in question. This can be performed automatically, semi-automatically and/or manually. Automatic and semi automatic reviewing can take care of speeding up the review process and can also be focused on identifying flaws that may not be as evident to the human eye. However, products that perform automatic/semi-automatic reviews are not perfect and at least in the year 2007 they are not intelligent; and even though the human mind is not perfect either, products can’t compete with it. Reviewing code manually takes more time than running a beautiful product, yeah, but skilled consultants can identify logic-related problems that would go against any pattern-matching product. So I just mentioned skilled consultants, and the reason behind I wrote that ’skilled’ word is that the quality of the deliverables you get from a manual source code inspection is equal to the skills of the person/people performing the review.I started that paragraph stating that ..consultants need access to.. and it’s also worth mentioning that even though a security consultant would indeed need to have access to the source code in order to perform a manual inspection, it isn’t always the case in other contexts. For instance, inspecting source code during a development process is a common practice these days. It will always be cheaper for a development company to get a product that they can run anytime they have a new code base against the source code, instead of paying someone to do it for them. In that case, they can either have the development team run it (it will depend on how joyful programmers find their new responsibility) or even the QA team. If it’s the QA team, then QA could use the product remotely without having actual access to the source code, reporting any findings back to the development team. So yeah, for a proper source code review a consultant needs to have access to the source code in question, but that isn’t the case at all times in all contexts, which makes sense.

Another thing about source code reviewing is how important it is for a consultant to be able to either compile/run the code or have an environment running the modules under review, with a version as exact as possible (having the exact same source drop isn’t always possible) - Here is when it gets a little dizzy. A comprehensive security review is not always possible and it isn’t just a matter of reviewing source code, so certain limits need to be established for the scope of work. The fact of the matter is that by simply reviewing source code you can have plenty of results but none of those results will turn into actual risks unless you put them in context and test how reliable/exploitable/useful they are. So in order to avoid having a lot of false positives it is always good to have an environment to refer to every now and then during the assessment.

The running environment isn’t just about discarding false positives though - it gives a clearer picture to the person reviewing the source code of what’s going on. Believe me, everyone loves object-oriented programming and abstract paradigms. Wait until you get to review a large-size project simply from a source code perspective and let me know how much time it would take you to trace down the interoperability between each module. I’m not saying it’s impossible, no, but believe me how much an environment would help in there.

But then again, I think I read once in Mark Curphey’s blog about the importance of defining a good statement of work, proposal, scope of work - and it’s absolutely true. It will get very confusing for a client to understand why you need to have an environment if you’re saying you will only perform a manual source code inspection. Of course it’s better for them if you end up testing more than what they thought they were paying for but forget about not having headaches while trying to justify any further ballpark figures.