[FD] SSD Advisory – Livebox Fibra (Orange Router) Multiple Vulnerabilities

SSD Advisory – Livebox Fibra (Orange Router) Multiple Vulnerabilities Full report: http://ift.tt/2DVOTk2 Twitter: @SecuriTeam_SSD Weibo: SecuriTeam_SSD Vulnerabilities Summary The following advisory describes four (4) vulnerabilities found in Livebox Fibra router version AR_LBFIBRA\_sp-00.03.04.112S. It is possible to chain the vulnerabilities into remote code execution. The “Livebox Fibra” router is “manufactured by Arcadyan for Orange and Jazztel in Spain” The vulnerabilities found in Arcadyan routers are: Unauthenticated configuration information leak Hard-coded credentials Memory leak Stack buffer Overflow Credit An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program Vendor response Arcadyan and Orange were informed of the vulnerabilities and patched them. Vulnerabilities details Unauthenticated configuration information leak and weak usage of default users The “Livebox Fibra” router web server does not properly filter GET request, an unauthenticated user can send the following GET request and get the configuration file from the router: === `http://IP/cgi/cgi_network_connected.js` === The router uses an insecure way to get the configuration variables, it loads JavaScript files dinamically that set JS variables with the router configuration information. Hard-coded credentials Default users that can be used to log in in the router’s website is: ApiUsr, with the password ApiUsrPass and orangecare with password orange. Memory leak The router’s web server allows to configure multiple configuration variables. In order to configure one of those variables, it makes a POST request like the following: === ``` POST /apply.cgi HTTP/1.1 Host: 192.168.1.1 Accept-Encoding: gzip, deflate Connection: keep-alive Proxy-Connection: keep-alive Accept: */* User-Agent: A Accept-Language: es-ES;q=1 Content-Length: 400 pi=[CSRF_TOKEN]&SET0=[CFG_VAR_ID]%3D[CFG_VAR_VALUE] ``` === CSRF_TOKEN – CSRF Token that changes for every POST request (We can generate a new token and use it in a new request on: http://IP/cgi/renewPi.js) CFG_VAR_ID – identifies the configuration variable that you want to modify (It changes at the same time that the CSRF_TOKEN changes). We can get the CFG_VAR_ID values from http://IP/cgi/cgi_sys_smtp.js CFG_VAR_VALUE is the new value for the configuration variable In order to trigger the vulnerability, we sent a POST request to change the configuration (with correct “pi” and CFG_VAR_ID”) and a greater “Content-Length” for the request. The server uses the “Content-Length” calculate the length of the new value and then it uses the calculated size in “strncpy”. We can play with information in the POST request in order to achieve that “malloc” allocates our configuration value in an interesting zone in memory. The server correctly allocates memory for our new value, but in order to read and save the new configuration value, it reads out of bounds due to a bad calculation of the length (based on the “Content-length” header). Stack buffer Overflow The router’s has an API that provides the configuration variables values in JSON – It is used by the smartphone app, called ‘Mi Livebox’. “/API/Services/Notifications/EmailNotification” returns a JSON object with the email address configured to receive notifications when a new device connects to the network or when a new phone call arrives. The function is vulnerable to buffer-overflow in the URL request parser If we make a request like the following we will triage the vulnerability: === `http://IP/API/Services/Notifications/[A repeated 243 times]` === We overwrite the following registers (MIPS Big Endian): s0, s1, s2, s3 and ra. Since we control **ra** we can control the flow of the program and jump to our shellcode. In order to exploit this vulnerability we have two problems: ASLR We cannot use special bytes on our exploit (spaces, null bytes..) This vulnerability is not exploitable by itself, but we can use the memory leak explained before in order to leak some memory address and calculate the Libc base. Then, we can use ROP gadgets from the libc or another lib, and finally get remote code execution.

Source: Gmail -> IFTTT-> Blogger