Raspberry Pi used to steal 500MB of mission data from NASA lab

Humza

TechSpot Staff
Staff member

The Raspberry Pi computer, thanks to its small footprint and ease of use, is loved by many hardware enthusiasts and often used for small-scale computing projects. Yesterday saw the device refreshed with upgraded hardware and it also became part of some bad news involving data theft from NASA's Jet Propulsion Laboratory.

Located in Pasadena, California, the Jet Propulsion Laboratory manages all the robotic missions on Mars and probes sent to Saturn, Jupiter and beyond. The facility was recently attacked by a malicious hacker who used a Raspberry Pi computer and external account credentials to compromise the mission's internal network.

An audit report by NASA's Office of the Inspector General reveals that the network hack remained undetected for 10 months in which the attacker was able to steal 500 MB of data spread across 23 files, including 2 files that contained information regarding international transfer of restricted military and technology.

The investigation further reveals that although the Pi had been attached to the network by an employee, NASA administrators did not know of its presence due to poor logging management, which the hacker used to their advantage as the vulnerable device remained unmonitored on the network. The audit also disclosed several other devices on the JPL network of which the administrators were unaware of.

After the agency came to know of the security breach, other facilities including the Johnson Space Center disconnected from the core gateway to protect their own network fearing that the attacker could exploit the network's widespread access to other facilities and compromise flight systems controlling currently active spacecraft.

The audit also brought into question JPL's weak IT security that reduced the lab's "ability to prevent, detect, and mitigate attacks targeting its systems and networks, thereby exposing NASA systems and data to exploitation by cyber criminals."

"JPL uses its Information Technology Security Database (ITSDB) to track and manage physical assets and applications on its network; however, we found the database inventory incomplete and inaccurate, placing at risk JPL’s ability to effectively monitor, report, and respond to security incidents. Moreover, reduced visibility into devices connected to its networks hinders JPL’s ability to properly secure those networks," the report states.

It's not the first time that a Raspberry Pi was used to attack a NASA facility. Back in April 2018, owing to an inconsistent inventory system at JPL, an attacker used a Pi device, that would otherwise have been denied access, to enter the mission's network. "One system administrator told us he does not regularly enter new devices into the ITSDB [Information Technology Security Database] as required because the database’s updating function sometimes does not work and he later forgets to enter the asset information. Consequently, assets can be added to the network without being properly identified and vetted by security officials."

The latest incident shows there's still much room for improvement that the space agency can undertake to prevent similar events from occurring in the future. "Improvements to JPL’s security controls and increased oversight by NASA is crucial to ensuring the confidentiality, integrity and availability of agency data," concludes the report.

Image credit: NASA/JPL-Caltech

Permalink to story.

 

TheBigT42

TS Maniac
The fact that the hacker used a Raspberry Pi is immaterial. There are hundreds of small computers the hacker could have used.
 

wiyosaya

TS Evangelist
Sounds like they have it backwards. IMO, the policy should be deny everything, then allow specific devices. It's more of a headache that way, but it seems like it would be more secure.
 

nbjeter3

TS Rookie
Sounds like they have it backwards. IMO, the policy should be deny everything, then allow specific devices. It's more of a headache that way, but it seems like it would be more secure.

Yes the essence of security best practices begins with a "deny all" statement, then allow specific devices with a easily followable paper trail of security requests and approvals that can be followed.. now does that actually happen???Ever??? Maybe at first... then complacence kicks in and things start getting more lax. The "C's" of a company start demanding that they and their friends be exceptions to the rules.. and pretty soon, it starts falling apart..