Posts Tagged ‘security’

Letting some air out the Tire Pressure Monitoring Systems (TPMS)

Sunday, August 22nd, 2010

Flat TireIronically when a security system contains flaws, it introduces new security problems.

Tire Pressure Monitoring Systems (TPMS) have been compulsory in new automobiles in the US since 2008. The TPMS is supposed to increase car security by reporting low tire pressure. Shortly after the plan became public, the security implications were obvious.

the people who are designing these systems are putting ”zero thought into security and privacy issues.

Now it’s possible to build intelligent improvised explosive devices (IED) capable of attacking specific targets! Or mines that will only disable vehicles with certain tires, e.g. those usually encountered on humvees, while leaving legitimate, civilian traffic alone.

Of course, the implications were obvious only to “professional paranoids”. Now, once the system becomes widely deployed, its security was evaluated is a recent research paper, excerpts of which are quoted below. And while the IED comment is meant as a joke, highway robbers are well known for making drivers pull over by puncturing their car tire.  The vulnerabilities of the TPMS show that they can virtually puncture the tire of a specific car.

This paper presents a privacy and security evaluation of wireless Tire Pressure Monitoring Systems using both laboratory experiments with isolated tire pressure sensor modules and experiments with a complete vehicle system. We show that eavesdropping is easily possible at a distance of roughly 40m from a passing vehicle. Further, reverse-engineering of the underlying protocols revealed static 32 bit identifiers and that messages can be easily triggered remotely, which raises privacy concerns as vehicles can be tracked through these identifiers. Further, current protocols do not employ authentication and vehicle implementations do not perform basic input validation, thereby allowing for remote spoofing of sensor messages. We validated this experimentally by triggering tire pressure warning messages in a moving vehicle from a customized software radio attack platform located in a nearby vehicle.

at the end of only two days of sporadic experiments involving triggering the TPMS warning on and off, we managed to crash the TPMS ECU and completely disabled the service.

We attempted to reset the system by sending good packets restarting the car, driving on the highway for hours, and unplugging the car battery. None of these endeavors were successful. Eventually, a visit to a dealership recovered the system at the cost of replacing the TPMS ECU.

No Comments

More functionality = less security

Sunday, July 11th, 2010

It’s often easier to make a complex system from ready parts. Instead of providing specific functionality, the resultingBusiness conference device does a lot more than you actually need. In so far as the system manages to do what is needed, nobody should complain about the extra functionality. However the extra functionality usually has severe consequences for the device’s level of security. An interesting example of this was presented at Hack in the Box this year.

A wireless presenter – designed to allow only a couple of functions (next/previous), easily achieved with a mouse and a keyboard – can allow someone to take over your computer while you make a presentation.

No Comments

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

New whitepaper available for download

Sunday, December 6th, 2009

Hagai Bar-El’s  technical paper entitled Intra-Vehicle Information Security Framework is available for download at http://www.discretix.com/resources/white_papers.html

No Comments

Please fill the tank, reboot the main CPU and oh don’t forget to clean the windshield.

Monday, November 30th, 2009

According to a recent article in the IEEE Spectrum, the cars we are driving (or at very least our managers) have more electronic control units (ECU) and lines of code than your typical commercial or military aircraft.

The avionics system in the F-22 Raptor, the current U.S. Air Force front line jet fighter, consists of about 1.7 million lines of software code. The F-35 Joint Strike Fighter, scheduled to become operational in 2010, will require about 5.7 million lines of code to operate its onboard systems. And Boeings new 787 Dreamliner, scheduled to be delivered to customers in 2010, requires about 6.5 million lines of software code to operate its avionics and onboard support systems. These are impressive amounts of software, yet if you bought a premium-class automobile recently, it probably contains close to 100 million lines of software code, says Manfred Broy, a professor of informatics at Technical University, Munich, and a leading expert on software in cars

Just like any other software, these millions of lines of code – parked in driveway – have exploitable bugs. A defect density rate of 0.4 defects per thousand lines of code combined with a conservative estimation of 5% of defects that are exploitable yields 2,000 exploitable bugs per 100 million lines of code!!!!!

So where does this leave the average commuter on the way from point A to point B. Probably quite afraid. Many of these bugs are an inevitable back door for hackers, raising serious security concerns.

Faulty lines of code are fact of life and there is not much we can do to pevent them, however some precautions can be taken to ensure that they are not exploited.

  1. Identify malicious code introduction targeted  at using existing exploitable flaws (e.g. secure boot and run time integrity verification).
  2. Allowing valid code images to be revoked and replaced with new, fixed images (renewability mechanisms).
  3. Preventing roll backs to faulty images (again, thru mechanisms like Secure boot and others).
No Comments