Category Archives: Research


Penetration Testing: The Art or The Science?

So, I have been penetration testing for a while now. Over the years, I have seen penetration testing evolve dramatically. Back in the days, tools were not as smart as they are now. Now, we have state of art tools (burp Pro, Net Sparker, HP Web Inspect to name a few) and to be brutally honest, these tools are only going to get better as time goes by. The application frameworks are also getting better. A widespread issue such as Cross Site Request Forgery, is not as prevalent as it used to be and that’s because the application framework are getting more security conscious then they were a few years ago.

In terms of penetration testing, people are spending lot more time in checking best security practices;

  • Cookies are marked as secure/http only
  • HTTP headers (x-frame, content security policy, HSTS, the list goes on…)
  • Usual SSL checks (ciphers, protocol, BEAST, CRIME etc)
  • Mixing HTTP and HTTPS
  • Auto-complete
  • yada yada yada
  • So, the point is everyone now a days follows a check-list to make sure all of this gets covered. I have no issues with check-list based approach and I understand that this is done to ensure that a level of consistency is achieved. My worry is that these check-lists are growing bigger by the day and we are making Pentesting a Science and killing the Art aspect of Penetration Testing.

    Penetration testing, to me has always been something which requires out-of-box thinking. My worry is, there are a number of things which you can’t document in a check-list, which are application and case specific and we need to educate the budding generation of penetration testers on this Art.

    If you report 20 best security practices but miss a critical business logic flaw, then its a #FAIL;

    To give you a more specific example to highlight this issue.

    Assessing The Forget Password Functionality

    So, these days apps send out a link with a token in it to reset your password. The link looks something like this:


    What tests do you perform on this:

  • check if the token is predictable (cryptographically insecure)
  • check the token is 1 time only
  • A few more tests (is it over SSL or HTTP etc)
  • check that you cannot use the token of 1 user to reset the password of another user. So you may try to generate a link:
  • http://host/resetpass.php?

    So, it turns out that in this 1 case, the app passes all these checks. Now, here comes the Art part. The Application validates that the token, but not quite as it should. It turns out that the application checks if the token is associate with an account on which reset password link has been generated rather than the actual email. So, in the above URL if the user ‘user2′ has not had a password reset initiated, the application will not process the request. However, if we initiate the reset process on both users (user1 and user2) then we can use the token for user1 to reset the link for user2.

    So, as an attacker all you need is someone’s email address.

  • You initiate a password reset on your account; get a valid token. Save this.
  • Initiate a password reset by submitting victim’s email in the forget password functionality.
  • Now, you can use your token to reset victim’s password and compromise his account.
  • Job Done!
  • The bottom line is, we need to strike a balance between the Science and the Art aspect of penetration testing. I get a feeling that currently the industry is moving away from the Art Aspect and pentesting is becoming more of a science. There are a couple of good presentations to get you motivated on business logic testing (1 of them by me and an ex-colleague):

    Get rich or die trying
    The Art of Exploiting Logical Flaws

    Thats my 10 cents for this week!

    Marketing Blurb
    If you would like to try out our Penetration Testing Services, contact us here!

    Pwning Postgres 9.1

    I recently came across a Postgres based SQL Injection in a web application. The database in question was the latest version (9.1). I was in luck and the back-end database user was “postgres” which is the default superuser account in Postgres. If you recall, Postgres and Php allows execution of stacked queries; ie, if the injection was in SELECT statement, you can terminate the SELECT statement and start a new statement like ‘CREATE TABLE..” etc, by using semi-colon between them:

    http://host/vuln.php?id=injection';create table NotSoSecure (data varchar(200));--

    This means that you can execute OS code on the back-end database. Sqlmap already supports this. The way Sqlmap does this is by injecting a User Defined Function (UDF).

    From Postgres site:

    “User-defined functions can be written in C (or a language that can be made compatible with C, such as C++). Such functions are compiled into dynamically loadable objects (also called shared libraries) and are loaded by the server on demand”

    Remember, while there is a default shared library present in Operating system which already has a system() function defined, you cannot use it because Postgres has a limitation that:

    all UDF must include a magic block after having included the header fmgr.h

    So, you need to create your own shared library, upload it, create a function referring to this library and then execute the function. Sqlmap, already has the libraries created for various postgres version and different OS versions. I have to say, Bernardo has done an awesome job.

    In case of Postgres 9.1, this attack did not work. After a little debugging, it was clear that sqlmap for now don’t have support for Postgres 9.1. it was trying to upload the library for 9.0 which was incompatible with 9.1. Bernardo, kindly pointed me to the instructions to compile the library for my architecture (64 bit). So, I compiled the library for Postgres 9.1 64 bit linux and you can download it here. Using this, I was able to create a function manually and execute the code, as shown in screenshot:

    There are some caveats though:

    Sqlmap uploads pre-compiled shared library to the database system. The library file I have compiled is about 10KB in size and postgres by default don’t allow creation of objects bigger than 8KB in size. So, changing the library file in sqlmap folder won’t do the trick. You will have to compile this file with some funky compiling options to reduce the size less than 8KB. I am sure sqlmap will look into this and get this sorted soon. I had to manually upload this file to the server using another file upload issue.

    Note: Stacking queries through web applications is rare in MySql and hence the same techniq doesn’t work under MySql.

    That’s all for now.
    Happy Hacking!

    The Art of Exploiting Injection Flaws@Black hat Vegas 2013

    Hello All,

    The popular course on Injection Flaws will return to Las Vegas at Black hat 2013. The 2 days hands on course covers Injection flaws and ONLY injection flaws. We dont talk about XSS, CSRF, CRLF etc etc. I think, 2 days is not enough time to learn the entire web application security and thus I only focus on Injection Flaws.

    I will be appearing on the famous podcast pauldotcom and giving a little insight on the course on April 25th 7PM ET.

    A little write-up about this can be found here:

    In short, the USP of course are:

    Advanced/Insane SQLI
    Examples where SQLI gets un-detected by commercial tools
    Advanced XPATH Injection (including 2.0)
    Advanced LDAP Injection
    Advanced HQLI/ORM Injection
    Advanced XXE Injection, including blind XXE

    The course page can be found here

    See you in Vegas!

    Update: here is the video from my podcast at pauldotcom:

    Video streaming by Ustream

    Update: My interview at Dark reading which also gives an insight into the course can be found here

    A Collaboration worth mentioning..

    Hello All,

    It has been a long time since you have heard from me :-(
    I am quite excited to share the news that I will be at Black Hat UAE 2012 to present a new talk titled ‘The Art of Exploiting Logical Flaws’. So, as most of you would agree that the application pentests are getting more challenging every day. The automated tools are now part and parcel of every pentester’s arsenal, but do these tools have enough intelligence built into them to identify core logic flaws. Even OWASP Top 10 does not have any mention of Logic flaws. While, there are some examples on internet of using MiTM tool to manipulate requests (e.g. price of a product on an e-commerce site), these are all a bit too common/outdated. We will show some cool logical flaws which we have found in real life pentests and hope that audience can benefit from these.

    More details here:

    Secondly, and rather more importantly, what makes this talk really special is that I will be speaking alongside Richard Dean, who heads the penetration testing team at Portcullis Computer Security. How often do you see two researchers from different firms who usually compete with each other, work alongside and produce good results? I think it is really great to see that the 2 companies (7Safe and Portcullis Computer Security) supporting our talk and many thanks to the directors of these firms. I hope other companies will also follow the same path.

    See you in Emirates Palace, Abu Dhabi!!!!


    What to/not to expect from pentest


    it has been a while since I posted something (nothing unusual), but I really wanted to touch on a sensitive/controversial topic. Firstly, the blog just represent my personal opinion and not that of my employer, so do not draw any conclusions!

    So, to start the debate, I have a question:

    Do you expect a black-box pentest to find *all* vulnerabilities?

    I will comment on this with mainly with a black-box app pentest in mind but the same logic apply to other forms of pentest too (in my opinion that is)

    My thoughts: Any pentest vendor you choose, they would try to find as many vulnerabilities as they possibly can. Most security consultancy companies (at-least all good ones) follow a set methodology, some sort of check-list, a number of in-house /commercial tools and other related material to ensure 2 most important things :

    1. consistency
    2. coverage

    Pentesters are not robots, they are humans and different people have different expertise and different skills and of-course some are more skilled in one area than others. The methodology, in-house/commercial tools, check-lists etc help achieve some level of consistency between various pentesters.

    Time factor: Black Box pentests are usually a function of time. That is you only get a few days to assess the security of a particular application. New vulnerabilities/technology makes our job more complicated/interesting. Most tests nowadays are scoped based around clients budget they have for security testing and hence the scope is limited to find as many vulnerabilities as one possibly can in that amount of time. The more time you will allow to find vulnerabilities, the more likely it is that new vulnerabilities will be found.

    What is a black box pentest: The nature of black-box pentest is such that it can never guarantee that there are no more security flaws other than those reported in the pentest report. For a more thorough assessment, source code auditing is recommended. Black box pentest is done primarily to provide assurance that if a reputed pentest vendor cannot find anything major wrong with the application’s security than its less likely to suffer from high risk issue(s). I can easily code up applications with critical security flaws which can only be identified when the source code is available and these are nearly impossible to find in a black box pentest.

    The length vs the breadth: Should you find a high risk vulnerability, how much time can you spend in exploiting it. Should you exploit it? Of-course, you should safely exploit it to demonstrate the true impact of the vulnerability. Often exploitation of one vulnerability leads to discovery of another vulnerability. E.g. exploiting a vulnerable file upload functionality can give you access to source code and could lead to discovery of a SQL Injection issue. But exactly how much time can you spend exploiting it. Can you afford to miss a Local file include vulnerability because you spent too much time exploiting some other vulnerability? Thus, when a critical issue has been identified I would always recommend that the retest don’t just focus on the 1 issue but at-least some more testing is done to ensure that the test has received a decent coverage.

    The out-of-box thinking: Pentest by nature involves creative thinking. The more familiarized the pentesters are with the application, the results will be so much better. Most pentesters would start a pentest by getting familiarized with the application. If I perform a pentest of the same application which i tested six months ago, then I would have already had an understanding of the application’s behavior/security/logic/input validation etc and I can then spend some time to come up with some new innovative hacks. But unfortunately, the way it works, If i do find a clever hack in the recent test than sadly, I will be asked the question “Why the Hell did I miss in the first pentest”…….

    Technology and Vulnerability move on: Again, even if you have not changed any line of code in your application it does not mean that the pentest will not find anything new this time. E.g. the world did not know of the padding oracle attack till 2 or so years ago; but because I know it now, I will identify and report it now. It does not mean I missed it then..

    Thus there are so many factors which one should consider when requesting a pentest and set expectations accordingly. Also the pentester needs to consider several factors to ensure that they provide the best possible result in the allocated time. Hopefully, this also highlights the need for regular pentest.

    Hope my rant dont upset too many people. Would love to hear what the other guys from the industry think about this….