Hack.lu Day #2 Wrap-up

Hack.lu SloganThe second day is over! Here is my wrap-up. After some doses of caffeine, the day started with the “Red Team Testing” workshop by Chris Nickerson (@indi303). He explained a methodology to conduct penetration tests. Good examples are the ones of the Tiger Team. The goal is to revamp the classic penetration tests and “shock” people: By provoking emotions, customers are forced to realize that they have security issues. Instead of giving a screen-shot of a root prompt, change their information, disclose confidential material. An example in a hospital environment, what’s more important? To have administrative rights on a domain controller or to compromise a medical device and change the amount of drugs prescribed by default? (with risks to kill the patient).

One of the major issues for companies today is the requirements for “compliances”. They are just standards and do NOT protect companies but consume the most part of the security budget! To conduct red team tests, the attacker must act as a bad guy not as a consultant. The classic tests are not effective and results must be relevant to the company business. Some time was spent on a methodology to define an efficient scope. This must be discussed with the customer who need to give his feedback by ranking the business components targeted by the penetration test.

Some tools (software and hardware) were reviewed to compose a basic survival kit for any good “red team tester”. There was so much useful topics to discuss that the workshop time was doubled! I skipped the regular talks scheduled in the morning but it was worth it!

After the lunch, back to the regular talks. The first one was about the security of BlackBerry smart phones by Mayank Aggarwal (@unsecuremobile). Presented by a colleague, he made a review of the current situation in the smart phones landscape. One fact is that, compared to regular PC’s, smart phones are more and more used to achieve the same tasks but without the same security level (often not enabled by the users). Also, security vendors address less attention to those devices. The BlackBerry was chosen for different reasons: it’s a main player in companies and it is known to be quite good protected:

  • Encryption (internal as external memory)
  • End-2-end encryption of communications with the RIM servers
  • Built-in firewall

But, BlackBerry owner’s life is not so easy. The first example with the one of Etisalat which owned devices by sending an upgrade package containing a malware. Then some examples of spyware applications were given like FlexSpy, Mobistealth or Trackaway. The most complete are able to track: gps, emails, pictures, contacts, calendar, SMS, call logs, etc. Several demos were given which resulted in interesting information leakages. To conclude the talk, a good tip was given: Do not let others use your smart phone! Physical access is never good.

During the lightning talks, a demo of a drone was performed. Technically, it’s easy to own a WiFi controlled drone. AT commands are send via UDP packets to port 5556 without encryption. By spoofing the remote controller IP address, it could be easy to send forget packets to the drone.

Drone Demo

The next talk focused on a common hardware security problem: keyloggers! How to detect them? Fabian Mihailowitsch started by explaining the issue with keyloggers: it’s a real threat (there are responsible of millions of loss of profit) and visual inspection of PC’s is not possible in big organizations. Fabian searched for a solution to detect them via some piece of code. The major part of the talk focused on PS/2 keyloggers, USB models are even more complex. Without diving into hardware details (definitively not my favorite domain), the goal is to detect a difference in time when you send commands between the keyboard and its controller on a “clean” system and a system with a keylogger. But there are two major issues:

  • The time difference is so light that the CPU must be exclusively dedicated to the detection during a short amount of time (this is achieved via a kernel module)
  • For the same reason, before starting the detection, you need to define your own baseline.

This makes the solution difficult to use and not very reliable. But excellent research performed by Fabian on this topic! His code should be released soon as a Google Code project.

Eric Filiol was back and explained how Office documents (Microsoft Office or OpenOffice) could be used as “weapons” (read: how to deploy malwares using regular documents, mainly used in enterprises). For me this was an update of the work presented during BlackHat Europe 2009 in Amsterdam. But it remains amazing how the documents can be altered without breaking the protection and how they can launch suspicious macros on the target hosts.

Finally, the last talk was given by Aureliano Calvo: “Showing differences between disassembled functions“. The goal was to present a visualization model to track changes in code during vulnerability analysis. Reverse engineering remains quite obscure for me and I followed the talk just “for the fun”. According to a friend who performs reverse engineering, it was a good talk  but the examples were too easy. I cannot judge by myself.

That’s all for today!

One comment

  1. Thank you for the sum up and your interest in the topic of detecting hardware keyloggers. Really enjoy the positive feedback. 😉

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.