I left Amsterdam after the closing keynote and I just arrived at home. This is my quick wrap-up for the second day of Hack in the Box!
The second keynote was presented by John Matherly: â€œThe return of the Dragonsâ€. John is the guy behind Shodan, the popular devices search engine. Shodan started because Nmap was not designed to scan the whole Internet. With Shodan,Â Stateless scanning isÂ used. Today, technologies allow to scan one specific port on the Internet in less time than making a coffee. Shodan allows securityÂ researchers to request some specificÂ scan on their projects. If the search engine is of course used by attackers to perform reconnaissance phases, it can also be used for many other purposes like:
- You can track if a US company is selling devices to prohibited areas
- You can track the impact of a patch which screws up a vendor infrastructure
- Same for malware analysis (bots, C&C)
- Security rating of a company that you want to buy? Can be used to create â€œsecurity ratingsâ€.
- Market share
- Do we need to push sales in a specific geographic area?
- IoT (machine 2 machine communications), printers, wind turbines, â€¦
John insisted in the IoT hot topic with many examples. Such devices tend to be connected on mobile networks. It makes them very difficult to contact the owner to say â€œFix your shitâ€. Many IoT devices also completely ignore our privacy and can expose sensitive data about our life, health. If youâ€™re interested in IoT security, have a look at the iotdbÂ on github.com, another project maintained by Shodan (Internet of Things nmap fingerprints).Â For sure, IoT are a pain and they will enforce their position of major threat in the near future.
After the first coffee break, I attended aÂ talk by Filippo Valsorda and George Tankersley about Tor:Â â€œNon-hidden hidden services considered harmful: Attacks and detectionâ€. Everybody knows Tor but what about the underlying protocol? Hidden services is a Tor feature which provides bidirectional anonymity and support generic services. They are identified with the .onion TLD.Â Well known example are drug markets ;-).
Services are published in a database that is a DHT (Distributed Hash Table) and the question is: How do we choose where to publish this database? The speakers explained the process of HSDir selection. Why is it critical? Hidden services users are facing a greater risks of de-anonymisation that regular Tor users. See the published slides for the details. The problem is low-latency implies correlation attacks (worried about entry and exit nodes). You can of course run your own HSDir and it will receive a subset of hidden service look-ups from users (after a few days). This will help in mapping relative popular hidden services. They explained how useful information can be collected by running your own HSDir (you can trust it if you run it yourself). Finally, as a conclusion, they presented the tool that developed to analyse Tor HSDirs (available here). Nice presentation but, if you are interesting in this topic, I recommend you to read the slides which contains a lot of details.
Then, back in track one, Lucas de Fulgentis presented â€œThe Windows Phone Freakshowâ€. His research was based on the following process: installation of apps, extraction of binaries, decompilation and review. Guess what? He discovered lot of bad stuff. Windows phone apps can be bases on two technologies: SilverLight or Windows Runtime. The result of his research is some kind of catalog of bad API usages that he called â€œfreaksâ€. A freak is just an example of vulnerable code.
The first freak presented was: self-defending apps. A lack of binary protection results in an app that can be analysed, reverse-engineered and modified. This is possible due to a lack of anti-debugging, obfuscation and resources integrity (+/-95% of tested apps lack of proper binary protection). There are tools like dofFuscator that helps to protest binaries. Keep in mind that binary protections simply mitigate but do not solve binary attacks.Â The next freak: data transport security. It concerns the transmission of sensitive data over unencrypted channels. Common issues are: No HTTPS and vulnerable to Mitm. As example, Lucas demonstrated how to abuse a vulnerable CNN application by changing or adding a breaking news. More applications are vulnerable: LinkedIn, eBay, e-banking applications. A good tip is to use SSL everywhere. Â Windows Phone 8 automatically discard invalid certificates. But if the CA is compromized and the attacker generates malicious cerfificates, the problem remains! To protect against this, implement certificate pinning.Â Next freak; data storage security. WP8 supports BitLocker (AES128) butâ€¦ it is disabled by default (I t can be enable via an ActiveSync policy). The device physical memory attacks allow access to some content. Do we really need sensitive data on our mobile device? Data can be stored in 3 locations: File system, external SD card or in the cloud. A common issue with credentials? There are stored in plain text! Use the DataProtection API. There is also a PasswordVault class available.Â The other freaks reviewed by Lucas: data leakage (involuntary data disclosure due to a side effect, authentication and authorisation and, last but not least, client side injection. For this point, a key point is to never trust data from the wild. â€œAll input is evilâ€ as said Lucas.Â Using an undocumented IPC call (Shell_PostMessageToast), Lucas demonstrated how to bypass the 4-digits PIN code protection in the DropBox application.Â Being a contributor to the OWASP Mobile Security Project, Lucas demonstrated the vulnerabilities and also the countermeasures that are available for the developers. Very nice talk!
After a good lunch and interesting discussions with peers, the last half-day started with Julien Vehent from Mozzila who presented â€œMozilla Investigator: Distributed and real-time digital forensics at the speed of the cloudâ€. MIG = â€œMozilla InvestiGatorâ€. Mozilla has approx 15000 servers.
Itâ€™s a challenge to monitor this and perform security operations. Julien explained what IOCâ€™s are (â€œIndicator of Compromiseâ€) like IP addresses, filenames, hashes, URLs, domains, â€¦ ). The good point, they can be shared! A security incident can be caused by internal mistakes. Did you know the unfortunate commit?
$ git commit -a . &&& git push github master
Password or credentials can be leaked in this case. How to know the impact on the completed infrastructure based on thousands of server? Mozillaâ€™s goal is to build a safer Internet with a strong startup/incubator mindeset. As said Julien, they experiment and fail fast. The current infrastructure is based onÂ 400+ active websites, a dozen of offices, remote workers, 2 data centers, tons of AWS accounts. How to do incident response in such environemnet (it’s like looking for a needle). For Julioen, the Â OpSec problems are:
The faster we can investigate, more we will find but Mozilla followed this principle: â€œIf you canâ€™t find the right tool, write your ownâ€. Julien demonstrate some usage of MIG.
Example 1: Locating a cron job that contains a password:
$ mig file -e 30s -path /etc/cron.d -content â€œbadpasswordâ€
Example 2:Â Is that bonet IP connected anywhere?
$ mig netstat -e 20s -ci 188.8.131.52
Each server is running an agent connected to a RabbitMQ relay.Â MIGÂ is light, written in Go, one static bin, config is pushed by tools like Puppet. Julien reviewed all the securty controls in place to let the agent work safely: Â Intensive use ofÂ PGP, no raw data returned to the server, ACLs. It looks to be a very powerfulÂ tool!Â MIG is available here.
The next talk is the one that everybody expects at security conference: It focus on infrastructures that everybody used in his/her day life: Parking systems. Jose Antion Guasch started this research a few years ago during his spare time and fully compromised the parking system of a well know vendor (not disclosed). His talk title was â€œYes Parking: Remotely Owning â€œSecureâ€ Parking Systemsâ€â€™.
This time, no SCADA devices, no complex technical skills but classic vulnerabilities like we can find on plenty of vulnerable web servers. But focus on public parkings? They have complex infrastructures and there is money involved! (a lot of!). For Jose, a kidâ€™s dream was to play with the parking gates just by clicking on a button and he succeeded. Every started with a simple login page. The rest of the research was based on the same structure as a classic pentest: information gathering, enumeration, analysts, exploitation, etc. A parking system is based on main components:
- The entrance (gate)
- A management / maintenance / payement system
- An exit (another gate)
Behind those components, we find dump personal computers connected to a network. Jose analysed different versions of the application (which changed after the original company was taken over by another one. For the old version, it was piece of cake. To resume: Indexable directory on the management server, a directory /backup with database dumps, restore the last one, get credentials and use them. Game over!Â For the other versions, it was a little bit more complex but the systems got also pwned. There, Jose found credit card numbers and was able to play with the gates, record new notification messages. But a real attacker could be much more evil by selling back monthly tickets, CC, monitoring people, controlling license plates.
Old version: Directory index -> /backup directory -> database dump -> restore the last one -> Get credentials -> game over
The newestÂ version was more difficult to pwn but it remained vulnerableâ€¦ Bad passwords (again), credit card numbersÂ in clear text, hability to record new voice messages, play with gates, â€¦Â Of course, a real attacker will play more evil and resell monthly tickets, lists of CC, monitor people, control license plates, â€¦ Â Jose’s advice to the application owners: Donâ€™t put anything online, harden, don’t use default config and restrict accesses!
The last talk was presented by Marina Krotofil and Jason Larson: â€œWhat you always wanted Â and now can: Hacking chemical processesâ€. They talked about Industrial Control Systems. They are â€œITâ€ systems implemented in â€œphysicalâ€ systems. Components convert analog to digital signals (ex: temperature, pressure). In traditional security, TLS is the xavier of all things. But different in industrial processes, the process canâ€™t stop due to an IT issue. Can you imagine: crypto key invalid => stop the process? Industrial systems can be controlled without modifiing the content of the message!
After a SCACA 101 5 mins sessions (always useful), they came back to process manipulation. In some process, the freshness of data is critical.Â They reviewed different types of attacks and their impact on a plant.
And for the closing keynote, the word was given to Runa A. Sandvick. She talked about â€œBringing security and privacy to where the wild thing areâ€. Runaâ€™s talk was addressing the securiy communitty but withoutÂ technical content, only nice facts and ideas. She worked on projects like Tor and the Freedom of the Press association.
Whatâ€™s the link with IoT and mobile phones? Back in 2010, we discovered that apps are leaking data to external services (ex: the Pandora music app). Another example, a riffle running Linux and connecting to appsâ€¦ Drones with a mobile phone and Wireless toys, etc. Keep in mind: â€œJust because you can does not mean you shouldâ€. So what do we do it? Exciting? Innovation? Managing expectation. Nobody takes care of updates on mobile phones. What if the OS reaches its end of life? No more updates? From a baseline and building on it. Baseline changes in timeâ€¦ Today the new baseline has many more options (example was given with cars). Why donâ€™t we have the same reflex with electronic devices? â€œNSA-proofâ€ is a term created by journalists. What does it mean really? We, as community, can help journalists to help to better understand. But hackers also do mistakes with logos, brands, â€¦ Think about the latest one, VENOW… We can do better!Â Security vs privacy. New roles are coming which replace the workd security by privacy: privacy analysts, privacy engineers, â€¦Â We need more transparency but often, there is a lack of context. Example: the screen with app permissions on Android. Facebook needs to access the microphone? But in which context? Â Where do we go from here? How to educate people? Be responsible (story of Chris Roberts who hacked a plane). Two interesting initiatives mentioned by Runa: Iâ€™m The Cavalry and BuiltItSecure.ly. I really liked her keynote which contained interesting ideas to keep in mind and to share!