And this is already the last day! My first choice for today was the talk of Andrey Belenko and Dmitry Sklyarov: “Secure Password Managers” and “Military-Grade Encryption” on Smartphones: Oh Really?. They presented their research about the security of keyword managers on smartphones. It’s recommended to not use the same password across several applications or services. This means for the end-users a huge amount of passwords to remind. It’s impossible to achieve this for regular people. That’s why we need tools called “passwords managers“. But are they really safe? First, they compared both environments: PC”s and mobile devices from an authentication point of view. Regular PC’s have multiple authentication methods: TPM, biometrics, SmartCard + PIN or classic passwords/passphrases. But on SmartPhones, only the last method is doable. The first security control on mobile devices is the lock screen (via another PIN/password or a “lock pattern“. Another problem: typing passwords on SmartPhone is a pain! Virtual keyboard, small keys do not help. So people are tempted to use simple passwords. Password cracking on SmartPhone is not easy: slow CPU, complex password-to-key transform will impact the usability. We need stronger password on SmartPhones (mobile data) but they are stronger to manage! The threat model proposed by Andrey was: Let’s assume that an attacker has physical access to the device and has access to the data. He wants to recover the master password to extract the stored passwords. Physical access is not a real issue. SmartPhones are small and can easily be stolen or lost in bars. What about backups? Two platforms were reviewed. iOS uses passcode or iTunes pairing (encryption is optional). On BlackBerry, your need the device password, encryption is also optional. Where are the database files? On iOS, you can use AFC (used by iTunes), SSH (jailbroken devices) or physical imaging (up to iPhone 4). On BlackBerries, you need the device password.
In the second part of the talk, some popular password managers were reviewed (encryption modes, features, etc). BlackBerry users can use the BlackBerry Password Keeper and BlackBerry Wallet. On iOS, there are much more applications! Some are free (20+), others are commercial. A few applications are exactly the same, only the look changes! They store data in SQLite files, master password is only 4 digits and stored in… plain text! iSecure Lite is also storing the master password in plaintext, retrieve it using a simple “SELECT password FROM preferences;“. Many iOS application names contains “Safe“, “Ultimate“, “Secret” but they security is really poor or inexistent! Some does not use salt to store their master password in MD5, so existing rainbow tables can be used to crack them.  The best one is Strip Lite – Password Manager.  And what about paid applications? We could expect more security. Some are SafeWallet, 1Password Pro, Data Vault, mSecure. 1Password is maybe the most popular but not the safest one. The worst one is SplashID.Note that the overall security is some applications can change depending on the iOS version used (iOS 5 introduced more security). Encryptions methods and features were reviewed. The conclusions are:
- None of the tested apps offer reliable protection on top of OS security.
- Using them on improperly configured device may expose sensitive data
- Paid apps are not necessarily better than free ones.
- Users: always use passcode, set backup password and do not connect devices on untrusted networks.
- Developers: Use built-in OS security services, don’t reinvent the (wheel of) crypto!
I see another aspect which was not covered by the speakers: Sometimes you need to find the best balance between security and features. Example: Some password managers can be synchronized with desktops.
The second talk was the one of Paul Royal. He explained how to “entrap malwares with transparent, scalable malware analysis“. Modern malwares use techniques to defeat security measures: obfuscations, server-side polymorphism and collection volume are common. That makes them difficult to catch. As they are use by real criminals, impact can be huge if they are detected and malware developers must implement controls to ensure that their code will be properly executed (business must go on!). There exists tools to obfuscate code, like ZeroPack. From an analyst point of view, automation is mandatory. Why? The volume makes manual analysis impossible (huge increase of samples). Today, modern malwares implement  analysis detection (Conficker checks for relocated LDT orTDL4 cehck for device emulation via WQL). Malware builder tools have features like anti-VirtualPC, anti-VMware, anti-VirtualBox, bypass sandboxes methods, etc. That’s why malware analysis tools must have transparency requirements:
- High privilege
- No non-privileges side effects
- Same instruction execution semantics
- Identical exception handling
- Identical notion of time
- In-Guest tools
- Reduce privileges guests
- Emulation (QEMU, Simics)
Paul showed a piece of code used by malwares to detect virtual environment (QEMU, VMware, KVM). Why transparency is important? Some analysis environment became very popular. We need to come back to physical analysis. The concept is to have a physicalizing virtual machine. This must be scalable (costs, efficiency) and automated. NVMTrace is a tool created to automate this procedure. It executes each sample in its own sterile isolated non-VM machine and provide access to NVM disk content and network traffic. Data can be post-analyzed using your favorite network traffic and disk forensic tools. In the future? more disk forensics (ex: record disk-level events as they occur) and use Arduino boards (ex: to inject keyboard/mouse events) and activate trigger-based malware). Code is available here:Â NVMTrace code is available here: code.google.com/p/nvmtrace. More information is available here:Â ether.gtisc.gatech.edu.
The next talk “Pwnage saga continues” by Nikhil Mittal was a continuation of the workshop organized by Nikhil on Teensy devices. So, I missed interesting stuff (how to program it) but the demos were very interesting. Teensy are small USB devices acting like a virtual keyboard. By using an Arduino interface, you can program them to send keyboard signals to the victim computer. Example: Windows menu, up, up, type “cmd”, enter, etc.
To use the USB devices, Nikhil used his tool call Kautilya. It’s a toolkit which provides various payloads which may help in breaking in a computer. He performed demos of several payloads:
- Grab a script from pastebin.com, schedule a task
- Setup a key logger which will send the captured data to paste bin.com after a given interval
- Create a Wireless hosted network, create an admin user and enable RDP access in the firewall
- Silently download a signed Java applet and connect back to Metasploit
The process was always the same: generate the script, install it on the USB device and execute the sequence of keys on the victim’s machine. They are of course some issues:
- Some systems have a HIDS which prevents USB hardware devices to be used (or via a Windows Group Policy)
- Teensy has a limited storage but you can attach an SD card.
- Data are sent on a one-way traffic. Not possible to read from the system.
The current limitations of Kautilya are:
- Many payloads needs administrative privilege
- Traffic from/to pastebin.com is not discrete
- It cannot clear itself after a single run
- Not very stable if some tools changed.
What about the future? Nikhil would like to write more payloads, implementation the support of the SD card, use payloads as libraries (to reuse them) and support non-english payloads(only US keyboard are supported at the moment). The conclusion to this talk: don’t leave workstations unattended. Attackers could insert the Teensy and compromise the host in a few seconds. Kautilya is available here: code.google.com/p/kautilya and interesting stuff can be found on Nikhil’s blog: labofapenetrationtester.blogspot.com.
The last half-day started with a presentation called “Preventing ‘Oh Shit!’ Moments for 20 Euros or Less“ by Phil Polstra. This talk covered USB device and how they work. Why? USB became a standard for people to exchange data across computers (Do you remember floppies?) but a few of us understand them. USB is not safe. They are also to see your best collection of tools to be deleted by an intrusive antivirus when you plug a key!  USB appeared in 1996 (!) and is based on pretty simple hardware (4 wires), hot pluggable, cable length unto 16 feeds (5 meters). About software? USB uses automatic configuration and is based on enumeration. Standard classes with corresponding drivers (audio, storage, keyboard, …). Then Phil focused on mass-storage devices. How to keep the USB storage drives safe? Some drives have a write-protect switch. Using “HKLM/System/CurrentControlSet/Control/StorageDevicePolicies/WriteProtect“. They also exist commercial solutions ($$$). But micro controllers are fun and cheap. Phil decided to build its own solution. Two families of chips were available: AVP or PIC. But Phil used a PTDI Vinculum II chip (and libraries are open-source)
We need to block the bad command blocks that could modify our drive. Why? For forensic purposes or to prevent infection by malwares. Paul demonstrated his tool of course. Another interesting video: USB flash drive forensic.
I followed a last talk about “Smartphone’s Apps Are Not That Smart: Insecure Development Practices“ by Simon Roses Femerling (@simonroses). If our phones are smart, it’ s not always the case for their applications! The web has a new concurrent: apps! All services are today available as “apps”. When you visit a website with your smartphone, it suggests you to install and use the apps instead. Some numbers:
- Sales will rise to 982 millions of devices in 2015.
- Average is 65 apps per devices but only 15 are used per week.
- 18 billions of apps downloaded for iOS (02/2011)
- 10 billions for Android (12/2011)
Apps are not developed in the same way and multiple technologies are used (Java, C, Objective-C, Ruby, HTML, Python, CSS JavaScript, Tcl, … What are the risks associated introduced with apps? 100 apps were analyzed from the official markets (1h per app) and different categories analyzed:
- Security
- Social networking
- Communications
- Servers
- Finance
- Media
- Productivity
- Travel
To help developers, OWASP has a mobile security project with a top-10: <pic?> Some bad example:
- Clear text secrets. How to mitigate? Use encryption, set correct file permissions and avoid saving data on external storage (SD-cards)
- Insecure channels (HTTP) and credentials or PII data disclosure. How to mitigate?
- Debug mode left active
- SQLi
- XSS
- Data validation
- Applications integrate with 3rd party libraries.
An important topic in apps security: permissions! A bad app may compromise your mobile and your money! permissions mitigation must be performed on both side:
- Developer:s: don’t abuse on permissions request (overprivileged)
- Users: apply common sense!
Bad crypto implementation is a recurrent issue. This has  already been said multiple times across different talks. Some secure development tips?
- Apps need to pass software security assurance practices
- Threat modeling your apps
- Understand platform and apps risks
- Professional security reviews are expensive but small ISV and single developers can use available resources.
- Implement jailbreak detection
Interesting talk, developers must review the slides!
Finally, I participated to the BlackHat Arsenal. It was the first time that Arsenal was organized in Europe. Â I presented my tool: pastemon. It helps you to monitor pastebin.com and alert you when interesting/suspicious content is detected. More information is available here.
That’s all for this edition! I’ll drive now back to Belgium. Thanks to the BlackHat team for the organization.