Security Hacks

1478 Articles

This Week In Security: No More CVEs, 4chan, And Recall Returns

April 18, 2025 by 6 Comments

The sky is falling. Or more specifically, it was about to fall, according to the security community this week. The MITRE Corporation came within a hair’s breadth of running out of its contract to maintain the CVE database. And admittedly, it would be a bad thing if we suddenly lost updates to the central CVE database. What’s particularly interesting is how we knew about this possibility at all. An April 15 letter sent to the CVE board warned that the specific contract that funds MITRE’s CVE and CWE work was due to expire on the 16th. This was not an official release, and it’s not clear exactly how this document was leaked.

Many people made political hay out of the apparent imminent carnage. And while there’s always an element of political maneuvering when it comes to contract renewal, it’s worth noting that it’s not unheard of for MITRE’s CVE funding to go down to the wire like this. We don’t know how many times we’ve been in this position in years past. Regardless, MITRE has spun out another non-profit, The CVE Foundation, specifically to see to the continuation of the CVE database. And at the last possible moment, CISA has announced that it has invoked an option in the existing contract, funding MITRE’s CVE work for another 11 months.

Continue reading “This Week In Security: No More CVEs, 4chan, And Recall Returns” →

A flowchart demonstrating the exploit described.

Vibe Check: False Packages A New LLM Security Risk?

April 12, 2025 by 23 Comments

Lots of people swear by large-language model (LLM) AIs for writing code. Lots of people swear at them. Still others may be planning to exploit their peculiarities, according to [Joe Spracklen] and other researchers at USTA. At least, the researchers have found a potential exploit in ‘vibe coding’.

Everyone who has used an LLM knows they have a propensity to “hallucinate”– that is, to go off the rails and create plausible-sounding gibberish. When you’re vibe coding, that gibberish is likely to make it into your program. Normally, that just means errors. If you are working in an environment that uses a package manager, however (like npm in Node.js, or PiPy in Python, CRAN in R-studio) that plausible-sounding nonsense code may end up calling for a fake package.

A clever attacker might be able to determine what sort of false packages the LLM is hallucinating, and inject them as a vector for malicious code. It’s more likely than you think– while CodeLlama was the worst offender, the most accurate model tested (ChatGPT4) still generated these false packages at a rate of over 5%. The researchers were able to come up with a number of mitigation strategies in their full paper, but this is a sobering reminder that an AI cannot take responsibility. Ultimately it is up to us, the programmers, to ensure the integrity and security of our code, and of the libraries we include in it.

We just had a rollicking discussion of vibe coding, which some of you seemed quite taken with. Others agreed that ChatGPT is the worst summer intern ever.  Love it or hate it, it’s likely this won’t be the last time we hear of security concerns brought up by this new method of programming.

Special thanks to [Wolfgang Friedrich] for sending this into our tip line.

This Week In Security: AI Spam, SAP, And Ivanti

April 11, 2025 by 13 Comments

AI continues to be used in new and exciting ways… like generating spam messages. Yes, it was inevitable, but we now have spammers using LLM to generate unique messages that don’t register as spam. AkiraBot is a Python-powered tool, designed to evade CAPTCHAs, and post sketchy SEO advertisements to web forms and chat boxes around the Internet.

AkiraBot uses a bunch of techniques to look like a legitimate browser, trying to avoid triggering CAPTCHAs. It also runs traffic through a SmartProxy service to spread the apparent source IP around. Some captured logs indicate that of over 400,000 attempted victim sites, 80,000 have successfully been spammed.

Continue reading “This Week In Security: AI Spam, SAP, And Ivanti” →

This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching

April 4, 2025 by 2 Comments

We know a bit more about the GitHub Actions supply chain attack from last month. Palo Alto’s Unit 42 has been leading the charge on untangling this attack, and they’ve just released an update to their coverage. The conclusion is that Coinbase was the initial target of the attack, with the open source agentkit package first (unsuccessfully) attacked. This attack chain started with pull_request_target in the spotbugs/sonar-findbugs repository.

The pull_request_target hook is exceptionally useful in dealing with pull requests for a GitHub repository. The workflow here is that the project defines a set of Continuous Integration (CI) tests in the repository, and when someone opens a new Pull Request (PR), those CI tests run automatically. Now there’s an obvious potential problem, and Github thought of it and fixed it a long time ago. The GitHub Actions are defined right in the repository, and letting any pull request run arbitrary actions is a recipe for disaster. So GitHub always uses actions as they are defined in the repository itself, ignoring any incoming changes in the PR. So pull_request_target is safe now, right? Yes, with some really big caveats.

The simplest security problem is that many projects have build scripts in the repository, and those are not considered part of GitHub Actions by GitHub. So include malicious code in such a build script, make it a PR that runs automatically, and you have access to internal elements like organization and repository secrets and access tokens. The most effective mitigation against this is to require approval before running workflows on incoming PRs.

So back to the story. The spotbugs/sonar-findbugs repository had this vulnerability, and an attacker used it to export secrets from a GitHub Actions run. One of those secrets happened to be a Personal Access Token (PAT) belonging to a spotbugs maintainer. That PAT was used to invite a throwaway account, [jurkaofavak], into the main spotbugs repository. Two minutes after being added, the [jurkaofavak] account created a new branch in spotbugs/spotbugs, and deleted it about a second later. This branch triggered yet another malicious CI run, now with arbitrary Github Actions access rather than just access through a build script. This run leaked yet another Personal Access Token, belonging to a maintainer that worked on both the spotbugs and reviewdog projects. Continue reading “This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching” →

MIT Wants You To Secure Your Hardware Designs

April 3, 2025 by 9 Comments

When you think of attacking or defending computer systems, you probably think of software viruses and the corresponding anti-virus software. But MIT’s 6.5950 class teaches secure hardware design — how to attack and defend CPUs from bad actors. Interested? The course is open source, so you can follow along as long as you don’t mind not getting a grade.

Browsing some of the lecture slides shows that the material isn’t as stuffy as you might imagine. A slide about side channel attacks, for example, features an article called “And Bomb the Anchovies,” which says that Washington DC pizza places know when big news is about to break because pizza delivery to places like the White House or the Pentagon trend upward (something spies call pizza-int, by the way).

Even if you don’t have a burning desire to design more secure hardware, some of the lecture slides make for an interesting flip through on a rainy weekend day. For example, the charts about RowHammer (“RowHammer in One Sentence”) is a great explanation about how software can cause DRAM failures to attack a computer. We only wished they’d identified companies A, B, and C in their study. There are also labs and they politely clarify what setup you need to do each lab (typically, just a Linux server, although some you can do with just a browser).

One of the great things about the Internet is that you can virtually audit classes from anywhere in the world, often for free. MIT is always up to something interesting.

Automatically Crack Safes With This Autodialer

March 30, 2025 by 13 Comments

When attempting to secure something, whether it’s a computer, sensitive data, or valuables, there’s always going to be a way to break that security. It might be impossibly hard, like taking centuries to brute-force an encryption algorithm, but it’s weakness is still there. And, like the future might make certain encryption obsolete, modern electronics has made security of the past somewhat obsolete as well. [Startup Chuck] has been using tools the creators of safes from the late 1800s could probably not have imagined.

The tool that [Startup Chuck] has come up with is known as an autodialer in the safe-cracking world, and as its name suggests it automates the process of opening the safe by trying as many combinations as possible. The autodialer attaches to the safe with three magnetic feet and couples to the dial through a chuck attached to a magnetic clutch, which allows the autodialer to disengage as soon as the correct combination is found. It’s driven with a stepper motor which can test out combinations so fast that [Startup Chuck] needed to take 240 fps video and slow it down to make sure that the mechanism was behaving properly.

The autodialer itself can’t actually open the safe, though. The last step of the process is taken care of by a bungie cord, attached to the safe handle to pre-tension it enough so that when the correct combination is finally entered the safe pops open automatically. For anyone looking to duplicate the project, [Startup Chuck] has added the program code to a GitHub page. If you’re looking at a more modern safe, though, there are of course ways to crack their security systems as well.

Continue reading “Automatically Crack Safes With This Autodialer” →

This Week In Security: IngressNightmare, NextJS, And Leaking DNA

March 28, 2025 by 9 Comments

This week, researchers from Wiz Research released a series of vulnerabilities in the Kubernetes Ingress NGINX Controller  that, when chained together, allow an unauthorized attacker to completely take over the cluster. This attack chain is known as IngressNightmare, and it affected over 6500+ Kubernetes installs on the public Internet.

The background here is that web applications running on Kubernetes need some way for outside traffic to actually get routed into the cluster. One of the popular solutions for this is the Ingress NGINX Controller. When running properly, it takes incoming web requests and routes them to the correct place in the Kubernetes pod.

When a new configuration is requested by the Kubernetes API server, the Ingress Controller takes the Kubernetes Ingress objects, which is a standard way to define Kubernetes endpoints, and converts it to an NGINX config. Part of this process is the admission controller, which runs nginx -t on that NGINX config, to test it before actually deploying.

As you might have gathered, there are problems. The first is that the admission controller is just a web endpoint without authentication. It’s usually available from anywhere inside the Kubernetes cluster, and in the worst case scenario, is accessible directly from the open Internet. That’s already not great, but the Ingress Controller also had multiple vulnerabilities allowing raw NGINX config statements to be passed through into the config to be tested. Continue reading “This Week In Security: IngressNightmare, NextJS, And Leaking DNA” →