HITB Amsterdam 2013 Day #1 Wrap-Up

I back in Amsterdam for the third time this month. Today, it is to participate to the Hack In The Box conference. This is already the 4th one, time flies! Like the previous editions, the event is organised at the Okura hotel, a very nice place. Thanks to the Easter break, roads were clear to Amsterdam and I arrived in time to register and grab some coffee.

The opening keynote was presented by Eddie Schwartz, the CISO of RSA. The title was “Embracing the Uncertainty of Advanced Hacks with Big Data Analytics“. Eddie started with this fact: “Uncertainty is a way of life for most of us“. What about security today? Edward started with an analogy to the movie “Moneyball“. In baseball teams, players are judged on the way (the power) they hit the ball. But is this statistic a good reference? Why not having a look at other stats like the time to run and reach the next base? Players are paid based on statistics. Can we translate this to the infosec landscape? To predict the future activities of people who will attack.  A funny quote: “If you got breached via your firewall, consider a job at a grocery store“

For most organisations, certainty is reached via audits. You get a nice ISOxxxxx certificate and feel safe (this is the case for most managers). Certainty is something people wants. We spend a lot of money to try to build some certainty but we need to embrace uncertainty: Do you know what will happen tomorrow? Some ideas were given by Eddie. First, the threat model must change (insiders, nation states, organised crime, hacktivists, others). Let’s look at data differently with this other example: A picture with everybody dressed the same (Elvis) but one of them has a bomb under his suit. How to find the bad guy? Interesting numbers reported by Eddie: How companies are spending their budget:

• Protect (80%)
• Detect (15%)
• Response (5%)

The next topic was: How can big data help in transform security? Don’t look for bad but for deviation of good. According to Edward, we need:

• Comprehensive visibility
• Actionable intelligence
• Agile analytics
• Centralised incident management

We are clearly facing a visibility problem: information is not normalised and difficult to analyse (this is not new). More data types you use, more complexity you add. Existing SIEM solutions were not designed to search so huge amount of data. Next, logs are not the only source of information. A level of intelligence must be added to help in detection of deviations. Infosec people must go from a focus on technology to business risk (from “ad-hoc” to “cyber-prophet” (nice term like “security evangelist“). Two teams have to work on specific tasks: A SOC will achieve more technical stff and a CERT will go deeper and track bad guys. More and more, everything you do will have relation with big data. More data you have, better it is. The analysts must have a prioritisation: Event capture > Investigation > Threat intelligence > Asset intelligence (life cycle). Very good keynote to start the day!

After a first coffee break, the regular talks started. My first choice was “Paparazzi over IP” by Daniel Mende. The title looked attractive to me and I was not disappointed!

Modern cameras have today network interfaces, they are “connected” devices! Daniel performed some researches to find security issues. His target was cameras manufactured by Canon. After all, they say it: “Canon, you can” … be exploited! 🙂 Some cameras have an Ethernet port, others have a WiFi adapter. Who are the nice targets? Journalists of course! When you read the price asked for some pictures (remember the “Paparazzi” in the title), you could imagine that data stored on cameras is very valuable. What if somebody could get the rough photos, unedited or upload bad images to the camera? Finally, what about turning the camera into a real-time monitoring device? Cameras use TCP/IP (btw, no IPv6 yet). Traditional attacks like ARP-spoofing works like a charm. It looks that the TCP/IP stack is unstable (it dies if IPv6 multicast is present) and established connections can be terminated TCP-RST. All we need to hijack sessions. They are several communication modes available:

• FTP upload mode
• DLNA
• Built-in web server
• EOS utility.

Using FTP, pictures taken by the camera are uploaded immediately to the defined FTP server (with configured credentials). Everything can be sniffed and extracted, even pictures. DLNA (“Digital Living Network Alliance”) uses UPnP for discovery and HTTP & XML to access media. No authentication, no restrictions! Joy! Every DLNA client (your browser) can access all the pictures! The Canon WFT server (“Wireless File Transmitter“) is a web server which exchanges information with the user’s browser via AJAX. Good news: there is authentication using HTTP Basic then session cookies are used. But the Cookie looks like “sessionID=40b1” (4 bytes – only 65535 possibilities) This can be broken in 6 lines of Python. This gives a full access to live view, stored pictures and some settings. there is only one requirement: somebody must be logged in! Finally, the EOS utility of “I wanna be root” 🙂 It sses SSDP & MDNS for discovery and PTP/IP for communications. An initial pairing PC/Camera is required. PTP/IP is something like USB over IP. (“Picture Transfer Protocol” – ISO 15740). Demo time! Daniel connected his camera to the network and it immediately generated mDNS traffic. His tool connected to the device, grabbed the settings, listed the files and finally took live pictures!

Photographs use insecure WiFi networks like Starbucks or hotels! Please guys, apply basic security countermeasures. Conclusions: it starting always from good ideas to improve daily job of people (photographs in this case) but implementation is done without security in mind. Next steps? New cameras have a built-in hotspot and will post movies and pictures directly to Facebook or Youtube. Oh joy!

The next talk was “Orchestrating a Fire Sale: Brining Dutch Alarm Systems to Their Knees” by Wilco Baan Hofman. Like in most countries, buildings in Holland are protected by alarm systems. Wilco performed some researches on the protocols used to exchange events between the alarm systems and their central management. His primary goal was to have more visibility: after all why alarms communicate only with their management centres? He found interesting vulnerabilities.  They are many protocols used by alarm systems. Some are analog (ANSI SIA, ANSI X/SIA, Ademco ContactID) while others are “over IP” (SIA-HS, Vebon SecIP, Chiron etc). Some are proprietary and others are standards based on countries. But all of manufacturers have the same problem: They make fatal assumptions and mistakes are made! Here are the assumptions:

• You cannot trust packets on the Internet,
• Same for source IP addresses.
• All packets from a session are from the same peer
• Nobody can decode this!
• If my product is certified, it is secure
• If nobody knows the protocol, nobody can decipher the message
• If my peer speaks the same protocol, it must be a valid peer
• Encryption is enough to make a connection secure
• Giving an alarm receiving centre the option to disable encryption will not lead to insecure deployments
• Alarm system electronics engineers can design secure Internet protocols

Before explaining the found vulnerabilities, Wilco gave some basics information about alarm systems. They are ATE (alarm devices), ARC (central management), PROM (buildings), etc. The first protocol reviewed by Wilco was SIA-HS. This is a protocol developed by Alphatronics and marked in the documentation as “impossible” to decipher. Really? A pattern with multiple repeating characters cannot be a valid crypto. Indeed, the data was just XOR’d… Big fail! Once the protocol dissected, Wilco wrote his own implementation of SIA-HS with nice features like pluggable handlers: logging to database, JSBONBOT IRC Event notification… (the free implementation is available here). Being able to decode the protocol used between the components of an alarm system may have huge security implications:

• MitM attacks
• Send false alarms (while remaining anonymous!)
• DoS the alarm centre ops
• DoS the Police response

Do you remember Die Hard 4? We are very close to this scenario! The next protocol dissected by Wilco was Vebon SecIP. It uses RSA 1024 bits and AES communication. Looks secure. No! There is a lack of identify verification, insecure cryptographic padding and no forward secrecy. What about the responses from the affected manufacturers? Between Augustus 2013 and January 2013 , Wilco received no feedback at all. Then Alphatronics asked to remove the publication already made. Vebon & ENAI responded better and Chiron offered a properly configured ARC to aid testing. But it will not solve the problem: ALL the already implemented systems are vulnerable (all the firmwares must be upgraded) and customers using insecure protocols must be isolated to mitigate attacks. Like the previous talk, this prove that  security must be properly implemented!

After a (good) lunch break, talks restarted and my choice was “Nifty Tricks and Sage Advice for Shellcode on Embedded Systems” by Travis Goodspeed.

Reverse engineering basic feature of embedded systems can be done without shell code (ex: multi-meter) but to go deeper, shell code is your best friend. Embedded systems are based on 8, 16 or 32-bits micro controllers, no OS. Good news, defensive features are an accident (No ASLR, no NX-bit) Even “toys” can be use for malicious purpose if you have code execution rights on them! Applications are multiple, signal jammers, impersonation, etc. Some funny examples were given by Travis like sending keys to a Microsoft wireless keyboard using the Next Hope digital badge ;-). Then Travis reviewed different architectures and explained how to exploit them. Honestly, I’m always amazed by those real hackers (in the good sense) who manipulate hardware like this.

My next choice was Tal Zeltzer’s presentation: “Virtually Secure: Analysis to Remove Root 0-day in an Industry Leading SSL-VPN Appliance“. Why try to hide the name longer? Tal talked about the legacy F5 SSL-VPN solution! This research started with a need to perform a pentest. So, are SSL-VPN appliance “secure“? The goal was to get command execution on the appliance called “FirePass“. Note that this appliance has been replaced by another model. It has legacy support but it is still used in many organisations! The research was performed on a virtual version of the appliance. This has pros & cons like the impossibility to develop memory corruption exploits. There was a “vulnerable” version of the appliance but it was impossible to activate it. So, Tal used another one and started to look for 0-day exploits. The appliance offers:

• HTTP(S)
• SSH
• Some PHP code

It was difficult to get even the kernel version using debug tools. So, the disk was mounted and explored with another OS. The main filesystem was encrypted using losetup & GPG (available on the clear filesystem). But without the password, no luck. The next step was to replace losetup with a Busybox shell to break the boot process. Tal got a shell. Then he installed a debug shell (added to init.rd) and were able to play in a whitebox environment without any restriction. The installed software was based on very very old versions as seen on the picture below:

The appliance was running “f5sshd“, a modified version of the SSH daemon. This one adds a feature to provide remote access to the F5 support team. PHP scripts were downloaded but… unreadable! The next step for Tal was to find a find to read them. The character distribution showed that the files were compressed or encrypted. Tal enabled the MySQL log (fo write down all queries). This is more convenient to detect SQL injections. Apache configuration was also reviewed for interesting modules. One found was tunnel-handler. The URL (https://xxx/tunnel) was tested and SQL injection found! It was more difficult than expected due to the very old MySQL version installed. But once done, root access gives you everything you want like adding users, sniffing traffic etc. But what about attacking clients? What about pushing a rogue version of the software to clients? Good point: F5 response was quick and positive. They did a good job and fixed the vulnerability in a few days. The presentation finished with a live demo! I like the way the speaker presented the research. It was like reading a book or a scenario with twists and solutions! Great talk.

After another coffee break, the last two presentations of this day! Philippe Langlois presented “LTE Pwnage: Hacking HLR/HSS and MME Core Network Elements“. Philippe is well-known for his deep knowledge of telecom solutions. LTE means “Long Term Evolution“. A fact, big players are thinking about putting their solutions into the cloud. Good news for researchers, if you can put it in the cloud, you can reproduce your own cloud at home!

LTE security remains for a while on NAT even if we know that NAT is not a security mechanism. What will happen when they will use IPv6 (which dropped NAT). A fact: more protocols, more services added by telecom operators, more servers and networks are required. This increases greatly the attack surface with new targets. Fuzzing, DoS, attacks remains the same. Philippe reviewed lot of different security issues based on mis-configurations or bad design. To conclude: Telecom infrastructures are using critical devices but security is a fail… as usual we should say. Operators are disinformated by vendors, hopefully some are getting proactive.

So, based on Philippe’s talk, you are thinking about switching from regular communications to alternatives like social networks? Bad idea! The last talk of the day targeted Twitter. Nicolas Seriot presented “Abusing Twitter’s API and OAuth implementation“. For a while, Twitter is well known and not a startup anymore. They had to adapt their infrastructure.

The OAuth API was introduced to enforce security. Twitter even imposes multiple constraints to developers writing clients (such as display requirements). Since last month, every request must be signed! Nicolas’s question is: can a rogue client spoof the identity of a regular client? He explained the basics of OAuth. How can 3rd party services use your account without knowing your password? xAuth is another method using one phase authentication. And finally, “App only” authentication is a new method to just get a timeline (bearer token) in all cases, consumer tokens are needed to authenticate with Twitter. So, if we have those tokens, we can spoof a client identity. Nicolas explained different methods with live demos:

• First technique: use strings against binaries
• Another technique: dump functions return values. (gdb is a good tool for this)
• Another technique: dump reallocated pointers (using dtrace)
• Finally: dump the whole process memory (keep in mind that everything remains in memory when a process is executed)

Non technical sources can be used: search Google, GitHub or Pastebin! Finally, Nicolas presented his own library called STTwitter (source here). What are the conclusions of this research? From a security point of view, OAuth to the desktop is a bad idea because keys it can be easily accessed. xAuth sends the password over the network. App Only auto is dangerous! It’s easy to perform a denial of service by exhausting the limits of a valid application, OAuth has two issues: Password change does not invalidate existing access tokens and badly co figured applications expose the tokens. So, why twitter tried to control the clients? The presentation ended with a nice demo of a Mac OSX twitter client crash, so easy! The research is available here.

Well, this is done for today! Stay tuned for more tweets and a wrap-up of day 2!