Reading this advisory I’m quite tempted to emit another rant on the relationship of heavy use of 3rd party components, lack of (security) quality assurance and services running at times where they’re not needed (see second workaround here). I’ll refrain from that for today. Just wanted to let you know that the underlying vulnerability in Struts2 was initially discovered by Meder Kydyraliev who gives this talk at Troopers in two weeks. He’ll certainly describe the inner workings of this one, and others… 😉
gtp_scan is a small python script that scans for GTP (GPRS tunneling protocol) speaking hosts. To discover those hosts it uses the GTP build in PING mechanism, it sends a GTP packet of the type ECHO_REQUEST and listens for an incoming GTP ECHO_REPLY. Its capable of generating ECHO_REQUESTS for GTP version 1 and GTP version 2. Also the script can scan for both, GTP-C and GTP-U (the control channel and the user data channel), only the port differs here.
In the output the received packet is displayed and the basic GTP header is dissected so one can see a GTP version 1 host answering a GTP version 2 ECHO_REQUEST with the ‘version not supported’ message.
Tests have shown that there are some strange services around, which answer to an GTP ECHO_REQUEST with a lot of weird data, which leads to ‘kind of’ false positive results but they can easily be discovered by checking the output data with your brain 😉 (eg. there is no GTP version 12)
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 …
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
Finding exploitable vulnerabilities is getting harder. This statement of Dennis Fisher published on Kaspersky’s Threatpost blog summarizes a trend in the development lifecycle of software . The last published vulnerabilities that were gaining some attention in the public had all one thing in common, they were quite hard to exploit. The so called jailbreakme vulnerability was based on several different vulnerabilities that had to be chained together to break out of the iPhone sandbox, escalate its privileges and run arbitrary code. Modern software and especially modern operating systems are more secure, they contain less software flaws and more protection features that make reliable exploitation a big problem that can only be solved by very skilled hackers. Decades ago it was just like this, but intelligent tools and sharing of the needed knowledge enabled even low skilled people to develop working exploits and attack vulnerable systems. Nowadays we are going back to the roots where only a few very knowledgeable people are able to circumvent modern security controls, but that doesn’t mean that all problems are gone. Attackers are moving to design flaws like the DLL highjacking problem, so only the class of attacks is changing from the old school memory corruption vulnerabilities to logical flaws that still can be exploited easily. But the number of exploitable vulnerabilities is decreasing, so this might be a sign that we are on the right way to develop reliable and secure systems and that developing companies are adopting Microsofts Secure Development Lifecycle (SDL) to produce more secure software. As stated in my previous blogpost the protection features are available, but not used very often. But if they are used and if the developers are strictly following the recommendations of the SDL, this trend of “harder to exploit vulnerabilities” proves that it can be a success story to do so.
One of the four vulnerabilities rated “critical” from yesterday’s MS patchday, that is MS10-063, has an interesting “Workarounds” section as for MS Internet Explorer. There it’s stated:
“Disabling the support for the parsing of embedded fonts in Internet Explorer prevents this application from being used as an attack vector.”
which, according to the advisory, should/can be done by setting the “Font Downloading” parameter to “Disable”.
Which is exactly what this document suggests. So taking a preventive approach, once more, might have saved some concerns (“Will we be targeted by this one”) and patch/testing time…
This is currently the most frequent search term leading Internet users to the Troopers website.
Probably Sheran Gunasekera’s great presentation “Bugs & Kisses – Spying on BlackBerry users for fun” is the piece they are after. Whatever they look for, this search term may help to shed light to an aspect that seems a bit overlooked in the ongoing debate about governments (U.A.E., Saudi Arabia, India) trying to get their hands on communication acts performed with BlackBerries in their countries.
[For those interested in that discussion this blog entry of Bruce Schneier may serve as a starting point.]
Given that most readers of this blog using a BlackBerry will most likely do so with a BlackBerry Enterprise Server (BES) installation, in this post I’ll focus on those deployments and will subsequently not cover BlackBerry Internet Service (BIS) scenarios.
RIM, very understandably, stresses the fact that in the current BES architecture – presumably – they [RIM] can only process (thus “see”) the data stream encrypted (by symmetric ciphers regarded sufficiently secure) between the BES servers usually placed on corporate soil and the endpoint devices (the Blackberries themselves).
What they don’t mention is the simple fact that cryptographic techniques quite often only secure some data’s transport path, but not elements on the endpoints (where the data is unencrypted and further processed). What if either the (BlackBerry) devices provide means to eavesdrop on the traffic – and Sheran discussed the relevant APIs in his talk, referring to the “Etisalat case” where in 2009 the major U.A.E. telecommunications provider distributed a software application for Blackberries that essentially allowed somebody [who?] to eavesdrop on emails by sending a copy of each email to a certain server – or even the BES itself is “somehow interfered with”? This article from Indiatimes at least suggests the latter possibility for BES servers located in India. Here’s a quoted excerpt:
“Significantly, the only time an enterprise email sent from a BlackBerry device remains in an un-encrypted or ‘readable’ format is when it resides in the enterprise server. ‘Feeding the email from the enterprise server to the ISP’s monitoring systems can, accordingly, help security agencies access the communication in pure text form’, DoT [India’s Department of Telecommunications] proposal said.”
So, in short, just discussing if BlackBerry based communication can be intercepted in transit may be a bit short-sighted. Thinking about the devices and the code they run (and who’s allowed to install applications, by what means/from which sources, yadda yadda yadda) or considering “some countries’ regulatory requirements” when deploying BES servers might be helpful, too.
It should be noted that we do not allege RIM any dishonest motives whatsoever (actually we have a quite positive stance as for the overall security posture of their products, if nothing else see for example this newsletter analysing the over-the-air generation of master encryption keys between the BES and the devices).
We just want to raise some awareness to the mentioned “blind spots” in the current debate.
For those of you who missed it: Microsoft released the associated advisory yesterday, together with a hotfix introducing a new registry key that allows users to control the DLL search path algorithm. For a detailed explanation of the problem we refer to the excellent article on Ars Technica.
For the record: no, AV (anti-virus software) will – in most cases – not protect you from security problems related to this one. And, no, there is no easy patch for this one either.
Carefully reading the “Mitigating Factors” and “Workarounds” section in the MS advisory or this entry from our blog might provide ideas how to address this or similar stuff (in the future).
Wishing you all some sunny summer days,
Enno
Update: this article gives some more technical details and this one describes some real attack paths against popular applications. Sorry, guys, good luck with fighting this one with traditional AV…
Just wanted to let you know that we sent out ERNW Newsletter 32 end of last week. As we promised it includes the results of research regarding the question “Is browser virtualization a valid security control in order to mitigate browser based security risks?”.
Simon did a great job with writing the latest newsletter. It’s a 30-page document which should help you to have a basis for well-informed decisions when it comes to the deployment of an application virtualization technology.
Download a signed version of the PDF here, or visit the archive to browse other issues of our highly technical newsletters.
Everybody who is interested in our newest tool ‘Loki’ is welcomed to head over to ERNW’s tool section and download it. Take this monster for a spin and let us know in the comments how you like it. Loki’s coding father Daniel is more than happy to answer your questions and criticism.
You don’t even know what Loki is?
In short: An advanced security testing tool for layer 3 protocols.
In long: Have a read in the Blackhat2010 presentation slides and mark TROOPERS11 in your calendar to meet the guys behind the research and for sure get a live demo of the capabilities – development is still ongoing, so prepare yourself for even more supported protocols and attack types.
And again: Talking about TROOPERS11… we’ve already selected the first round of speakers. Details to be published soon 🙂
