This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat – Hackaday

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that 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 once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasnt sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the 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, making it much harder to win the lottery with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

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 has some odd behavior. When generating DNS requests, the TXID is incremental its predictable and not randomized. Additionally, the TXID will periodically reset back to its initial value, so not even the entire 16-bit key space is exercised. Not great.

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 springing up around that code drop combined the source with the uClibc library and buildroot. OpenWRT was one of the notable users, and when uClibc development stalled, OpenWRT devs forked it as uClibc-ng. OpenWRT took off 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, way up there ^) name-checks OpenWRT as using uClibc-ng. This was the case up until 2017, when the LEDE release moved to the better-maintained musl standard library. No maintained release of OpenWRT has this vulnerability. The problem is devices like the Starlink router, which may be vulnerable, as its running an ancient fork of OpenWRT.

Researchers from the Dolos Group were hired for a simple task, a code review for robot code. Robot here meaning RPA Robots from Automation Anywhere snippets of Robotic Process Automation code. These are scripts with GUIs to automate a process, like copying data from one form to another. The problem is that these scripts were less-than-straightforward to audit. It was a zip, containing XML files, containing Base64 encoded data. Decode the base64 data and the result is random noise. The possibilities are that its actually binary data, its compressed, or its encrypted. A quick test using ent reveals that its almost perfectly random its encrypted. How do you go about auditing encrypted code? The better question may be, how does the application run encrypted code?

The answer is straightforward: the framework installer includes hard-coded AES keys. We could ask what the point of pre-shared key encryption is, when the key is publicly available. If we allow ourselves to be a bit jaded, then we might conclude that these scripts are encrypted solely so the company can advertise Bank-grade encryption on their website theres certainly no security advantage to it. The Dolos Group researchers are a bit more charitable, simply observing that managing keys is a much harder problem than cryptography itself.

[Hussein Daher] and [Shubham Shah] of Assetnote took on the challenge of a banks bug bounty program, and discovered that dotCMS was the most interesting avenue to peruse. Why? Its open source, so they were doing code auditing instead of black box investigation. And auditing did indeed find something interesting. DotCMS had a file upload function with a directory traversal flaw. This theoretically means an easy RCE just upload a web shell, and open the url. On the real system its a bit more complicated. First off, they had to map the directory structure of the target system, not an easy task. Even using a neat trick, /proc/self/cwd/ to get to the right directory, the actual webroot was locked down tight. The actual PoC that worked was to attack the JavaScript location, as those scripts could be overwritten. Its a fun tale of finding quite a serious problem. It sounds like they did quite well for themselves on this bug bounty search.

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

Mandiant has discovered a particularly sneaky APT group, naming them UNC3524. Think of that as a placeholder, as theres a decent chance this is one of our old friends, like Fancy Bear and Cozy Bear, both Russian-based groups. There are not enough giveaways to make a positive identification, and it could be a different group entirely, as all of the indicators are publicly known techniques like the use of reGeorg for proxying connections. Thats open source software, as well as open source intelligence.

Regardless, these guys managed some impressive feats, like staying in a network undetected for 18 months in some cases. A distinct technique is to compromise IoT devices on the network, like IP cameras, and use those 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 and executive workers, and tries to get access to their email accounts. It speculated that IT accounts are targeted to know when the infection is discovered. The executive account access showed evidence that the attackers were looking for advance notice of corporate news, like mergers and acquisitions. Knowing these kind of plans in advance could give an investor a huge edge in trading, but the advanced techniques suggest a government sponsored actor. Maybe Russia or another state is developing a novel revenue stream. 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 a few known DNS names as well.

Via Ars Technica

See the article here:
This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat - Hackaday