SOURCE Dublin Wrap-Up Day #2

SOURCE Kit

I’m writing this wrap-up from the Dublin airport, waiting my flight back to Belgium. This new edition of SOURCE is already over. What did we learn today?

This second day started with Vincenzo Lozzo‘s keynote. Lorenzo gave first, some facts. From an economic point of view, Internet will generate nice business in the coming years (2012: $60B, in 2016: $86B – according to Gartner). Another one, KPMG announced a raise of 40% increase in data-loss incidents. But a good news: entrepreneurs are looking to invest where there is a business like infosec. Also, US government said that cyberwar is like a regular war and army forces can be used. Scary to read some quotes like this one:

Report for NATO justifies killing of hackers in a cyberwar.

In the security world, some people are not ready to share information with vendors when they found vulnerabilities. Infosec security is fundamentally trying to solve tech problems thought non-technical actions. They are different groups of attackers: Organized crime, they are also trying to get as much money as possible. If the ROI is not good enough, they will choose another target. Hacktivists are a different group with less sophisticated attacks. The scariest group is nation-states. Huge budgets, attacks can be very sophisticated depending on the target. A nice quote from Lorenzo:

Can you even kick them out if they ever get in?

Then he also explained a game strategy based on the FlipIt  game to try to guess the attacker behaviour. But some group of attackers can’t be analysed with this technique. Banks are an example: it’s more a fair game. They know they will be attacked from time to time. The insecurity of complexity: At conferences, you learn new ways to attack. You try to implement new controls to block them. But it’s not sure that they can be implemented. The market of lemons compared to infosec is not new. Are we checking security from a wrong angle? Bugs don’t attack companies, people with exploits do. Lorenzo make a comparison between “bug bounty” programs and blue hat prize. Fixing a bug will not really improve the overall security. He gave a good example with Acrobat Reader: there is a difference between bug fixing and mitigation. Since they implemented a sandbox, there are less 0-days released.

Lorenzo

Fixing bugs is like draining the sea with a spoon. It makes you look heroic but doesn’t achieve anything

Things that Vincenzo would like to see in the future:

  • Better ways to simulate attackers (vs classic pen tests)
  • Faster and more agile countermeasure creation & deployment
  • Better data gathering about attackers
  • Stronger economical research on attack dynamics
At the opposite, let’s avoid:
  • Cyber witch hunts
  • Military solutions to technical issues
  • VC-backed snakeoil companies

Patrick Schulz and Felix Matenaar were the first regular speakers with their talk about Android: “Android application reverse engineering and defences“. They started with a motivating example. First step, the static information gathering: This can be achieved by decompiling the application, examining the Type System (classes) and APIs. It’s quite easy with Android. Then, the dynamic analysis is performed with sandboxes and debuggers like APKTool. What are the Interesting stuffs to look for? Data validation, license checks and client checks are good examples. Then you can add extra code and redistribute the application. So, from a developer perspective, how to avoid this? How to protect your applications and how to address those problems?

Patrick & Felix

To prevent static analysis, use code obfuscation, dynamic code loading. You can also make code harder to read. Some tools are referred here. Application modification (or temper proofing) is another risk. Run time integrity checks. React to the fact that your application has been modified or repacked. Hide interesting code and make it harder for malware authors to repack it. A technique presented by the speakers was “Manifest Cheating“. Inject a “name” attribute in the application tag with ID 0 and value “detect.class”. It will be skipped by packet but will make APKtool to crash when analysing the file later. If you really implement the detect.class, it will be executed and you’ll know that your application was repacked. Runtime integrity checks can be implemented like checking the application signature. Dynamic analysis or anti-runtime analysis: Use techniques like debugger detection and prevention.

Then the floor was open to improvised lightning talks and discussions. First, Dildog presented some tests he make yesterday night with URLs and Unicode characters that make Google Drive creating non-deletable files on the filesystem. Funny! Then, some tools were presented again by Patrick and Fellow. Finally, I quickly introduced my tool to monitor pastebin.com.

After a lunch and some good conversations enjoying the sunny weather over Dublin, the last half-day restarted with Peter Morgan and John Villamil. They presented “Monkeyherd: Stay fuzzy my friends“. This is a fuzzing tool developed by Accuvant Labs and is definitively an offensive tool. People usually know simple fuzzing tools but it can quickly become more complex to implement. Question from the speakers: Why aren’t more companies doing fuzzing? Some are doing well (like Google, Microsoft, Mozilla) but it requires motivation to deal with discovered bugs, company resources and experience to execute this process.

Peter & John

They explained deeply how to implement distributed fuzzing. Monkeyhard is deployed in the Amazon EC2 cloud and based on tools like SSH, Git, Ruby/Python and Redis. It can also perform GUI automation, dynamic binary instrumentation and uses a C&C to keep track of discovered vulnerabilities. It looks to be a very powerful tool.

Ben Williams was the following guest with a talk about hacking appliances. This was a talk that he already performed in Amsterdam for BlackHat 2012. Then he presented an update of his research this year again at BlackHat. As I missed it due to an agenda conflict, it was a good opportunity to refresh my mind. What’s new? Nothing much! Security vendors still fail to properly protect their appliances. They are usually considered as “safe” and deployed in DMZ but some, providing basic network services, can be connected to internal networks. They also receive lot of prices as “product of the year”, scarry!

Ben Williams

Who were Ben’s victims:

  • Sophos Email Appliance (v3.7.4.0): Admin webgui attack with a 500 passwords list. Done! (No protection against bruteforce or account lockout). OS command injection and reflective attack.
  • Citrix Remote Access Gateway: authentication bypass & port forwarding via SSH
  • Symantec Email Gateway: owned by receiving a mail and spawn a root shell.
  • TrendMicro Email Gateway.
All those example were completed using classic penetrating testing techniques! Most appliances are not hardened. Based on Linux or FreeBSD, the following components are often installed: compiler, tcpdump, debugger, perl, python, etc. Ben’s conclusions are: don’t close your eyes when buying a security appliance. Ask the vendor what kind of hardening is performed and include them in your pentest scopes. Like the previous editions, a nice talk with funny screenshot and (horror) stories. Good job Ben!

Last but not least, Nick Hiliard presented “The DDoS that didn’t almost break the Internet“. Everybody remembers the massive DDoS attack against SpamHaus a few months ago. Nick came back on this story and gave interesting details about how it happened. Everything started on March 18th with a DDoS against the website and blacklist servers operated by SpamHaus. They asked the help of CloudFlare to mitigate the attacks.

Nick Hiliard

Nick explained how the attack was performed: It was based on DNS amplification: a DNSSEC query for “ANY ripe.net” is 54 bytes but DNSSEC replies to this query with 3181 bytes (58x amplification!). 27 millions of open DNS servers are available in the Internet (source: openresolver.org). The attackers were a mix of compromised end-users, compromised WordPress/Joomly instances and VPS servers.  Most important, what are the lessons learned:

  • Unicast flood control is critical on IXPs
  • Use OOB networks to manage your critical devices!
  • IXP peeing IP’s should probably not be routed on the Internet
  • Reality rarely gets in the way of a good headline
  • Bad guys are careful not to get caught

Finally, keep in mind: botnets are large and use BCP38 and DNS ACLs

The presentation about “SQL Post-exploitation” was cancelled, the speaker was not able to join the conference. The SOURCE conference is now over! Thanks to Stacy & Christien for the organisation and to accept me as a speaker. If we met during the conference and have questions about my talk or tools, feel free to contact me! See you next year, again in Dublin?

3 comments

Leave a Reply

Your email address will not be published.

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