Presentation on SAML 2.0 Security Research

Compass Security invested quite some time last year in researching the security of single sign-on (SSO) implementations. Often SAML (Security Assertion Markup Language) is used to implement a cross-domain SSO solution. The correct implementation and configuration is crucial for a secure authentication solution. As discussed in earlier blog articles, Compass Security identified vulnerabilities in SAML implementations with the SAML Burp Extension (SAML Raider) developed by Compass Security and Emanuel Duss.

Antoine Neuenschwander and Roland Bischofberger are happy to present their research results and SAML Raider during the upcoming

Beer-Talks:
– January 14, 2016, 18-19 PM, Jona
– January 21, 2016, 18-19 PM, Bern

Free entrance, food and beverage. Registration required.

Get more information in our Beer-Talk page and spread the word. The Compass Crew is looking forward to meeting you.

Subresource Integrity HTML Attribute

Websites nowadays are mostly built with different resources from other origins. For example, many sites include scripts or stylesheets like jQuery or Bootstrap from a Content Delivery Network (CDN). This induces that the webmasters implicitly trust the linked external sources. But what if an attacker can force the user to load the content from an attacker controlled server instead of the genuine resource (e.g. by DNS poisoning, or by replacing files on a CDN)? A security-aware webmaster had no chance to protect his website against such an incident.

This is the point where Subresource Integrity kicks in. Subresource Integrity ensures the integrity of external resources with an additional attribute for the two HTML tags <link> and <script>. The integrity attribute contains a cryptographic hash of the external resource which should be integrated in the site. The browser then checks if the hash of the fetched resource and the hash in the HTML attribute are identical.

Bootstrap example:

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs8" crossorigin="anonymous">

In the example above, resource bootstrap.min.css is checked for its integrity with its Base64 encoded SHA-384 hash. If the integrity check is positive, the browser applies the stylesheet (or executes the script in the case of a <script> tag). If the check fails, the browser must refuse to apply the stylesheet or execute the script. The user is not informed if the check has failed and a resource therefore could not be loaded. The failed request can only be seen in the developer tools of the used browser. The following image shows the error message in the Chrome developer tools.

Console in browser does inform about subresource integrity check fail.

Console in browser does inform about subresource integrity check fail.

The crossorigin attribute in the example configures the CORS request. A value anonymous indicates, that requests for this element will not have set the credentials flag and therefore no cookies would be sent. A value of use-credentials would indicate, that the request will provide cookies to authenticate.

The subresource integrity attribute is currently being reviewed before becoming a W3C standard but is already supported by Chrome 45≤ , Firefox 43≤ and Opera 32≤.

Concluding, the subresource integrity attribute offers better possibilities for webmasters to ensure the integrity of external resources. However, this attribute is not supported by older browsers and needs to be adjusted at every resource change. In the end, a security aware webmaster will keep more control with less effort by keeping all resources hosted on his own servers.

Come’n’Hack Day 2015

Being a security analyst at Compass Security is an interesting thing, no doubt. Besides interesting projects, there is plenty of know-how transfer and interactions between the employees. For example, each year, all security analysts come together for an event called Come’n’Hack Day. During this year’s event, they had the pleasure to perform an attack/defense hacking contest against each other.

IMG_1447

Hacking-Lab‘s new Capture The Flag (CTF) system was used for this purpose. It was only the second time this system was used for an event, after the premiere at the European Cyber Security Challenge final last October in Lucerne.

IMG_6058

The participants were spread on three teams: Proxy Foxes, Lucky Bucks and Chunky Monkeys. Each team owned servers with running applications, and had different tasks to perform in order to get points:

  • ATTACK – Attack the other team’s applications, and steal a gold nugget.
  • DEFENSE – Protect its own applications.
  • CODE-PATCHING – Find and patch vulnerabilities in its own applications.
  • AVAILABILITY – Keep the own applications up and running.
  • JEOPARDY – Solve hacking challenges (cryptography, networking, etc.).
  • POWNED – Try to exploit the other teams’ servers.

After a hard fight, the Chunky Monkeys grabbed the first place, closely followed by the Lucky Bucks:

scoring

Almost one hundred gold nuggets were stolen during the day:gold_nuggets

All attendees enjoyed the highly eventful day. With six different ways to score points, each participant could contribute to its team’s success. This makes such a CTF occasion not only a great social event idea for security analysts but potentially for any organization having technical skilled employees (IT security officers, sysadmins and/or developers)!

What is a “Fake President Fraud” and how to Protect Your Company

“Fake President Fraud” or “CEO Fraud” is a social engineering attack where an adversary tries to convince a member of the financial department of a company to send out a payment to the attacker’s bank account. The attack can be divided into three steps.

  1. Establish Contact:
    Typically only employees responsible for bank transfers get contacted by the adversary, as they have all needed permissions to execute payments. Therefore the criminal impersonates a CEO or any other superior who has enough authority to arrange urgent payments.
    These kind of social engineering attacks work if the adversary gathers enough information about the individual he wants to impersonate. As most CEO’s are referenced on the world wide web with detailed personal information such as curriculum vitae and email address, it is easy for an attacker to gather everything he needs to fake a CEO email. Furthermore, company websites often disclose information about customers and other useful details which help an adversary to be more convincingly when requesting a payment.
  2. Request Payment Transaction:
    The attacker often uses email (spear phishing) or phone calls (vishing) to contact his target. Whereby a phone call only works if the victim does not know the voice of the impersonated superior, an attack over email has no such restrictions.
    The request itself is about an urgent payment to a foreign bank account and uses a variety of pretexts such as acquisitions or customer projects. For this step to succeed, the criminal uses different elements to convince the target to be compliant to his request and send out the payment:

    1. Authority: Asking the target as an authority adds a strong argument to every request. Jonathan J. Rusch writesPeople are highly likely, in the right situation, to be highly responsive to assertions of authority, even when the person who purports to be in a position of authority is not physically present.” One of the most impressive experiment in social psychology history, which demonstrated the blind obedience to authority figures, is the Stanley Milgram experiment.
    2. Valorization: The “fact” that the CEO or a superior has “chosen” this specific employee implies that he trusts him. The feeling of being trusted makes the body release oxytocin, often referred as the “love hormone”. This hormones facilitates trust and attachment between individuals. This is an additional factor that helps the attacker to quickly build feelings of rapport and to convince the target to be compliant to his request and send out the payment.
    3. Secrecy: In order to avoid that a target verifies the authenticity and validity of an order, attackers often label the request as “STRICTLY CONFIDENTIAL” or insert statements like “this project is still secret and its success depends on this transaction”.
    4. Pressure: Shifting all the responsibility for the success or failure of a project to the target’s shoulder, the attacker put a lot of pressure on him. This will induce the victim to be more compliant and execute the request.
    5. Urgency: Urgency and authority is a good combination to convince the target to perform the payment as fast as possible. The attacker creates a false sense of urgency in order to get the target to make a rushed judgment or a rash decision. Example email:ceofraud
  3. Transfer Money:
    If the attacker manages to convince the targeted employee to send out the payment, the money gets transferred to the foreign bank’s account.

 

Now the question arises what a company can do to avoid a “Fake President Fraud”. Different organizational and technical steps can be done to mitigate the risk of an incident.

  1. Organizational:
    1. If possible email or phone communication should not be allowed when authorizing large payments. Therefore a face-to-face meetings should be mandatory.
    2. Develop and communicate guidelines and processes of how payment transactions need to be handled.
    3. If a transaction does not fit the defined process it should be necessary that the employee asks feedback questions which verify that it is a authorized request.
    4. Employees should participate a special social engineering training to learn how to avoid getting manipulated by an attacker. The goal of the course should be to convey how an attacker thinks, arise a general awareness for social engineering attacks and explain that such attacks are not limited to one communication channel (e.g. email, SMS, WhatsApp, personal).
    5. Only publish as little financial and personal information in social media and company websites as necessairy. This makes it harder for an adversary to prepare his attack.
    6. A two-step (4-eyes) verification process when sending out large amounts of money to foreign bank accounts helps mitigating the damage an attack. It is important that the companies culture is good enough that the second person actually really reviews the payment and can challenge the first person without fears for both of them of being in a “Big Brother” system.
    7. Do not allow employees to use their personal email address for business purpose. This avoids that a compromised private email account allows someone to gain business data access.
  2. Technical:
    1. Do not allow that an email from an external mail server is accepted by your mail server when the email address contains your domain name.
    2. Always use email signatures/encryption at least when sending mails with confidential and/or sensitive content (e.g. S/MIME, PGP).
    3. Mark emails from external mail-servers with a tag inside the subject (e.g. [EXTERNAL]). This should be done when the emails enter the company’s mail server. With conditional formatting mails can be marked in red if the mail originates outside the company.
    4. To avoid an Outlook WebAccess from being hacked and used to perform a CEO Fraud, a strong authentication method should be used in addition of a strong password policy (e.g. client certificates, two factor authentication or access restriction to VPN traffic only).
    5. Attackers may register and use similar looking domains for a CEO fraud attack. To be aware of this, the company should check if there are any similar existing domains (e.g. .co instead of .com top-level domain) and blacklist them on their mail server.
    6. Additionally the company should try to register all similar looking domains to make it harder for an attacker to register a domain for his attack which looks slightly different then the domain of the company.

Even if the described attack is a real threat, exploited by attackers around the world every day, there are some effective steps to mitigate the risk of an incident as shown above. Especially an awareness training where the employee is taught when to be suspiciously and how attackers try to manipulate people is recommended, as this is the best protection against different types of social engineering attacks.

DCF77 Zeitsignal Manipulation

In diesem Artikel wird aufgezeigt, wie einfach das per Funk ausgestrahlte DCF77 Zeitsignal manipuliert werden kann. DCF77 wird in vielen Bereichen eingesetzt in denen eine genaue Uhrzeit benötigt wird: Von der einfachen Armbanduhr bis zur Industrieanlage.

Was ist DCF77

In Europa existiert seit 1959 der Zeit Sender DCF77. Der Sender verfügt über eine Reichweite von 2000km und befindet sich in Mainflingen – Deutschland. Drei Atomuhren dienen als Zeitbasis. Neuere Empfänger setzen teilweise auf GPS anstelle von DCF77, haben jedoch den Nachteil, dass sie eine Aussenantenne für den Empfang benötigen. Lösungen mit einer Internetanbindung hingegen beziehen ihre Zeit üblicherweise über das Netzwerk.

Bild-Quelle: https://de.wikipedia.org/wiki/DCF77#/media/File:Dcf_weite.jpg

DCF77 Reichweiten Karte

Wo wird DCF77 eingesetzt

Die DCF77 Einsatzgebiete sind unter anderem: Kirchturmuhren, Ampelanlagen, Tarifschaltuhren bei Energieversorgungsunternehmen, Industrieumgebungen, Server, öffentlicher Verkehr, Rundfunk oder normale Wecker und Armbanduhren.

Was sind die Folgen einer Zeitmanipulation

Bei einer Manipulation des Weckers des Nachbarn hält sich der entstehende Schaden im Allgemeinen in Grenzen. Im Gegensatz dazu stehen Automationslösungen wie sie z.B. in der Lebensmittel- oder Chemieindustrie vorkommen, bei denen durch falsche Prozesszeiten immense Schäden entstehen können.
Auch im Bereich der IT-Kommunikation können die Auswirkungen wahrgenommen werden z.B. falls Computerzertifikate nach einer Zeitmanipulation ihre Gültigkeit verlieren, da das Gültigkeitsdatum abgelaufen ist. Die verschlüsselte Kommunikation schlägt somit fehl.

DCF77 Sender im Eigenbau

DCF77 Sender sind im Gegensatz zu Empfängern öffentlich kaum erhältlich. Doch wie sieht es aus, wenn man selbst ein DCF77 Signal aussenden möchte? Der Zeitaufwand um selbst ein Sender (Hardware und Software) mit geringer Reichweite zu bauen, ist ähnlich gross wie einen eigenen Empfänger zu bauen. Die benötigten Informationen zum Bau eines Senders (Protokoll, Sendefrequenz, Modulation) sind im Internet leicht zu finden, werden sie doch auch zum Bau eines Empfängers benötigt.

Um die Anfälligkeit von DCF77 Systemen aufzuzeigen, wurde ein kleiner Sender mit einer Reichweite von ca. 30cm gebaut. Für höhere Reichweiten wäre eine grössere Antenne sowie ein Verstärker nötig. Die Umsetzung wäre mit geringem Aufwand möglich, die Aussendung des Signals jedoch illegal.  Mit dem Sender können beliebig manipulierte Zeitinformationen (Datum/Zeit/Wochentag) gesendet werden, die von den DCF77 Uhren, die sich im Empfangsbereich befinden, übernommen werden.

DECEEF77-Sender

DCF77 Piraten Sender – DECEEF77

Projektziel: DCF77 Piratensender mit kurzer Reichweite. Abgebildet ist die selbstentwickelte Hardware und Software DECEEF77 V.1.0. Der zu sendende Zeitstempel kann nach dem Einschalten bzw. Anschluss der mini USB Stromversorgung, über die drei Tasten (+ / Enter / -) eingestellt werden.

Protokoll

Trägerfrequenz 77.5kHz
Modulation Amplituden Modulation
Bitrate 1 Bit pro Sekunde
0.1 Sekunde Trägerabsenkung Logisches 0
0.2 Sekunde Trägerabsenkung Logisches 1
59. Sekunde Keine Trägerabsenkung

Das folgende Bild stellt die Sendeleistung über die Zeit dar. Jede Sekunde wird die Sendeleistung für 0.1 Sekunden (logisches 0) oder 0.2 Sekunden (logisches 1) abgesenkt, bei der 59 Sekunde findet keine Absenkung statt.

DCF77-AM-Modulation

DCF77-AM-Modulation

Der Zeitstempel wird innerhalb einer Minute vollständig übertragen. Im folgenden Kreisdiagramm sind die 59 Bits, die pro Minute übertragen werden, dargestellt. Pro Sekunde wird ein Bit übertragen, welches durch einen Strich auf dem Kreis eingezeichnet ist.

DCF77-Kreisdiagramm

DCF77-Kreisdiagramm

Der Zeitstempel wird in Bit 21 bis 58 codiert. Die mit P1, P2 sowie P3 gekennzeichneten Bits sind jeweils die Parity Bits die zur Validierung der korrekten Übertragung des Signals genutzt werden.

Hardware DECEEF77

  • µC: Atmel ATMEGA328P-PU
  • 16 MHz Quarz Takt
  • 77.5 kHz Rechteck zu Sinus Filter
  • Operationsverstärker als Verstärker für die Antenne.
  • Eine Ferritstabantenne die für den Empfang des DCF77 Signals gedacht ist, wurde verwendet, um das Signal auszusenden.
  • Print-Design mit Altium Designer

Schaltungsbeschreibung

DECEEF77-Schema

DECEEF77-Schema

Der Mikrocontroller U1 teilt den 16MHz Quarz Takt auf 77.5kHz runter. Auf dem Port PB3 wird entweder ein 5V Rechteck mit dem 77.5kHz Signal ausgegeben, oder PB3 wird hochohmig geschaltet. Es wird somit eine 100% Amplitudenmodulation verwendet (volle Leistung oder keine Leistung). Durch R2 und R4 wird bei hochohmigem Ausgang der Pegel auf 2.5V gehoben.

Durch mehrere Tiefpass-Filter (R6 bis R9, C6, C7, C10 und C11) wird das Rechtecksignal in einen Sinus (respektive Sinus ähnlich) umgewandelt.

DECEEF77-Tiefpassfilter

DECEEF77-Tiefpassfilter

Der Operationsverstärker U3 verstärkt das Signal und koppelt es über den Kondensator C9 auf die Antenne.

DECEEF77-Verstaerker

DECEEF77-Verstaerker

Die Schalter S1, S2 und S3 sind direkt an den Mikrocontroller Ports angeschlossen, die als Pull-Up Eingänge konfiguriert sind. Die Schalter dienen dazu die Zeit einzustellen (+, Enter, -).

DECEEF77-Schalter

DECEEF77-Schalter

U2 ist das LCD Display das über ein 4-Bit Interface verfügt.

DECEEF77-Display

DECEEF77-Display

J1 dient als In-Circuit-Programmier-Interface und verwendet das Standard 6-Pin ISP Layout.

DECEEF77-ISP

DECEEF77-ISP

Der Test

Ein DCF77-Wecker wird dazu verwendet, um die Funktion des Senders zu testen. Nach 3 bis 5 Minuten läuft der Wecker synchron mit dem Sender.

DECEEF77_TEST

Black Hat USA 2015 – part 2

For the second part of our report about Black Hat USA 2015, we decided to change topic, and switch from web application security to two hot topics nowadays: Security in Internet of Things and mobile security. We encourage you not only to read this summary but also to go online and take a closer look at the videos or the slides. We aimed at giving you all the relevant links for each talk.

Remote Exploitation of an Unaltered Passenger Vehicle

Presented by Charlie Miller & Chris Valasekvideo

One of the most publicized talks before Black Hat even started, was the manipulation of the Jeep car. Some content of this talk could already be seen on YouTube weeks before the Black Hat conference. Therefore, the expectation for this presentation were really high.

BH_passenger_vehicleCharlie and Chris, the two speakers, mastered the pressure in a very sovereign way. They presented the whole attack, from discovering the cars that could be hacked remotely, to the point of completely take control over the car’s management interfaces, including components affecting the driving features such as the car’s breaks. Besides the technical details of the car architecture and the attacks used to circumvent some of the car’s security mechanism, they fill the talk with funny stories occurred during the months of research. An example was how they managed to explain to the garage mechanic repairing their test car why the display of the media center got suddenly black, “without” any obvious reason for it. These funny stories together with the demonstration videos make the talk worth of watching it.

In conclusion, despite the cool presentation and the nice techniques used, this talk illustrates the fatal consequences of poor security in the Internet of Things. A lot of objects nowadays are connected to the Internet and can be managed remotely. If the security mechanisms implemented are not sufficient to circumvent malicious attacks the outcome can be very scary, like for example a car remote controlled by an hacker. If you are interested in IoT security and want to know more about attacks and how to protect against these, don’t miss our new and upcoming Compass Security course for Internet of Things next year.

StageFright: Scary Code in the Heart of Andorid

Presented by Joshua Drakeslidesvideo

Mobile security became very popular in the last Stagefright_bug_logoyears. One of the presentation at Black Hat 2015 that received most reactions regarding mobile security was certainly StageFright. StageFright is an Android’s Multimedia Framework library written primarily in C++. It handles all videos and audio files and also MMS. The weaknesses found inside this library, a buffer overflow, was also baptized StageFright and permits an hacker to execute arbitrary operations on the victim device through remote code execution and privileges escalation. The talks showed a proof of concept that didn’t require user interaction but get directly executed when an MMS was received on an Android device. It means, the number of the victim, together with knowing that the OS of his cellphone is an Android, is the only information that an hacker needs to know to perform the attack.

The StageFright weakness was rated so high that Deutsche Telekom decided for example to disallow the transmission of MMS on his network.

Some proofs of concept performed by Compass Security showed that the attack vector is not as straightforward to exploit as explained during the talk and that the payload need to be adjusted depending on which version of OS is in use. However, the consequences can be fatal if the attack is a minimum targeted. As mitigation there are several approaches: First of all apply the Android patch. If this cannot be achieved, disable automatic retrieval of MMS messages. However, this is not supported in all MMS applications and does not cover the download through the web browser. As the ultimate solution one can block the reception of text messages from unknown senders.

References:

Black Hat USA 2015 – part 1

Black Hat USA is the most famous IT security conference in the world that every year congregate thousands of security experts and interested to Las Vegas. For its 18th year the conference took place in the glamorous Mandalay Bay Conference Center in Las Vegas. And as every year, two security analysts of Compass Security have attended the conference to learn about the latest trends in IT security.

Mandalay Bay Resort & Casino

For the first part of the post we have chosen two talks concerning web security that show elegant techniques for a penetration tester or attacks on new frameworks. We encourage you not only to read this summary but also to go online and take a closer look at the videos or the slides. We aimed at giving you all the relevant links for each talk.

FileCry XXE

Presented by Xiaoran Wang & Sergey Gorbaty – slideswhitepapervideo

External Entity Attacks (short XXE) is not a new attack vector and the possibilities to exploit these have been already studied by many researchers.

In a nutshell, XML allows inclusion of external resources and the parser will include these automatically. This type of attacks was mostly seen as a server side vulnerability to achieve server side resource inclusions and potentially arbitrary command executions. The two researchers of Salesforce presented a very elegant attack that exploits XXE on client side bypassing the Same Origin Policy.

Many libraries in the past were affected by XXE, so also the Microsoft library MSXML3.0. This library is deprecated and replaced by the non-vulnerable MSXML6.0 library. However, it is still available in older version of IE, for example IE 6. In IE it is possible to force the browser to switch to compatibility mode. By just putting the meta tag <meta content=”IE=6″ http-equiv=”X-UA-Compatible”> in a web page the browser is forced to switch mode and loads also the dll of the deprecated library. Afterwards, the deprecated library can be used, as showed in this short code snippet:

xmlDoc = createDocumentFromText(text,"3.0",null);
xmlDoc.loadXML(text);

The next step was to think about a method to bypass the SOP. The parser uses the browser engine as a resolver for external entities in order to enforce SOP. A redirection handler on the attacker controlled site was introduced that made a redirection to the external entity. IE only checks SOP for the initial request but does not enforce SOP in the case of a redirection.

With this method it was possible not only to bypass SOP but also to read out arbitrary files on the filesystem of a victim visiting the hacker website. There are some limitations in the attack: First the content of the file read should not contain characters like \x00, &, %. Therefore, most of the html pages cannot be retrieved with this method. Second, in order to retrieve files on the filesystem, the exact filename and path should be known to the attacker. Here the list provided by the researchers:

  • victim file/site cannot contain null-byte
  • most HTML pages are not vulnerable
  • the first few hundred characters are vulnerable
  • JSON pages are vulnerable
  • binary files are not vulnerable
  • works only on Windows 7 and below
  • all IE versions though

The patch for this vulnerability was released by Microsoft on April 2015 therefore, if you have patched your system, you should be safe.

Server-Side Template Injection: RCE for the modern webapp

Presented by James Kettle – whitepaper – video

Template engines are nowadays popular frameworks to represent dynamic data via web pages. If unsafely used, application could be misused to perform server side template injections. This talk focused on how to detect such vulnerabilities and determine which template engine is used. In case of a template injection the consequences could be fatal: remote code executions can be achieved, turning every vulnerable application into a potential pivot point.

The speaker presented a very well structured approach on how a penetration tester can analyze an application to find such flaws. The first step would be detect a template injection. This is in general the most difficult step. This vulnerability can appear in two distinct contexts, a plaintext and a code context.

For example sending the request {7*7} and receiving 49 in the response could be an indicator for a plaintext context template injection. In most of the cases where a plaintext context template injection is present, it is also possible to find a XSS vulnerability. Otherwise, with a code context template injection, XSS is in general not possible. But it is possible to inject HTML tags, for example by sending }}<tag>.

After having detected the vulnerability, the second step is to determine the template engine in use. If it is not possible to find it out by inspecting error messages or server banners, a penetration tester can send different payloads to evaluate differences in the response. The speaker showed a very useful diagram to accelerate this task:

payloads

Afterwards, the possibilities to exploits such a vulnerability are infinite. For example, with the FreeMarker template we can send the following payload to extract the user running the service:

<#assign ex="freemarker.template.utility.Execute"?new()> ${ ex("id") }

As one can directly see, the consequences of having such a vulnerability in his own web page would be terrible. However, during the presentation, the speaker didn’t explain in depth how such a flaw would arise. The developer has to completely misunderstand the usage of a template to make such error occur. This could happen if template code is not loaded statically from the filesystem but created dynamically with some input taken from the user. Or it could occur through the intentional exposure of template markdown in an attempt to offer rich functionality to the end-user.

References:

Compass Security at CYBSEC15 in Yverdon-les-Bains

CYBSEC15

As in past years, Compass Security will participate in the upcoming CyberSec Conference in Yverdon-les-Bains (formerly Application Security Forum – Western Switzerland). This year, we will contribute in two events:

First, Antoine Neuenschwander and Alexandre Herzog will conduct a day long training session on Tuesday, November 3rd. Participants will be able to exercise their skills and learn with step-by-step instructions on how to exploit vulnerable web applications at their own pace and with the support of the trainers within the hacking-lab.com CTF environment.

ivanoSecond, Ivano Somaini will share his practical experience of physically breaking into banks and other critical infrastructures in his talk “Social Engineering: The devil is in the details” on Wednesday, November 4th. Ivano looks forward to his first talk in the French speaking part of Switzerland. He was lately a lot in the news in the Swiss Italian and German part of Switzerland, due to his extensive interviews to Coop Cooperazione (in Italian), to the Tages Anzeiger (in German), and his participation to popular talkshow “Aeschbacher” on Swiss television SRF1 (video of the interview).

We are looking forward to meeting you at this occasion, either during the Castle evening networking event, the workshop or the conferences!

Aftermath of the Netgear Advisory Disclosure

Update – 13.10.2015: Netgear published a new firmware (version 1.1.0.32) which fixes the reported authentication bypass.

My most recently appointed colleague, Daniel Haake, described in the previous blog article “Authentication Bypass in Netgear WNR1000v4 Router” how he found an authentication bypass in commonly used Netgear firmwares. Due to the rediscovery of the issue and its public disclosure, we decided to go public despite the fact Netgear did not yet release a fix for the identified security hole.

Shortly after the release of the Compass advisory on public mailing list Bugtraq, we were contacted by Joe Giron, who experienced troubles with his Internet connection around September 27th. On September 28th, Joe noticed that his Netgear router’s primary DNS server had been set to point to a non-standard DNS server. This timeframe means that attackers were active before the release of Shellshock Lab’s blog article (which is detailing the same vulnerability). Joe mentioned that the remote administration interface of his Netgear router was accessible via the Internet, but protected by a strong password. He therefore had high suspicions that he fell victim of an attack against an unpatched vulnerability in his router. The release of our advisory was the confirmation and technical explanation of it.

The IP of the rogue DNS server set in his router did not only expose a DNS service, but also a web server. This web server served various PHP scripts, log files and text files. The logs contained over 17’000 entries of presumably hacked routers, including their IP address, username and password of their administration interfaces. A further analysis of this list would identify more than 11’000 unique routers.

netgearpasswords

As we discovered that this authentication bypass was being exploited in the wild and that over 10’000 users were affected, we contacted Switzerland’s CERT for further help. GovCERT was very helpful and took over the case by

  • Attempting to contact Netgear again to urge them to release the patch
  • Analyzing the logs of the web server and identifying the victims
  • Taking down the command and control server to avoid further infections
  • Liaising with GovCERT’s partners worldwide to notify the Internet service providers of the victims

In the meantime, the media got interested in the advisory and Threatpost published yesterday evening an article about the flaw and its follow-up. A second person reached out to us after the publication of this article, describing the same infection vector as well as the same IP address for the DNS and C&C server. We are currently in contact with other media outlets and will update this section when further articles are released.

The debate between responsible- and full disclosure is endless and both approaches have their pro- and cons. At Compass Security, we attempt to get the best balance between these two approaches. We are confident that our approach of leaving some time for the vendor to patch the vulnerability before publicly disclosing the issue in case of no adequate response was the best. Public information has proven to work and helped identifying ongoing attacks. Coordination with the relevant authorities allowed coordinated action against the attackers and will hopefully help the victims of this hack.

Media Update, 11.10.2015:

Media Update, 12.10.2015:

Authentication Bypass in Netgear WNR1000v4 Router

Three months ago I tested the web interface of the Netgear WNR1000v4 router for some typical vulnerabilities. When playing around with the application by forcefully calling different URLs in contexts it was not meant for, I got some strange, but interesting behaviour.

I accessed different URLs and then switched back to the root web directory to have a look at some web application feature. At this moment I realized that I did not have to submit any credentials to access the administration interface. It seemed that the whole HTTP authentication process was not active anymore and I remembered that I definitely did not log in because I wanted to test the password reset feature. This was really strange, so I logged out and had a look at my Burp request history to determine which resource triggered this behaviour.

After some tests I realized that the resource /BRS_netgear_success.html is the problem. If you are not authenticated and call the URL several times the HTTP Basic Authentication temporary gets deactivated and you can access the administration interface without username and password [1].

This works because the “password deactivation feature” is used when you first plugin the router to configure some settings the first time.

I tested this vulnerability on the WNR1000v4 Netgear router with the following firmware versions:

Because this firmware is used for multiple devices, other devices are probably affected as well. This page references a list of devices which are very likely to be impacted [2]:

  • JNR1010v2
  • JWNR2000v5
  • JWNR2010v5
  • WNR614
  • WNR618
  • WNR1000v4
  • WNR2020
  • WNR2020v2

After the discovery I contacted Netgear through different channels to find a way for responsible disclosure. Unfortunately Netgear was not very responsive and it took a longer time until they responded. After about 2 months they sent me an undisclosed security fix which solves the problem. Netgear twice refused to respond to our request for a patched firmware release date. In the meantime, the issue was rediscovered and publically disclosed by another researcher [4]. This public disclosure prompted us to release our advisory to the public on October 6th.

In this case not the end of the story, but just the trigger of further events detailed in follow-up post “Aftermath of the Netgear Advisory Disclosure”.

References:

[1] http://www.csnc.ch/misc/files/advisories/CSNC-2015-007_Netgear_WNR1000v4_AuthBypass.txt
[2] http://kb.netgear.com/app/answers/detail/a_id/28025
[3] http://kb.netgear.com/app/answers/detail/a_id/26742
[4] http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.html