Archive for June, 2010

Side-channel attacks for Software-as-a-Service

Sunday, June 27th, 2010

Side-channel attacks (SCA) are usually associated with high-tech equipment used to monitor power consumption and electro-magnetic emanations of a smart card. Yet a web server thousands mile away can also by attacked using SCAs. As shown in a recent research paper, monitoring how much information was received and how much time it takes, allows the attacker to find out what encrypted information was received by a web browser.

With software-as-a-service becoming mainstream, more and more applications are delivered to the client through the Web. Unlike a desktop application, a web application is split into browser-side and server-side components. A subset of the application’s internal information flows are inevitably exposed on the network. We show that despite encryption, such a side-channel information leak is a realistic and serious threat to user privacy. Specifically, we found that surprisingly detailed sensitive information is being leaked out from a number of high-profile, top-of-the-line web applications in healthcare, taxation, investment and web search: an eavesdropper can infer the illnesses/medications/surgeries of the user, her family income and investment secrets, despite HTTPS protection; a stranger on the street can glean enterprise employees’ web search queries, despite WPA/WPA2 Wi-Fi encryption. More importantly, the root causes of the problem are some fundamental characteristics of web applications: stateful communication, low entropy input for better interaction, and significant traffic distinctions. As a result, the scope of the problem seems industry-wide. We further present a concrete analysis to demonstrate the challenges of mitigating such a threat, which points to the necessity of a disciplined engineering practice for side-channel mitigations in future web application developments.

No Comments

Please Continue to Hold

Monday, June 21st, 2010

Almost every security measure makes the life of its beneficiary more difficult, and thus those who stand to gain the most are also the most likely to breach security regulations. This subject – the topic of a recent research paper shows that in order to avoid this unfortunate situation, it is better to explain why the security measures are needed.

We found that subjects were significantly more likely to cheat or abandon the task when provided with non-security explanations or a vague security explanation for the delay. However, when subjects were provided more explanation about the threat model and the protection ensured by the delay, they were not more likely to cheat than subjects in the control condition who faced no such delay. Our results thus contribute to the nascent literature on soft paternalistic solutions to security and privacy problems by suggesting that, when security mitigations cannot be made “free” for users, designers may incentivize compliant users’ behavior by intentionally drawing attention to the mitigation itself.

No Comments

Automobile Hack – We Should Have Known Better

Tuesday, June 1st, 2010

No one in the automotive security industry could miss the recently published news article titled “Beware of Hackers Controlling Your Automobile”, published here, and a similar essay titled “Car hackers can kill brakes, engine, and more”, which can be found here. In short, it describes how researchers succeeded in taking over a running car, messing with its brakes, lights, data systems, and so on.

As alarming and and serious as this is, it should not come as a surprise.

Just before we begin to discuss the attack, there is one fact that should be emphasized, which is not emphasized in the articles: the hack, while carried out from a vehicle driving at a short distance, did not actually involve taking over the target vehicle without the driver’s consent, e.g., over a communication link. Carrying out the attack required that the attackers connect, physically, to the CAN bus of the car. They did it with a laptop that was physically connected to the CAN bus inside the target car, with said laptop also maintaining the wireless connectivity to the other car (from which the attacks were launched). As of today, there is no clear way for an attacker to reach the CAN bus from outside the car using wireless connectivity alone.

This should not make us feel much better, though. The fact that no such clear way is known today does not mean that such a way will not be found tomorrow. Consider that paths need not be “formal”, designed, ones. If there is an application in the car that connects on one end to a wireless network and on the other end to the CAN bus, and if this application has some flaw that allows it to be properly exploited, then the path from the wireless network to the CAN bus can be formed without having to install a laptop (or any other device) within the physical premise of the car. So keep using your car, but keep reading the news as well.

What I wanted to discuss is why this attack should not come by as a surprise to anyone. It seems as we make a same mistake again; a mistake we’ve made in the past, and thus should have known better. The mistake is designing a system with a hard external shell, which is very soft in the inside. We already tried this with networks on the Internet. Back in the nineties, it was widely accepted by most IT people that as long as a firewall is installed to isolate the corporate network from the Internet, not much else needs to be done, e.g., to protect internal components from each other. As long as the bad guys are kept out, why do we need to fortify what’s in? We then learned that firewalls can occasionally be bypassed, and that most attacks involve insider components anyway. Every network security manager knows by now that while a firewall is necessary, internal hosts need to be hardened, almost as if the firewall did not exist.

When designing car networks, it seems as we forgot what we learned when designing corporate networks. The CAN bus has no meaningful security of its own, and most applications using it are not any wiser. Instead, the entire vehicular system derives its security from the fact that the bus only spans the physical embodiment of the car, where all components are presumably cooperative and non-evil. As soon as an internal component becomes evil, either because it was taken over by an attacker exploiting a flaw in it, or, as was just demonstrated, because it was planted by someone else with different interests and morals, the system breaks apart.

What can be done? Use our past experience and wisdom to build security in the car network as we do in the corporate network. Entities speaking to each other need to be securely authenticated, and some access policy needs to be enforced. Design the internal network as if outsiders can get in, because one day they will.

In a paper of mine, Intra-Vehicle Information Security Framework, I discuss a system that, among several other security features, provides for secure messaging between car components. Secure messaging would allow the brakes system to be able to tell signals coming from its valid controllers apart from signals coming from an outsider’s laptop, even if this laptop can access the CAN bus. As opposed to other secure messaging systems, it was built for low latency even on resource-constrained devices, to suit the typical vehicular use-cases.

We got very smart in network security over the past twenty years. We already paid the price of learning from experience. Let us not re-pay it; especially where the cost might be higher.

Taken with permission from Hagai’s Blog.

No Comments