It is a nightmare for anyone running an Internet-facing information system when customers inform you that something strange going on. At first thought, you might think it’s user error, or maybe the only strange thing is the customer themselves. However sometimes when you start digging the case deeper, you find traces of suspicious activity or even actual changes done or even worse, something completely missing or replaced.
I had recently the pleasure to look into one of such events, when a customer’s Internet-facing information system, running an unidentified content management system (CMS) was found compromised. The customer noticed that things, things that the intruder did not intend to change, had changed, and therefore started to ponder what is going on. For the benefit of this system, built using nonstandard methods and layouts, made the attacker vulnerable to be noticed at the early stage. Since the attacker was using more or less standard procedure, as many do, she assumed that her changes to the system will go unnoticed for a long time. Indeed this is the core aim for any persistent attacks; to stay under the radar as long time as possible. For this intruder, it only lasted a week.
All CMS inherit the systemic vulnerability of browser-based applications, where functionalities are embedded into the content, causing heavy maintenance overhead to the publishing process to ensure that no such process instructions are found inside of the content, in this case text, itself. As these kind of vulnerabilities are very common, this attacker tried to exploit it by introducing a hidden change to the CMS formatting specifications to allow any of such formatting on both the server- or client-side. She assumed that by only changing the content format definition to allow such instructions to be embedded would not cause changes on the surface. And indeed in many cases, they would not. But luckily in this case, the content was laid out in a way which revealed the slight change immediately and widely. In the case this would remain unnoticed, and the access to the system would remain, the system had been converted in effect to a malicious nest of worms and other nasty creatures. A nest which would not look like a trap for the user, but instead an innocent customer service department or breakfast room.
Furthermore this attacker was not of the best or most diligent kind of them as she gained access to the system using a stolen password and did not clean her traces (i.e. logs) and the whole of her conception of a backdoor was just a bunch of custom-made admin accounts easily spotted among the real ones. But she was clever enough to take her time, kindly waited what will happen, and not proceed too quickly.
What remains under investigation is of course who did all this, and there is clear evidence on that. Of course you could be creative, and ask if it’s done by the one who granted admin privileges to his/her legitimate login credentials, or was it the parasite like creature who tried to build her house on neighbour’s soil? After all, she was just trying to set up yet another launchpad for her, where she could live and stay — maybe because she was kicked out from her previous accommodation?
As a final note, easy ways to defend this kind of parasites; keep your password policy clear and enforce it, do not do anything in cleartext in public, read the manual, don’t underestimate the lower level border around maintenance interfaces and most importantly do things a bit different than others. The last advice is crucial, as most of the exploits are developed against a rather stable environment, a slight change in the setup or just behaviour might uncover if not invalidate them quicker than you think! And yes, please do remember to perform regular backups.
Author
Kristo Helasvuo, Guest Author.
Comments