Thursday, January 21, 2016

Deliberately hidden backdoor account in several AMX (HARMAN Professional) devices

Your conference room, a watchful protector.

About the vendor: "AMX ( is part of the HARMAN Professional Division, and the leading brand for the business, education, and government markets for the company. As such, AMX is dedicated to integrating AV solutions for an IT World. AMX solves the complexity of managing technology with reliable, consistent and scalable systems comprising control and automation, system-wide switching and AV signal distribution, digital signage and technology management. AMX systems are deployed worldwide in conference rooms, homes, classrooms, network operation/command centers, hotels, entertainment venues and broadcast facilities, among others." Source:

To be fair, their products really do offer a wide variety of features, which is probably also the reason why US President Barrack Obama is sometimes seen in front of a control panel by AMX, while sitting in a meeting at the White House. According to the case studies published by AMX they have multiple governmental and military bodies equipped with their conference room gear. This includes but is not limited to the White House, the U.S. Forces Afghanistan as well as the Center for Strategic and International Studies (CSIS).
Some of the affected devices seem to be "tested and approved by the US DoD as a JITC certified secure command and control, conference, training and briefing room solution" as well according to this AMX web page. Further AMX market customer profiles can be accessed here: AMX customer profiles

Black Widow and Batman, the watchful AMX protectors
Black Widow and Batman, the watchful protectors within the AMX device
(Image sources, AMX:
Black Widow:

With that said, lets talk about security.

How AMX (HARMAN Professional) handles security.

In early 2015 SEC Consult decided to take a look into the security of a conference room solution provided by AMX. Let's not waste any words on the tiring process of getting the binaries out of the small black box and jump right to the meat of it all.

During the analysis of the authentication procedure of one of the central controller systems (AMX NX-1200), something strange popped up:

IDA excerpt: "setUpSubtleUserAccount" function
IDA excerpt: "setUpSubtleUserAccount" function

A function, which they decided to call "setUpSubtleUserAccount". And this function does exactly what the name would suggest.
It sets up a subtle user account. The strings seen in the above screenshot, revealed an interesting detail about the vendor's security strategy. AMX apparently called for a little extra help in the universe of Marvel superheroes to protect their products (and coincidentally also the U.S. military) from the evil super villain hackers. At least that is what we assume, because the expert spy and top S.H.I.E.L.D. agent Black Widow has her own personalized account on the device.

"Natasha Romanova, known by many aliases, is an expert spy, athlete, and assassin. Trained at a young age by the KGB's infamous Red Room Academy, the Black Widow was formerly an enemy to the Avengers. She later became their ally after breaking out of the U.S.S.R.'s grasp, and also serves as a top S.H.I.E.L.D. agent"

Like most superheroes, Black Widow prefers to stay under the radar, not requesting any credit for her heroic actions. Because of that, the vendor made an effort in hiding her details from eyes of innocent admins and users alike:

AMX Master Configuration Manager: Black Widow backdoor account is hidden and does not show up anywhere
AMX Master Configuration Manager: Black Widow backdoor account is hidden and does not show up anywhere
As the daily work of a superhero, especially for an IT SECURITY SUPERHERO, is quite challenging, AMX went ahead and implemented some additional tools like a packet-capture/sniffing facility, to aid the expert spy Black Widow in the fight against the super villain hackers. These tools are only available to our superhero as the power they hold should not be available to simple administrators.

Responsible disclosure

As usual, SEC Consult Vulnerability Lab communicated this issue according to our responsible disclosure policy. Initial contact and exchange of the security advisory was performed through the European sales team at AMX. About seven months(!) later AMX provided a fix for the backdoor. A quick review of the new firmware showed that the backdoor was still in place, but Black Widow was gone. Did she decide to step down after being exposed? Did they fire her? Unfortunately we don't have any details on this.

(Image source:
(Image source:

Whatever the reason may be, the vendor decided to hire somebody from the DC universe this time. Na na na na na na na na ... you guessed it. BATMAN! But not the usual Batman, the leet-hacker-Batman, who uses numbers and special characters to write his own name:

IDA excerpt: New backdoor username 1MB@tMaN
IDA excerpt: New backdoor username 1MB@tMaN
(Image source:
This time around, we decided (tried) to get in direct contact with somebody responsible for security at AMX (HARMAN Professional). After numerous emails requesting a security contact to exchange the information about the vulnerability, finally somebody replied. We exchanged the security advisory unencrypted, as requested by AMX. Then they went silent again.

Fast forward another three months to early 2016, we had still not heard back from AMX, despite asking for a status update several times, and even postponing the release of the security advisory in order to give them (even) more time for sorting things out with Batman and Black Widow.

Yesterday (2016-01-20) AMX finally replied, informing SEC Consult that they have released firmware updates for the affected products. These updates are untested and unconfirmed by SEC Consult.
Grab them here while they're hot: - we were told that some of the updates can only be retrieved through AMX tech support.

Furthermore, our contact stated that AMX will be starting a major security initiative which is a very good thing to do!

For the tech geeks, here is our advisory with additional technical information, a contact timeline detailing the communication attempts and a list of affected devices.

Be aware though, that the backdoor password is only for agents of S.H.I.E.L.D. and hence will not be disclosed.

Tuesday, January 12, 2016

McAfee Application Control - The dinosaurs want their vuln back

(c) Fotolia 69135396

Bypassing McAfee Application Whitelisting for Critical Infrastructure Systems

The experts of the SEC Consult Vulnerability Lab conducted research in the field of the security of application whitelisting in critical infrastructures. In the course of that research the security of McAfee Application Control was checked.

The experts developed several methods to bypass the provided protections (application whitelisting, read- and write protections as well as memory corruption protections).

Moreover different vulnerabilities were identified including the installation of software from 1999 with a well-known buffer overflow in it on all protected systems.

McAfee was notified by SEC Consult on 2015-06-03. Since the vendor didn't fix the described vulnerabilities within the responsible disclosure deadline an advisory was released on 2015-07-28. McAfee claimed to provide fixes for the identified vulnerabilities by the end of third quarter 2015, however, at the current moment all issues remain unfixed.

Due to this fact the experts of the SEC Consult Vulnerability Lab now release the whitepaper on the security of McAfee Application Control.

The whitepaper can be downloaded from our website here:
McAfee Application Control whitepaper

Talks on that topic were already presented at conferences such as IT-SeCX 2015, DeepSec 2015 and BSides Vienna 2015. Additional information can be found in the slides from the talks.

Out of our experience we at SEC Consult consider it necessary for critical infrastructures to regularly install new updates, use only software reviewed by security professionals and further increase the awareness of end users with security trainings. For such systems it’s not enough to solely rely on a security layer such as application whitelisting. Rather, the underlying security of the system itself must be increased.

We do not see a reason for not using application whitelisting if the software is secure and doesn’t tear holes in the overall system security but it’s important to understand that it doesn’t replace robust security measures.


The slides with further details including vendor response from IT-SeCX 2015 are available here:

A (German) video of the IT-SeCX 2015 talk can be found on YouTube:

Update (2016-01-20): The English video from DeepSec 2015 Vienna can be found here:

Link to the advisory (including workarounds):

Wednesday, November 25, 2015

House of Keys: Industry-Wide HTTPS Certificate and SSH Key Reuse Endangers Millions of Devices Worldwide

© seanlockephotography | Fotolia

In the course of an internal research project we have analyzed the firmware images of more than 4000 embedded devices of over 70 vendors. The devices we have looked at include Internet gateways, routers, modems, IP cameras, VoIP phones, etc. We have specifically analyzed cryptographic keys (public keys, private keys, certificates) in firmware images. The most common use of these static keys is:
  • SSH Host keys (keys required for operating a SSH server)
  • X.509 Certificates used for HTTPS (default server certificate for web based management)
In total we have found more than 580 unique private keys distributed over all the analysed devices. Correlation via the modulus allows us to find matching certificates.

We have correlated our data with data from Internet-wide scans ( and and found that our data set (580 unique keys) contains:
  • the private keys for more than 9% of all HTTPS hosts on the web (~150 server certificates, used by 3.2 million hosts)
  • the private keys for more than 6% of all SSH hosts on the web (~80 SSH host keys used by 0.9 million hosts)
So in total at least 230 out of 580 keys are actively used. Other research has pointed out the extent of this problem (Heninger, Nadia, et al. "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Durumeric, Zakir, et al. "Analysis of the HTTPS certificate ecosystem"). However using our approach, an attribution at a vendor/product level is now possible. Plus the private keys have now been obtained.

Focus of analysis by SEC Consult

How do static keys come into existence?

They have been embedded, essentially "baked in" the firmware image (operating system) of devices and are mostly used for providing HTTPS and SSH access to the device. This is a problem because all devices that use the firmware use the exact same keys. The impact is described later in this post. The keys are not a result of bad randomness (e.g. Debian weak keys, PRNG boot gap, etc.).

The source of the keys is an interesting aspect. Some keys are only found in one product or several products in the same product line. In other cases we found the same keys in products from various different vendors. The reasons vary from shared/leaked/stolen code, white-label devices produced by different vendors (OEM, ODM products) to hardware/chipset/SoC vendor software development kits (SDKs) or board support packages firmware is based on. Here are some examples:
  • A certificate issued to a "Daniel", email ( is used in firmware from Actiontec, Aztech, Comtrend, Innatech, Linksys, Smart RG, Zhone and ZyXEL. This certificate is found in a Broadcom SDK. The affected vendors used it as a basis to develop their own firmware. More than 480.000 devices on the web are using this single certificate.
  • A certificate issued to Multitech in Bangalore, India is used in firmware from Aztech, Bewan, Observa Telecom, NetComm Wireless, Zhone, ZTE and ZyXEL. This certificate can be attributed to a Texas Instruments SDK for ADSL2+ routers. Over 300.000 devices on the web are using this certificate. A SSH host key can be attributed to this SDK as well.
  • A certificate issued to "MatrixSSL Sample Server Cert" is used in WiMAX gateways from Green Packet, Huawei, Seowon Intech, ZTE and ZyXEL. All affected devices use the same code base, which is likely developed by ZyXEL. At least 80.000 devices on the web are using this certificate.

Why are so many devices exposed to the web?

Another aspect to the whole story is the large number of devices directly accessible on the web. Just by looking at the numbers one can deduce that it is highly unlikely that each device is intentionally exposed on the web (remote management via HTTPS/SSH from WAN IP). Enabling remote management exposes an additional attack surface and enables attackers to exploit vulnerabilities in the device firmware as well as weak credentials set by the user.

In some cases this behaviour can be attributed to a vendor's insecure default configuration. An example is Ubiquiti Networks, who have remote management enabled by default in most products. This issue is documented in a separate blog post. We have also noticed that there is a surprisingly high number of Seagate devices on the web. Around 80.000 Seagate GoFlex home NAS devices are exposing HTTPS and SSH. The Seagate Share feature sets up port forwarding via UPnP. This feature is most likely responsible for a lot of the exposed devices and it is unclear if users are even aware of this problem.

In other cases ISPs expose their subscriber's devices (CPE - customer premises equipment) to the Internet. By correlating the affected hosts with GeoIP information, we found large clusters of devices with the same keys located in the networks of different ISPs. We can deduce that devices are CPEs provided to subscribers. These devices are owned, distributed and managed by ISPs and use ISP-specific firmware. Some ISPs have a particularly bad track record when it comes to exposing remote management interfaces:
  • US-based ISP CenturyLink exposes HTTPS remote administration on more than half a million devices, which is close to 10 percent of their total subscribers (6.1 million). Affected products include ZyXEL's Q1000, C1000Z, Actiontec's GT784WN, C2000A, C1000A, V1000H, and Technicolor's C2000T and C2100T.
  • TELMEX in Mexico exposes HTTPS remote administration on more than one million devices (22 million subscribers total). Affected products are various Huawei Internet Gateways including HG658d.
  • Telefónica in Spain (Movistar) exposes SSH remote administration on more than 170.000 devices. Affected products are Comtrend's VG-8050 and possibly some ZyXEL DSL gateways.
  • China Telecom exposes SSH remote administration on more than 100.000 ZyXEL and ZTE devices.
  • VTR Globalcom in Chile exposes SSH remote administration on more than 55.000 Ubee Interactive cable modems.
  • Chunghwa Telecom in Taiwan exposes SSH remote administration on more than 45.000 ZyXEL devices.
  • Telstra in Australia exposes SSH remote administration on more than 26.000 Cisco devices.
Top 10 Countries

What is the impact of the vulnerability?

Impersonation, man-in-the-middle or passive decryption attacks are possible. These attacks allow an attacker to gain access to sensitive information like administrator credentials which can be used in further attacks. In order to exploit this vulnerability, an attacker has to be in the position to monitor/intercept communication. This is easily feasible when the attacker is located within the same network segment (local network). Exploiting this vulnerability via the Internet is significantly more difficult, as an attacker has to be able to get access to the data that is exchanged. Attack vectors can be BGP hijacking, an "evil ISP", or a global adversary with the capability to monitor Internet traffic.

Searching for key fingerprints in data from Internet-wide scans is a low-cost way of finding the IP addresses of specific products/product groups. This enables researchers to measure the extent of the problem but attackers can use this approach as well to exploit vulnerabilities (e.g. weak passwords or vulnerabilities in firmware) at scale.

Which vendors/products are affected?

We found more than 900 products from about 50 vendors to be vulnerable. Of course our data is limited to the firmware we had access to. Affected vendors are: ADB, AMX, Actiontec, Adtran, Alcatel-Lucent, Alpha Networks, Aruba Networks, Aztech, Bewan, Busch-Jaeger, CTC Union, Cisco, Clear, Comtrend, D-Link, Deutsche Telekom, DrayTek, Edimax, General Electric (GE), Green Packet, Huawei, Infomark, Innatech, Linksys, Motorola, Moxa, NETGEAR, NetComm Wireless, ONT, Observa Telecom, Opengear, Pace, Philips, Pirelli , Robustel, Sagemcom, Seagate, Seowon Intech, Sierra Wireless, Smart RG, TP-LINK, TRENDnet, Technicolor, Tenda, Totolink, unify, UPVEL, Ubee Interactive, Ubiquiti Networks, Vodafone, Western Digital, ZTE, Zhone and ZyXEL.

We have generated tree maps in order to interactively explore the HTTPS certificate and SSH host key exposure on the public web including distribution on a per-country and ISP basis. Affected products are included as well in the hover boxes.

SSH Host Keys

Did you inform affected parties?

We have worked together with CERT/CC to address this issue since early August 2015. CERT/CC made great efforts to inform affected device vendors, chipset manufacturers and affected ISPs. Some vendors have responded and have started to implement fixes. CERT/CC informed major browser vendors as well. This vulnerability is tracked as VU#566724. Several CVE-IDs have been assigned as well.

What can be done?

As a first step, vendors should make sure that each device uses random, unique cryptographic keys. These can be computed in the factory or on first boot. In the case of CPE devices, both the ISP and the vendor have to work together to provide fixed firmware for affected devices.

Furthermore ISPs have to make sure remote access via the WAN port to CPEs is not possible. In case the ISP needs access for remote support purposes, setting up a dedicated management VLAN with strict ACLs (no CPE to CPE communication) is recommended.

End users should change the SSH host keys and X.509 certificates to device-specific ones. This is not always possible as some products do not allow this configuration to be changed or users do not have permissions to do it (frequent in CPE devices). The required technical steps (generating a certificate or RSA/DSA key pair etc.) are not something that can be expected of a regular home user.

Recommended selected elements of a mitigation strategy for vendors to avoid deploying insecure, ‘toxic’ devices are:
  • Execution of application security tests with high assurance level for all product components
  • Enforcement of Software Security Assurance in the whole software development process
  • Ongoing reevaluation of the maturity of application security
  • Maintenance of trust in the market through a long-term, fundamental approach to application security rather than a reactive and opportunistic one

All identified certificates and private keys will be released shortly.

We want to thank CERT/CC for coordinating this vulnerability and the team at the University of Michigan and Rapid7 for publishing their Internet-wide scan data.

This study was conducted by Stefan Viehböck, Senior Security Consultant at SEC Consult.

Thursday, November 5, 2015

The Omnipresence of Ubiquiti Networks Devices on the Public Web

There are ongoing in the wild attacks against Ubiquiti Networks devices. Attackers are using default credentials to gain access to the affected devices via SSH. The devices are infected by a botnet client that is able to infect other devices.

Further information about these attacks is available at:

The high number of Ubiquiti Networks devices on the web is due to an insecure default configuration. Remote administration is enabled by default. Contrary to best practice this exposes the HTTP/HTTPS and SSH administration service to the web (via the WAN port). This issue has been discussed on the support forums on several occasions. The Ubiquiti Networks employees' statements were:

"After we disabled management to WAN interface by default, there were many many complaints. Many WISPs still need access to the WAN interface for: provisioning the devices, and management -- even when in place at customer's home, the WISPs still want access." -Ubiquiti Networks Support

"We did disable remote management by default, and took a lot of flack from our users, so we reverted it." -Ubiquiti Networks Support

This "insecure out of the box" approach is unique among network device vendors. WISPs are Wireless Internet Providers, who offer broadband services using Ubiquiti Networks gear. Ars Technica has a feature on one of these WISPs.

Attackers can remotely exploit weak passwords and vulnerabilities in the firmware to gain access to affected devices and are doing just that right now. After gaining access to the device, attackers can create a large botnet that can be used for DDoS attacks, spamming etc. The affected device class is a valuable target as it not only allows access to the internal network but also access to traffic that passes through it. Attackers can redirect DNS queries (e.g. to attack online banking sites) or even infect web downloads by people who connect to the internet via the device.

As organizations and individuals struggle with securing embedded devices, a long lifespan of an infection is guaranteed.

Another vulnerability lies in the reuse of cryptographic secrets. A certificate including its private key is embedded in the firmware of several Ubiquiti Networks products. This certificate is used for the HTTPS service (default server certificate for web based management) and is the same on all devices. An attacker in a privileged network position can execute man-in-the-middle or passive decryption attacks on the HTTPS communication. These attacks allow access to sensitive information like admin credentials. This vulnerability is significantly harder to exploit than the vulnerability discussed above. However, searching for the certificate fingerprint in data from internet-wide scans is a low-cost way of finding the IPs of specific products/product groups and allows us to measure how many Ubiquiti Networks devices are exposed to the web.

The project by University of Michigan and Rapid7 periodically scans the public internet and collects information. By correlating the fingerprint of the certificate used with the Sonar SSL Certificates data set, we can find devices that are intentionally or unintentionally exposed to the web. In a recent scan we found more than 600.000 devices. We have analyzed the distribution of other static cryptographic secrets in use in embedded devices and have yet to find a certificate that is more frequently used than one by Ubiquiti Networks devices.

In the meantime the Censys Project by University of Michigan has launched. Censys is a scan-driven search engine that allows us to quickly find hosts that use the certificate. At the moment Censys reports that more than 1.100.000 devices are using this certificate (eb54c44a32a64497d8926ff87ba708f96fb0bff3).

Most devices are located in Brazil (480.000), Thailand (170.000) and the United States (77.000), but deployments of significant size are found in the Iraq, Spain and Poland as well. We have created an interactive tree map that allows to explore the geographical distribution of affected hosts at a country and ISP/organization level. The tree map is based on the data and covers less hosts than the data by Censys.

We have contacted Ubiquiti Networks back in August and communicated our findings (further information can be found our security advisory). While they have acknowledged the reuse of cryptographic secrets and proposed a fix, they have yet to comment on the remote administration issue.

Users can protect themselves from attacks by disabling remote administration and setting a strong administrator password. Changing the certificate to a custom one is also highly recommended as well.

The advisory contains technical information found in the certificate including corresponding RSA private key. Another certificate (fingerprint 61c96773fa2064148511d5cae262b721ba001fb6) was found to be used by other Ubiquiti Networks products as well, and is used on around 14.000 devices on the web.

Reuse of cryptographic secrets in HTTPS server certificates as well as SSH (host keys) is a widespread issue in embedded systems. We are in the process of preparing a larger study that will be released later this month.

Update: Some users have requested a list of affected products. We have documented the results of our analysis (incl. product list) in our security advisory. The list is not necessarily complete though and has not been confirmed by Ubiquiti Networks.

Wednesday, November 4, 2015

Interview: SEC Consult Praktikant Thomas Weber über die gewonnene European Cyber Security Challenge

Thomas Weber, former SEC Consult intern, was part of the winning team of the European Cyber Security Challenge (ECSC). We congratulate him and the team for this great success! It was a good opportunity for him to apply the knowledge he gained in his study at the Technical University of Vienna (Master Embededd Systems), during his internship at SEC Consult and through additional self motivated studies. He looks forward to participate in next years ECSC.

The complete interview with Thomas is available in German:


Die zweite European Cyber Security Challenge (ECSC) ist geschlagen! Beim Finale am 22. Oktober in Bern setzte sich das österreichische Nationalteam gegen Deutschland, Rumänien, Spanien, Großbritannien und die Schweiz durch. Unter den Siegern ist Thomas Weber, 25 Jahre, Student an der Technischen Universität Wien und ehemaliger Praktikant bei SEC Consult. Wie er die European Cyber Security Challenge erlebt hat und warum seine Praktikumserfahrung maßgeblich zum Sieg beitrug, erzählt er im Interview im SEC Consult Blog.

Credits: Swiss Cyber Storm

Erstmal herzliche Gratulation zum Sieg! Wie fühlt man sich, gegen so starke Teams angetreten zu sein und doch gewonnen zu haben?
Ich bin einfach stolz auf unser Team. Wir haben gezeigt, dass wir uns auf einem hohen Niveau behaupten können und das ist schon ein gutes Gefühl.

Wie kam es überhaupt zu deiner Teilnahme an der European Cyber Security Challenge?
Ich wurde durch einen Online-Artikel auf diesen Wettbewerb aufmerksam. Da ich gerne Rätsel löse und mich auch im Zuge meines Studiums (Master Embededd Systems) viel mit Computer beschäftige, habe ich mich angemeldet.

Das Team Österreich musste ja zuerst formiert werden, oder?
Ja, die nationale Ausscheidung begann mit einer Online-Qualifikation, bei der sich jeweils zehn Schüler und zehn Studenten qualifizieren konnten. Dabei mussten einzelne Aufgaben gelöst werden, wofür es Punkte gab. Wer im Gesamtranking bei den ersten zehn dabei war, kam ins österreichische Finale. Bei diesem wurden wir in Gruppen zu fünf Leuten gelost und hatten einen gewissen Zeitrahmen, in dem wieder Aufgaben gelöst werden mussten – natürlich vor dem konkurrierenden Team, da die Gruppe mit der schnelleren (und richtigen) Abgabe mehr Punkte bekam.

Wie hast du dich (bzw. auch das gesamte Team) auf das Finale in der Schweiz vorbereitet?
Wir haben begonnen, gezielt Strategien vorzubereiten, um optimal auf diese gemischte Form des Jeopardy/Attack-Defense CTFs eingestellt zu sein. Es haben sich nach und nach Leute im Team gefunden, die die verschiedenen Rollen (Server-Infrastruktur, Attack/Defense, Pressearbeit...) übernahmen und sich das entsprechende Wissen aneigneten. Wir haben uns diverse Programmiersprachen näher angesehen und mit der in der Schweiz zu erwartenden Infrastruktur verschiedene Szenarien durchprobiert, da wir einen ESXi Server von der CSA (Cyber Security Austria) zur Verfügung gestellt bekamen. Um das Netzwerk mussten wir uns nicht selbst kümmern, das übernahm die Organisation der Swiss Cyber Storm, die den Bewerb organisierte.

Was war deine Rolle / dein Part im Team Österreich?
Ich war einer der Leute, die Webapplikationen auf Schwachstellen untersuchten, um diese dann bei den anderen Teams ausnützen zu können. Jedes Team  hatte auf den Teamservern die gleichen Dienste am Laufen.

Was waren die Aufgabenstellungen?
Es gab mehrere Reverse-Engineering Aufgaben, die auf bereitgestellten Laptops zu lösen waren. Dabei musste auch der Netzwerkverkehr analysiert und ein Custom-Algorithmus zur Verschleierung des Netzwerk-Traffics geknackt werden. Die üblichen CTF Webservices liefen auf bereitgestellten Teamservern, die es zu verteidigen galt. Dabei war eine Website mit absichtlich eingebauten Sicherheitslücken zu untersuchen und zu reparieren, sodass die anderen Teams diese Lücke nicht ausnützen konnten.

Was war die größte Herausforderung?
Die größte Herausforderung war der komplett neue Modus. Im Punktesystem sowie bei den Aufgaben gab es leider noch Pannen, die natürlich bei solch einem Wettbewerb passieren können – gerade, wenn er neu ist. Dies betraf unser Team am Anfang sehr stark, da unsere Attack-Punkte über einen längeren Zeitraum nicht gezählt wurden. Dadurch hatten wir ein starkes Defizit zu den anderen Ländern. Das war möglich, da einige Teams alle Services stoppten und kaum Punkte verloren. Dieser Punktefehler wurde jedoch nach zwei Stunden behoben, der erlittene Punkterückstand blieb allerdings. Ich bin jedoch zuversichtlich, dass die ECSC nächstes Mal viel reibungsloser ablaufen wird, nicht zuletzt weil die Veranstalter ein hervorragendes Spiel auf die Beine gestellt haben.

Wie konnten dir deine gesammelten Erfahrungen vom Praktikum bei SEC Consult im Rahmen der ECSC helfen?
Ich bin um einiges schneller und effizienter geworden, wenn es um das Erkennen der relevanten und irrelevanten Sicherheitslücken geht. Als ich bei SEC Consult begonnen habe, haben mir die Schulungen und Meetings in den ersten drei Wochen meines Praktikums sehr viel gebracht. Das schnelle Erkennen war auch beim ECSC gefordert, da man ansonsten bei unwichtigen Teilen eines Webdienstes viel Zeit
verlieren kann.

Was empfiehlst du anderen jungen Menschen, die ebenfalls White-Hat-Hacker werden wollen?
Das Zeug zum White-Hat hat jeder, der ausdauernd, neugierig und technisch interessiert ist. Empfehlenswert, aber nicht notwendig, ist ein Studium mit Informatikschwerpunkt. Allerdings kommt man nicht drum herum, sich selbst Wissen anzueignen. Derartige Wettbewerbe sind eine gute Möglichkeit viele Dinge durch Eigeninitiative zu lernen, daher lohnt es sich auf jeden Fall mitzumachen!

Wirst du nächstes Jahr wieder an der Cyber Security Challenge teilnehmen?

Wie sehen deine weiteren (Karriere-)Schritte aus?
Ich werde mein Masterstudium weiterführen und nach dem Abschluss in die Privatwirtschaft gehen.

Zur Person
Thomas Weber ist Student an der Technischen Universität Wien (Master Embededd Systems) im dritten Semester.  Zum Studium führte den 25-Jährigen seine Leidenschaft für Informatik, insbesondere im Bereich Hacking. Als professioneller White-Hat-Hacker möchte Weber in Zukunft das World Wide Web sicherer machen. 

Monday, June 22, 2015

Bypassing Microsoft EMET 5.2 - a neverending story?

The experts of the SEC Consult Vulnerability Lab managed to adapt the EMET 5.0 / 5.1 bypasses to additionally work against the latest Microsoft EMET version which is 5.2. Results of the research were already presented this year at NorthSec 2015 in Montreal.

Since EMET 5.2 didn't fix any of the identified bypass techniques developed by the SEC Consult experts, migration of the bypasses was quite trivial.

With the introduction of EMET 5.1 Microsoft tried to break the "scan-down" approach (used to retrieve the image base of EMET.dll) by forcing a hole between the code section and the PE header. To circumvent this the new bypass techniques searched for the start of the code section instead of the PE header. This was done by using the hardcoded byte sequence from the start of the EMET 5.1 code section. Because the start of the code section changed with EMET 5.2, this pattern had to be updated to make the exploit work again. This was the only required modification to adapt the bypasses from EMET 5.1 to EMET 5.2.

The approach of hardcoding patterns from the code section is not recommended because it requires a modification of the exploit as soon as a new version of EMET gets released. Therefore SEC Consult later developed a more reliable technique to identify the start of the code section without using hardcoded patterns.

Tuesday, May 19, 2015

KCodes NetUSB: How a Small Taiwanese Software Company Can Impact the Security of Millions of Devices Worldwide

Today the SEC Consult Vulnerability Lab released an advisory regarding a vulnerability in a software component called NetUSB. This post intends to give some background information about this vulnerability.

NetUSB is a proprietary technology developed by the Taiwanese company KCodes, intended to provide “USB over IP” functionality. USB devices (e.g. printers, external hard drives, flash drives) plugged into a Linux-based embedded system (e.g. a router, an access point or a dedicated “USB over IP” box) are made available via the network using a Linux kernel driver that launches a server (TCP port 20005). The client side is implemented in software that is available for Windows and OS X. It connects to the server and simulates the devices that are plugged into the embedded system locally. The user experience is like that of a USB device physically plugged into a client system. It’s worth noting, that the NetUSB feature was enabled on all devices that we checked and the server was still running even when no USB devices were plugged in!

We initially found the NetUSB kernel driver on a TP-LINK device and decided to spend some time on it. To establish a server-connection, a simple mutual authentication check needs to be passed. The authentication is entirely useless as the AES keys are static and can be found in the kernel driver as well as in the client software for Windows and OS X. As part of the connection initiation, the client sends his computer name. This is where it gets interesting: The client can specify the length of the computer name. By specifying a name longer than 64 characters, the stack buffer overflows when the computer name is received from the socket. Easy as a pie, the ‘90s are calling and want their vulns back, stack buffer overflow. All the server code runs in kernel mode, so this is a “rare” remote kernel stack buffer overflow.

It turns out, that not only TP-LINK uses NetUSB in their products. We found references to 26 vendors in the file “NetUSB.inf”, which is part of the client driver setup for Windows. It is likely, that these vendors have licensed the NetUSB technology and are using it in some of their products. Our advisory contains a list of affected devices, where SEC Consult has verified the vulnerability within the firmware. Unless otherwise stated, the list is incomplete regarding other affected vendors.

To get an idea how many products are affected, we downloaded a bunch of firmware images from D-Link, NETGEAR, TP-LINK, Trendnet and ZyXEL (actually, we downloaded all of them). Then we checked if those firmware images contain the NetUSB kernel driver (NetUSB.ko). We found 92 products out of the analysed firmware images that contain the NetUSB code. A list of affected products can be found in our advisory. We did not check the firmware of the remaining 21 vendors. Many affected products are high-end devices and were released very recently (yes, even the ones that look like spaceships!).

Each vendor uses different terminology when referring to the NetUSB feature. NETGEAR calls it ReadySHARE, other vendors simply call it “print sharing” or “USB share port”. Here are a few examples:

Figure 1: TRENDNET NetUSB feature

Figure 2: TRENDNET NetUSB feature - "USB Share Port"

Figure 3: TP-LINK NetUSB feature


While NetUSB was not accessible from the internet on the devices we own, there is some indication that a few devices expose TCP port 20005 to the internet. We don’t know if this is due to user misconfiguration or the default setting within a specific device. Exposing NetUSB to the internet enables attackers to get access to USB devices of potential victims and this would actually count as another vulnerability.

We tried to get in contact with KCodes back in February 2015 and provided them with a detailed vulnerability analysis including proof of concept exploit code. They sent a few nonsensical responses and then further ignored us. Afterwards, we informed TP-LINK and NETGEAR directly about the vulnerability. The other vendors were informed by CERT/CC and other CERTs - thanks very much for the coordination!

To this day, only TP-LINK released fixes for the vulnerability and provided a release schedule for about 40 products. Sometimes NetUSB can be disabled via the web interface, but at least on NETGEAR devices this does not mitigate the vulnerability. NETGEAR told us, that there is no workaround available, the TCP port can't be firewalled nor is there a way to disable the service on their devices.

In the past, we’ve seen a few cases where vulnerabilities in code, which is shared by many embedded devices, have a huge security impact. Some of the vulnerabilities were based on protocol design issues (e.g. Wi-Fi Protected Setup, however, the (consumer) embedded systems industry is always keen on keeping development costs as low as possible and is therefore using vulnerability-ridden code provided by chipset manufacturers (e.g. Realtek CVE-2014-8361 - detailed summary by HP, Broadcom or outdated versions of included open-source software (e.g. libupnp, MiniUPnPd in their products.

Here we have another case that shows the sad state of embedded systems security. Because the same vendors are building the IoT devices of tomorrow, we will see a lot of this in the future.