A few weeks ago I blogged about “The Art of Logging” and explained why it is important to log efficiently to increase changes to catch malicious activities. They are other ways to catch bad guys, especially when they make errors, after all they are humans too! But it goes the other way around too with system administrators. Last week, a customer asked me to investigate a suspicious alert reported by an IDS. It looked like an restricted web server (read: which was not supposed to be publicly available!) was hit by an attack coming from the wild Internet.
Here is a quick wrap-up of the just finished BSidesLondon. It was already the 5th edition (and my 5th participation!). This year, they moved to a new location close to Earls Court where is organized InfoSec Europe at the same time, good idea for those who want to attend both worlds: Hackers wearing t-shirts VS. Vendors wearing ties! This year, it was just a one-day journey for me, I’m writing this blog post while waiting for my train back to Belgium.
[This blogpost has also been published as a guest diary on isc.sans.org]
When investigating incidents or searching for malicious activity in your logs, IP reputation is a nice way to increase the reliability of generated alerts. It can help to prioritize incidents. Let’s take an example with a WordPress blog. It will, sooner or later, be targeted by a brute-force attack on the default /wp-admin page. In this case, IP reputation can be helpful: An attack performed from an IP address reported as actively scanning the Internet will not (or less) attract my attention. On the contrary, if the same kind of attack is coming from an unkown IP address, this could be more suspicious…
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 22.214.171.124
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!
The SSL and TLS protocols have been on the front of the stage for months. Besides many vulnerabilities disclosed in the OpenSSL library, the deployment of SSL and TLS is not always easy. They are weak cyphers (like RC4), weak signatures, certificates issues (self-signed, expiration or fake ones). Other useful features are mis-understood and not often not configured like PFS (“Perfect Forward Secrecy”). Encryption effectiveness is directly related to the way it is implemented and used. If it’s not the case, encrypted data can be compromized by multiple attacks scenarios. To resume: For users, the presence of a small yellow lock close to the URL in your browser does not mean that you are 100% safe. For administrators and website owners: it’s not because you have a good SSL configuration today that it will remain safe in the coming months/years. Unfortunately, keeping an eye on your SSL configurations is a pain.
Just a quick post about a problem that security analysts are facing daily… For a while, malicious Office documents are delivered with OLE objects containing VBA macros. Bad guys are always using obfuscation techniques to make the analysis more difficult and (try to) bypass basic filters. This makes the analysis not impossible but boring and time consuming.
As example, we see more and more VBA macros with strings obfuscated by encoding characters with the ‘Chr()‘ or ‘Chrw()‘ functions. Check the following piece of code:
Set ertertFFFg = CreateObject(Chr$(77) & Chr$(83) & Chr$(88) & Chr$(77) & Chr$(76) & Chr$(50) & Chr$(46) & Chr$(88) & Chr$(77) & Chr$(76) & Chr$(72) & Chr$(84) & Chr$(84) & Chr$(80))
Once decoded, the variable ‘ertertFFg‘ is assigned the following value:
Set ertertFFFg = CreateObject(MSXML2.XMLHTTP)
Seeing more and more macros based on this obfuscation technique, I wrote a quick and dirty Python script to help a friend. Currently it supports the following syntaxes:
The script reads the macro from stdin and output the decoded strings to stdout. Feel free to use it, it is available on my github repo.
[This blogpost has been published as a guest diary on isc.sans.org]
Handling log files is not a new topic. For a long time, people should know that taking care of your logs is a must have. They are very valuable when you need to investigate an incident. But, if collecting events and storing them for later processing is one point, events must be properly generated to be able to investigate suspicious activities! Let’s take by example a firewall… Logging all the accepted traffic is one step but what’s really important is to log all the rejected traffic. Most of the modern security devices (IDS, firewalls, web application firewalls, …) can integrate dynamic blacklists maintained by external organizations. They are plenty of usefull blacklists on the internet with IP addresses, domain names, etc… It’s quite easy to add a rule on top of your security policy which says:
if (source_ip in blacklist): drop_traffic()
With the “blacklist” table being populated by an external process. Usually, this rule is defined at the beginning of the security policy for performance reason. Very efficient, but is it the right place?
Let’s assume a web application firewall which has this kind of feature. It will drop all connections from a (reported as) suspicious IP address from the beginning without more details. Let’s put the blacklist rule at the end of the policy of our WAF. We have now something like this:
if (detected_attack(pattern1)): drop_traffic() elif (detected_attack(pattern2)): drop_traffic() elif (detected_attack(pattern3)): drop_traffic() elif (source_ip in blacklist): drop_traffic()
If we block the malicious IP addresses at the beginning of the policy, we’ll never know which kind of attack has been tried. By blocking our malicious IP addresses at the end, we know that if one IP is blocked, our policy was not effective enough to block the attack! Maybe a new type of attack was tried and we need to add a new pattern. Blocking attackers is good but it’s more valuable to know why they were blocked…
A few days ago, I proposed a challenge to solve. The first ten people, who solved it, won a free ticket to attend the security conference Hack in Paris in June. Thanks to all the players! If all tickets were assigned after a few days, some people did not solve the challenge and asked me to publish a small wrap-up with the solution. The challenge was based on a single file still available here. About the participants, here are some stats:
- The file was downloaded from 253 unique IP addresses
- The solution (another file to download) was downloaded from 29 uniques IP addresses
Not too bad for a small challenge like this! Let’s go with the solution…