This week in security: UClibc and DNS poisoning, encryption is difficult and the goat

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] in 2008 who simply refuses to go away. This week, a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical again.

So, for a quick reminder, DNS lookups usually happen over unencrypted UDP connections, and UDP is a stateless connection, which makes spoofing easy. Originally, DNS just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that this was not enough when combined with a technique that generated massive amounts of DNS traffic. This attack could poison DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, which made it much more difficult to “win the lottery” with a spoofed packet, since the TXID and source port had to match for the spoof works.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function behaves strangely. When generating DNS queries, the TXID is incremental – it is predictable and not random. Additionally, the TXID will be periodically reset to its initial value, so even the entire 16-bit keyspace is not accessed. Not great.

Your OpenWRT must be this old to be vulnerable.

The twist comes when we look at the history of uClibc. It was originally written for μClinux, a Linux port for microcontrollers. When Linksys released the source for the WRT54G, some of the projects born around this code removal combined the source with the uClibc library and buildroot. OpenWRT was one of the most notable users, and when uClibc development stopped, the OpenWRT developers turned it into uClibc-ng. OpenWRT has grown in popularity and several vendors like Qualcomm have adopted it as their SDK. This is how we get things like OpenWRT 15.05 running on the Starlink router.

The vulnerability disclosure (first link, very top ^) verifies the name of OpenWRT as using uClibc-ng. This was the case until 2017, when the LEDE version switched to the better maintained musl standard library. No maintained version of OpenWRT has this vulnerability. The problem is devices like the Starlink router, which may be vulnerable because it’s running an old fork of OpenWRT.

Revising code the hard way

Researchers from the Dolos group were hired for a simple task, a code review for the robot code. Robot here means Automation Anywhere RPA Robots – Robotic Process Automation code snippets. These are scripts with graphical interfaces to automate a process, such as copying data from one form to another. The problem is that these scripts were less than simple to audit. It was a zip, containing XML files, containing Base64 encoded data. Decode the base64 data and the result is… random noise. Possibilities are that it is actually binary data, either compressed or encrypted. A quick test with ent reveals that it’s almost perfectly random – it’s encrypted. How do you audit encrypted code? Perhaps the better question is, how does the application execute the encrypted code?

The answer is simple: the framework installer includes hard-coded AES keys. We might wonder what is the point of pre-shared key encryption, when the key is publicly available. If we allow ourselves to be a bit blasé, we could conclude that these scripts are encrypted only so that the company can advertise “bank-grade encryption” on their website – there is certainly no benefit in terms of security. The Dolos Group researchers are a little more charitable, simply observing that key management is a much more difficult problem than cryptography itself.

Bank Hacking Simplified

[Hussein Daher] and [Shubham Shah] from Assetnote took on the challenge of a bank’s bug bounty program and found that dotCMS was the most interesting avenue to pursue. Why? It’s open source so they were doing code auditing instead of black box investigation. And the audit did indeed find something interesting. DotCMS had a file upload feature with a directory traversal flaw. This theoretically means easy RCE – just download a web shell and open the URL. On the real system, it’s a bit more complicated. First, they had to map the directory structure of the target system, which was not an easy task. Even using a trick, /proc/self/cwd/ to access the correct directory, the actual webroot was locked. The actual PoC that worked was attacking the JavaScript slot, as these scripts could be overwritten. It’s a funny story of finding a pretty serious problem. It looks like they did pretty well on this bug bounty search.

The Kubernetes Goat

The best way to learn about rig safety is to dive in and get your hands dirty. This is apparently the opinion of [Madhu Akula], which built Kubernetes Goat as an intentionally insecure playground for Kubernetes. The Docker image cluster comes with a series of scenarios – guided vulnerabilities that you can explore and learn from. If Docker or Kubernetes security sounds interesting, grab the goat by the horns and dive in.

Who is UNC3524

Mandiant discovered a particularly sneaky APT group, naming them UNC3524. Consider this a placeholder, because chances are it’s one of our old friends, like Russia-based bands Fancy Bear and Cozy Bear. There aren’t enough giveaways to make a positive ID, and it could be an entirely different group, since all the indicators are publicly known techniques – like using reGeorg for proxy logins. It is open source software, as well as open source intelligence.

Either way, these guys have pulled off some impressive feats, like staying in a network undetected for 18 months in some cases. A separate technique is to compromise IoT devices on the network, like IP cameras, and use them as local command and control servers. As they say, the S in IoT stands for security. Network segregation is your friend.

Once a foothold is established, the group targets IT professionals and executives, and attempts to access their email accounts. He speculated that computer accounts are targeted to know when the infection is discovered. Access to the executive account showed that the attackers sought advance notice of company news, such as mergers and acquisitions. Knowing about these types of plans ahead of time could give an investor a huge advantage in trading, but advanced techniques suggest a government-sponsored player. Maybe Russia or another state is developing a new source of income. There are a few indicators of compromise to watch out for. One of the easiest to spot is SSH traffic on non-standard ports. There are also a few known DNS names.

Via Ars Technica

Comments are closed.