This Week in Security: Randomness is Hard, SNMP Shouldn’t Be Public, and GitHub Malware Delivery
Randomness is hard. To be precise, without dedicated hardware, randomness is impossible for a computer. This is actually important to keep in mind when writing software. When there’s not hardware providing true randomness, most rnd implementations use a seed value and a pseudo random number generator (PRNG). A PRNG is a function that takes a seed value, and turns it into a seemingly random value, and also produces a new seed for the next time a random value is needed. This could be as simple as a SHA256 sum, where the hash output is split to become the next seed and the random value.
The PRNG approach does still have a challenge. Where does the initial seed come from? There are a few common, if flawed, approaches, and one of the most common is to use the system clock. It’s not a bulletproof solution, but using the microsecond counter since the last system boot is often good enough, because there are a lot of them to choose from — the entropy is high. With that brief background in mind, let’s talk about what happens in VBScript. The Randomize call is used to seed that initial value, but Randomize has some quirks.
The first is a great feature: calling Randomize a second time with the same seed doesn’t reset the PRNG engine back to the same initial state. And second, when called without a value, Randomize uses the number of system ticks since midnight as the PRNG seed. There are 64 ticks per second, giving five-and-a-half million possible seeds, or 22 bits of entropy. This isn’t great on its own, but Randomize internally typecasts that number of ticks into a narrower value, with a maximum possible of time-based seeds set at 65,536, which is a lot easier to brute-force.
We don’t know the exact application where the researchers at Doyensec found VBScript generating secure tokens, but in their Proof of Concept (PoC) test run, the generated token could be found in four guesses. It’s a terrible security fail for basically any use, and it’s a deceptively easy mistake to make.
GoAnywhere Exploit
The folks at WatchTowr have a report on a blistering 10.0 CVE in the GoAnywhere Managed File Transfer (MFT) product. This vulnerability was first published on September 18, and the WatchTowr crew took a look at it, and had questions. This bug is a deserialization attack that can land even without any authentication. It can result in command injection, and the latest update from GoAnywhere vendor Forta vaguely indicates that it is being used for attacks in the wild. But this is particularly odd: before the vulnerable interface deserializes, it first checks for a valid signature. And WatchTowr researchers couldn’t find a leak of a valid private key. So how was the vulnerability in use in the wild?
Lucky for us, there’s a part two to this story, but not all of the mysteries are explained. This CVE is indeed being exploited in the wild, with the earliest known exploit being September 10th. Since there was a full week between the earliest known compromise and the release of the patch, it seems unfortunate that it took WatchTowr this long to confirm that this vulnerability was actually exploited in the wild.
Cisco and Public SNMP
Two million Cisco systems are at risk from CVE-2025-20352. This is a remotely accessible flaw in the handling of Simple Network Management Protocol traffic. The attack does require valid credentials, but the attack works using SNMPv1, v2, or v3. While SNMPv3 has more secure user credentials, the earlier SNMP versions just used “community strings”, a text based password that was often set to “public”.
This vulnerability seems to lead to either a crash or a Remote Code Exploitation (RCE). It’s not entirely clear how difficult it is to achieve RCE, but it’s noteworthy that RCE here is run as root, a level of access not usually available even to administrators of Cisco equipment. So far there’s no indication that this was used in the wild, but now that some information and a patch is available, it’s likely not going to take long for someone to reverse-engineer the vulnerability and weaponize it.
More Spilled Tea
Remember the Tea Spilling from a couple months ago? The Tea app had an unsecured Firebase database. It turns out that wasn’t an isolated incident. [Mike Oude Reimer] has been working on OpenFirebase, an auditing tool for FireBase installs. And to prove the point, did an audit on 400 of the most popular Android apps from a trio of categories in the play store, and found 150 Firebase servers that granted unintended access of some sort. That’s a bit stunning, that over one in three Android apps have insecure Firebase servers associated with them.
Github Malware Delivery
There’s a malware campaign that has happened in the last couple weeks, based around Search Engine Optimization and GitHub repositories. The instructions peddle malicious commands to users looking for popular software on the Mac, like LastPass and others. I was prepared to write about how Ad Blocking is really a form of security protection, as these campaigns are often delivered via advertising, but this one seems to primarily be based on real search engine placement.
This isn’t the only malware campaign that takes advantage of GitHub’s reputation as a trusted source of software. A phishing campaign was also recently spotted, where spam messages were added as GitHub issues, with the spammers tagging their victims, and offering fake Y Combinator sponsorships. Since the messages were sent via GitHub, most spam blockers treated them as legitimate. This campaign was a bit more clever than most, making use of domain typo-squatting, with the y-comblnator.com domain used as part of the campaign. The goal here being draining the crypto accounts of people sufficiently fooled by the messages.
Bits and Bytes
Is nothing sacred? In addition to GitHub, malware appears to be distributed via Steam, in updates to games. The most recent example was the Block Blasters game, which was on Steam for nearly two months before shipping malicious code.
How can you figure out whether an image is AI, or has been manipulated with AI or other tools? There’s quite a few approaches, but one of the interesting ones is to look at the JPEG artifacting. If part of the image has ever been compressed via JPEG, this results in blocky artifacts that are hard for the human eye to spot, but easy to see with the right tools.
And finally, in a blast from the past, Supermicro has another pair of vulnerabilities that could allow malicious firmware on server Baseboard Management Controller (BMCs). The way these images are signed is slightly odd, with the various portions of the file signed independently. The attack is to treat these sections like cards in a deck, and shuffle malicious slices into the stack. The verification routine thinks all the important pieces are signed, but during a real boot, the malicious code runs instead. Patches coming soon.
hackaday.com/2025/09/26/this-w…
