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.

Continue reading “This Week In Security: Randomness Is Hard, SNMP Shouldn’t Be Public, And GitHub Malware Delivery”

An Internet Speedometer With A Dekatron

[Sprite_tm], like most of us, is fascinated with the earlier ways of counting and controlling electrons. At a hacker convention, he found an old Dekatron tube hooked up to a simple spinner circuit. The prescription for this neon infatuation was to build something with a Dekatron, but making another spinner circuit would be a shame. Instead, he decided to do something useful and ended up building an Internet Speedometer with this vintage display tube.

Like all antique tubes, the Dekatron requires about 400V to glow. After a bit of Googling, [Sprite] found a project that drives a Dekatron with an AVR with the help of a boost converter. Borrowing the idea of controlling a boost converter with a microcontroller, [Sprite] built a circuit with the Internet’s favorite Internet of Things thing – the ESP8266 – that requires only a 12 volt wall wart and a handful of parts.

Controlling the rotating glow of a Dekatron is only half of the build; this device is an Internet speedometer, too. To read out his Internet speed, [Sprite] is using a managed switch that allows SNMP to read the number of incoming and outgoing octets on a network interface. By writing a simple SNMP client for the ESP8266, the device can read how clogged the Intertubes are, both incoming and outgoing.

With an acrylic case fresh out of the laser cutter and a remarkably good job at bending acrylic with a heat gun, [Sprite] has a tiny device that tells him how much Internet he’s currently using. He has a video of it running a speedtest, you can check that video out below.

Continue reading “An Internet Speedometer With A Dekatron”