VAR-201301-0564
Vulnerability from variot - Updated: 2022-05-17 02:02The Aastra 6753i is a versatile IP phone. Each time the Aastra 6753i reboots, it downloads the configuration file .tuz from TFTP and contains the encrypted SIP account username and password. The Aastra 6753i IP Phone uses a slightly modified 3DES algorithm in ECB mode, allowing an attacker to modify the phone settings by modifying the configuration file. Anacrypt is prone to an information-disclosure vulnerability. Successful exploits may allow attackers to obtain potentially sensitive information that may aid in other attacks. Versions prior to Anacrypt 1.04 are vulnerable. Note: This issue was previously titled 'Aastra 6753i '.tuz' Configuraton File Information Disclosure Vulnerability'. The title and technical details have been changed to better reflect the underlying component affected. 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.
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. 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
Show details on source website{
"affected_products": {
"_id": null,
"data": [
{
"_id": null,
"model": "limited release code sip",
"scope": null,
"trust": 0.6,
"vendor": "aastra",
"version": null
},
{
"_id": null,
"model": "limited boot",
"scope": "eq",
"trust": 0.6,
"vendor": "aastra",
"version": "2.5.2.1010"
},
{
"_id": null,
"model": "limited",
"scope": "eq",
"trust": 0.6,
"vendor": "aastra",
"version": "3.2.2.56"
},
{
"_id": null,
"model": "limited aastra 6753i ip telephone",
"scope": null,
"trust": 0.6,
"vendor": "aastra",
"version": null
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
}
]
},
"credits": {
"_id": null,
"data": "Timo Juhani Lindfors",
"sources": [
{
"db": "BID",
"id": "57151"
},
{
"db": "PACKETSTORM",
"id": "119237"
},
{
"db": "CNNVD",
"id": "CNNVD-201301-071"
}
],
"trust": 1.0
},
"description": {
"_id": null,
"data": "The Aastra 6753i is a versatile IP phone. Each time the Aastra 6753i reboots, it downloads the configuration file .tuz from TFTP and contains the encrypted SIP account username and password. The Aastra 6753i IP Phone uses a slightly modified 3DES algorithm in ECB mode, allowing an attacker to modify the phone settings by modifying the configuration file. Anacrypt is prone to an information-disclosure vulnerability. \nSuccessful exploits may allow attackers to obtain potentially sensitive information that may aid in other attacks. \nVersions prior to Anacrypt 1.04 are vulnerable. \nNote: This issue was previously titled \u0027Aastra 6753i \u0027.tuz\u0027 Configuraton File Information Disclosure Vulnerability\u0027. The title and technical details have been changed to better reflect the underlying component affected. \nAastra IP telephone encrypted .tuz configuration file leakage\n-------------------------------------------------------------\n\nAffected products\n=================\n\n Aastra 6753i IP Telephone\n Firmware Version 3.2.2.56\n Firmware Release Code SIP\n Boot Version 2.5.2.1010\n\nBackground\n==========\n\n \"The 6753i from Aastra offers powerful features and flexibility in a\n standards based, carrier-grade basic level IP telephone. With a\n sleek and elegant design and 3 line LCD display, the 6753i is fully\n interoperable with leading IP Telephony platforms, offering\n advanced XML capability to access custom applications and support\n for up to 9 calls simultaneously. Part of the Aastra family of IP\n telephones, the 6753i is ideally suited for light to regular\n telephone requirements.\"\n\nDescription\n===========\n\nAastra downloads its configuration files over TFTP on every\nreboot. \n\nThe .tuz format has a simple header and 3DES encrypted payload:\n\nOffset | Length | Comment\n-----------------------------------------------------------------------------\n 0 | 16 | Always 55 42 43 7f 80 f8 5c 98 0f fc af 26 9e da 16 8d\n 16 | 1 | A byte that indicates how many padding bytes are in the\n | | last 3DES block. The padding consists of zeroes. Typically configuration files are\nencrypted using the same key. This means that when we compare the\nencrypted .tuz files from two similarly configured phones we can see\nwhere the differences are in the payload. Suppose we have two users,\n\"John Doe\" and \"Jane Doe\", and that the name happens to be aligned\nexactly to the 64-bit 3DES block. We can now observe that the\nciphertext differs only by 64 bits:\n\n... \n 0007450 7c ce ff 07 05 51 9f b7\n 0007460 19 40 e0 b1 a0 f4 13 78\n-0007470 83 f2 14 f3 8c 4d cb c6\n+0007470 6d 57 f6 74 8c fd 4d 39\n 0007520 c5 34 0e 2a 3b 6b da 1c\n 0007530 5f 69 fe c3 b8 0f 37 0a\n... \n\nIf we copy this block from John\u0027s encrypted configuration file to\nJane\u0027s configuration file then Jane\u0027s phone will suddenly show John\u0027s\nname in its LCD display, SIP traffic and HTTP interface. \n\nNow it gets interesting: We can actually copy any 64-bit block to the\noffset where the name of the user is shown and the phone will happily\ndecrypt it for us!\n\nExploit\n=======\n\nAvailable on request. Has decrypted a 4605-byte configuration file in\n9 hours (each reboot gives you only 8 bytes and rebooting takes around\n60 seconds). When you know the offset of the admin password you can\nselectively decrypt only that and attack similarly configured phones\nwithout having to decrypt complete configuration file. \n\nTimeline\n========\n\n2012-02-01 Discovered the vulnerability while adjusting firewall rules\n to let the phones access TFTP. \n2012-02-02 Contacted Aastra via their contact box:\n http://www.aastra.fi/Yhteydenottolomake.htm\n2012-02-03 Contacted Aastra via trixbox forum:\n http://liveweb.archive.org/http://fonality.com/trixbox/forums/vendor-forums-certified/aastra-endpoints/security-contact-aastra\n2012-02-03 Received confirmation from Aastra that the information has\n been forwarded to the head of engineering. \n2012-04-25 Contacted Aastra informed them that details will be\n disclosed in 2013",
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
},
{
"db": "BID",
"id": "57151"
},
{
"db": "PACKETSTORM",
"id": "119237"
}
],
"trust": 0.9
},
"external_ids": {
"_id": null,
"data": [
{
"db": "BID",
"id": "57151",
"trust": 1.5
},
{
"db": "PACKETSTORM",
"id": "119237",
"trust": 0.7
},
{
"db": "CNVD",
"id": "CNVD-2013-00068",
"trust": 0.6
},
{
"db": "CNNVD",
"id": "CNNVD-201301-071",
"trust": 0.6
},
{
"db": "OSVDB",
"id": "88878",
"trust": 0.3
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
},
{
"db": "BID",
"id": "57151"
},
{
"db": "PACKETSTORM",
"id": "119237"
},
{
"db": "CNNVD",
"id": "CNNVD-201301-071"
}
]
},
"id": "VAR-201301-0564",
"iot": {
"_id": null,
"data": true,
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
}
],
"trust": 1.6
},
"iot_taxonomy": {
"_id": null,
"data": [
{
"category": [
"Network device"
],
"sub_category": null,
"trust": 0.6
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
}
]
},
"last_update_date": "2022-05-17T02:02:35.628000Z",
"references": {
"_id": null,
"data": [
{
"trust": 0.6,
"url": "http://packetstormsecurity.com/files/119237/aastra-ip-telephone-crypto-failure.html"
},
{
"trust": 0.6,
"url": "http://www.securityfocus.com/bid/57151"
},
{
"trust": 0.3,
"url": "http://www.osvdb.org/show/osvdb/88878"
},
{
"trust": 0.3,
"url": "http://www.aastra.com/aastra-9480ict.htm"
},
{
"trust": 0.3,
"url": "http://seclists.org/bugtraq/2013/jan/11"
},
{
"trust": 0.3,
"url": "http://www.securityfocus.com/archive/1/525683/30/0/threaded"
},
{
"trust": 0.3,
"url": "http://www.aastrausa.com/aastra-6753i.htm"
},
{
"trust": 0.1,
"url": "http://liveweb.archive.org/http://fonality.com/trixbox/forums/vendor-forums-certified/aastra-endpoints/security-contact-aastra"
},
{
"trust": 0.1,
"url": "http://www.aastra.fi/yhteydenottolomake.htm"
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
},
{
"db": "BID",
"id": "57151"
},
{
"db": "PACKETSTORM",
"id": "119237"
},
{
"db": "CNNVD",
"id": "CNNVD-201301-071"
}
]
},
"sources": {
"_id": null,
"data": [
{
"db": "CNVD",
"id": "CNVD-2013-00068",
"ident": null
},
{
"db": "BID",
"id": "57151",
"ident": null
},
{
"db": "PACKETSTORM",
"id": "119237",
"ident": null
},
{
"db": "CNNVD",
"id": "CNNVD-201301-071",
"ident": null
}
]
},
"sources_release_date": {
"_id": null,
"data": [
{
"date": "2013-01-06T00:00:00",
"db": "CNVD",
"id": "CNVD-2013-00068",
"ident": null
},
{
"date": "2013-01-03T00:00:00",
"db": "BID",
"id": "57151",
"ident": null
},
{
"date": "2013-01-04T01:43:44",
"db": "PACKETSTORM",
"id": "119237",
"ident": null
},
{
"date": "2013-01-06T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201301-071",
"ident": null
}
]
},
"sources_update_date": {
"_id": null,
"data": [
{
"date": "2013-01-06T00:00:00",
"db": "CNVD",
"id": "CNVD-2013-00068",
"ident": null
},
{
"date": "2013-01-03T00:00:00",
"db": "BID",
"id": "57151",
"ident": null
},
{
"date": "2013-01-06T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201301-071",
"ident": null
}
]
},
"threat_type": {
"_id": null,
"data": "remote",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201301-071"
}
],
"trust": 0.6
},
"title": {
"_id": null,
"data": "Aastra 6753i \u0027.tug Profile Information Disclosure Vulnerability",
"sources": [
{
"db": "CNVD",
"id": "CNVD-2013-00068"
}
],
"trust": 0.6
},
"type": {
"_id": null,
"data": "information disclosure",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201301-071"
}
],
"trust": 0.6
}
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.