Message-ID: <84lical6po.fsf@sauna.l.org>
Date: Thu, 03 Jan 2013 15:46:43 +0200
From: Timo Juhani Lindfors <timo.lindfors@....fi>
To: bugtraq@...urityfocus.com
Subject: Aastra IP Telephone encrypted .tuz configuration file leakage


Aastra IP telephone encrypted .tuz configuration file leakage
-------------------------------------------------------------

Affected products
=================

  Aastra 6753i IP Telephone
  Firmware Version 3.2.2.56
  Firmware Release Code SIP
  Boot Version 2.5.2.1010

Background
==========

  "The 6753i from Aastra offers powerful features and flexibility in a
   standards based, carrier-grade basic level IP telephone. With a
   sleek and elegant design and 3 line LCD display, the 6753i is fully
   interoperable with leading IP Telephony platforms, offering
   advanced XML capability to access custom applications and support
   for up to 9 calls simultaneously. Part of the Aastra family of IP
   telephones, the 6753i is ideally suited for light to regular
   telephone requirements."

Description
===========

Aastra downloads its configuration files over TFTP on every
reboot. Since the configuration files often contain SIP account
usernames and passwords they are typically offered only in the
encrypted .tuz format.

The .tuz format has a simple header and 3DES encrypted payload:

Offset | Length | Comment
-----------------------------------------------------------------------------
   0   |   16   | Always 55 42 43 7f 80 f8 5c 98  0f fc af 26 9e da 16 8d
  16   |    1   | A byte that indicates how many padding bytes are in the
       |        | last 3DES block. The padding consists of zeroes.
  17   |   16   | 3DES encrypted string "Tuzo v1.3 rev1 "
  33   |  8*N   | 3DES encrypted payload

Aastra uses a slightly modified (no initial or final permutations)
3DES algorithm in ECB mode. Typically configuration files are
encrypted using the same key. This means that when we compare the
encrypted .tuz files from two similarly configured phones we can see
where the differences are in the payload. Suppose we have two users,
"John Doe" and "Jane Doe", and that the name happens to be aligned
exactly to the 64-bit 3DES block. We can now observe that the
ciphertext differs only by 64 bits:

...
 0007450 7c ce ff 07 05 51 9f b7
 0007460 19 40 e0 b1 a0 f4 13 78
-0007470 83 f2 14 f3 8c 4d cb c6
+0007470 6d 57 f6 74 8c fd 4d 39
 0007520 c5 34 0e 2a 3b 6b da 1c
 0007530 5f 69 fe c3 b8 0f 37 0a
...

If we copy this block from John's encrypted configuration file to
Jane's configuration file then Jane's phone will suddenly show John's
name in its LCD display, SIP traffic and HTTP interface.

Now it gets interesting: We can actually copy any 64-bit block to the
offset where the name of the user is shown and the phone will happily
decrypt it for us!

Exploit
=======

Available on request. Has decrypted a 4605-byte configuration file in
9 hours (each reboot gives you only 8 bytes and rebooting takes around
60 seconds). When you know the offset of the admin password you can
selectively decrypt only that and attack similarly configured phones
without having to decrypt complete configuration file.

Timeline
========

2012-02-01 Discovered the vulnerability while adjusting firewall rules
           to let the phones access TFTP.
2012-02-02 Contacted Aastra via their contact box:
           http://www.aastra.fi/Yhteydenottolomake.htm
2012-02-03 Contacted Aastra via trixbox forum:
           http://liveweb.archive.org/http://fonality.com/trixbox/forums/vendor-forums-certified/aastra-endpoints/security-contact-aastra
2012-02-03 Received confirmation from Aastra that the information has
           been forwarded to the head of engineering.
2012-04-25 Contacted Aastra informed them that details will be
           disclosed in 2013.

Powered by blists - more mailing lists