Server-side request forgery in Sage MicrOpay ESP

Asterisk Senior Security Consultant Mike Loss shares a story from a testing engagement that was fun for us, moderately bad news for our client and ultimately worse news for a vendor. Spoiler alert – this story has a happy ending.

During a testing engagement last year I was working on a web app called “Sage MicrOpay ESP”. ESP stands for Employee Self-service Portal, and it’s a pretty standard HR web app, allowing employees to enter timesheets, book leave, etc.

Looking at the first handful of requests made by the browser when loading the page, one stood out immediately as… odd.

There are a few file extensions that really set the spidey-sense tingling when it comes to web apps. The list is long, but classics include pl, sh, exe, and in this instance, .dll.

Image Source

Looking through the URL parameters in the request, something else stood out – the ‘CommonDatabase’ and ‘CommonServer’ parameters. It seemed pretty odd that the user would be in control of a web app’s database connection. At first I doubted that was what was actually happening but once I noticed that the value in ‘CommonServer’ matched the naming convention of the target organisation’s server fleet, I became more confident that I was on to something.

Put simply, it turns out that one of ESP’s very first actions upon loading was to tell the client’s browser: ‘Hey I need you to tell me to connect to a database server. You should tell me to connect to this one!’.

There’s essentially no reason for a web application of this type to ever ‘ask’ a regular client which database on which server the application should connect to. In any sane application this value would be in a configuration file, somewhere inaccessible to normal users of the application.

So of course I did what any normal tester would do, I threw a bunch of garbage at the interesting parameters to see what would stick.

Most things I tried at first resulted in the request timing out, but we maintain a pet DNS server for just such an occasion. Keeping an eye on the query logs for the server and sending the request again with our DNS name in the ‘CommonServer’ parameter resulted in a lovely sight.

At the very least we have some kind of server-side request forgery in play. The obvious next step for us was to see what else we can get the server to talk to. Internal hosts? Hosts out on the Internet?

The thing clearly wants to talk to a database server… let’s give it a database server. The .dll file extension tells us it’s on Windows, so MSSQL is an obvious place to start.

Starting up a netcat listener on port 1433 on a host in AWS and then sending our DNS name in the ‘CommonServer’ field generated exactly the result we’d hoped for.

So we have a web application on the inside… and it thinks I’m it’s database server…

Image Source

I wonder if I can get it to send me credentials?

The obvious tool for the job here is Responder. It’ll happily impersonate a server, then negotiate and accept more or less any authentication request that a client is willing to send it, then serve up the resulting credentials on a platter.

After repeating the process with Responder in place of our netcat listener, we get some creds!

Fun for us, but moderately bad news for our client.

At this stage I was moderately disappointed by the quality of the very obviously default creds, especially since they were no good to me in terms of further attacks on the target infrastructure.

I started goofing around with the format of the server address, trying out UNC addresses, internal addresses, specifying ports, that kind of thing, and eventually hit on formatting it like this:

…which made my Responder go off like crazy.

Image Source

For those not familiar with NTLM authentication, it APPEARS that the application has interpreted our gently mangled server name as a UNC path, in such a way that it thinks it needs to get to the database via SMB.

As a result, it’s connected to my Responder listener on port 445, and Responder has told it to authenticate via NTLM. The application has kindly obliged and we end up with a NetNTLMv2 hash – that long string of yellow alphanumerics at the end of the image.

Now, a NetNTLMv2 hash is quite a lot slower to crack than a regular NTLM hash if you want to actually recover the password, but if you notice that ‘$’ at the end of where I’ve redacted the username? That means the account being used to authenticate is the AD account of the actual server itself. That means the password is randomly generated and LOOOONG.

Never going to crack it. Just not gonna happen.

What we COULD do however is relay the authentication attempt… IF the target organisation had any services facing the internet that used NTLM authentication AND allowed connections from computer accounts. This might seem unlikely at first, but ‘Authenticated Users’ includes computer accounts, and heaps of sysadmins grant rights to ‘Authenticated Users’ where they should really use ‘Domain Users’. In any case, our target organisation didn’t have anything else with NTLM auth facing the Internet so it’s at this point that the attack becomes kind of academic.

In addition to this particularly entertaining issue, we also identified a number of other issues with the application, including unauthenticated access to staff names, phone numbers, addresses, and other sensitive PII.

After delivering the report to our client we began the least fun part – the disclosure to the vendor.

It turns out that ‘Sage’ is a pretty big company, and finding anyone responsible for infosec matters was non-trivial.

I started with the support email on the website. While the staff at the other end responded very quickly, there seemed to be a breakdown in communications.

Sage support continued to insist that I needed to provide a customer number before they would provide me with any support services. I tried explaining that I wasn’t asking for support services…

And then they stopped replying to my emails. 🙁

So I tried the traditional “security@” email address… Not a peep.

I asked around with some industry contacts… Nobody knew anybody who worked at Sage.

Finally I resorted to what I think of as ‘the Tavis’.

Turns out Tavis is a smart guy (who knew, right?) because this worked… real fast.

Without boring you to death with details, I almost immediately received a phone call from an actual dev, who was actually familiar with the app, and who actually wanted to fix the problem!

I passed through the details, they fixed the issues, and a patch came out about a month later.

Finally, because we’re meant to be trying to actually make things better when we hack stuff, I’d like to go over a quick summary of the ways this could have been prevented.

On the dev side, the most obvious part is that the client should not have ever been given the opportunity to choose the back-end database server. It should have been set in a config file somewhere.

Of course, we can’t expect vendors and developers to always do the right thing. Strict outbound network filtering would’ve prevented both the MSSQL and NTLM credential exposures. Your computers almost certainly do not need to talk to things on the public Internet on tcp/445 and tcp/1433, so don’t let them!

Sage were very helpful and friendly (and appreciative) once I actually made contact with the right group within the company, but getting there was unnecessarily difficult. Monitor your security@ address and publish a contact on your website for vulnerability disclosure.


Vulnerability Disclosure: SQL Injection in Flash Page Flip

During an engagement for one of our clients we came across Flash Page Flip and found that it is vulnerable to SQL Injection. As per our responsible disclosure policy, the creators of Flash Page Flip were contacted to advise them of the issue.

90 days have passed since our initial communication, and we have received no further response. SQL injection is not a new topic. To be more precise, it is a 20th century bug which is supposed to be long gone. The reason we decided to pursue this vulnerability officially (CVE-2015-1556 and CVE-2015-1557) is due to the apparently wide spread use of this application.


The lack of input validation was noticed across the majority of Flash Page Flip’s code and affected multiple pages such as:

  • NewMember.php
  • GetUserData.php
  • SaveUserData.php
  • DeleteUserData.php
  • /xml/Pages.php

In other instances weak input sanitisation functionality was implemented, before the SQL query was sent to the backend database. Some of the affected pages are listed below:

  • /admin/EditSubCat.php
  • /admin/ViewPage.php
  • /admin/AddMag.php
  • /admin/AddCat.php
  • /admin/EditCat.php

Exploitation of this vulnerability could allow attackers to extract the data used by Flash Page Flip which may be considered not sensitive. However, Flash Page Flip could also be used as a plugin to other CMS platforms and therefore may share the same database, as it happened during our engagement. In this case, SQL Injection may result in exposure to more sensitive CMS data, including credentials.

The full advisory can be found here.

Communication timeline:

  • 27th Jan 2015 – Contacted vendor with initial disclosure
  • 10th Feb 2015 – Contacted vendor with CVE identifiers
  • 29th Apr 2015 – Vulnerability published

Intra-Cloud App Disruption Risks

Automating application deployments into the ‘cloud’ is not always as simple as it should be. Depending on how you approach this problem, you may need to delegate access to components that may increase the risk of unauthorised changes. If you’re doing this in Amazon Web Services (AWS) you may have heard of CodeDeploy. CodeDeploy is one of the methods AWS has to push application code into their cloud environment. AWS has a number of mechanisms to control and limit what actions can be performed by administrators, and by compute-instances themselves. Unfortunately, not all of the AWS systems allow granular control, and may leave your applications exposed.

Auto Scaling is one of these AWS subsystems that can be used to assist with automating application deployments. Unfortunately, Auto Scaling’s access control mechanisms do not allow granular resource restriction. The risk introduced is, if you delegate Auto Scaling permissions to AWS resources, they can make changes to ALL of your Auto Scaling settings across your entire account.

The rest of this article will cover the following:

  • How CodeDeploy works;
  • What AWS Identity and Access Management (IAM) configurations are required;
  • How to deploy apps into AWS with CodeDeploy;
  • How to integrate load balancers into your deployment;
  • The risks this introduces; and,
  • How to manage these issues.

Continue reading Intra-Cloud App Disruption Risks

Say ‘Hi’ to the SAMM Self Assessment Tool

Asterisk are happy to be releasing their first public beta of the SAMM Self Assessment Tool, or SSA. One of our favourite OWASP projects is the OpenSAMM project, and for those who haven’t seen OpenSAMM before, it is a framework to help organisations to evaluate their current software security practices, and build measurable targets and plans for improving these practices.

Part of OpenSAMM includes conducting assessments (you can’t manage what you can’t measure right?). The OpenSAMM methodology categorises these assessments as either Lightweight or Detailed. SSA aims to provide a very simple way to perform this Lightweight assessment, and compare your current status with some pre-canned target states. And literally, that’s it.

We’ve used this tool on a number of engagements to quickly gauge where an organisation is, and it’s certainly helped with figuring out the ‘current state’ of an organisations software security maturity.

There’s currently two different ways you can use SSA:

  1. You can visit and complete the checklist directly. You don’t even have to save your assessment anywhere if you don’t want. On the other hand, if you want to store your results, there’s a few ways to do that, such as in your cookies or online in a database. For online storage you need to Sign Up, either with a username and password (please don’t re-use your passwords folks), or you can sign in with a Google account too.
  2. Clone a copy of the Rails app and spin it up somewhere locally. We recognised quite early on that some organisations may feel uncomfortable with tracking this sort of information on the Internet, so, if you have the capability, sure, feel free to clone the repository locally and do what you wish.

SSA is being released under an MIT license, and our intent is to give it back to the OWASP community for further enhancements. We have a high level list of proposed features available on the GitHub page, but currently they’re being developed on a ‘When Christian Has Time and is Sober’ timescale. SSA forms part of our Toolkit, of which we’re slowly publishing other tools and utilities too. So watch this space!

As always, we’re really interested in your feedback, queries, concerns, issues. So feel free to send us queries via @asteriskinfosec or as Issues on the GitHub project.

Application Security: Your First Steps

One of the areas of information security that Asterisk has a keen interest and involvement in is that of Application Security. Whilst security of your infrastructure, in particular the perimeter and end-points, has been a focus point for a number of years now most of the important information stored by your business doesn’t usually reside in those locations. Sure, transient remnants of information are always likely to exist on your end-points, but centralised storage and management of sensitive information has been a central enabler for IT since the concept of client/server architecture began. For most people involved in information security, or even information technology, this is not news at all. In fact, it’s been the message that organisations like OWASP have been hammering on about for over a decade now. Unfortunately traditional firewalls and anti-virus don’t really help you when it comes to assuring the security of your applications, especially your web-applications, on the contrary your firewalls are usually configured to explicitly allow access to your web-applications, I mean that’s what they’re for.

As part of our involvement with the application security space we participate in conferences and events focused on the security of applications, unfortunately, these events always struggle to draw in the people that would really benefit from this knowledge. I’m talking about the masses of people who actually run their businesses online, or the people that rely on the Internet for their commerce, and there’s lots of us (yes us too, we utilise various online services for the management of our business too).

So where do they start? Can they talk to their IT guy? Can they talk to their AV vendor? If there were an easy solution to securing applications, we would have all done it already, right? And if you’re in the business of relying on your staff, or contracted staff, to build applications for you, then trust us, this is definitely an issue that you should be aware of. If you haven’t had an opportunity to read Verizon’s Data Breach Investigations Report for 2012 then you should get your hands on it [pdf] (Or a really good high level summary can be found over on Securosis). One of the takeaways from the report is the number of breaches where the vector was hacking via web applications. (The recent report indicates that overall 10% of external hacking incidents, leading to breaches, where related to web applications. This statistic increases to 54% when looking at organisations with 1000 or more employees)

Honestly, starting is the simplest bit; it is being aware of the problem. Awareness that a lot of attacks are opportunistic in nature, and that you aren’t necessarily a target, except for the fact you reside in some form on the Internet. The tools and the methods employed by these attackers are not a dark art; they’re relatively simple and widely discussed in the industry and by many ‘above-board’ organisations. One such organisation is OWASP, a not-for-profit worldwide organisation focused on improving the security of application software. And you know how they do it? The publish materials and tools, for free, online. Asterisk is so keen to dedicate itself to this cause that two of our founders are local chapter leaders within OWASP.

If step one is increasing your awareness of just how exposed your applications are online, then step two would be dedicating your morning read to some of OWASP’s materials (If I had to choose a starting point, the latest version of the OWASP Top 10 is as good as any), or better yet, finding out when your next OWASP chapter meeting is and heading on down to say ‘hi’.

Don’t give up hope, and don’t worry, this is going to be the first of many posts on how you can start looking a little closer at the security of your applications.