TL/DR: The past six months have brought some herculean security issues such as Log4j and the more recent Spring4Shell. It’s now not uncommon to hear about computer systems getting breached and criminals dominating the underground economy. Could it be that the digital transformation that the entire society has gone through made it more vulnerable? Have we lost control of our digital life? In this blog post, white-hat hacker in TV series Hackad and co-founder Sprinkler Security David Jacoby uncovers some of his real-life hacking gigs exposing the technical details that made it possible for him to compromise his customers.
When I look at IT security I can clearly see how it has changed, being today much more mature now than it’s ever been. Governments are working on policies and legislation forcing companies to prioritize IT security. As a result, the entire bug bounty community has bloomed in a way that I could never imagine, security researchers are now working together with companies to identify and mitigate vulnerabilities in a way that we have never done before.
While the sector is slowly progressing, there are a slew of challenges when it comes to guarding your company’s data. One big problem is that we are not taking advantage of the information and knowledge we are exposed to. The IT-security industry is quite binary and divided into interest groups. We have people interested in network segmentation, malware analysis, system hardening, vulnerability management, policy and governance, etc, where each group has experts in their own fields. However, to ensure better collaboration between red teams and blue teams, you need to combine the knowledge of all of these groups.
Having worked in the IT-security industry for over 25+ years doing vulnerability and security research, as well as working as a professional ethical hacker performing penetration tests and red teaming, I can assure you that while companies can be good at one thing, for example, network segmentation, but can be extremely bad at for example vulnerability management.
It’s no secret that given the complexity of building IT security, it’s important that we talk about all components of IT security and learn how to combine red teaming results with vulnerability management, security awareness, and system hardening.
Thou shalt not commit a logical flaw
We have gone from hosting a lot of servers on-prem to having a pretty wide cloud-based infrastructure resulting in a host of security problems.
Looking back at one of my penetration tests, the scope was to obtain access to the corporate network, which was not the easiest task because the client had no external Internet-facing servers except a VPN gateway and their mail server. Their staff could access the corporate network through the VPN, and the VPN was not using usernames or passwords-only certificates so brute-forcing was not an option. Besides, we were also not allowed to attack the clients through phishing emails or exploiting vulnerabilities in their client software. I know what you are thinking – this is not the most realistic approach because an attacker would phish the employees… and I agree.
The scope was narrow and complicated, but they did have that mail server. The server was both hosting the MTA and a web mail software called @mail (AtMail). I found out that there were two versions of this software – community and premium.
After downloading the community version – which was the one being used by the client – I noticed there were some weird filenames on my webserver running the AtMail web app. At first, it seemed that any file attached to an email would end up in a specific directory in the webroot. But I was wrong.
The web application indeed had different behaviors. The normal behavior when attaching a file was that the attached file got uploaded to the server but using a temporary name deleting the file extension. For instance, if you attached a PHP file, the filename on the server would be random with the extension .dat. The problem here was that the temporary directory was part of the webroot which allowed attackers to list all temporarily attached files.
In the same folder some files were not using the temporary filename scheme, but files with their original names including the extensions. That’s when I noticed a logical flaw. After creating a new email and attaching a file, one could save the email as a draft.
This saved the attached file using MIME encoding which has a parameter with the original filename, and when you opened the saved draft, the attached file decoded using the filename variable in the MIME header saving the file on disc using its original name.
You could achieve a fill file upload without any issues. BINGO! By simply uploading a web shell to the web server, I got access to the machine as www-data. The server was both the web front end and the actual MTA, so when browsing the file system, I found all the users’ mail spools.
The scope was to access the corporate network, but the mail server was not in any way connected to the corporate network. The normal procedure for the company was to send the certificate to their employees via email, which is a standard way of doing things.
Through the access, I had to the mail server I could access users’ email spools, and inside the email spools I found the certificates, usernames and passwords, and installation guides on how to get VPN working. BINGO #2
Key Takeaways
- Your external facing systems need to be secure and not contain sensitive information
- Remote workers should always be forced to use MFA when accessing systems from the Internet
- Application Isolation is important, sharing resources is not always a good thing.
Game Over, Man!
Defining the scope of a penetration test is far from simple. How much access should we give the tester? What scenarios do we want to test? During this penetration test, my goal was to hack as many systems as I could and gain access to the sensitive parts of the network, for example, become domain administrator.
Performing a security test can be done in different ways – you can do it without any information, or you can fast forward in the testing phase and assume that you have breached a device. In this test, we used the “assume breach” scenario which gave me access to a computer together with a low privileged domain account. Organizations need to assume that some of their employees’’ technical devices (laptop, phone) do get compromised at some point. The question we need to ask ourselves is what can be achieved by the attacker if they do get access to ONE computer.
An attacker could extract information such as stored passwords, saved information in the browser, session cookies, and a lot more. In our testing phase, I did not have access to anything like that, but I did have access to the client’s network.
In many cases, it’s all you need to elevate your privileges or find account information giving you access to more resources. With access to ONE compromised device, attackers are able to pivot to other machines on the network and eventually elevate privileges to gain access to the internal network. If they obtain domain admin permissions it’s game over and they can compromise/infect large portions of the network.
With this in mind, I wanted to see if I could use my local low privilege account to elevate privileges. A little bit of sniffing around the network resulted in me finding the addresses of several domain controllers, this is the machines containing policies and account information for all your users.
This particular domain controller allowed me to dump all usernames connected to this controller. One attack which is extremely suitable right now is brute-forcing passwords, but this might trigger a lockout of the account which is something that we avoid.
Some domain controllers have enabled a feature, which will lock the account if the wrong password is entered more than – for example – three attempts. There is something that I have learned from my 25+ years of performing penetration tests, almost all companies have a default password for new accounts. These passwords differ from each organization, but for some weird reason there are a few passwords that seem to work almost everywhere such as “p@ssw0rd”, “summer2022” or “Password12345”. So I started to look for those passwords but without luck.
After some failed attempts, I took the company name and added “!” after the name and used “Summer2019” instead to see if some accounts just kept old passwords without changing, and BINGO!
It was almost embarrassing how many accounts still used these weak passwords. In the year 2022, we are still VERY bad at passwords.
With the new accounts, I could access their email and internal resources on the network, such as shared file storage. One of the shared folders was dedicated to the local IT department and, in this folder, I found source code and test scripts with usernames and passwords. These passwords were very high privileged and this resulted in me becoming domain administrator on the network within four hours.
All it took was one compromised device because the internal network was so extremely weak.
The main takeaway:
- Protecting your external assets are VERY important, but your internal network is just as important.
- Local hardening is super important; you need to assume that your devices will get breached.
You don’t know what you’ve got inside already
From weak and reused passwords to accidentally exposing confidential information online, the mix of risks could indeed be an abomination.
Most of my hacks have been simple and logical. While it might sound surprising, a zero day vulnerability is not the only way to break into your company. Almost all of the organizations that I have tested have had simple mistakes such as unpatched servers, credentials in clear text, and bad network segmentation among others.
One of the most effective attack vector is “password re-use”, and this is verified repeatedly when we look at how cybercriminals work. There are many different methods to protect against password re-use, such as two-factor authentication, but it’s not only the users who need to protect against this. Even with all the technology that we have out there protecting us against high-level attacks, we should never forget that a weak password might be the end of a company.
Companies – irrespective of their scale – need to make sure that their customer data is as secure as it gets, and that the services storing credentials don’t get breached. It’s all part of the ecosystem – if one side breaks, it affects all other sides.
The red pill to security is to do whatever it takes.
Written by:
David Jacoby, Founder/Hacker Sprinkler Security Sweden AB & Unbreached AB
With over 25 years of experience in professional hacking under his belt, Jacoby has been a technical advisor to some of Sweden’s most successful IT security companies. Among hacking various Swedish companies, he could get into a fully updated Mac without any hacking tools.