Your mission, should you choose to accept it
We were contracted by an organisation in the UK education sector, to test the security of their external infrastructure. In essence: for anyone with access to the internet, what damage can they cause by accessing only internet-facing applications? In this case study, we’ll show how a simple error message appearing on a single web domain was be used to gain a foothold on the organisation’s email system, eventually leading us to compromise the email address and backup recovery keys for every user on the organisation’s IT network.
More info, more problems
During the scoping stage, the client gave us a list of IP ranges and URLs they wanted us to test, including their webmail servers. One of the assets was a URL showing an error message. But the error message was verbose; it gave more information than it needed to, information which could be used by attackers should they wish to conduct a cyberattack. The text of the error message included the details of a “crypt server” and the email address of someone at the organisation – presumably its creator. By Googling “crypt server”, along with some details provided in the error message, our penetration testers turned up some open-source code on GitHub for an application that stores recovery keys.
We surmised that the email address was probably one of the developers at the organisation who had set up a webpage several years before. But a malfunctioning piece of code meant that the webpage with its detailed error message was publicly accessible. Although obscure, any attacker using an IP scanner who wanted to conduct research into the organisation would be able to find the page.
If your admin password is “password”…
Some cursory research on GitHub revealed that the web application code for the “crypt server” came preconfigured with a default admin password – “password”. Our penetration testers used those credentials on the login page (whose URL was specified in the error message) to log in to a vault storing backup recovery keys for every user on the organisation’s IT network, linked to their email address.
At this point, we contacted the client to let them know that this was unsafe. While the penetration tester’s mindset is that using default credentials for sensitive information is dangerous, the attacker’s mindset views that same information as a useful stepping stone to the next stage of their attack. The question on an attacker’s mind will always be: How can they escalate their access privileges or pivot to another part of the network?
Can you hack a password reset manager?
The next asset we tried to compromise was a password reset manager. Using one of the email addresses from the crypt, we decided to attempt a password reset. Rather than receiving an email containing a password reset link, the user could reset their password within the application using the answers to their security questions.
Naturally, our pen testers grabbed an email from the vault and attempted to reset the password in the application. To answer the security questions, they would have to gather some open-source intelligence from social media. It did not take long before one user’s Facebook account yielded possible information on the answers to their security questions.
Worse still, the password reset function allowed the user to see whether the password they had entered was incorrect before they clicked “Submit”, allowing our penetration testers to see their false answers in the text field, without entering an incorrect too many times and risking an account lockout. Using clues from the Facebook account, they correctly guessed the answers to his security questions and successfully reset the user’s password.
With a new password, our penetration testers now had an email account and attempted to log in to various IT platforms on the organisation’s network. By trying to log in to one of the applications for staff, we discovered that we were able to access the organisation’s Microsoft Outlook email domain. This meant the login credentials we had compromised were credentials for that user’s domain account, and we could successfully log in to a variety of services on the organisation’s IT network.
Bonus round: hacking MFA to imitate a web developer
The last asset in the scope was a login for web developers. While we could try the same techniques as before (taking a username and conducting a password reset), web developers at the organisation required a two-factor authentication to login. The next tactic our penetration testers would attempt was to take an email address and spam it with repeated requests for multi-factor authentication until user finally accepted the request.
Unfortunately, we didn’t have time to complete this tactic on the engagement.
Our recommendations
There were a number of security flaws and misconfigurations that led to the compromises achieved in this penetration test. Our security recommendations were as follows:
- Remove any verbose error messages. The original error message that led to gaining a foothold was left there by the developer debugging the application. These should be turned off for live websites.
- Disable debugging for live websites to prevent verbose error messages
- Whitelist IPs for webpages that are no longer needed, and only allow certain IP addresses to access them.
- Change all default credentials for administrator accounts to web and network services.
- Change the controls around password reset managers so that users can only reset their password from a link sent directly to their email.