Breaking

Some More Security Research on The nPA AusweisApp

After the initial quick shot (see this post) we decided to have a closer look. And some more stuff turned up.

After decompiling the integrated java stuff we stumbled about hard coded server credentials:

package Idonttell;

public abstract interface Idonttell
{
public static final boolean debug = false;
public static final boolean auth = true;
public static final String SMTP_SERVER = "Idonttell.openlimit.com";
public static final String SMTP_USER = "Idonttell@Idonttell.openlimit.com";
public static final String SMTP_PASSWORD = "Idonttell";
public static final String SEND_FROM = "Idonttell@Idonttell.openlimit.com";
public static final String[] SEND_TO = { "buergerclient.it-solutions@Idonttell.com" };
public static final String MAIL_HEADER_FIELD = "OpenLimitErrorMessage";
public static final String MAIL_HEADER_FIELD_PROP = "yes";
}

The AusweisApp uses these credentials to authenticate against a mail server and send error reports to a dedicated email address. The server was accessible from the internet and services like SMTP, FTP and SSH were running. Following the principles of responsible disclosure the vendor was contacted and responded within a few hours, so the servers are already protected against any kind of misuse. So save your time and keep the german hacking laws in mind ;-).

Nevertheless doing code reviews for years, one point on the checklist is secure storage of data. Any kind of secrets should never be included directly in the source code and never ever in cleartext like it was done in the AusweisApp. These secrets can be accessed quite easily, so how useful is an authentication feature, if everybody knows the password ;-)?

This leaves me scratching my head. Maybe I was a bit overhasty when writing this 😉

Ok, getting serious again, this finding is another proof that the concept of rating closed source software based on well chosen metrics can help to determine the trustworthiness of software, because building secure software means that you develop with security in mind and this is what these metrics are measuring.

have a nice week and be aware of more updates as our research continues. We’re investigating another interesting possible flaw …

Michael

Continue reading
Breaking

Our contribution to the public discussion about the German new ID card (nPA)

Currently there’s quite some discussion about the security properties and posture of the German new ID card (“Neuer Personalausweis”, “nPA”, some technically reasonable security discussion can here be found e.g. here.

While – as of our current knowledge – we do not expect major security flaws on the architecture level, the problems discussed so far (like Evilgrade style attacks against one of the main applications or keylogging the PIN in scenarios with pinpad-less readers ) certainly show that security best practices must be followed by all parties involved in the development, deployment and use of the nPA and it’s associated applications. From our perspective this may be expected from the applications’ developers as well.
Looking at this:

TTICheck 32/64 Bit - (c) 2010 Michael Thumann
[i] Scanning .

.\ePALib_Client.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\mozilla\AusweisApp_FF3x_Win\components\siqeCardClientFFExt.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\npeCC30.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\pdcjk.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\PDFParser.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\PdfSecureAPI.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\PdfValidatorAPI.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\PdfViewerAPI.dll; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqApp.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqBootLoader.exe; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqBootLoaderAC.exe; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqCertMgr.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqCIFRepository1_1.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqCipher.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqCryptoAPI.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecCert.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecCertAttr.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecCertCV.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecCRL.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecCTL.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecMgr.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecOCSP.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecOCSPRequest.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecP12.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecP7.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecTSP.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecTSPRequest.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqDecTypeMatcher.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqeCardAPI_svr.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqeCardClient.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqEncP7.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqEPAProfile.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqHash.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqISO7816EPA.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqOIDManager.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqP1Verifier.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqP7Encoder.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqRNG.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqSEMk.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqSEMk_srv.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqSEMkApp.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqSSLClient.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqTerminalPCSC.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\siqTiffTxtParser.ols; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09
.\toolKillProcess.exe; Linker Version 8.0; ASLR NOT supported; DEP NOT supported; No SEH found; TTI = 26.09

we’re not sure if that’s the case ;-), when looking at the new AusweissApp with our closed source security metric.

So far for our little contribution to the mentioned debate,

have a great day everybody,

Michael

PS: At Troopers 11 there will be a presentation from Friedwart Kuhn on using the nPA for authentication purposes in corporate environments.

Continue reading
Building

ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 1

At several occasions we’ve been asked to provide some background on the Rapid Risk Assessment (RRA) methodology we frequently use for a transparent (and documented) understanding of risks in certain situations and to deliver structured input for subsequent decision taking. As I had to write down (in another context) some notes on risk assessments and – from our perspective – practical, reasonable ways of performing them, I take the opportunity to lay out a bit the underlying ideas of the RRA approach. Which, btw, is no rocket science at all. Honestly, I sometimes wonder why stuff like this isn’t practiced everywhere, on a daily basis 😉

Here we go, second part to follow shortly. Feel free to get back to us with any comments, criticism, case studies, whatever. Thanks,

Enno

============

1. Introduction

There’s a number of heterogeneous definitions of the term “risk”, quite some of them with an inconsistent or ambiguous meaning and use[1]. In the following we will rely on the definitions furnished by the standard documents ISO 31000 Risk management — Principles and guidelines (providing a widely recognized paradigm for risk management practitioners from different backgrounds and industry sectors[2]) and ISO/IEC 27005 Information technology — Security techniques — Information security risk management (with a dedicated focus on the information security context).

ISO 31000 simply defines risk simply as

             “effect of uncertainty on objectives”

where uncertainty is “the state, even partial, of deficiency of information related to, under­standing or knowledge of an event, its consequence, or likelihood”[3] [ISO31000, p. 2].

Accepting uncertainty as being the main constituent of risk is a fundamental prerequisite for our approach outlined below. It must be well understood that first a certain degree of uncertainty is intrinsic to dealing with risks[4] and second that there’s always a trade-off bet­ween the – given resource constraints and human bounded rationality[5] – necessary reduction of complexity and (presumed) accuracy during an exercise of risk assessment.

[ISO31000, p. 8] emphasizes that “the success of risk management will depend on the ef­fectiveness of the […] framework” and [ISO31010[6], p. 18] concludes that “a simple method, well done, may provide better results than a more sophisticated procedure poorly done.”

Or, to express it “the blog way”: going with a simple method and thereby preserving the ability to perform exercises in a time-efficient manner, while accepting some fuzziness, will usually provide better results (e.g. for well-informed decision making) than striving for the big hit of a comprehensive risk enlightenment considering numerous potential dependencies and illuminating various dimensions of security objectives (which usually gets finished at the very moment Godot arrives).

2. Sources of Threats

In general two main possible approaches can be identified here:

  1. Use of a well-defined threat catalogue (usually one and the same at different points of execution) which might be provided by an industry association, a standards body or a government agency regulating a certain industry sector. While this may serve the common advantages of a standards based approach (accelerated setup of overall procedure, easy acceptance within peer community etc.), [ISO31010, p. 31] lists some major drawbacks of this course of action, laying out that check-lists    
    • tend to inhibit imagination in the identification of risks;
    • address the ‘known knowns’, not the ‘known unknowns’ or the ‘unknown unknown’.
    • encourage ‘tick the box’ type behavior
    • tend to be observation based, so miss problems that are not readily seen.

 

  • Adoption of (mostly) individual threats for individual risk assessment performances, depending on the amount of available resources, the context and “the question to be answered by means of the exercise”. This certainly requires more creativity and most notably experience on the participating contributors’ side, but will generally produce better and more holistic results in a more time-efficient way.

One essential element of the RRA is to (only + strictly) follow the latter approach (individual threats, depending on context). This means that some key players of the exercise-to-be-performed have to figure out the main threats before the proper risk assessment’s performance (usually by email) and that additional threats are not allowed later on. Again, in our perception, this is one of the critical success factors of the approach!

3. Contributing Factors

ISO 27005 (currently, that is as of 2008) defines information security risk as the

                    “potential that a given threat will exploit vulnerabilities of an asset […]
                     and thereby cause harm to the organization”.

Following this, three main factors contribute to the risk associated with a given threat:

  • the threat’s potential
  • the vulnerabilities to-be-exploited
  • the harm caused once the threat successfully materializes.

There’s a vast consensus amongst infosec risk assessment practitioners – and this is reflected by the way the wikipedia article on “risk” explains information security risk – that it hence makes sense to work with an explicit “vulnerability factor” expressing how vulnerable an asset is in case a threat shows up, for two main reasons:

  • When thinking about threats, this allows to differentiate between “external pheno­mena” (malware is around, hardware fails occasionally, humans make errors) and “internal conditions” (“our malware controls might be insufficient”, “we don’t have clustering of some important servers”, “our change control procedures are circumvented too often”).
  • This differentiation allows for governance and steering in the phase of risk treatment (“we can’t change [the badness of] the world, but we can mitigate our vulnerability”;  which then is expressed by a diminished vulnerability factor and subsequently reduced overall risk.)

This furthermore facilitates looking at some asset’s (e.g. a product’s) intrinsic pro­perties (leading to vulnerabilities) without knowing too many details about the environment the asset is operated in.
  


[1] The wikipedia article on the subject might serve as a starting point.

[2] Based on AS/NZS 4360 which in turn is regarded as a major contribution to the mainstream concept of risk in the 20th century.
The definition of the term “risk” within ISO 31000 is taken from ISO GUIDE 73:2009 and it can be expected that future versions of ISO 27005 will incorporate this definition (and the underlying idea) as well.

[3] It should be noted that the terms (and concepts) of “risk” and “uncertainty” might dispose of some duality on their own (see [COFTA07, p. 54ff.] for a detailed discussion on this). Still, we strictly follow the ISO 73 approach here.

[4] Where “assessing them” is one step in “dealing with risks”.

[5] [COFTA07, p.29] employs the concept of a “transactional horizon” to express the inherent limitations. Furthermore see [KAHNEMANN] or [SIMON] on bounded rationality.

[6] ISO 31010 gives an overview of risk assessment techniques.

Continue reading
Building

The Case For/Against Split Tunneling

Once again, in some customer environment the question of allowing/prohibiting split tunneling for (in this case: IPsec) VPN connections popped up today. Given our strict stance when it comes to “fundamental architectural security principles” the valued reader might easily imagine we’re no big fans of allowing split tunneling (term abbreviated in the following by “ST”), as this usually constitutes a severe violation of the “isolation principle”, further aggravated by the fact that this (violation) takes place on a “trust boundary” (of trusted/untrusted networks).
Still, we’re security practitioners (and not everybody has such a firm belief in the value of “fundamental architectural security principles” as we have), so we had to deal with the proponents’ arguments. In particular as one of them mentioned additional costs (in case of disallowed ST forcing all 80K VPN users’ web browsing through some centralized corporate infrastructure) of US$ 40,000,000.
[yes, you read that correctly: 40 million. I’ve still no idea where this – in my perception: crazy – number comes from]. Anyhow, how to deal with this?
Internally we performed a rapid risk assessment (RRA) focused on two main threats, that were:

a) Targeted attack against $CORP, performed by means of network backdoor access by piece of malware acting as relay point.

a) Client gets infected by drive-by malware as not being protected by (corporate) infrastructure level controls.
[for obvious reasons I’ll not provide the values derived from the exercise here]
While the former seems the main reason why NIST document SP 800-77 “Guide to IPsec VPNs” recommends _against_ allowing ST, the RRA showed that the latter overall constitutes the bigger risk. To illustrate this I’ll give some numbers from the excellent Google Research paper “All Your iFRAMEs Point to Us” which is probably the best source for data on the distribution and propagation of drive-by malware.

Here’s the paper’s abstract:

“As the web continues to play an ever increasing role in information exchange, so too is it
becoming the prevailing platform for infecting vulnerable hosts. In this paper, we provide a
detailed study of the pervasiveness of so-called drive-by downloads on the Internet. Drive-by
downloads are caused by URLs that attempt to exploit their visitors and cause malware to be
installed and run automatically. Our analysis of billions of URLs over a 10 month period shows
that a non-trivial amount, of over 3 million malicious URLs, initiate drive-by downloads. An even
more troubling finding is that approximately 1.3% of the incoming search queries to Google’s
search engine returned at least one URL labeled as malicious in the results page. We also explore
several aspects of the drive-by downloads problem. We study the relationship between the user
browsing habits and exposure to malware, the different techniques used to lure the user into the
malware distribution networks, and the different properties of these networks.”

and I’m going to quote some parts of it in the following, to line some (in the end of the day: not so) small calculations.

The authors observed that from “the top one million URLs appearing in the search engine results, about 6,000 belong to sites that have been verified as malicious at some point during our data collection. Upon closer inspection, we found that these sites appear at uniformly distributed ranks within the top million web sites—with the most popular landing page having a rank of 1,588.”

Now, how many of those (top million websites and in particular of the 0.6%) will be visited _every day_ by a 80,000 user population? And how many of those visits will presumably happen over “the split tunnel”, thus without corporate infrastructure level security controls?
Looking at the post infection impact they noticed that the “number of Windows executables downloaded after visiting a malicious URL […] [was] 8 on average, but as large as 60 in the extreme case”.
To be honest I mostly cite this opportunisticly to refer to this previous post or this one 😉

And I will easily refrain from any comment on this observation ;-):
“We subject each binary for each of the anti-virus scanners using the latest virus definitions on that day.  […] The graph reveals […] an average detection rate of 70% for the best engine.”

Part of their conclusion is that the “in-depth analysis of over 66 million URLs (spanning a 10 month period) reveals that the scope of the problem is significant. For instance, we find that 1.3% of the incoming search queries to Google’s search engine return at least one link to a malicious site.”

Let’s use this for some simple math: let’s assume 16K Users being online (20% of those 80K overall VPN users) on a given day, performing only 10 Google queries per user. That’s 160K queries/day. 1.3% of that, i.e. about 2K queries will return a link to at least one malicious site. If one out of 10 users clicks on that one, that means 200 attempted infections _per day_. If you cover 70% of that by local AV, 60 attempts (the remaining 30%) succeed. This gives 60 successful infections _each day_.
So, from our perspective, deliberately allowing a large user base to circumvent corporate infrastructure security controls (only relying on some local anti-malware piece) might simply… not be a good idea…

thanks

Enno

Continue reading