Cross site scripting (XSS) is nothing new, it has been prevalent for as long as I have been a developer. In my experience, frameworks have reduced the amount we have to worry about protecting against certain attacks as they often handle the escaping for you. However this can give a false sense of security and let you take your eye off the ball. Protecting against threats must always be on your mind as a developer and is not just an item on the to do list to consider later.
A number of weeks ago I was given access to “bob” (https://app.hibob.com/), a cloud hosted HR system that was being rolled out at my place of work. The application created by Tel Aviv company Hibob is a platform which focuses on growing employees. People are encouraged to interact with it frequently in order to get the most out of it. It provides a means to book holiday, see your HR data and be social within your organisation. In a recent article announcing $20 million of investment they reveal some of their customer base, “Monzo, Etoro, Happy Socks, Fiverr, Receipt Bank and Karmarama.”, which include two banking institutions. Due to the amount of personal information held in the system I wanted to have a closer look at the inner workings, it didn’t take long to identify a massive vulnerability.
I had noticed that every piece of information on the website was loaded via API calls on the front end. These calls would pass your session cookie which determines the scope of what you can see for the given API call.
I started with some cross site request forgery attempts as this is something I have played a bit with when fixing a vulnerability on another website. The few basic tests I carried out seemed to protect against this type of attack. From there I thought I would try something a bit more basic. I went to my profile page and looked at what I could edit. There is a free text box to put in something about myself. I tried typing an anchor tag first and to my surprise it accepted it and inserted my link. I got a little excited and tried a script tag. Again it took it, but I quickly realised that it would not function due to the way it is added to the page. I changed tact and inserted an anchor tag with an onclick event.
<a onclick="alert('test');">Link</a>
This alerted to the screen. I had discovered an XSS vulnerability. Not only was it an XSS vulnerability, it was a “stored XSS” one, the highest risk. Reflected XSS is the most common, it relies on a user following a link that includes the attack payload in the URL, with stored XSS the script is stored in the system and shown to many users time and time again. This kind of script can remain unnoticed for a long time. All I had to do now was a bit of googling (my JavaScript is not great) and craft the right payload.
I took what I had found and attempted to do something meaningful with the exploit. The result of an hours play was a script that would run on load of my profile page (this is public to anyone within my organisation). The script would perform three actions,
- get the current users id – a simple GET request to an API method achieves this
- call an API method that gets all the personal info about that user. This would normally be displayed on your own profile only and not publicly
- make a final call to an external website, sending the data that has been captured
As I was trying to do this ethically, I added the script to my profile as an onclick with a warning explaining what would happen if clicked, then I tried on my own profile. It was successful, I was able to extract my salary information. This was obviously not a good real-life test as I had access to my own data anyway. I enlisted a willing colleague and amended the script so that it would only extract postcode. The test succeeded and I had retrieved my first piece of personal information from another person.
I took my findings to HR and we created a test user with which I could attempt to extract their salary information. I changed the script back to extracting salary info and demonstrated that if the test user visited my profile I would be sent their salary information, which of course we tried and it was successful.
With the risk now validated, the decision was made in our organisation to disable everyone’s accounts until the vulnerability was fixed. That morning we had already opened a dialog with Hibob in anticipation of validating the threat, we sent details of the vulnerability, including the script used.
I wanted to take a further look to see what else you could do as I imagined this was the tip of the iceberg. But of course my account had been disabled. I set up a free trial of the application and it wasn’t long before I was able to craft a script that, if executed by an administrator, I would be granted administrator privileges myself. The exploit was the same, but with different API calls. All I would need to do is get the admin to view my profile. I don’t even need to do anything clever to find out which users are admins as it is a HR system, it is going to be the HR manager in your organisation. Getting the admin to view my profile would be a piece of cake. This exploit is the jackpot in my opinion. Once you have admin privileges you can do anything inside that organisation’s account: Manage users, access personal information/documents on any employee (past and present), be destructive (delete records). Privilege escalation is one of the most serious exploits and much more rare, this had me excited that I had achieved it so easily but it also reminded me how much security is out of your hands as consumers. I would say you are better off “unplugging” from the internet, but as a developer that would put me out of the job!
It’s easy to forget as a developer how big an impact one XSS vulnerability can have. You can have the best security out there but it takes just one mistake to make all the other measures obsolete. To reiterate how severe this vulnerability was, I have listed the personal information I was able to extract:
- Salary information (past and present)
- Bank account number and sort code
- National insurance number
- Passport number
- Date of birth
- Address
- Personal phone numbers / email addresses
- Information about any dependents
Just a couple of those bits of information would assist in identity theft but the list above is staggering.
Hibob have a page on their website talking about security. They certainly say all the right things. Here are a few quotes.
“Is my data secure? In a word, YES!”
“Our site and API undergoes independent, ongoing 3rd Party penetration testing, security scans, threat detection and black box assessment.”
“We do everything that is technically possible to protect it.”
https://www.hibob.com/security/
On 15th May, 6 days after I found the issue, Hibob confirmed that the vulnerability had been fixed. In addition, they said they had identified an issue with the XSS filter on their Web Application Firewall (WAF) which they were addressing. I am glad to see that they took the situation seriously, investigated and fixed the hole quickly.
I have since taken a look and can see that the affected field now removes the event from the tag when output to the page (onclick, onerror etc.). It still allows scripts to be submitted and stored, but prevents them from running by encoding when output to the page. I’m not entirely convinced this is the right approach. Sanitisation of output is happening, but why would you not do a level of sanitisation on storing the data as well? If you block the script before it is stored you limit the risk of it getting displayed later. By allowing the script to be stored, you must ensure that every place that content is output is correctly encoded.
The hole I identified has been fixed so it cannot be abused going forward. Hibob say that edits to fields are logged and they are in the process of checking if an attack has ever been carried out. I asked how long the vulnerability had been there, they are investigating that currently so it is not known whether the vulnerability was missed by penetration testing or introduced afterwards.
I contacted Hibob for comment in relation to the vulnerability I had identified but did not receive a response.
This is a reminder to developers and internet users to be vigilant. More so for developers as we are in a position to protect people against attacks. In this instance, there is little the user can do to protect themselves. Users don’t decide what HR system a company uses, and therefore don’t get a say in their data being stored there. Companies adopting systems like this are being told that the system is secure, and this is backed by third party security testing, ISO and SOC2 certification. Where do you draw the line with trusting a system?
I have heard a lot about bug bounties in recent years. It is something I feel this system could really benefit from. Bug bounty programs are becoming more popular and will only become more widely used as time goes by. They provide a process for groups of ethical hackers to find holes in your system in return for a cash reward. Companies buy into it as a way of ensuring a higher level of security. It’s an alternative or compliment to traditional penetration testing. They can be really effective and lucrative for the hackers involved. Earlier this year a hacker was the first to reach $1 million on HackerOne.
If you are a developer, I would strongly advise you take a look at doing a security course. There are free ones out there. I have come across the Hacker 101 course from HackerOne. I am yet to take it but know it can only help me understand the threats better and ensure that I am doing my best to protect the systems I develop.
Below is a demonstration of the exploit (which has since been fixed).
Ben Richardson 