Hashdays Wrap-up Day #1

I’m in Luzern for a few days but the Hashdays security conference started today! w00t! This is the first edition for me. A very nice opening session performed by the defcon-switzerland group which organises this event. They gave funny stats about this edition in terms of registration, paper used, exchanged emails, etc. After the classic security recommendation – if you see what I mean (they also operated a wall-of-sheep like I do during BruCON), they introduced the keynote speaker: Christien Rioux.

Christien explained how to manage hackers in the security industry. For sure, he has a great personal history with a lot of different experiences.

The introduction was funny to see: The evolution of his look across the multiple positions he had during his career. Indeed, our physical changes are not only due to the time (we are all becoming older), but it’s also based on the decisions about our career (switching from t-shirts to ties). How do we build a better hacker security professional? The security timeline changed too from physical security (since the beginning) to data security and applications security. They are also different business models: consultancy, security products, enterprise or SaaS. And companies over time? Seed, startup, small company, growth period and maturity. Think yourself: Why are you doing security? for money? because you are bored? for altruism, ego, fame? Do you like your job? What position will you hold in 10, 15 years? Being famous is a good idea but it is difficult to turn this into real money. And once you have money, you try to not remain famous at all. Success? It is different for everyone. But everybody agrees: “money != happiness“. What’s the impact of hacker culture on companies? Skepticim, paranoia, maker ethics. How to encourage the hacker culture: “Google time“, “hackatons” or security awareness training. Management survival tips? Think about role progression (contributor, lead, middle-management, etc) beware of the “Peter Principle” ? Chris ended with the ten commandment of hacker management:

• Thou shalt appear presentable, approachable and kind
• Thou shalt be a good team leader and a good individual contributor
• Thou shalt prioritise the team you are on, rather than the team you lead
• Thou shalt in be inclusive of man skillets and expertise in your organisation
• Thou shalt embrace time management techniques
• Thou shalt not depend on ‘rock stars’ and ‘hero coders’
• Thou shalt embrace process
• Thou shalt not require perfection, for it is the mortal enemy of ‘good enough’
• Thou shalt trust but verify
• Thou shalt give feedback well, and take feedback even better.

After a coffee break, the regular sessions started. My first choice was Nicolas Orbeli about “Please insert^H inject more coins“. Nicolas explained how this project started. The primary idea was simple: To try  to add more coins into game machines to play longer.

But coin handling devices are not only present in arcade games, also in ATM’s, vending machines (drink, cigarettes, parking) or casino slot machines. To handle coins, multiple devices are used in those machines: coin acceptors which detect the coins and send the value to the device. Some may detect multiple currencies and may include false money detector. The coin hopper is another device used to give money back to the customer when needed. Those devices use communication protocols via parallel, serial, MDB or… ccTalk. They are vendor specific. Nicolas focussed on ccTalk during the rest of the presentation. ccTalk means “Coin Controls Talk“. ccTalk is not fully public and some specs are available only after you signed a NDA(!). It is based on request/response messages like RS232 data transmission(9600 8N1). It uses addresses for all devices on the bus. Common addresses are: “1” for the controller, “2” for the coin accepter, “3” for the coin hopper, etc. The message format is based on a standard frame with a destination, a payload and a checksum (amongst others). Commands are code on 1 bytes: 255 possible commands.  The first step in Nicolas’s project was to use a Teensy device to communicate with a machine. Can we do more? ccSniff & ccParse are two other  interesting tools. You can use a bus pirate (open source hardware hacking tool) to sniff for interesting traffic. Once data captured, Nicolas reversed the protocol. The next logical step would be to inject data onto the bus (to get more credits or drinks ;-), right?. ccTalk has a command to ask a device to change its address (to solve addressing conflicts). Good!  Let’s do some device in the middle now. ccJack is the next tool developed to perform the hijacking process. Example: inject coins! Even more? Some coins acceptor can be re-calibrated: What if a 0.10 EUR coin becomes 5 EUR credit? The path taken by coins can also be modified! What about inserting a coin and getting it back in return. Nicolas also reviewed protections? Some machines requires a PIN code. Some implementation of ccTalk has encryption features. In the latest versions, payload and headers can be encrypted. The speaker’s future research will focus on:

• Encryption: it looks suspicious and not properly implemented
• Some devices accept a memory dump with ccTalk: is there possible vulnerabilities? Is it doable to upload a new(rogue) firmware?

What are the machine protections? Some require 2 key to get the money. Access to the bus only requires the machine to be open (you need a laptop, a bus pirate…), not very discrete! Another potential project: Arduino + Bluetooth and place the device on a temporary opened machine. Note that Nicolas’s tools will be available soon after hashdays. This was an very interesting presentation. The topic was not common but we are facing such devices every day. Nicolas accomplished a real hacker job!

The next talk was about IPv6. Again you should say… but mandatory otherwise it will be too late. Marc Heuse presented “IPv6 Insecurity Revolutions“. Marc has already made previous talks on IPv6. This time, he decided to simply skip the introduction to IPv6 slides and to go straight to the point, “That’s live!“.

IPv6 security is kind of boring for Marc but nobody else is doing that (except Fernando Gont). His talk was a “pot-pourri” of security stuff about IPv6. What’s the current sitatuin according to him? About reported vulnerabilities, there are more IPv6 vulnerabilities (CVE) than IPv4 and even if IPv4 is everywhere. This is due to the maturity. Reminder from 2012: RA flooding? Still not yet fixed by Microsoft & Juniper Netscreen. Today there is a revisited attack: RA flooding with route entries. Neighbor solicitation flooding (same result, the kernel does nothing else than replying to RS packets). What about fragmentation? This is not at router problem anymore. Only the host is allowed to fragment. What happens with packets > 64K? BSOD of course! Marc gave plenty of other examples with a Zyxel personal firewall or Astera boxes. Another Marc’s research: he used the 2500 top domains with IPv6 hosts and did a DNS brute force and port scanning (only the administrative ports – VNC, RDP, Telnet, SSH, FTP). Results were of course different! Much more ports remain publicly open on IPv6. Same study for ISP’s (on router) and… same results! Why? To protect your environment, you must have firewalls… They are expensive and you must buy some. Technical teams have no time to configure them and there is no hackers on IPv6! Marc performed lot of scan and get almost no complain from his ISP. This is a good proof that organisations do not track IPv6 in logs. Finally, Marc gave some interesting tips to perform pen test with IPv6 resources. The main issue is the scan: 12 to 14 days were required to scan the whole IPv4 network for only one port. This is simply not possible on IPv6 (simple ping scan). Target discovery is the key. How to achieve this? First, find the AS for the target (https://apps.db.ripe.net/search/full-text.html). Does the AS announce IPv6? (bgp.he.net/ASxxxx#_prefixes6). Often, the first addresses used are always ::1, ::2 and ::3. Another technique, use DNS! Reverse DNS enumeration: All IPs must be in DNS, too difficult to remind them (not like 8.8.8.8). A very good talk with practical examples without the boring part of IPv6 theory!

After a good lunch and some Club-Mate, we started the second half-day with Alexander Kornbrust who talked about “Self-defending databases“. I had the opportunity to listen to Alexander during the management session and found the topic really interesting.

SQL injections… an old topic but still heavily used by attackers! The solution is quite simple to get rid of this problem: fix the code! Yeah, but not realistic due to multiple reasons: time, legacy applications, complex organisations, etc. During the reconnaissance phase, attackers try to guess the databases, tables and rows names which could contain interesting data. This can be fully automated using tools like SQLmap.  Problem: when a vulnerability is found and being exploited, there is a very small time window which is too short for most organisation to react (even if you have a powerful SIEM!). The Alexander’s idea was to let the database detect if it is under attack and protect itself (usually the detection is performed by a WAF or by the application). Alexander demonstrated how to implement this in Oracle. The principle is simple: by checking the error reported by malformed queries, you can detect if somebody is trying to attack you. Typical errors are ORA-00900, ORA-01789 etc… (classically fired by SQLmap). The next step is to react on those errors. How? By sending an email, locking the offensive DB account or terminate the session or, last resort, shutting down the server? Each decision has pro & con. The final choice will depends on your business. Implementing such controls can also generate lot of false positives (example with Scottish names O’Connor). In fact, once you captured the attacker’s data, you are free to implement all countermeasures: blocking IP addresses based on regions, cities. Exchange the data into other devices. Alexander introduced a good way to reduce the amount of false positives, by using weights assigned to errors:

• TOR Network: +10
• Internet: +4
• Suspicious country: +8
• Known web app scanner: +20
• etc…

Other ways to detect SQL injection are fake (honey) data. Create a extra table with a raw called “password” or “creditcard“. This table will never be used by application but will be monitored.  Any access will be the result of a scanner, hacker or … insider! Same philosophy with fake functions. Developers are working with pairs. Example: encrypt() / decrypt()). Make a fake decrypt() function which will maybe be called by the attacker. Finally, I’d like to thank Alexander for the reference to my blog post during his presentation! The final question will be: how easy will it be to implement in your own database environment?

Next, I switched from the database world back to the iOS devices one with Ilja van Sprundel who talked about “The Security (or Insecurity) or 3rd Party iOS Applications“. The topic was the auditing of iOS applications. It was not about bugs in iOS but really on common security issues seen in 3rd party applications and how to fix or mitigate them.

The apps market is exploding today and more organisations start to care about the security of mobile devices.  Apps are developed in objective-C with classes which take care of the basic stuff like I/O, memory allocations, etc. Ilja reviewed common mistakes performed by developers. Apps usually exchange data with servers located on the Internet but the transport security is often low (ex: weak ciphers suite). To use secure transport, you must use CFNetwork says Apple. On iOS, data sharing between apps is not allowed but sometimes developers need to share. They found a way to get around this and this appears to be supported now by Apple. App A will register an URL handler and app B will call this URL with data (RPC alike).  But any webpage can call this link too, so any webpage can do IPC with the application. UIWebView is another method can be used to build GUI, it renders HTML (Javascript is ok). If uninfected data can be injected by the attacker, you got a XSS. UIWebView handle also more URLs like “tell://”. This is on by default but can be disabled. Good tip: give URLs to Safari and let him render the page instead of UIWebView. UIImage is another one, it’s a general image class to process all common image formats. There is no way to specify what you want to support or not (example: don’t process TIFF files). Header / XML injection is not iOS specific but can be used too. Why? Developers develop their own HTTP handling stuff and forget to escape dangerous data like “\r”, “\n” or quotes. If there are APIs, use them! Format string bugs are very common too (same for C language). This was a talk really for iOS developers, I didn’t follow all the example but they looked a good list of “do and don’t“.

The following talk I attended was the one of Andrei Costin: “Ghosts in the Air (Traffic)“. I missed him during a previous conference and was happy to see his research again on the schedule. The talk was about protocols used in air traffic controls. Andrei started with a big disclaimer: “Do not try this at home“. ATC is a very complex system based on legacy components and lot of human interactions. Note that computers are there to help traffic controllers to take actions. They don’t take them by themselves! Andrei introduced the protocols using to control the traffic. What are the problems? First, a lack of input control. Manuals say it black on white:

Then Andrei explained how the new ADS-B protocol works. It has many interesting features like checking if an airline  exists or not, communication between airlines… Collecting data is quite easy. You just need a receiver (a box) to listen to the broadcasted information. Some boxes are self-made projects like the micro ADBS-USB adapter). Based on the captured information, very nice applications can be developed like flightradar24.com. What are the threads related to ADS-B? authentication, authorisation, privacy, message integrity (HMAC), message refresh (non-replay) and massive public DB’s with private detail. Potential mitigations exist but are not public. How can we exploit this?

• Bad intent of pilots
• Pranksters
• Abuse (paparazzi
• Criminals (money)

Some data are publicly accessible, as an example the Federal Aviation Administration (database of aircrafts). Potential attacks scenario is DoS by injecting fake planes on the traffic controller screen or one plane with multiple positions. Interesting talk which proves that once protocols and computers are used it’s always possible to abuse them. The final demo was the simulation of a two planes crash on a screen. Nice! (from a technology point of view of course 😉

The last talk today was presented by Marc Ruef (I finally met him in real life! ;-)) about “Firewall Rule Reviews – Methodologie and Possibilites“. According to Marc, firewall review is not a new brand topic but remains important.

What’s the goal? identify insecure, inefficient, wrong and obsolete rules. First questions is: “Are firewalls obsolete?“. This is huge debate but according to Marc, we should still use firewalls but in the right way and rules review is one of the key. What are the steps?

• Extract the rules
• Pasrse
• Dissect (objects, services , action)
• Identify weaknesses

Exporting and parsing the rules can be a challenge depending on your firewall $VENDOR. Once done, weaknesses can be searched like ANY rule, bi-directional, broad open ports, DROP-ALL missing or objects mashups. Some rules are obsolete, temporary, lack of comments or logging disabled. Once a bad rule has been identified, a remediation is proposed (countermeasure) to the customer. This must be reviewed with the customer for approval. Example: certain legacy applications may require the Telnet protocol). Think about global settings (AV  rules, caching, etc). Based on the different projects he completed, Marc gave some statistics about the most common problems:

• No logging
• Rules with ANY
• Unsafe protocols
• Bi-directional rules

Usually during a first audit (on a 300 rules policy), 20-30% of weaknesses are found. During the next audits, only 7-10%! Marc’s conclusions were: it’s important to maintain the firewall configurations safe and parsing them allow a good analysis. Don’ forget to enable logging and to document them! Finally, even if performance and reliability is sometimes low with firewalls, we must keep them: they are an extra control point in your security policy.

That’s all for the first day! Let’s have some more fun now…