Hack.lu 2013 Wrap-Up Day #1

Here is the first wrap-up of hack.lu 2013 edition (I’m wearing today the t-shirt from 2008, this is already my sixth edition). As usual, the event started with a bunch of workshops. I attended the one presented by Matt and Kacper Why about Scapy. I did not event a deep knowledge of this packet manipulation tool. Not only, you can create, capture or manipulate packets but it is using the Python interpreter and can be easily integrated into your tools. After an introduction, some protocols were reviewed: ICMP, ARP, DNS and HTTP. Very interesting workshop!

After the lunch, the regular talks started with the one of Dennis Rellikaan & Thijs Houtenbos: “Automated vulnerability scanning and exploitation“. By reading the title, we could expect something around classic vulnerability scanner but it was something completely different. They started the talk with two questions:  First one: “Who downloaded scripts from the Internet?” then “Who checked for some malicious code in those scripts?” It is a fact: Most of us don’t. Their research was based on the scripts and applications published on well-known developers’ repositories: sourceforge.net and github.com. The idea was the following: how to find vulnerabilities in source code published and find which online services use them and are vulnerable? This was achieved in five steps:

• Collect the source code
• Analyse the code for possible vulnerabilities
• Exploit the findings in a local environment to confirm the issue
• Search for installation online
• Validate the findings.

• SQL injection
• File inclusion
• Command injection

• allinurl:”/page.php?page_id=”
• allintitle:”My Special script v0.2a”

To bypass, Google’s restriction, they used a set of different IP addresses with pauses of 8 seconds between each request to not trigger the filter. This resulted in 20K queries / day

They gave other statistics based on their findings and how they computed a score for each resource. This was a great research idea. The next question is now: how many systems are really exploitable?

The next presentation was called “Debugging and reserving the HTC Android boot loader” and presented by Cedric Halbronn  and Nicolas Hureau. All mobile phones have a boot loader. This is a piece of code executed when you turn on the device. Its goals are:

• To initialise the hardware
• To load the OS (Android)
• To restore the device to its factory state
• To update the phone

Why look at the boot loader? Regular users don’t care about it but… it can be used to also get permanent root access on your device or to install custom RPM (ex: Cyanogenmod). They are often based on closed source code and not updated very often. What about physical security and how can we get access? The research focused on the HBOOT used by HTC. Two modes are available: HBOOT and FASTBOOT. The first one allows to input commands, the second one is used to get ID or ref lash the device. They demonstrated that vulnerabilities exist in the HBOOT boot loader (using the command line). The speakers explained in details how they found and exploited this problem. Regarding the tools, they used gdbproxy.py which is a Python script interfacing gdb and the debugger in HBOOT. It works like a gdb server (using the RSP protocol). The talk was very technical and focused only on one device, the HTC Desire Z).

After a coffee break, David Guillen Frandos came on stage to present “Spin: Static instrumentation for binary reverse engineering“. Reverse engineering is definitively not my cup of tea but David was a great speaker and explained his research with simple words. He started with a short introduction about reverse-engineering (he goal is to discover how programs work – using a debugger). In the past time, assembly language was written by humans but, today, compilers do all the work and this sucks! Code is difficult to read and they are predictable, respect call conventions, etc. The idea of the talk was to take advantage of this to perform reserve-engineering. Let the machine do all the work? Possible? Can it replace a human? How far can we go in this process? This is the goal of “binary instrumentation“. What is this? David explained what’s this technique. It allows to modify and rewrite existing binaries. This can change their behaviour at execution time. Some tools are Pin, Valgrind. Those tools work at assembly level.  Can be used for performance evaluation, CPU emulation or tracing and profiling.  And for security purposes? We can create complex conditional breakpoints. Create more application logging / output or … modify the behaviour. To use binary instrumentation, let’s try to think like the application developer, let’s try to work on function basis (by using complex breakpoints, looking at the stack). By generating some logs with this info to discard most of the “boring” functions. David wrote its own tool to achieve this: Spin. This tool is used for instrumenting at function granularity. It runs in application memory space, allows to receive function parameters and, optionally, can modify return values. It works by patching call instructions, like the principle of DLL hooking. The demo was performed on Winzip… David demonstrated how to use this technique to restrict the human interventions to an “acceptable” level -> 6 functions -> register without a SN -). To conclude: it is possible to automate some reserver-engineering methodologies but there are limits: David’s tool is far from being perfect and it is not suitable for API hooking. Great research!

The next talk was presented by Joany Boutet and Tom Leclerc: “Grand Theft Android: Phishing with permissions“.  Some applications require way too much permissions and, this is a first way to detect them as suspicious. Remember: always review the permissions of an app before installing it on your device. But is it sufficient? Not sure based on the presented research. It  was about “intents“. Using “intents” is a way to allow interprocess communications between two applications. The talk explained how to bypass classic control by installing two rogue applications instead of one and make them talk to each others via intents. Very nice idea! Conclusion from the speakers: Intents should be displayed to the end user as the classic permissions to have a clearer view of the app behaviour.

Then, Jurriaan Bremer, a student active in many projects like Cuckoo came to talk about  abusing Dalvik. Dalvik is the process virtual machine in Android. It’s the software that runs applications on Android devices. Jurriaan explained how he successfully abused Davik… for fun! Way too deep for me! But it concluded with a nice demo popping out a calc.exe, classic but efficient! 😉

The last talk for today was performed by Walter Belgers from the Toool NL group. His idea was to compare locks and classic security (hardware vs software). They are huge differences from a design point of view: Locks are security deices and they risks are pretty well understood and tested! (sometimes for certification). What are they?

• Key control (who can copy the key?)
• Protection against destructive and non-destructive attacks
• Tights costs and space contraints

Locks cannot be patched! It could cost a lot of money if a vulnerability is found within locks already installed. Keep in mind: Showing a key is like showing your password! Software can have backdoors (Did I say “NSA”?), it’s the same for locks. Walter compared lot of security issues:

• What about key reuse? As an example: some keys open the common door of a building and your own door. Similarities with root or administrator users. Keys are reused across buildings or countries.
• Do we have 0-day in locks? Yes! Electric lock opened with a rotating ring with magnets
• Abusive press release: “We are unbreakable!”, really?
• Brute force attacks? Harder in physical world. Key pins = password length , same fight.
• Security testing? Vulnerability scanners?

Walter is a great speaker, great slides, great content! This idea of comparing both world was interesting! That’s all for today, it’s not beer time! Stay tuned for more wrap-ups!