Exploiting an insecure cipher in the wildThu 6 July 2023
Tagged: software, cryptography
OpenSIPS is an open source SIP proxy. The topology_hiding module hides information about your network topology.
From the Topology Hiding tutorial:
Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.
If topology hiding is used as a security measure, then you might naively think it is a security vulnerability if it is not hiding anything.
However, I reported my findings to the opensips-security mailing list, and was informed that this is not a security issue. I think I just don't know enough about SIP, but that's fine. It's still fun to exploit it.
If you're using topology_hiding without the dialog module, then the topology information is encoded into a URI parameter of the outgoing Contact header. (If you are using the dialog module, then my understanding is that OpenSIPS stores the information internally and does not pass it on even in an encoded form).
The 3 things that are encoded are the incoming packet's Record-route set, Contact header, and socket address. This is done by the build_encoded_contact_suffix() function.
The information is serialised into a string, the string is encrypted, and the result is encoded with a slight variation of base64, before being passed out as a URI parameter in the outgoing Contact header.
Here's an example serialisation (my example has no Record-route set)
\x00 \x00 Record-route length (0) \x23 \x00 Contact length (35) sip:email@example.com:9000;transport=udp Contact \x12 \x00 Socket length (18) udp:127.0.0.1:8000 Socket
The lengths are big-endian.
And here is the code that encrypts the string:
for (i=0;i<(int)(p-suffix_plain);i++) suffix_plain[i] ^= topo_hiding_ct_encode_pw.s[i%topo_hiding_ct_encode_pw.len];
(suffix_plain is the string we're encrypting, p points just past the end, and topo_hiding_ct_encode_pw is the password from the config file).
It XORs each byte by the corresponding byte of the password, looping the password when it is too short. This is the Vigenere cipher, but with XOR instead of addition.
Here's an example of how you might configure the topology_hiding module in your OpenSIPS config:
loadmodule "topology_hiding.so"; modparam("topology_hiding", "th_contact_encode_param", "thinfo"); modparam("topology_hiding", "th_contact_encode_passwd", "m6d90nmvg645fh");
This will put the encoded data in a Contact URI parameter called "thinfo", encrypted with the password "m6d90nmvg645fh".
Here is an example of a Contact header that OpenSIPS could transmit:
Given that the incoming and outgoing Contact headers have the same user identifier (probably not true in every case, but common), and given that the incoming Contact header is part of the plaintext that was encrypted, we have quite a large fragment of known plaintext.
If we assume the absence of a Record-route set, then we know that this fragment starts at the 3rd byte, and we also know that the first 2 bytes are both zero (i.e. the ciphertext equals the key for those bytes). So it is possible to simply XOR the start of the ciphertext by the fragment that we know, and we retrieve a repeating copy of the key, which we can then use to decode the rest of the ciphertext.
Even if there is a Record-route set, all is not lost! We know that our known plaintext fragment is in there somewhere, so we just need to try all possible key lengths and locations of the fragment until we find one that does not present a contradiction. This runs in milliseconds.
I have written a proof of concept.
$ time ./th-decode.pl key="m6d90nmvg645fh" msg="\x00\x000\x00sip:firstname.lastname@example.org:6000;transport=tcp\x12\x00udp:127.0.0.1:5000" real 0m0.015s user 0m0.011s sys 0m0.004s
Even if we didn't have a long known plaintext fragment, there is plenty of scope for an attack. You at least know the form of the plaintext (e.g. you know the lengths have to add up, you know what a socket address looks like, you know that a Contact header begins "sip:" and has an "@" sign in it).
Even if the key is longer than the message, we just move into the realm of key reuse with a one-time pad, which is still no bueno. If you can collect two ciphertexts and XOR them together then you are left with the XOR of the two corresponding plaintexts, at which point you don't care about the key at all.
Since I learnt from the opensips-security mailing list that this is not a security issue, no mitigation is necessary.
That said, if you were inclined to mitigate the problem, the best solution is probably to switch to using the dialog module so that your topology information is kept inside OpenSIPS.
Also, while I have your attention, OpenSIPS does not verify hostnames in SSL certificates. I wrote a fix but it's a bit clunky, and nobody who knows better seems to care to fix it, so it's probably not going to get fixed any time soon.
If you like my blog, please consider subscribing to the RSS feed or the mailing list: