NASA’s JPL keeps getting hacked. That’s the worrying conclusion of a NASA audit published earlier this month.
The Jet Propulsion Laboratory, managed by Caltech and located near Pasadena, makes and flies unmanned spacecraft and runs NASA’s deep-space network. Hackers could have done some serious damage—not just to JPL projects, but to other NASA operations as well, by moving laterally.
Looks like some SecOps people have serious fixes to do. In this week’s Security Blogwatch, we get close enough for guv’mint work.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: pilot vs. crew.
JPL BYOPi FAIL
What’s the craic? Brittany A. Roston reports the report—Hackers stole 500MB of NASA mission systems data using Raspberry Pi:
NASA has revealed it discovered a security breach that allowed hackers to steal 500MB of data related to ‘major mission systems.’ … An external user’s account had been compromised, enabling the hacker to access the JPL network with a Raspberry Pi computer.
…
[It] was disclosed by the NASA Inspector General Office of Audits. … The report explains that NASA JPL utilizes a web app called Information Technology Security Database (ITSDB) for tracking and managing … assets. The JPL internal network is only accessible to ‘IT resources’ that have been registered in this database.
…
Managers are given 30 days to assign the new property to system security plans. … A Raspberry Pi that wasn’t authorized for the JPL network was able to access it and steal data.
Sounds like someone was asleep at the switch? Davey Winder confirms NASA Has Been Hacked:
An unauthorized Raspberry Pi computer … was targeted by hackers, who then moved laterally further into the NASA network. … The hackers apparently got as far as the Deep Space Network (DSN) array of radio telescopes and numerous other JPL systems.
…
If that sounds pretty serious stuff, it's because it is. … It paints a very poor picture of JPL network security indeed.
…
Everything from poor IT asset visibility and security violation ticket resolution shortcomings, through to untimely delays in patching known vulnerabilities. … System administrators lacked security certifications, no role-based security training was in place and JPL, unlike the main NASA security operations center (SOC), didn't even have a round-the-clock incident reporting capability.
But what’s the significance of this “ITSDB” thing? Nicholas Fearn quips There's space for improvement:
A rogue Raspberry Pi … wasn't authorised to be connected to its network.
…
JPL uses a special database for tracking devices and applications on its network, but according to auditors, this was "incomplete and inaccurate". As a result, JPL's ability to monitor, report and mitigate attacks was placed at risk.
…
What's more, NASA failed to implement a threat hunting program that had been recommended by IT security experts.
Let’s summarize the 12 issues from the audit report, but aggressively de-waffle-ified: [You’re fired—Ed.]
Over the past 10 years, JPL has experienced several notable … incidents that have compromised … its IT network. For example, in 2011 … intruders gained full access to 18 servers supporting key JPL missions. … In April 2018 JPL discovered an account belonging to an external user had been compromised.
…
We found multiple IT security control weaknesses:
- The [ITSDB is] incomplete and inaccurate, placing at risk JPL’s ability to effectively monitor, report, and respond to security incidents. …
- Reduced visibility into devices connected … hinders JPL’s ability to properly secure [its] networks. …
- JPL’s network gateway … had not been properly segmented to limit users only to those systems and applications for which they had approved access [which] enabled an attacker to gain unauthorized access. …
- NASA failed to establish Interconnection Security Agreements … to document the requirements partners must meet to connect to NASA’s IT systems and describe the security controls that will be used. …
- Security problem log tickets … were not resolved for extended periods of time. … While system administrators may request a waiver … we found waivers were not reviewed annually as required, resulting in … outdated compensating security controls that expose the JPL network to exploitation. …
- JPL system administrators misunderstood their responsibilities regarding … identifying malicious activity. …
- JPL had not implemented a threat hunting program recommended by IT security experts … and instead relies on an ad hoc process. …
- JPL had not provided role-based security training or … security certifications for its system administrators. …
- JPL incident management and response practices deviate from NASA and recommended industry practices. For example … JPL’s SOC does not maintain round-the-clock availability of … incident responders. …
- Team coordination issues delayed … incident containment and eradication. …
- Documenting and sharing cyber threat information [falls] short. …
- No controls were in place to ensure JPL compliance with … the contract between NASA and Caltech [that] requires JPL to report … security incidents. … Nor did NASA officials have access to JPL’s incident management system.
Wow. But what can we learn? Here’s tatha:
If people don't do the right thing the business needs, why is it too hard to do? Can't we reduce the pain to do the right thing so doing the lazy / wrong thing is harder? People not doing things tends to be an indication of boundaries and responsibilities being drawn in bad ways.
…
Why do people have to manually enter systems into the host database? … Firewall all systems to access the central registry only, and widen the firewall after an authorized registration.
…
That way, the admins just have to rack systems with a usb stick with some credentials, and it goes or it doesn't. If basic things are so hard people don't do them, something is structurally wrong.
This “BYOPi” problem will only get worse. So says guruevi:
The new Pi's are PoE capable. And there are various other pluggable SoCs which can be entirely hidden from sight: You can buy an ESP32 with PoE which gives you enough power to run a web server or a tunnel into any organization and you can hide them pretty much anywhere.
And this Anonymous Coward goes even further:
Look up 'pwnplug' … it's a good reference for using the pass through technique to get around pesky [security] solutions. If they're decent they also hooked up a GSM dongle to it so they can C2 + exfil without traversing the target's normal egress which may be stringent or monitored.
…
Once you're this embedded into an internal network, it's pretty straight forward most times to get the data you want. … Most orgs are relying on EDR/HIPS tools which in this case are largely useless.
Perhaps asset whitelisting is the answer? Heed olliej’s experience:
IT security people need to stop thinking in terms of disallowing “unauthorized” devices on physical (wired and WiFi) and … start designing for human nature. Assume that the physical networks are compromised, and have all privileged resources only accept connections over VPN.
…
At least Google and Apple gate almost all internal resources on VPN connection and per machine authentication. This is over 10s of thousands of machines and users. It also makes attempts to use "unauthorized" devices with your privileged resources harder.
…
[And] mandate updating. … I work at a company that drops network access to privileged resources of any machine that is more than X days behind installed an update. … If you are allowing out of date machines to access privileged resources you're rapidly heading to game over.
Meanwhile, Ross Judson has heard of reductio ad absurdum:
There are three perspectives on inventory:
What you want to have,
what you think you have,
and what you actually have.
Reconcile.
The moral of the story?
Even if you have the basics of policy, are you sure the actual implementation is on track?
And finally
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites… so you don’t have to. Hatemail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Image source: RadioFan (cc:by-sa)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
