This Week in Security

250 Articles

This Week In Security: XcodeSpy, Insecure SMS, And Partial Redactions

March 26, 2021 by 25 Comments

There seems to be a new trend in malware, targeting developers and their development and build processes. The appeal is obvious: rather than working to build and market a malicious application, an attacker just needs to infect a development machine. The hapless infected developers can now do the hard work to spread the malicious payload.

The newest example is XcodeSpy, discovered by a researcher who chose to remain anonymous. It works by using the Xcode IDE’s Run Script function to, well, run a script that completely backdoors your computer. The instance was found in a repackaged open source project, TabBarInteraction, but they’re just innocent victims. It was simple enough for someone to insert a script in the build process, and distribute the new, doped package. It’s probably not the only one out there, so watch out for Run Scripts with obfuscated payloads.

Continue reading “This Week In Security: XcodeSpy, Insecure SMS, And Partial Redactions” →

This Week In Security: Spectre In The Browser, Be Careful What You Clone, And Hackintosh

March 19, 2021 by 12 Comments

Google has been working on mitigations for the Spectre attack, and has made available a Proof of Concept that you can run in your browser right now. Spectre is one of the issues that kicked off the entire series of speculative execution vulnerabilities and fixes. What Google has demonstrated is that the Spectre attack can actually be pulled off in Javascript, right in the browser. Spectre is limited to reading memory allocated to the same process, and modern browsers have implemented measures like site isolation, which puts each site in a separate, sandboxed process.

These security features don’t mean that there is no practical dangers from Spectre. There are a handful of ways an attacker can run Javascript on another site, from something as simple as an interactive advertisement, to a cross-site scripting injection. Google has produced features and guidance to mitigate those dangers.

Via Bleeping Computer. Continue reading “This Week In Security: Spectre In The Browser, Be Careful What You Clone, And Hackintosh” →

This Week In Security: Text Rendering On Windows, GNU Poke, And Bitsquatting

March 5, 2021 by 27 Comments

Project Zero just unrestricted the details on CVE-2021-24093, a potentially nasty vulnerability in Windows 10’s DirectWrite, a text rendering library. The flaw got fixed in this month’s patch Tuesday roundup. The flaw is accessible in all the major browsers on Windows 10, as they use DirectWrite for font rendering. The trick here is to use a malicious font that uses some nonsense values. Those values result in a buffer allocation that is too small for complex characters such as Æ.

Because the vulnerability is a Windows library, it’s possible that an exploit would automatically work as a sandbox escape, but I haven’t seen confirmation either way. Let us know if you have some insight there.

Via Bleeping Computer

GNU Poke

The good folks at GNU have minted the 1.0 release of poke, a new binary editing tool. The real killer feature of poke is that it can interpret binary data, decoding it back into readable data structures. If you’re familiar with the way Wireshark can decode packets and give useful, organized output, it seems that poke will provide a similar function, but not limited to network traffic.

It looks like it could become a useful tool for getting a look inside otherwise opaque binaries. What poke brings is a system where you can write pretty-printing templates on the fly, which should be very useful when mapping out an unfamiliar binary. Distros will likely pick up and start packaging poke in the coming weeks, making it even easier to get and play with. Continue reading “This Week In Security: Text Rendering On Windows, GNU Poke, And Bitsquatting” →

This Week In Security: Mysterious Mac Malware, An Elegant VMware RCE, And A JSON Mess

February 26, 2021 by 10 Comments

There’s a new malware strain targeting MacOS, Silver Sparrow, and it’s unusual for a couple reasons. First, it’s one of the few pieces of malware that targets the new M1 ARM64 processors. Just a reminder, that is Apple’s new in-house silicon design. It’s unusual for a second reason — it’s not doing anything. More precisely, while researchers have been watching, the command and control infrastructure didn’t provide a payload. Silver Sparrow has been positively found on nearly 30,000 machines.

The malware also has an intentional kill switch, where the presence of a particular file triggers a complete removal of the malware package. Researchers at Red Canary point out that this package behaves very much like a legitimate program, difficult to pick out as malware. Ars Technica got an off-the-record statement from Apple, indicating that they are tracking the situation, and have revoked the developer’s certificate used to sign the malware. It’s not entirely clear whether this prevents the malware running on already compromised machines, or just stops new infections.

So who’s behind Silver Sparrow? The observed stealth mode and other complexities suggest that this is more than a simple adware or ransomware campaign. Since it was discovered before the payload was delivered, we may never know what the purpose is. It may have been a government created campaign, targeting something specific. Continue reading “This Week In Security: Mysterious Mac Malware, An Elegant VMware RCE, And A JSON Mess” →

This Week In Security: ISNs, Patch Tuesday, And Clubhouse

February 19, 2021 by 4 Comments

Let’s talk TCP. Specifically, how do the different TCP connections stay distinct, and how is a third party kept from interrupting a connection? One of the mechanisms that help accomplish this feat is the TCP sequence number. Each of the two endpoints of a TCP connection tracks an incrementing 32-bit number, corresponding to the bytes sent in the connection. It’s handy, because each side can use that value to track what parts of the data stream they have received. On missing packets, a message can be sent requesting bytes 7-15 to be resent, for instance.

Each side of the connection sets their own Initial Sequence Number (ISN), and it’s important that this number is unique, as collisions can cause stream confusion. That statement should make your security spidey sense tingle. If a collision can cause problems when it happens by chance, what can a hacker do with it intentionally? Potentially quite a bit. Knowing the current sequence number, as well as a couple other pieces of information, a third party can close a TCP stream or even inject data. The attack has been around for years, originally known as the Mitnick Attack. It was originally possible because TCP implementations used a simple counter to set the ISN. Once the security ramifications of this approach were understood, the major implementations moved to a random number generation for their ISNs.

Now to this week’s story: researchers at Forescout took the time to check 11 TCP/IP stacks for vulnerability to the old Mitnick Attack (PDF Whitepaper). Of the eleven embedded stacks texted, nine have serious weaknesses in their ISN generation. Most of the vulnerable implementations use a system time value as their ISN, while several use a predictable pseudorandom algorithm that can be easily reversed.

CVEs have been assigned, and vendors notified of “NUMBER:JACK”, Forescout’s name for the research. Most of the vulnerable software already has patches available. The problem with embedded systems is that they often never get security updates. The vulnerable network stacks are in devices like IP cameras, printers, and other “invisible” software. Time will tell if this attack shows up as part of a future IoT botnet.
Continue reading “This Week In Security: ISNs, Patch Tuesday, And Clubhouse” →

This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More

February 12, 2021 by 6 Comments

Code obfuscation has been around for a long time. The obfuscated C contest first ran way back in 1984, but there are examples of natural language obfuscation from way earlier in history. Namely Cockney rhyming slang, like saying “Lady from Bristol” instead of “pistol” or “lump of lead” instead of “head”. It’s speculated that Cockney was originally used to allow the criminal class to have conversations without tipping off police.

Code obfuscation in malware serves a similar purpose — hiding from security devices and applications. There are known code snippets and blacklisted IP addresses that anti-malware software scans for. If that known bad code can be successfully obfuscated, it can avoid detection. This is a bit of a constant game of cat-and-mouse, as the deobfuscation code itself eventually makes the blacklist. This leads to new obfuscation techniques, sometimes quite off the wall. Well this week, I found a humdinger of an oddball approach. Morse Code.

Yep, dots and dashes. The whole attack goes like this. You receive an email, claiming to be an invoice. It’s a .xlsx.hTML file. If you don’t notice the odd file extension, and actually let it open, you’re treated to a web page. The source of that page is a very minimal JS script that consists of a morse code decoder, and a payload encoded in Morse. In this case, the payload is simply a pair of external scripts that ask for an Office 365 login. The novel aspect of this is definitely the Morse Code. Yes, our own [Danie] covered this earlier this week, but it was too good not to mention here. Continue reading “This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More” →

This Week In Security: Perl.com, The Great Suspender, And Google’s Solution

February 5, 2021 by 46 Comments

Perl has been stolen. Well, perl.com, at least. The perl.com domain was transferred to a different registrar on January 27, without the permission of the rightful owner. The first to notice the hack seems to have been [xtaran], who raised the alarm on a Reddit thread. The proper people quickly noticed, and started the process of getting control of the domain again. It seems that several other unrelated domains were also stolen in the same attack.

I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.

The Great Suspender, Suspended

I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?

I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.

It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.

The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.

Libgcrypt

It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.

Android Botnet

A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.

Google Solution to Open-Source Security

Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.

Microsoft in My Pi

And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.

The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.

Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.