|[Backdated Post]||Date of finding: 13/03/2020||Actual date of publication: 25/10/2020||[Backdated Post]|
In this post I will talk about some incident response work I did for a non-profit organization dear to my heart.
One of their front-facing websites was experiencing trouble, it was redirecting some of its visitors to a strange human verification page..
Before reaching out to me they had already contacted their ISP and the developer of the website for help, both of which weren’t able/willing to contain the problem. No matter how many times the developer removed the malicious code from an infected page, the attacker would simply infected it again while spreading to other pages.
By the time they contacted me the website was already in pretty bad shape. Some links on their homepage pointed towards a 404 of their ISP, others pointed to a static page of the developer while some others were just blank 404 pages. The rest of the pages were redirecting the user towards some social engineering trick which tried to make the visitors accept (malicious) push notification. It was masquerading as a sort of intermediary human verification step, much like what you sometimes see when using a VPN service while trying to access Google services.
Since those SQLi issues were already raised four months ago in my vulnerability assessment, they contacted me.
I made sure to continually send my findings and recommendations to the staff.
In the first few days I discovered the following:
- The malicious human verification page where the users ended up was made specifically for Chromium browsers.
- It used chrome-specific API calls to request push notification permissions.
- The attackers inserted up to three malicious scripts into an infected page:
- Notably, this piece of malware was present in every page, even those not infected by the redirect script.
- Two redirect scripts, each using a different chain of redirects, one long and one short
(they could both end up in one of five landing pages which were variations on the same malicious human verification request with different images and styling).
- Before arriving at the landing pages there were many redirects, in varying amounts.
- I wasn’t able to find malware in the few redirection pages that I checked.
Then the worst-case scenario happened, the attackers successfully attacked and gained control over the admin panel, locking us out on their way in. By this time the staff had already redirected the domain to to another one, to safeguard the visitors. The staff established that the top priority was to find out if the attackers also infected a different important website which allegedly relied on the same database as the infected website. They were fearful the infection might spread to this other more sensitive website. I was to be tasked with fully investigating the attack, focussing on a potential spread via the database.
That marks the end of this tale. The website was quickly put out of its misery, defeated by complexity and cyberspace pirates.
Investigating a real attack was very interesting and I have learned heaps. Although I was presumably only asked to help out because they had nowhere else to go, I would still like to thank them for placing their trust in me. :)
The tactics that the attackers used were pretty ingenious, at least if I’m not reading too much into their actions.. Breaking only some parts of the websites with something rather innocent looking while lining the rest of the website with a hidden privilege escalating exploit. This way owners/administrators would be tempted to log in to their admin panels to check out what was happening, not knowing their sessions were probably the real target. Failing that, the attackers would infest every resource on your website, maximizing the amount of users which would be redirected towards their malicious second stage. I never figured out what the attackers had in store for the users which accepted these malicous push notifications though. I presume they could use it as a sort of C2 implant although this would probably require additional exploitation of the push notification mechanism in the browser. In any case, the implant would probably produce a pretty stable connection since cleaning out accepted push notifications isn’t something people do frequently, and neither is removing/switching browsers.
I was rather excited to take on this investigating challenge and was sad to see them give up on recovering their website. Although it was true the website was somewhat aged and the blend of plugins they used made it difficult to upgrade without making many breaking changes. I believe this last bit in particular to be the website’s undoing, if it would’ve been easy to fix they’d have done it.
The complexity of patching also deterred them from maintaining the website, which over time lured in attackers.
I would say complexity was the true killer of this website, a point I drove home in my later conversations with them. Luckily they have learned, and have aimed for simplicity and better security in their future digital investments.
Since this was now a repeat attack on Belgian websites I urged both victims to inform the Belgian CERT of their respective attacks. I also informed the non-profit in question about the privacy-implications of a full website takeover, GDPR-wise.