A pain in the backdoor — The importance of package integrity checks
Unfortunately malicious intrusions are a part of life. Products such as Tripwire do a great job of keeping an eye on your file integrity, but what about package integrity? You can set up a cronjob of your package manager to check integrity, but few take the time to set this up. Take a look at this blog by Bear Giles for a taste of what’s involved. As he mentioned: “At first glance this sounds like it’s just a second way to implement Tripwire but there’s a huge difference – provenance. If I use ‘tripwire’ I have no reason to trust the initial set of files. That’s not the case with package metadata.” To borrow the Trojan tagline, package metadata checks are: “The pleasure you want, the protection you trust.”
Many servers in this world only rarely get a package integrity check, and often only when validating an initial deploy, or troubleshooting a server that has clearly been compromised. Packages will sometimes go wonky due to hardrive hiccups, but packages also provide a perfect avenue for a backdoor. Daniel Cid wrote a good blog about a particularly nasty Apache binary backdoor that could go unnoticed for way too long without a package integrity check, since attackers don’t need any additional files to act as a backdoor and just use the Apache binary for it. Here’s a brief explanation re-quoted from there:
“Linux/Cdorked.A is one of the most sophisticated Apache backdoor we have seen so far. Although we are still processing the data, our Livegrid system reports hundreds of compromised servers and thousands of potential victims. The backdoor leaves no traces on the hard drive of compromised hosts other than its modified httpd binary. All the information related to the backdoor is stored in shared memory, the configuration is pushed by the attacker through obfuscated HTTP requests that aren’t logged in normal Apache logs. This means that no command and control information is stored anywhere on the system.
The HTTP server is equipped with a reverse connect backdoor that can be triggered via a special HTTP GET request. It is invoked when a request to a special path is done with a query string in a particular format, containing the hostname and port to connect. The client IP of the HTTP dialog is used as a key to decrypt the query string as a 4 byte XOR key. Additionally, IP specified in X-Real-IP or X-Forwarded-For headers will override the client IP as the XOR key. This means we can craft a X-Real-IP header that will in effect be a “\x00\x00\x00\x00” key…”
So what to do? You could always set up that package manager cronjob I mentioned earlier, but there is an easier way. Simply use Metafor to detect package differences. Metafor takes care of your package integrity needs by comparing hashes of your package metadata. It complements products such as Tripwire, for an added level of protection.
For best results I suggest implementing one of these solutions before the system gets compromised. Lest you create a self-repairing back door.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)