During the month of May 2014 we performed an offensive security analysis, trying to find how hard would it be for a low-to-medium skilled attacker to disrupt the core of the Internet (ie. achieve the largest possible impact at the lowest common layer, with minimal resource). This is a confidential report on our results, showing vulnerabilities and incidents which have been properly reported in the meanwhile (authors contacted, CVE assigned, patches written and incidents handled).

Motivations

The target of our analysis are looking-glasses, web applications hosted by Autonomous Systems to offer restrict public access in order to debug network connectivity issues. We identified them as a possible weak links because:

• they are web scripts, directly connected to backbone (BGP) routers via telnet/ssh
• many of them have been written in 90’s or 00’s, without security in mind
• many of them have not seen any update in many years
• a bunch of open-source software are deployed by many ASes

A succesfull attack on a looking-glass means gaining access to routers console, by just attacking decade-old PHP/Perl scripts.
An attacker could steal credentials or find web-flaws to login and run arbitrary commands on the routers. Even with proper ACL in place, it is easy to escalate privileges by abusing one of many existing techniques, eg. on Cisco [0] and on Juniper [1] routers.

Once there, an attacker can cause great havoc on the network. Low-hanging targets include leaking sensitive informations (eg. private routing plans) and fingerprinting the internal network. Medium-level attacks could encompass redirecting some of internal routing (eg. setting up mirroring interfaces) or performing DoS (eg. by changin OSPF configuration).
High-level attacks would instead be targeted to the Internet: multiple rogue routers announcing malicious BGP routes will effectively disrupt worldwide connectivity.

The last point is basically our motivation to submitting for this bug bounty, as the vulnerabilities and incidents below could have been abused to disrupt the Internet at BGP level from multiple injection points.

Results

All the flaws we found can be categorized as follow:

• unsafe default config resulting in exposed IP, credentials, and SSH private keys => direct login to routers
• weak commands sanitization => arbitrary commands injection to routers
• remote memory corruption => RCE on looking-glass servers, exploitable to read routers credentials
• reflected XSS => stealing cookies for other network administration panels under the same-origin

In particular, we got 6 CVEs assigned and confirmed:

• XSS in Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3926.txt
• Routers command injection in mrlg4php - http://www.s3.eurecom.fr/cve/CVE-2014-3927.txt
• Exposed credentials in Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3928.txt
• Exposed SSH keys in Cougar-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3929.txt
• Exposed credentials in Cistron-LG - http://www.s3.eurecom.fr/cve/CVE-2014-3930.txt
• Remote memory corruption in SUID binary - http://www.s3.eurecom.fr/cve/CVE-2014-3931.txt

Each report contains full details and timeline on the issue.

Starting from the above CVEs, we performed a brief survey of impacted AS and we observed the following number of incidents:

• 18 exposed configuration files (containing IPs, usernames, telnet/ssh passwords)
• 12 remote command injection (via mrlg4php)
• 4 misconfigured CGI (exposed IPs, usernames, telnet/ssh passwords)
• 3 exposed SSH private keys

We privately contacted all the ISP (Cc:ing their national FSIRT) to properly secure the exposed configuration files, and to update mrlg4php to fixed version.

Disclosure

In order to avoid major screw-ups, we proceed as following:

• asked CERT-FR (our national one) and CERT/CC to coordinate disclosure for us, they suggested instead to handle the issue ourself
• contacted MITRE to get confirmation of the issues, got 6 CVEs assigned
• contacted authors to report the issues. Worked with the available ones for a patched version. Filled bugs for unreachable ones, as suggested by CERT/CC.
• contacted all AS and national FSIRT to report the incidents we spot in the wild. Worked with them for follow-ups.

All the process took ~1 month, and was handled in embargo mode and in private as far as possible. We are now reaching the proposed deadline for full public disclosure (16/06) with no pending blockers by software authors and AS.

Research reports

Once the embargo is over we would like to produce more detailed reports on what we found during the study, as such we are submitting an academic paper to WOOT’14 and a talk at DEFCON’14. Both are current under embargo and pending review, but we can attach them, if requested, under an informal non-disclosure agreement.

[0] Cisco bulletin: cisco-sr-20130318-type4

[1] Juniper bulletin: JSA10420