Broadband Caps Could Mean Consumers Pay for Bot-Net Traffic

The broadband caps proposed by Comcast and other home ISPs would mean that consumers would now be paying for excessive traffic from their networks, even when malware or bot-nets caused the traffic. Much media attention has been paid to the effect of traffic from spam and video ads used in normal web pages, but little has been said about the effect on consumers that malware infection could now have.

Imagine a simple malware infection that sends email. That infected machine could send millions of emails a month, easily breaching the modest bandwidth limits that some are proposing. How will the average consumer respond when they get warnings and then large bills from their network ISP for traffic that they did not cause? Imagine the help desk calls, irate customers and the increased costs of handling such incidents. How will the average help desk technician handle claims that infected systems caused the excess traffic?How will courts handle the cases when the consumer refuses to pay these charges and the ISP pursues their clients for the money?

Attackers are the real winners here, at least those interested in causing chaos. Effective attacks to cause financial damages and ISP cutoff against a known/focused target become all that much easier to perform. If you hate your neighbor and her barking dog, then you get her machine infected with malware and cause her to get a huge bill from her cable company. Do this enough and you can damage her credit, get her cut off from the Internet and maybe even interfere with her ability to earn a living (especially if she is a web worker). Heck, malware isn’t the only way – break into her wireless network or find it open to start with – and you have the perfect entry point for making her “iLife” a true nightmare.

Sure, some folks say these risks already exist without the added pressures of ISP bandwidth caps. They are right, they do. Some folks also say that these threats may make average consumers pay more attention to security. I think they are wrong, this will be just another item on a long list of ignored and forgotten “bad things” that happen to “other people”. However, I do think that these attacks should be a serious concern for the ISPs implementing the caps. The ISPs seem to be sharing a primary of claim that they are adding these caps due to bandwidth issues and the costs required to handle the current and future traffic. Yet, I would suggest that bandwidth caps are very likely to raise their support and account management costs exponentially – which could mean that they are shooting themselves in the foot.

Bandwidth caps are a bad idea for a variety of reasons (including stifling innovation), but they play directly into attacker hands and lend attackers a new spin on how to cause damage and chaos. In the last few weeks, much has been made of the recent growth in bot-net infected systems. Experts point to a nearly 400% increase over the summer months alone. Imagine the chaos and issues that could stem from calculated campaigns that wrangle those bot-net infected machines into breaking the boundaries of their ISP. Maybe bot herders would even change from holding end users hostage to targeting ISPs with bandwidth cap breaking storms that would trigger massive client notifications, calls to technical support and account management systems. Maybe attackers could figure out a way to use bot-net infected systems to cause “human customer denial-of-service” attacks against cable companies. I am certainly not rooting for such a thing, but it seems plausible given the current state of infected systems.

I just don’t see a positive for anyone coming from these ideas. I don’t see how they aid the consumer. I see how they could be used to harm both the consumer and the ISP. I see how attackers could leverage the change in multiple ways – given than many are extensions of existing issues. Generally, I just fail to see an upside. I find it hard to believe that consumers will be thrilled about paying for illicit traffic that they will argue they did not create and I can’t see the courts doing much to force them to pay for that traffic. I guess only time will tell – but it seems to me that in this game – everyone loses…

VMware Multiple Vulnerabilities

Multiple vulnerabilities were released for what looks like most versions of VMware. VMware Workstation, Server, Player, and ESX Server contain two vulnerabilities. The first of these is an unspecified error in the “OpenProcess”. This can be exploited by local users to escalate their privilege. From some limited Google searches I found that “OpenProcess” is an API function that must be being used by VMware’s core application.

The next vulnerabilities isn’t actually a VMware vulnerability as it is a freetype font vulnerability. CVE-2008-1806, CVE-2008-1807, and CVE-2008-1808 describe vulnerabilities in the font that can lead to the exploitation of systems (applications) using them. The same is true in VMware, if an application is using these fonts, then it’s possible to compromise the system via exploitation of the vulnerable application.

There appears to be an updated build for all version except ESX, which has an update pending.

CERT Warns of SSH Attacks

Earlier this week US-CERT warned of attacks using stolen SSH keys. After access is gained to the machine, a rootkit (Phalanx2), is installed on the system. Once installed, the rootkit steals other keys from the system and sends them back to the attacker, allowing them to compromise other machines. The rootkit seems to create a directory, existance of the directory /etc/khubd.p2/ indicates a compromise. However, it should not be assumed because it’s not there that the machine is not compromised. It’s believed at least some of these machines were compromised by the Debian SSL Key bug from the summer.

US-CERT has provided some mitigation strategies to ensure that machines do not get compromised by this exploit. First, identify and examine systems where SSH keys are used as part of automated process. Any instance where keys are used without passphrases, a  passphrase should be used to reduce the risk of a compromise. Finally, ensure that internet facing systems are fully patched.

Bank Data Sold On Ebay

A few banks had a wake up surprise when they found that one of their servers had been sold on Ebay. The system was bought for about $150, and was acquired by an IT manager. Upon booting the machine he noticed that there were several cd ISOs on the disk array in the server. In each of these cd images were backups of customer credit card applications. The banks were notified by the buyer, but it is unknown where the machine was between the time it was at the bank and when it showed up on Ebay. I’m sure the banks are scrambling to implement encryption on their backups as we speak.

Trend Micro Auth Bypass

An issue has been discovered some Trend Micro products, which can be exploited by attackers to bypass authentication. Version affected are OfficeScan 7.0, 7.3, and 8.0; Worry-Free Business Security 5.0; and Trend Micro Client/Server/Messaging Suite versions 3.5, and 3.6. Currently there are fixes for OfficeScan 8.0, and Worry-Free Business Security 5.0. It’s expected that patches for other versions will follow shortly.


Web Application Scanning Tools

There have been several publicized releases of web scanning tools this week. Three specific ones come to mind, that enable assessors to automate a large part of the web application/site assessments. With this, there’s a lot of buzz on mailing lists about these tools, so expect an increase in threat to any web facing applications or sites. All of these tools are freely available for download.

Internet Explorer Security Zone Bypass

It’s possible to bypass the security zones within Internet Explorer. An issue has been identified in the way that security policies are applied when a URI is specified in the UNC form: \\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE’. When a URI like this is accessed remotely, Internet Explorer does not apply the correct Security Zone Permissions. This issue affects Internet Explorer 5,6 and 7 under all versions of Windows.
Microsoft has released a work around for this issue. The work around can be found in Microsoft’s techbulletin for this issue. http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx

SPAM Backscatter

We are getting many reports of mail servers under heavy load because of SPAM backscatter. This happens when a spammer uses a company’s email address to forge the “FROM” field in the email. When mail servers get these spam emails and reject them because they are sent to a user that doesn’t exist, the SPAM targeted mail server will send a bounce back message to the forged “FROM” field. Now as you might imagine, when a spammer sends out over a million emails it’s very likely that many of those will go to addresses that no longer exist, and innocent company in the “FROM” field gets blasted by thousands of bounce backs.

What can we do about this though? Unfortunately if you’re the one getting the backscatter, not a whole lot. However, you can help to prevent backscatter for others. We recommend that email servers be configured to REJECT bad email during the initial transaction instead of accepting it and creating a bounce back reply. Also consider not using “out of office” email replies. This also creates backscatter when the vacationed user receives spam. This could also land you on a spam blacklist, if whoever got the backscatter happened to report your mail server as a backscatter sender.

Ignuma 0.0.9.1 Overview

I spent a few minutes this morning looking at the newest release of Ignuma. If you aren’t familiar with it, it is another penetration testing framework, mostly focused on Oracle servers, but has plenty of other capabilities and front ends a number of fuzzing and host discovery tools.

The tool is written in Python and has both command line and GUI interfaces, including a QT-based GUI and a more traditional “curses-based” GUI. The tool is pretty easy to get working and adapts itself pretty well to some easy scans, probes and fuzzing. In the hands of someone with skills in vuln dev, this could be a capable tool for finding some new vulnerabilities.

The tools is written to be extendable and the Python code is easy to read. It is not overly well documented, but enough so that a proficient programmer could add in new modules and extend the capabilities of it pretty easily.

The tool is still in heavy development and it looks like it could be interesting over the next few months as it matures. Keep you eyes on it if you are interested in such things. You can find the latest version of Ignuma here.