Penetration testing blog

Back to writing after several days or weeks (I could go back and check when the last post took place but I’m very lazy)

In case you’re not familiar with the PCI standard, here’s their website: https://www.pcisecuritystandards.org/

Basically, anyone dealing online with American Express, Discover Financial Services, JCB, MasterCard Worldwide, and/or Visa International is required to comply with a series of security requirements. The main aim is to prevent someone malicious from obtaining access to the credit cards that you handle as well as to make sure that you’re not keeping any sensitive data unsafe internally; and the process therefore involves not only a software-level review but also physical security assessments.

Depending on how many transactions you handle a year and a few other variables (such as if your company has already been compromised before) you get a merchant level assigned which ranges from Level 1 (bigger, more critical) to Level 4 (smaller). Depending on your Level you get different base requirements.

For a detailed description of the 12 main requirements, take a look at: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

I ran across this article by Mark Curphey called “Why the PCIStandard needs as serious re-think” where he talks about the Quarterly scans performed by ASVs (Approved Scanning Vendors) and the quality of the work they deliver.

I wanted to add something more to it, just a quick note, that was the whole purpose of this post.

There is a supporting document by PCI called “PCI DSS Validation Requirements for Approved Scanning Vendors (ASVs)v 1.1” which among several other items, it describes the 5 different Risk levels available at the time of tagging a vulnerability with the corresponding risk.

The document is available <here>

Vendors can’t go creative and assign a risk level that they feel fits the issue, they need to work along the different levels presented by the standard and the explanation provided by the standard for each level. And that’s where I’m going with this. The explanation is completely focused on network-level security and privilege escalation and gets to be a very deep headache at the time of determining in real life what goes where.

If you’re used to running software products that do everything automatic for you, then fine, you don’t even know what I’m talking about here and probably don’t even care - but I wouldn’t advice simply sticking to your automatic product. When findings stuff that automatic products would just miss and/or when working with web-application security, then you better have a Tylenol near by.

The difference between a level and another (level 2 and level 3 for instance) simply means “Compliant” or “Non-compliant” (in case the merchant is unable to fix this on time) and it’s therefore very important to think twice or even three times before deciding what risks to assign. I’m not saying avoid Level 3, I’m saying that you often run into dark areas where there’s no easy way of determining where an issue falls and you need to be careful whenever you make that decision.

Let’s just stop here and we’ll talk about PCI, ASVs and QSAs some other time.

I don’t really know in what format you deliver your reports to your clients, and it would be great if you could comment on that - but here’s a tool that I’ve used before to turn a word document into an “uneditable” (not saying it can’t be reversed) PDF version.

Reasons why you may want to do that.

1- You’re not giving out a template report document, therefore making it harder for someone to edit/redistribute.

2- Making sure that your Word document isn’t disclosing any information isn’t easy. I’d recommend taking a look at all strings (don’t forget ucs2be)  inside the binary, before sending that out.

http://www.pdfforge.org/products/pdfcreator/

Thanks

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.

Hello there - it’s been some time since I wrote my last post here so I thought it would be a nice deal to share something with you. I don’t know if you’re familiar with the Ruby on Rails framework. I will probably spend some posts talking about framework security given the increase in web application related frameworks and the fact that none of them are bullet proof.

One cool framework for Ruby programmers is Ruby on Rails. You can find it here: http://www.rubyonrails.org/

After some quick googling around I found the “Ruby on Rails Security Project” which is a website/project destined at reviewing security aspects of the framework and providing all necessary resources that ROR programmers would need to have handy at the time of securing their web applications.

Such a project can be found at: http://www.rorsecurity.info/

They have a sweet Cheat-sheet available at: http://www.rorsecurity.info/ruby-on-rails-security-cheatsheet/

If you ever do any RoR programming, then you’ll probably find those links useful.