Exploiting CVE-2020–8597

--

In our hunt for a security vulnerability to research for our project, we stumbled across the nonprofit OSWAP Foundation working to improve the security of software and eventually came across IoTGoat and WebGoat. OWASP earlier released WebGoat which is an insecure Web Application for educational purposes which now already in its 8th version.

The IoTGoat Project is a deliberately insecure firmware based on OpenWrt and maintained by OWASP to educate software developers and security professionals with testing commonly found vulnerabilities in IoT devices.

IoTGoat is still work in progress and OWASP encourages everyone to build and submit new challenges for the environement. The first 10 challenges for the most important vulnerabilities are expected to be released soon.

This inspired us to look into OpenWRT vulnerabilities after which we stumbled upon CVE-2020–8597. A vulnerability found in a specific implementation of the Point-to-Point Protocol which is preinstalled on OpenWRT. That package is used by a lot of routers and comes pre-installed on a bunch of Linux distributions.

So let’s jump right into it!

The Point-to-Point Protocol (PPP)

PPP goes back to the late 1980s, while at this time SLIP (Serial Line Internet Protocol) basically was the standard for serial IP implementations, and network interface cards (NIC), as we know them today, did not exist yet.

For connecting computers to real networks serial connections were used to connect computers point-to-point. Such a serial connection does have a baud rate of 115200 which equals to 0.1152 Mbps and was mostly used to connect the workstation to a gateway/modem.

The layer two protocol PPP supplements SLIP and is still in use today for connection establishment between your (ISDN, DSL, ADSL) modem and the internet service provider (ISP) or in UMTS/3G networks. Even cable and fiber connections are using PPP with PPPoE (over ethernet) to establish a connection.

Because of that, this as outdated seeming legacy protocol is still ubiquitous in today’s systems by being preinstalled on almost any Linux distribution.

Explaining CVE-2020–8597

The Extensible Authentication Protocol (EAP) is an authentication framework which is part of PPP to negotiate authentication methods between peers. Lets imagine the following scenario:

The attacker Alice (Router A) wants to attack the pppd (daemon) on Bob’s system (Router B). Therefore Alice starts the communication with Bob’s pppd client by sending a configuration request to Bob.

Now Bob replies with the configuration and then (in step 5) requests the EAP Identity from Alice.

After that Alice replies with her response identity (step 6) and sends an EAP MD5-Challenge containing her identity name again. This EAP should not be successful for exploiting the CVE because an unsuccessful EAP Challenge makes the server log:

rcvd [EAP Response id=0x8a Identity <Name "Alice">]
EAP: unauthenticated peer name "Alice"

So what?

The next time Alice sends an extremely long identity name within the EAP-Challenge.

IoTGoat ifconfig, highlighting the MAC address of eth0 to address the challenge packet
EAP MD5-Challenge packet
Starting the pppd in IoTGoat

Which leads to to following log entry:

rcvd [EAP Response id=0x8a Identity <Name "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA">]
EAP: unauthenticated peer name "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

An identity name exceeding the length of 255-bit exploits the vulnerability in pppd and kills the daemon:

*** buffer overflow detected ***: pppd terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fea131337e5]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fea131d515c]
/lib/x86_64-linux-gnu/libc.so.6(+0x117160)[0x7fea131d3160]
pppd[0x42a858]
pppd(main+0x95f)[0x40981f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fea130dc830]
pppd(_start+0x29)[0x409db9]
======= Memory map: ========
[full log can be found here]

This immediately results in a Denial of Service (DoS).

The pppd process running on router B is terminated. Router B used pppd for setting up new connections so as a result, the router won’t be able to set up new connections and won’t work anymore until a reboot or restart of pppd. Since routers are usually not rebooted frequently, the DoS can last a while.

Additionally, since this is a buffer overflow it may also be used for arbitrary code execution but we were not able to reproduce this in OpenWRT.

Conclusion

This vulnerability has been patched by the maintainer of ppp on February 3rd. Because it affects the pppd it is mostly of importance to ISP’s and router manufacturers. Even though most Linux distributions come with the ppp package preinstalled it is not in use by default.

Written by Benjamin Burkhardt & Job Paardekooper

References

IOActive Security Advisory

Point-to-Point Protocol (PPP)

--

--