Symbiosis in Malware

In nature, we find special relationships between organisms where one organism acts as a host for another. In other words, the hosting organism is part of the hosted organisms life cycle. These kinds of relationships are called “symbiotic.” Three common types exist:

1. Parasitic- In a parasitic relationship, the hosted organism gets benefits from the hosting organism. This may be in the form of nutrition, shelter, protection, etc. The distinguishing feature of this relationship is that the hosting organism is harmed–albeit perhaps in a small way– by the hosted organism. Some examples are fleas, tapeworms, and bot-fly larvae.

2. Commensalistic – A commensalistic symbiotic relationship is similar to a parasitic relationship except that, while the hosted organism gains benefit from the hosting organism, it does no harm to that hosting organism. Birds nest in trees, remoras eat the food scattered about when the shark eats, and neither does any perceivable harm to its host.

3. Mutualistic – A mutaulistic symbiotic relationship is, as you may have guessed, is a relationship where both organisms benefit. A bird that feeds on parasites in a crocodiles teeth and the clown fish that both protects and is protected by the anemone are good examples.

Much like in nature, computer malware (viruses, trojans, worms, etc) has a life cycle that relies on a hosted system to thrive. Malware, by nature, is parasitic. Even if it’s not actively doing damage by destroying files or rendering systems unbootable, it’s still sapping system resources. Because it does harm, there are two consequences. First, harm being done is usually in some way detectable. Second, because it does harm, system owners typically want it removed.

However, malware has by and large shifted over the years in both its design and purpose. Viruses were at one time more flamboyant and overtly harmful. Windows would pop up on the screen to inform you that your system had just been “pwned.” Often these windows would bear some moniker or handle of the perpetrator. Some viruses would destroy or encrypt files, and boot sector viruses would render systems unable to even load the operating system. These viruses were written usually by individuals or small groups for the purpose of notoriety. “Bragging rights” was usually the goal. Because of the attention such viruses drew, attempts were quickly made to remove them. While many viruses made international news, they typically did not survive for a very long time. Overtly harmful malware has a short, albeit flamboyant, lifespan.

Today, the primary focus of malware producers is financial or political gain. Their focus is persistent presence on systems, using them in collective networks known as “botnets” to send spam or perform attacks. The goal is to remain on your system for as long as possible. Anything that would draw attention to the malware, like pop-up windows or system file damage, would be counter-productive. The malware is written to sit in the background performing its task while the user works on that spreadsheet or plays that game. The user should have no knowledge of the malware’s presence. This is what producers of malware desire, which brings us to the point of this article.

As I wrote earlier, malware is parasitic and does harm. Harm raises alarms and is usually detectable. In the shift in focus, modern malware is less parasitic and more commensalistic. Like the remora eating the scraps around the sharks mouth, the malware seeks to reap the benefits of the system. Should the remora do harm to the shark, it might get eaten itself, thus ending the relationship.

Malware writers would rather the malware’s relationship with the system to be purely commensalistic. If no harm at all is done to the system, the malware could sit on the system like the bird in the tree, undetected and unhindered.

However, here is one place where the parallels between symbiotic relationships in nature and in computer systems break down. In nature, commensalism exists where the hosted organism does no harm, at least measurably, to the hosting organism. Even if malware does not destroy files or produce pop-up windows, it still uses (or steals, rather) system and network resources. And even if it could by some technical miracle reduce the amount of resources being used to practically nothing, there is still the issue of permission.

We differ from trees as organisms in this illustration in that birds do not require nesting permission from trees. Though the birds do no harm, if we were the trees we may be shouting “hey, who gave you permission to nest in my branches? Get out!” We demand our sovereign system rights, and an application had better not install unless we allow it. The Sony root kit fiasco of several years ago is a good indication of the dander to be raised when software is installed on people’s systems without there permission.

Also, we forget the concept of ownership when we deal with the natural aspects of symbiotic relationships. While a tree might not “mind” the bird in the branches, the owner of the property where the tree is planted might not like the birds on the trees. Trespassing, regardless of whether the trespasser does any harm to the property, is still regarded “harm” in the minds of many, therefore the relationship between system and malware could never be considered commensalistic without permission being granted by the owner, and unless the malware provided some measurable benefit, this permission would normally never be granted. If these measurable benefit did exist and the harm was negated, the relationship would be mutualistic rather than commensalistic.

This permission would also need to be freely given, not based on extortion-like threats. If malware provided benefit but threatened to destroy system files if attempts were made to remove it, this would still be considered by most to be harm. Recently, I read the book “Daemon” where a complex form of intelligent malware began taking over everything. When the daemon took over a company, it promised absolute prosperity as long as it was allowed to exist and perform unhindered. Resistance, however, was met by not only financial harm but physical as well. Although companies thrived financially under the daemon’s control and both received great benefits, the relationship was built on extortion and could not be considered mutualistic.

Also, there could be no deception in a mutualistic relationship, for deception, by nature, is harmful. The malware could not prevent itself as something else. This would be no different than a trojan application. The malware would have to present itself honestly to the user. It would not need to disclose all that it does, however, just get permission from the user to do whatever it wants. In any case, the malware (if it could still be called that) would need to deliver on its promises. If it either harmed the system or failed to provide the promised benefits, it should be removable by the user. An invited guest that refuses to leave is no longer a guest but an intruder.

Even if all of these criteria were met, we should still reject such software. Though benefits may be realized and harm to our systems may be a thing of the past, surely this software is harming others. An ethical red flag should shoot up when we realize we are actually giving, in a digital sense, aid and comfort to the enemy. We should find the idea repulsive that our systems are being used to send out Viagra emails or being used to DDOS a newspaper website. People, however, are basically self-centered. Should malware achieve this level of mutualism, many will buy into it.

It’s probably pure fantasy to believe malware could ever have a mutualistic relationship with the system, and the efforts of malware writers to reach that commensalistic level are probably asymptotic at best. As malware approaches that line and fades more into the white noise of normal system services and activities, however, detection will become increasingly problematic.

Based on what I’ve presented, could it really be said that even our symbiotic relationships with legitimate software is truly mutualistic? Are companies truly up front with us about what their software actually does on our systems and networks? Does that document reader software company tell you up front of the resource hit you will experience when you use it or the network traffic generated when it attempts to update itself? What about vulnerabilities known but are as yet undisclosed by that company?

Should truly mutualistic malware arise, we should avoid it and do all we can to combat it. However, I doubt it will be that much less worthy of our trust than much the licensed software we install on our systems on a daily basis.

Posted in malware | Tagged , , , , | Leave a comment

Another Security Company Attacked — WAF vs. Code Review Redux

Earlier in the year, HBGary Federal was broken into by members of Anonymous. Last month, RSA was breached by an attacker and their SecurID products were most likely compromised. Over the weekend, an attacker who goes by the handle “Fdf” broke into a database owned by Barracuda Networks. Barracuda is well-known for its network security appliances. The Web Application Firewall (probably a Barracuda device itself) apparently went off-line for maintenance, and the attacker used that window of opportunity to use an SQL Injection flaw to obtain employee email addresses, phone numbers and other sales-related data. The kind of data compromised was not of a highly sensitive nature.

The attack is noteworthy for the simple fact that Barracuda is, like HBGary and RSA, a company that provides security products and/or services, especially pertaining to web application security. Hence, there is a quite a bit of irony involving a breach using a web application flaw on a website owned by a company specializing in web application security. However, the attack had nothing to do with their WAF appliance (except that it was apparently down at the time). The attack was based on a flaw in their application code.

One question I have is, how did the attacker know when the WAF would be offline? Was he probing constantly or did he just get lucky? According to this article, the attack was launched during the maintenance window. Lots of companies perform such maintenance over a weekend so maybe it was reasonable for the attacker to attempt an attack during this time, or maybe he had some additional intel.

Regardless of how the attacker managed to attack at just the right time, it’s hard lesson learned about having redundancy and not leaving yourself exposed in the way Barracuda’s web applications were allowed to be. I can imagine the reasoning behind it. “Well, it’s only a WAF and it won’t be down that long. Nobody will even notice. ” The odds were probably in their favor, and had I been in the same position, I might have made the same decision.

This is also an interesting, practical example of the PCI-DSS debate ongoing regarding the requirements for those subject to PCI standards to protect externally-facing web applications by either performing a code review OR installing a WAF (web application firewall). I’m not sure if Barracuda in this case is subject to PCI standards in this case. The server in question may be completely segmented from any part of their network where payment card data is processed. However, the very fact that WAFs sometimes are brought down for maintenance points to a flaw in the PCI DSS mentality that a WAF alone is sufficient to “..ensure these applications are protected against know attacks…”. SQL injection is a known attack. It is perhaps one of the oldest web application attacks. However, PCI-DSS does nothing to address how the WAF is configured, nor does it address the need for redundancy in case one needs to be brought down for maintenance.

So, will Barracuda review its code and fix the flaw in the script that led to this attack? We can certainly hope so. A more likely scenario, however, is that they will simply ensure that the WAF is back up and running. It probably costs less. Maybe they’ll learn a little and add some redundancy. However, my fear is that those others handling credit card data will take the easy path on the path to PCI compliance and install an appliance rather than fix their code. The attackers, meanwhile, patiently wait for that eventual maintenance window.

Posted in Application Security, Breaches and Attacks | Tagged | Leave a comment

The Ultimate Hacker Tool

A real threat has arisen on the information security horizon. I’m not talking about APTs or Anonymous. The threat I speak of is much, much more dangerous. I speak of a threat against the network infrastructures of entire nations. I speak of…old women with shovels.

Last week, an elderly woman in former Soviet Georgia was digging for scrap metal and damaged a fiber optic backbone cable, leaving almost the entire nation of Armenia without Internet access for several hours.

What we can learn from this is that sometimes the weakest link in our chain may be unknown to us. Armenia may have spent quite a lot of money protecting its infrastructure from APTs and other such threats, but their only physical Internet pipeline was buried under only a few inches of mud. Maybe it will make us consider our own infrastructures a bit more. Any attacker worth his salt isn’t going to spend precious hours trying to get around your WAF rules when much simpler–perhaps even nontechnical–attacks exist.

Posted in Breaches and Attacks, Hardware | Leave a comment

RawCap Portable Sniffer for Windows Released

One of the annoyances of packet sniffers for Windows has always been the requirements of WinPCap or other drivers just to get it functioning. RawCap has no such requirements. It runs as a standalone executable with no installation or libraries of DLLs necessary.  It’s a definite must-have for your portable tool collection on your USB drive.  There are a couple of caveats, however. According to the documentation, it may not work in Windows 7 and Vista and usage on Windows XP is recommended. Also, .NET 2.0 is required, thus making it somewhat less than portable. Thanks to @Mubix for bringing this tool to my attention. Find out more about RawCap here.

Posted in Tools | Tagged , , , , | Leave a comment

Times Square Video Hack

I saw this story linked on Drudge today about a man who was able to connect a video transmitted to an iPhone and use a repeater to transmit the video to any screen near the transmitter. He has a YouTube video on the link as proof.  The video looked convincing, but I’m going to have to cry foul. I could be wrong, but my gut feeling is that, unless these screens are receiving their video on a wireless signal, there would be no way to inject a signal. I suppose if the power of the transmitter were great enough, it might somehow get picked up, but It just seems a little far-fetched and works just a little too consistently.

 

 

Posted in Uncategorized | Leave a comment

New Site in Progress

Decided to rebuild the whole thing from scratch. This might be fun, but please be patient as I put together all the necessary bits.

Posted in Uncategorized | Leave a comment