Friday, 20 June 2008

A more detailed description of the Jura F90 vulnerability

The issue is a lack of input validation. OWASP would be a great learning exercise for the coders on this product. It seems to be assumed that only trust-worthy users will connect only to trust-worthy sites. I could not find any evidence of input validation.

Through the magic of Web Scarab and Paros proxy, one can capture the Internet communications used by the F90 Internet Connection Kit software. What you soon see is that the software does not account for either bypassing the local application and changing the input or in spoofed and re-directed sites.

The software does not validate the site it gets the information from nor does it sufficiently validate the input to the software.

At the moment as I think there are so few people as crazy as I am who actually have to have a gadget just as it is Internet connected; this is not likely to become a widespread attack vector.

The software is an oversized web proxy with other stuff to connect to the coffee machine thrown in. Jura did not make the assumption that an evil attacker could purposefully modify and publish “evil” coffee “recipes.

I have been taking the updated SANS@Home 610 course. I have a GREM, but Lenny and the other guys have added an additional component to the Reverse Engineering Malware Course. So I had to take it.

The course focuses on analysing and reversing malware, but IDA and Olly work on binaries of all types and the bad combination of a bottle of good resiling and 9 coffees after midnight is not a good combination. Hence I decided to attack my coffee maker and the control software.

There are certain aspects of code (like the ever faithful GETS() function) that should be beaten from existence. Others need to be securely configured such that all the required variable fields are entered correctly (see SPRINTF()). Unfortunately the coders at Jura did not consider that “bad people” would ever attack a coffee maker ;).

There are 2 main attacks that I have noted,
1 Loading a malicious setting or recipe into the device causing a “coffee overflow” etc.
2 More seriously, not validating the input correctly coupled with a lack of authorisation of the source and nothing to stop invalid data at the host means that malformed strings can be fed to the software that can either crash the system or if crafted correctly run a binary on the host.

So, as most people who check this list I no doubt know, not validating input is bad. Trusting the web as you have a piece of custom software that is closed source and a belief that users are all nice is bad.

No comments: