Author: Michael Thumann

Events
by Michael Thumann

TROOPERS20 Training Teaser: TLS in the Enterprise – Post Quantum Security

Our workshop “TLS in the enterprise” was held for the first time at Troopers 2018 and was our special contribution to the IT Security world to increase the usage of TLS and point out the pitfalls, when switching to TLS.

But time is changing and TLS is a kind of standard nowadays, at least when looking at HTTPS, but there are still a lot of things to do regarding other protocols like

  • Jabber
  • LDAP
  • Telnet
  • SMTP, POP3 and IMAP
  • SIP and RTP
  • MySQL
  • Postgres
  • SSL based VPNs

just to name a few ;-). We will cover that in our training too, but the most important new stuff will be Post Quantum Security and how it will affect the future of encryption. We will talk about crypto algorithms and which of them can still be used in the future, we will talk about timelines and preparation (including the actual state of technology) like develop your master plan and we will try to clear up the myths regarding quantum computers to get your enterprise ready for the post quantum era :-).

Become aware that quantum computers will likely break most traditional public key crypto and every secret it protects. Examples for affected crypto: RSA, DH, ECC, ElGamal, PKI, digital certificates, digital signatures, VPNs, WiFi protection, smartcards, HSMs, crypto currencies, two factor authentication which relies on digital certificates (e.g. FIDO keys, Google security keys, etc.) and of course TLS.

And the quantum computers are not that far away, as the following timeline proves:

  • 1998: first working quantum computer
  • 2016: Google develops quantum computer
  • 2017: D-Waves announces the commercial availability of the D-Wave 2000Q™ quantum computer
  • 2017: IBM and Microsoft announces quantum computers
  • 2018: several quantum microprocessors available
  • 2019: likely over 100 quantum computers available

hmm, you are afraid now? No ;-)! You are curious? You got the point, it’s time to get prepared. The early bird catches the worm (which btw. is also true for getting your Troopers ticket and workshop seat 😉 ) the NSA said, and it moved to post-quantum in January 2016.

So to satisfy your curiosity, see you at our workshop “TLS in the enterprise” at Troopers 2020.

Cheers

Frieder and Michael

Continue reading
Building
by Michael Thumann

DirectoryRanger 1.5.0 Is Available

The next major release of DirectoryRanger is now available for customers, and for everyone who would like to try it ;-). Current attacks show that quite often the topic of Active Directory Security is not on the security agenda, but it should be, and this was the reason for us to build the tool and, of course, to maintain and improve it. So what are the major new features released with DirectoryRanger 1.5.0? Here we go:

Continue reading “DirectoryRanger 1.5.0 Is Available”

Continue reading
Building
by Michael Thumann

DirectoryRanger 1.1.0 Introduces Informational Audit Checks

With version 1.1.0 our tool DirectoryRanger introduces a new feature: informational audit checks. These checks do not have a severity rating because they are just “for your information” and the included information might or might not contain security issues, depending on other facts. But these checks can help to reduce your Active Directory attack surface by pointing you to some aspects which need your attention and at least require to be discussed and documented (and they might also imply governance measures like a risk acceptance).

Continue reading “DirectoryRanger 1.1.0 Introduces Informational Audit Checks”

Continue reading
Building
by Michael Thumann

printf(“Hello World!”)

ERNW has a new baby, so please say “hello” to the new ERNW SecTools GmbH ;-).
But why another ERNW company? Short answer: Because we want to contribute to changing the way how software is built today: insecure, focused on profit and sometimes made by people who ignore lessons from history. So how can we contribute in this space? Start changing it ;-).

Continue reading “printf(“Hello World!”)”

Continue reading
Breaking
by Michael Thumann

Mobile Application Testing

Our new workshop about mobile application testing, held for the 1st time at the Troopers conference 2013, is coming closer. So I would like to take the opportunity and post an appetizer for those who are still undetermined if they should attend the workshop ;-).

While the topic of mobile application testing is a wide field that may contain reverse engineering, secure storage analysis, vulnerability research, network traffic analysis and so forth, in the end of the day you have to answer one question: Can I trust this application and run it on my enterprise devices? So first you have to define some criteria, which kind of behavior and characteristics of an application you regard as trustworthy (or not). Let us peek at malware … besides harming your devices and data, malware is typically:

  • obfuscated and/or encrypted
  • contains anti-debugging features
  • contains anti-reverse engineering features

This makes the analysis process a difficult task and comparing these characteristics especially to ordinary iOS applications from the AppStore, at least one is also true for these apps: Those are encrypted and are only decrypted at runtime on your Apple gadget ;-).

Continue reading “Mobile Application Testing”

Continue reading
Breaking
by Michael Thumann

Microsoft Advisory 2757760: Windows Internet Explorer Zero-Day Vulnerability

Actually a Windows Vulnerability (Microsoft Advisory 2757760) related to the Internet Explorer Version 7, 8 and 9 is in the news. Microsoft is aware of the problem, but there’s no patch available yet. We call this a 0-Day :-). Making the problem even worse, on monday reliable exploit code was released within the Metasploit project, so exploit code is already in the wild.

Basically Microsoft suggests two workarounds:

But both of them have some impact: EMET must be deployed before any usage (btw. EMET can be configured via Group Policies) and disabling Active X and Active Scripting might break some business relevant web sites (that can be added to the “Trusted Sites” Zone, but might produce major operational effort).

There are more possible mitigating controls, so let’s just summarize some ideas:

  • Use of alternative browser: if you have it deployed already, go for it :-). Otherwise we have the same deployment issue as with EMET.
  • Sandboxing/Application Virtualization: It’s the same as with the alternate browser, of you have it, go for it, otherwise it will be a long term project. And be aware that also Application Virtualization won’t address all issues (see the ERNW Newsletter 32 for details).
  • No local admin rights: This doesn’t protect from exploiting the vulnerability, but at least reduces the impact. We strictly recommend to check the local administrator group and remove all users that don’t rely on it for fulfilling their business tasks. And btw. this topic is not new ;-), see also ERNW Newsletter 4, published in 2004!
  • Blocking communication for the clients at the corporate firewall: Be aware that this doesn’t really work. Modern exploit code is able to use the corporate proxy infrastructure including authentication to circumvent this control. Metasploit has exploit payloads for this.
  • Disabling/Blocking Flash content: While potentially not strictly required for exploitation, at least in some of the exploits currently observed in the wild Adobe Flash plays a major role. So like discussed in  these Insinuator posts (1, 2 and 3), restricting the use of Adobe Flash would proactively prevent some known exploits from working. But the newly published Metasploit exploit doesn’t use Flash, so keep  in mind that this mitigating control can only be used in addition to other ones.

So for a short term mitigation we recommend the following (especially for corporate environments)

  1. Disabling Active X and Active Scripting via Group Policies
  2. Disable/block Flash content
  3. Remove unneeded local administrative privileges
  4. If available use alternative browser or EMET

For long term mitigation (might also be feasible in small environments as short term mitigation):

  1. Deploy EMET
  2. Evaluate possibilities of application sandboxing/virtualization
  3. Deploy alternative browser. Be aware that deploying a second browser might not be an option for big corporate environments (central management and supporting/maintaining additional software are the main reasons for this).

And finally DON’T PANIC ;-), start to address the problem in a professional way.

Hope that helps a bit
Michael

Continue reading
Breaking
by Michael Thumann

The Web Application Firewall Story continues

Some days ago another advisory related to a web application firewall (WAF) product was published. This time the product Airlock by Ergon was affected by a vulnerability that combines Encoding and NULL Byte attacks to circumvent the pattern based detection engine. We have described these attacks in detail in our newsletter “Web Application Firewall Security and The Swiss Army Knife for Web Application Firewalls” because they belong to a well known category of attacks against WAFs.

The product is commonly used in the swiss banking industry to ensure PCI DSS compliance and serves as another proof that WAFs can’t protect web applications from skilled attackers as already stated by me in an earlier post that you can find here. Beside these “5 myths of web application firewalls” we can also look at WAFs based on the typical attack vectors against web applications:

These attack vectors are described in detail in the famous “Web Application Hackers Handbook” and if you’re doing web application assessments they belong to the mandatory test methodology. Based on our WAF research we have compiled a little nice diagram that reflects the technical capabilities of WAFs to protect against these attack vectors:

As you can see especially authorization (user A can access data of user B) attacks and also logic flaws can not be addressed by WAFs because they can not be detected by pattern matching and even by whitelisting approaches. By the way when testing banking web applications one of the most relevant questions to answer is “can customer A see account information of customer B” :-). This raises the question “Why is the banking industry using WAFs to protect their customers data instead of fixing vulnerabilities in their applications or in general ensuring the quality?”. And again, finally we end up realizing that implementing a Security Development Lifecycle (SDL) would fulfill our “security needs” in a more effective way, but this time just from an attackers point of view.

Have a great day
Michael

Continue reading