About the discovery of another security vulnerability in NASA

7h3h4ckv157
InfoSec Write-ups
Published in
5 min readAug 9, 2022

--

- 7h3h4ckv157

This write-up is approximately my “nth disclosure” in NASA. If any of you doesn't know about NASA, I'll explain ⬇

The National Aeronautics and Space Administration (NASA) is an independent agency of the US federal government responsible for the civil space program, aeronautics research, and space research. NASA's science is focused on better understanding Earth through the Earth Observing System; advancing heliophysics through the efforts of the Science Mission Directorate's Heliophysics Research Program, exploring bodies throughout the Solar System with advanced robotic spacecraft such as New Horizons, and researching astrophysics topics, such as the Big Bang, through the Great Observatories and associated programs (Credit: Wikipedia).

For amateurs

  • What is XSS?
XSS: Cross-Site Scripting

Cross-site Scripting (XSS) is a security vulnerability ordinarily found in websites and web applications which accept client input. Illustrations incorporate: Search engines login forms, message sheets, comment sections, etc.

3 types of XSS are defined as follows:

  • 1. Reflected XSS
  • 2. Stored XSS
  • 3. DOM Based XSS

1. Reflected XSS

Reflected cross-site scripting (R-XSS) emerges when an application gets information in an HTTP GET request and incorporates that information within the immediate response in an risky way. Reflected XSS attacks happen when a noxious script is reflected off of a web application to the victim’s browser.

Impact

If an aggressor can control a script that’s executed within the victim’s browser, at that point they can Perform any activity inside the application like that client: Viewing pieces of information that only the client can see (Affect confidentiality), altering any data that the client can adjust (Affect Integrity), etc.

2. Stored XSS

(Random picture of SXSS: Google search)

It’s the most dangerous XSS vulnerability where attacker provide the input and it’s stored by the application. The stored inputs embed into an afterward response in a hazardous way and rendered within the page. The script provided by the attacker will then execute within the victim’s browser, within the context of their session with the application. For exploitation, all ought to the victim visit the page where the pernicious script is stored.

Impact

  • Account takeover (ATO)
  • The attacker can steal data including bulk stealing of session cookies (multiple users visiting page), Can run JS code
  • Perform requests in the name of the victim or for phishing attacks
  • etc

1. DOM Based XSS

The type-0 XSS attack wherein the assault payload is executed as a result of adjusting the DOM environment within the victim’s browser. When web site contains JavaScript that takes an attacker-controllable value and passes it into a perilous function. So the client-side code runs in an startling manner.

(Random picture of DOM Based XSS: Google search)

#! The amateur’s portion is over

XSS in NASA’s Domain

NASA recognizes that external vulnerabilities can be discovered by anyone at any time and has issued a policy in order to provide clear guidelines to security researchers so that they feel comfortable reporting vulnerabilities they have discovered in good faith. NASA believes that public disclosure in the absence of a readily available mitigation will increase risk to NASA Missions. As a result, NASA requests that researchers refrain from sharing vulnerability reports with others for 90 days.

From their policy

Their Policy can be find here: NASA VDP

I thought the level of security in NASA would be high, but I’m wrong, their systems/products are as vulnerable as any other. Their VDP doesn’t have any Leader-board, they don’t offer any rewards, and the only incentive of security researchers is the possibility of partaking in the investigation process. The individual who makes the report, particularly if there are no rewards is something really weird. After Reporting the multiple reports in my past, they fixed all bugs within one week and don’t even send any acknowledgement letter.

I never keep in mind how many loopholes I found previously. A few past Proof of Concepts are detailed underneath:

  1. My 1st XSS in NASA

2. nth XSS PoC posted in Twitter

3. OS Command Injection

The Latest PoC

This bug doesn’t rely on “.nasa.gov” but I’m not gonna disappoint you. Instead of theoretical demonstrations I’m posting a neat PoC video here itself (Can also checkout on my Channel: 7h3h4ckv157)

Straightforward strategies
1. Subdomain Enumeration (Use your methodology)
2. Client-side code review (Check out suspicious links)
3. Manually checking the parameters accepts user input through URL (For PoC, I directly executed in the search box)

1. The subdomain: https://pds.nasa.gov2. suspicious link on code: <a href="https://pds-atmospheres.nmsu.edu/">Atmospheres&nbsp;(ATM)</a> 3. XSS 4. Done

Final thoughts

  • I like to share a fun fact, one of my friends Joshua P found nearly 100 XSS in NASA this month. You can see that over here: (XSS) — x100)
  • I hope you relished my write-up. Feel free to connect & share your views with me. You can find me here @•7h3h4ckv157

From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE!

--

--

Reformed Hacker | Hall of Fame: Google, Apple, NASA, 𝕏 (Twitter) & Many more | CVE ×4 | HTB - GURU