Sometimes it pays to walk away

Sometimes it pays to walk away

The second post in my series from the darkened room; sometimes I walk away.


The second post in my series from the darkened room; sometimes I walk away.

This engagement was a pure web application penetration test. The new client was an online retailer and the story starts and ends at the pre-test phase. They contacted us to perform a web app penetration test against a single URL. They initially wanted to spend no more than two days on the test, which would have been a day of testing and a day of reporting. The application contained in excess of 500 dynamically generated pages, five different payment mechanisms (one of which was to take bitcoin) and a user management system. With the size and complexity of the system, I estimated 14 days to fully test in line with PCI-DSS Req 11.3 but the client simply wasn’t having it. It was two days max, that is what another penetration testing firm had already quoted and if we wanted the business then we would have to match it.

What followed was one of the most difficult discussions between testing and sales. Sales wanted the business. Testing wanted nothing to do with it. In the end our CEO put in a call to the client and politely explained that to do the test justice he would need 10 days minimum to test the site to PCI-DSS standards. He understood that the client had been quoted two days and suggested something a little different to the client. We could do it bounty style. We would agree £10,000 for a proven critical risk issue, £7,500 for a proven high-risk issue and so on. That way, if there was nothing found then nothing would be paid. In the end we walked away from the job. Doing a good job is always better than doing a quick job.

A month or so passed and the new client came back to us. They had had the two-day pen test performed by the other party but were not too happy with the output from the test. They had addressed all the findings and now would like to take us up on our bounty style test. Now the client made a little mistake, in the email trail was the invoice from the other testing company and the report. It looked ok and told us what they had fixed. Could we rise to the challenge? Commercials were signed and a start date was set.

Ryd and Peter sat down on a cold and wet English winters Sunday morning and went through the job. One thing stood out as a viable attack vector and again, OSINT helped. The reconnaissance and intelligence gathering phase of testing is so very important. It told us one thing that would help immensely. Their web server has PUT enabled and the scripts directory was writable. After a few hours of experimentation, we knew that there was some extra protection player in play here and we were unable to create new files. We could however modify existing files. What followed was a “you are kidding right?” moment and our two testers sitting down for a cup of tea.

“Let’s go for the most game over event for a PCI test, steal the cards. But safely”

“We could modify one of the JavaScript files to mirror the card transaction to our server. That way we can hash them on the server and just send the hash string.”

“That’s a pretty sick idea. But look at the source, they are checking the hash of the file.”

“Not rand.js though, it isn’t being checked properly, typo.”

“What if we fix rand.js for them too, it sets the encryption salt.”

Some minutes later, hashes of the transactions were being sent to one of our servers via HTTPS. That’s devastating, but could this be built on? Yes, was the answer. The following day their account manager had the conversation with the client to inform them that we had two Critical Risk issues (stolen card numbers and customer account takeovers) and two High Risk issues (HTTP PUT enabled and blind SQL Injection). It is fair to say that the client was extremely unhappy. Having just had a penetration test, how could these issues have been missed? From Peters point of view:

“The initial vulnerabilities, while easily detected by a competent level of reconnaissance, were missed by our commercial vulnerability scanners. We ran Nessus, NeXpose and OpenVAS against the target and these all missed the issues we identified. There were a couple of opensource tools that run manually identified the initial issues, as did our tool set but it was down to the testers experience and imagination to come up with the attacks. In the end, the only thing that was identified by automated tools was the HTTP PUT vulnerability. We had to manually trawl the source code of the site and test a lot of iterations to find a way to leverage the vulnerability. I still think we could have gone a lot further in the attack. We were able to mirror and capture all the card transactions, so the attack was viable from the financial crime viewpoint. Further, we were able to take over users accounts for newly registered users as we could set the random string used by the encryption salt function for user data to whatever we liked, rendering all encryption reversible to us.

This was a great example of a firm doing most things almost right but not seeing the value of skilled attackers. What started for them as a tick box exercise soon turned into a real penetration test.  In all we spent three days on the test to complete the proof of concept attacks.

As ever, we only had to be lucky once and, on this job, we got four hits of luck.

  • Recent Articles
Author Details
Founder & CEO at Hedgehog Security

Peter has been in the Information Security world since 1999 and in IT in general since 1996. His work history contains a unique blended balance between the development of exceptional technical capabilities and business knowledge. Peter is a proud father of twins and enjoys GT endurance racing on the weekends.

We would like to keep you informed about our services. Please tick the options below to receive occasional updates via

  • penetration testing steps
    Peter talks to FindMyUkCasino
  • Malware
    SB Tech Breach

    Last week saw SB Tech Breached by the hacking group Maze. It seems that every week the group are announcing more victims.  GameOn asked our CEO Peter Bassill, to give us some insight into the attack. The GameOn article is here.

  • Privacy
    Howto VPn

    In our “How to securely” series we asked our followers what tools they would like a simple guide on to help them stay secure online. There seemed to be a lot of confusion as to what a VPN is and why you should or should not use one. So we asked Peter to help.

  • WhatsApp
    How To Whatsapp Safely

    WhatsApp is among the fastest-growing instant messengers out there, and almost a social network in its own way. But if you are using it, there are some steps you should take to protect your security and privacy.

  • Morrisons Breach Update

    The UK’s highest court ruled that Morrisons can not be liable for a criminal act of a person seeking to harm their business. On April 1st, 2020, a panel of five justices unanimously ruled that Morrisons was not “vicariously liable”.

  • Remote Working Considerations

    With the current pandemic situation, we all need to be taking remote working considerations. While adjusting the work paradym, it is vital to keep a mind’s eye on the security and safety of the businesses information assets

  • Securing Zoom
    How To: Securing Zoom

    In this guide we are looking at how to go about securing zoom. Since the onset of the global pandemic, we have seen surge in “zoom bombing”. This is where people with malicious intent look for in-progress zoom meetings to join and cause trouble.

  • Software Security
    Dell EMC iDRAC memory corruption Vulnerability

    A critical vulnerabiltiy has been identified in Dell EMC iDRAC7, iDRAC8 and iDRAC9. Some unknown processing is affected by this issue. Manipulation with an unknown input can lead to stack based memory corruption.

  • Hiscox Sues for Failing to Disclose Data Breach

    On March 27th, Hiscox Insurance Company Inc. filed a complaint against law firm Warden Grier for concealing a data breach that occurred back in 2016.

  • Software Security
    Privilege escalation on Nginx Controller up to 3.1.x Controller API

    A critical vulnerability has been identified in Nginx Controller up to 3.1.x (web server,) affecting an unknown code block of the component Controller API.

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Scroll to Top