0x01 – Introduction/Preface:

Now, to preface... this is a re-post of my old research into MIL/DoD - I contacted them several times, and suggested that due to their infrastructure being so appalling, It would have likely been a good idea to talk them into launching a bug bounty program or VPD -- Of course, they have one now, and while I'm by no means taking credit for it, I put huge emphasis on their lack of a VDP/BBP, nor any decent security contacts (at the time). I had a media contact reach out to DoD to voice my complaints about them ignoring my emails. After some back-and-forth emails with someone high up in InfoSec at DoD, they told me they had been considering a VDP or BBP for a while, and told me I was welcome to test their assets and report my findings, as a "trial-run" of sorts in regards to them handling triage for their upcoming program. This gave me the chance to become one of the very first (albeit brief - it was a 48 hour trial run) vuln hunters to be able to test on their program. After the release of this post, my comms have always been MUCH better regarding making reports to MIL/DoD, so that's definitely a huge improvement!

Anyhow, for the sake of historical purposes (w/ me being one of the first known people not employed or contracted by DoD to have legal permission to test these assets, not to mention it gives you an insight of my inferior exploitation/vuln identification process from back then so you can take a look at how I've improved over the years).


Part 1 (this current post) will be focusing on what was identified during the 48 hour trial run (as part of the agreement, prior to their VDP existing, I was told I had 48 hours to find some security issues and present them with an overview of my findings).. Part 2 on the other hand will be an overview of my thoughts in general on the US Government and Military’s stance towards ethical hacking, and how things have changed over the course of the past decade. The second part of this post will also cover a number of (redacted) examples of vulnerabilities I found in DoD assets after they launched their official VDP. This will allow you to see the different approach that needed to be made after their VDP was established, thus demonstrating where they have improved in terms of security over the years, and where they are lacking in terms of areas where mitigation could help. I’m hoping this will offer some useful perspective for people hunting on DoD in future.


0x02 – My findings:

The first target I decided to attempt to find some security flaws was very likely the easiest of all (despite me thinking It’d have been one of the more difficult ones). The target in question is the Defense Contract Management Agency which is responsible both for ensuring that arms and weaponry are delivered to the military, through a series of bidding contracts co-ordinated with arms dealers across the globe (in addition to providing equipment that was sourced direct from the US Military stockpiles. The DCMA manages over 300,000 contracts, valued at over Seven Trillion dollars. Every single day, the DCMA receives nearly 1,000 new contracts and authorizes more than $700 million in payments to contractors. These items include everything from Fighter Jets, to bombs, stockpiles of fully-automatic weapons.

With this in mind, I assumed it’d have been one of the more difficult DoD/Military assets to target — especially after seeing this:

qt_Dwg9e

Anyhow, I needed to not have worried whatsoever. I spent maybe 2 or 3 minutes running Sublist3r piped to EyeWitness, and almost immediately a subdomain caught my eye. Within a few minutes of navigating to the domain that caught my eye (also displaying the same warning listed in the screenshot above), I manually inputted ‘ and %27 into a few different HTTP GET params, and by the third or fouth param, it triggered a MySQL error. I did not exploit this fully by pulling personal details of DoD employees and contractors, as while being given the chance to perform these tests, I was informed that, while being allowed to escalate, I was not allowed to do anything that resulted in exposure of PII. Based on the name names, escalation of this definitely looked like PII, so I reported without escalatin. That being said, the SQL error itself included some very interesting table names which strongly implied that the databases contained PII relating to various DoD employees, including home addresses, phone numbers, wages, and so on.

Here is the path to the vulnerable URL:

https://pubapp.dcma.mil/CASD/setup_CasdPaymentOfficeReport.do?Seqid=36%27

Here is the output of the SQL error message:

I didn’t pull the database here, as that would have been far too intrusive and entirely unnecessary in order to confirm the vulnerability.

Based on the fact that this is a website that only DoD employees can sign up to, and based on the fact that the info stored in the SQL error appears to contain PII, it is only same to assume that this personal information is that of Military and US DoD employees. Consider the following scenario… a terrorist organization or foreign adversary exploits this flaw, and as a result they have the names and addresses of a number of confirmed DoD employees, which would obviously be a major (and potentially even fatal) security breach. This actually close hits home to me — as some of you may know, my former hacking partner joined ISIS as the individual leading their cyber division (I obviously cut all contact with the scumbag once I found out what type of person he became). Well, one thing he was responsible for doing was creating “kill lists” of military personnel during his time within Islamic State Hacking Division, and encouraging jihadists to target them in real life, for example:

Flaws such as the one identified above could have been used by nefarious and evil individuals in order to create “kill lists” of military employees, so to see something like this as my very first finding while testing their assets is not only terrifying to me, but also makes me sick to my stomach considering my scumbag of a former hacking partner was literally creating “kill lists” of US Military personnel at a similar period in time. It’s worth noting that military contractors such as arms dealers are also listed in this database, who I’m sure would also be considered “fair game” as targets for ISIS kill lists.

The next target I chose, is the US Army. My very first finding here made me seriously question if they had any clue at all what they were doing back then.

The first flaw I found was also in a subdomain. I identified a Local File Disclosure flaw that allowed me to perform directory traversal in order to read local files. I confirmed the vulnerability via /etc/passwd and /etc/issue then I decided to do a little more digging, so I read the bash_history file on the system… when I saw its contents, my eyes lit up… rather than its default location, the HTTP Daemon had been installed in root dir AND as a root user. So, with this in mind, I attempted to instead try reading /etc/shadow – and, voila, worked no problem

Here is the vulnerable URL: http://mesl.apgea.army.mil/mesl/account/EHFileDownload?fileString=../../etc/shadow

their shadow file (of course with any sensitive info removed):

aaaaaaaaaaaaa

As you can see from the image above, the root hash is MD5, With something like hashcat and a half-decent GPU, it would very likely be possible for an attacker to crack the hash in barely any time at all. The SSH port was open, and cert-based authentication was not enabled. It was just a case of connecting via a username/password combo. All an attacker would need to do is read /etc/shadow via the LFD, spin up hashcat, and then SSH into the box as root to exfiltrate all of the data. Hell, this process could even be done via a bash one-liner… a single line in a terminal to remotely gain root access to a military server and exfiltrate all of the data from there without even having to be sat near your PC at the time.

The situation I just described is somewhat concerning, but when you look at the actual data that was contained on this server, it becomes outright terrifying. “MESL”, the branch of the military that was vulnerable to what I just described is the “Military Exposure Surveillance Library” which is a library of sensitive documents.. so sensitive, in fact, that after I identified these flaws, they took down MESL and instead made it accessible only via SIPRNet – for those not in the know, SIPRNet is the “Secret Internet Protocol Network“, maintained by the Defense Information Systems Network. SIPRNet is used by the US DoD and Department of State, alongside some reputable agencies from five eyes countries (such as MI6 or CSIS) in order to share and transmit classified application up to L-Clearance also known as SECRET clerance

The US Governent describes this level of clearance in the following manner:

This is the second-highest classification. Information is classified Secret when its unauthorized disclosure would cause "serious damage" to national security.
Most information that is classified is held at the secret sensitivity
.

"examples of serious damage include disruption of foreign relations significantly affecting the national security; significant impairment of a program or policy directly related to the national security; revelation of significant military plans or intelligence operations: compromise of significant military plans or intelligence operations; and compromise of significant scientific or technological developments relating to national security."

It’s great that they finally switched to using SIPRNet to host the sensitive documents from the Military Exposure Surveillance Library, as opposed to an incredibly vulnerable and publicly-accessible webserver. The fact that a random script kiddie could write a single line of bash in their terminal, hit enter, go grab a coffee or smoke a joint or whatever, then when they come back they’ve got access to confidential military data that is listed sensitive enough to cause “serious damage” to national security if it were to be released, well this is outright dangerous, to put it lightly.

Of course SIPRNet (nor anything) for that matter is truly impenetrable, but having data like this , n a vulnerable public-facing web-server is just ridiculous, so at least they’re now using SIPRNet.


After this finding, I decide to test army.mil domains a bit more, and I come across this via some basic Google-fu:

http://adh.usace.army.mil/svn/adh/adh-doc/svnScripts/include/config.php

Of course, it’d only be save to assume that this is an issue… due to where it is location within the file system.. well, turns out this config file is actually being called and used by that server. The credentials contained suggest that it’s a useless subversion server, but upon connection you can see that this is quite clearly not the case. Not only is there sensitive info on that box alone (via the DBMS creds provided), but also due to the manner in which is is network, lateral movement and pivoting further within the US Military networks. For the cherry on top, even if they WEREN’T leaking valid credentials that give access to sensitive data, they’re still using “mysecretpassword” to authenticate. Originally looking at this file, I was almost certain it was just a demo script or something… although once we were able to authenticate, we realized that clearly was not the case. Idk if their plan was to disguise this as something useless? The first two things that came to my mind were “useless” or “honeypot”, but luckily neither of those are the case.

Below is the output of the file:

Despite this being a trivial and simplistic vulnerability that I’m sure any random noob could find, It’s worth considering the target itself that is affected… “DREN” is the “Defense Research and Engineering Network” and is the “Engineer Research and Development Center” – It looks like someone setup some SVN software as a test, and then just continued to use it for version control on their actual military research. Some of these findings make me very glad that the DoD has a proper VDP now, because things are a lot more secure these days (although this was only maybe a little more than half a decade ago). I just don’t understand why stuff like this is even public-facing at all. Imagine how much a foreign state actor would pay for copies of all of the source code of various research projects being worked on by the US Military – this would be taking the concept of corporate espionage to an entirely new level.


Next, a few XSS vulnerabilities I found in army.mil – the first being a simple GET-Based reflective with some incredibly trivial filter bypass:

http://apd.army.mil/AdminPubs/Searchtitle_number_pubs.jsp?xradio=pubnum&search=</title><lol/onmousemove=confirm(1)>

To break things down for anyone wanting to learn:

  • My reflection is landing between some title tags, so I am starting my payload with a closing title tag in order to break out of it.
  • Spaces were being stripped from input, so I used the / symbol in place of a space, between my tag name and event handler.
  • many common tag names were being filtered, so instead I opted to use an arbitrary tag name with an agnostic event handler.
  • “alert” was blocked, so I used “confirm” as my alternative.

This second XSS in army.mil is an XSF (Cross-Site Flashing) attack – sometimes always known as Flash parameter manipulation. It results in a DOM-Based XSS scenario (as opposed to a source-based reflection). For this one, the core army.mil website (their primary domain) is affected. Within ActionScript (the ECMA-Based language in which Flash applications tend to be written in), there is an unsafe method known as getURL(); – as the name of the method suggests, it will attempt to navigate to a URL.

The vulnerable SWF in question was “flash_detection.swf” – It comes along with the associated HTTP GET parameter called flashContentURL= – any inputs supplied to this parameter will treat such input as a remote URL. For example, if someone were to input //evil.com or http://evil.com/ then once someone clicked on the link, it would redirect them to that website. Open Redirects are pretty much worthless, especially in the context of this site (no oauth misconfigs or anything along those lines).

So, rather than limiting myself to open redirection, I instead attempted to redirect to a javascript: URI to trigger my payload that way. Immediately, I was blocked by a WAF as soon as I attempted javascript:alert(1) – by this stage, I was thinking this may be challenging… but turns out it was almost laughably trivial. I just changed the alert to a confirm and voila, a working payload!

The final payload was the following:

http://www.army.mil/gettysburg/flash_detection.swf?flashContentURL=javascript:confirm(1337)

Although it’s useless these days, with Flash being a dying (s/dying/dead) technology, back when I was performing these tests, Flash was actually still real common – during this period of time, it was actually supported by default in Google Chrome, which at the time was the most popular browser in use. If you aren’t familiar with XSF or other similar flash related vulns, and you want to learn about them for historical purposes, then check out my tutorial on the subject.

Another flash-based XSS I found in army.mil was Cure53’s very interesting Flash XSS that was identified a year or so after my writeup on Flash XSS. This one included a trick I knew nothing about in my writeup, which I found very interesting. They’d borrowed a technique found by irsdl (someone with lots of experience in Flash XSS, who inspired a bunch of my own research). Cure53 (and everyone who read the writeup) seemed to be the impression that this 0day was limited only to WordPress, and nobody seemed to have noticed any cases of it outside of WordPress. Since I’d been doing my own research into Flash Hacking for at least a couple years prior to this 0day release, I could have sworn I remembered seeing that same SWF file on other sites that weren’t running WordPress.. so, I did some google dorking and it turned out my suspicions were correct. Here is an example of the aforementioned Flash XSS on an army.mil subdomain which isn’t running WordPress:

http://usar.army.mil///desktopmodules/SharedLibrary/Plugins/MediaElement/flashmediaelement.swf?jsinitfunctio%gn=alert%60

I noticed a few quirks about the “desktopmodules” in particular. Firstly, I noticed it wasn’t accessible if you tried to access it like a normal directory e.g. like site.com/desktopmodules – you had to use three slashes such as site.com///desktopmodules/ like given in my example. This knowledge came in very handy for me once they launched their actual VDP, because there was lots of content in there that was overlooked, and people’s directory bruteforcing tools weren’t finding those dirs due to the extra slashes. I was lucky to have found them at the time. I spent a lot of time enumerating these dirs and reporting many critical vulns, but that’s something I’ll be covering in Part #2 (as they were all reports made after DoD launched their VDP).

Another thing that piqued my interest is that I noticed the “SharedLibrary” directory in the URL path, which made me wonder whether it was shared across DoD websites… So I navigated to https://pentagon.mil///sharedlibrary/ and my suspicions were confirmed. Tried the same payload, and b00m, XSS in the pentagon. I then tried the exact same thing with defense.gov although a very small tweak was required

http://defense.gov///desktopmodules/SharedLibrary/Plugins/MediaElement/flashmediaelement.swf?jsinitfunctio%%gn=%%60alert%%60

almost the exact same payload, although it looks like they were performing some sort of string replacement function specifically on the % character, they weren’t looping and performing the str replacement function with each iteration, so it was trivial to bypass, just by adding an additional % in each part of the URL where that character occurred.

There was a large number of (non-wordpress) military websites vulnerable to this same flaw, which were also included in my report, here are some examples of the official websites of various branches of the US Military which were vulnerable to this specific flaw:

  • US Central Command
  • US Northern Command
  • Defense Threat Reduction Agency
  • Defense Intelligence Agency
  • Office of the Under Secretary of Defense for Personnel & Readiness
  • US Marine Corps
  • Defense Logistics Agency
  • Defense Media Activity*
  • North American Aerospace Defense Command (NORAD)
  • US Airforce
  • US Airforce recruitment services website (www.rs.af.mil)
  • Defense Acquisition University
  • United States Force Korea
  • United States Force Japan
  • US Natiobal Guard
  • Defense POW/MIA Accounting Agency
  • Joint Chiefs of Staff
  • Headquarters of the Marine Corps (www.hqmc.marines.mil)
  • Naval Sea Systems Command (www.navysea.navy.mil)
  • US Indo-Pacific Command

*this one in the Defense Media Activity (dma.mil) domain is particularly interesting to me because session hijacking here would allow you to be able to register your very own .mil domain names and get access to free hosting on military servers

Every site in that list was vulnerable via its primary domain (e.g. their main site as opposed to a subdomain) unless stated otherwise. In Part 2 I’m going to be showing another (currently unknown to the public) XSS 0day affecting some other software also found within ///desktopmodules.


Next, here is yet another trivial XSS in cape.army.mil (The Center for the Army profession and ethics). It attempts to set the page title via a user-controlled HTTP GET param, therefore a user can just modify the “title” value and set the title to anything they want (their inputs will be reflected back there). There are a few (very weak) filters in place here. Firstly, it doesn’t let you make use of script tags. Additionally, it prevents the “alert” keyword from being used. Bypassing was merely a case of using any tag other than a script tag, and using “prompt” or “confirm” in place of “alert”.

The final payload was the following:

http://cape.army.mil/case-studies/vcs-single.php?id=1&title=<body onload=prompt(1)>


Like with the example above, here is yet another XSS I identified within the US Army through means of setting a page title value that contains my XSS payload. I’m starting to see a recurring theme here. The site in question is cecom.army.mil which is the US Army’s Communications and Electronics Command Center. Unlike the above example, where I had to avoid usage of script tags and also avoid usage of the “alert” keyword, the US Army’s CECOM website has no filtering in place at all, and due to it landing within a regular reflection context, pretty much any generic XSS payload would work.

The final payload was the following (about as basic as it can ever get!):

http://cecom.army.mil/historian/docssearch.php?title=<script>alert(1)</script>

You’d tend to think that a site like (as in, a site dedicated to the US Army’s Communications and Electronic Command Center) would not be vulnerable to such a trivial payload, but I honestly can’t say I’m surprised in the slightest (especially considering some of the sites I’ve found similar bugs in, which you will seen in Part 2).


Continuing with the theme of identifying more XSS, I attempted to take a look at some domains relating to USACE which is the US Army’s Corps of Engineers. The very first thing that caught my eye is that they are running ColdFusion, and with that in mind, I assume it would be relatively trivial to hack these servers entirely (but, who wants to burn an 0day, right?).

I wasn’t able to use any of the older LFD methods to grab the password.propertiess file or abuse the 0day regarding their insufficient entropy for seeding strings (allowing for a system compromise) as I didn’t want it stolen to be by the military XD. It is now patched is anyone wants to see how it worked.

So, instead of playing around with my 0day, I focused on XSS (while also attempting to trigger stack traces to see if i could find anything jiicy

The first of these was a POST-Based Reflective XSS affecting “rivergages.mvr.usace.army.mil” – the vulnerability is within a CFM/ColdFusion script which allows you to perform search queries.

The script itself is located here:

http://rivergages.mvr.usace.army.mil/WaterControl/search2.cfm

The vulnerability is triggered by sending your payload via HTTP POST “fld_search=” parameter. You need to ensure that the “submit=search” POST parameter is also sent alongside your payload in your request.

The POST input used to trigger this XSS looks something like the following:

fld_search=”/><svg onl\u006fad=pr\u0006fmpt(1337)&Submit=Search

A breakdown of what’s actually happening:

  • “/> is used to break out of the context of the previous tag, to allow us to inject our own new tag afterwards
  • JS event handlers, as well as certain keywords such as “prompt”, “alert”, “confirm”, etc are blacklisted.
  • The filtering in place only appears to be checking for those specific strings, as a whole (along with some others)
  • I am replacing one char from each blocked keyword with an encoded equivalent, for example \u0006f will represent the letter “o”, so, I am using this in place of one of the letter “o” within my event handler of choice, and I’m using it in place of the letter “o” within my “prompt” keyword. This allows me to bypass the filtering in place.

I’m actually somewhat confused as to how this is triggering in coldfusion in this manner, with my specific choice of payload. Does anyone have an explanation as to why it’s not just throwing a HTTP 500 error or a Stack Trace output like it generally would if those chars are inputted into a coldfusion app? if anyone happens to know why, then please inform me as I’m curious about the matter. At least it worked regardless 🙂


Another subdomain, also operated by the US Army Corps of Engineers, also happens to be running ColdFusion. Rather than being a POST-Based Reflective XSS like within the example above, this one is instead DOM-Based via URL redirection.

The site in question is “corpslakes.usace.army.mil” and the vulnerable script is “link.cfm”. My first attempt was Open Redirection, which was trivial, It’s just a case of setting the URL you want to navigate to via the “link” parameter for the CFM script, like so:

https://corpslakes.usace.army.mil/employees/link.cfm?Link=//evil.com

While open redirects have some security impact, it is generally very minimal, so it seems necessary to attempt escalation. Every time I see a redirect parameter, my immediate thought is “DOM-Based XSS”, so logically that was the next thing I tested, simply by replacing the value for “?link=” with a redirect path to a javascript uri scheme, like so:

https://corpslakes.usace.army.mil/employees/link.cfm?Link=javascript:alert(1)

As I hoped, the javascript uri payload popped an alert box for me (also, it should be noted that this is DOM-Based in nature, stuff like Chrome’s built-in XSS sanitizer won’t block this, nor will many of the popualr commercial WAF softwares.

It should be noted that there is a very limited SSRF on that same subdomain. I’m not going to bother posting it here, because it’s practically useless. The MAXIMUM impact of the bug is that you can use XSPA to probe for internal services running behind a firewall. There aren’t any services that can be used to escalate it to RCE, nor are there even any means of achieving LFD via usage of the file:/// uri scheme.

That’s all for the army.mil vulns found within 48 hours of the test starting. Don’t fret though, plenty other .mil sites were pwned during those 48 hours 😉


Next in line is DISA – The Defence Information Systems Agency (disa.mil) – despite being yet another tech-oriented military website, it was once again trivial to find a vulnerability here within minutes. It should also be noted that the role of DISA is to offer cybersecurity support to the Military Generals, the Secretary of Defense, and even the President of the USA. To top things off, DISA is responsible (in their own words) for offering support to “any individual or system contributing to the defense of the United States.“, the ramifications of which are somewhat concerning. Although the vulnerability identified was only an XSS, and although it was affecting their ESGR login portal as opposed to some of their more sensitive login portals, this did not matter. No HttpOnly, and headers + cookies setup in one of the post bizzare manners I’ve ever seen allowed for this XSS to be used to perform session hijacking on any *.disa.mil domain, including their primary domain.

DISA has a warning page in place for open redirects, but, it’s practically useless as the warning message only pops up for 3.5 seconds, before automatically redirecting you to the page anyways. By setting the site you want to redirect to as a javascript: uri instead, you can trigger a DOM-Based XSS. HttpOnly isn’t present, session hijacking is trivial. The fact it allows for hijacking on ANY disa.mil subdomain is the most worrying part. This issue was rectified very fast by them, to be fair — or, somewhat at least. They implemented HttpOnly flag for cookies immediately after me reporting it, prior to them beginning to work on patching the XSS flaw itself. This at least allowed for some (albeit minimal) mitigation while they worked on implementing a fix, which was a good thing for them to do.

The vulnerable URL is the following:

https://esgr.csd.disa.mil/fa/ExternalLinkDisclaimer.aspx?url=javascript:alert(1)

Or, instead of waiting for it take 3.5 seconds, you could just break out of the hyperlink tag entirely, like so:

https://esgr.csd.disa.mil/fa/ExternalLinkDisclaimer.aspx?url="><script>alert(1)<script//

There is definitely a recurring theme among military sites wherein they will attempt to implement open redirection protections in a manner that will lead to XSS. This generally happens either one of three ways:

  • They reflect the URL you are redirecting to within the href attribute for the <a> tag so their “warning page” will display the hyperlink (so you can just have javascript:fetch(//lolpwned); as your payload – There are many ways to obfuscate these hyperlinks, but we’ll get into that some other time
  • They reflect your inputs into the href attribute of an <a> tag like above, and you can use an XSS payload to break out of the context of the attribute within that tag, then injecting your own tag that contains your payload
  • They reflect the link into some javascript source in <script> tags, having the redirect performed via JS (while warning you usually with a countdown to automatic redirect), allowing you to either set your payload to javascript:fetch(//lolpwned); for a DOM-XSS scenario, or you set your payload to DOM or Reflective XSS scenario by either breaking out of the script tags before injecting your own tags with your payload, or, injecting your payload within the context of the <script> tags by injecting is as pure JS.

Additionally, I’ve very occasionally seen badly-implemented (i.e. XSS vuln) open redirect protections via making use of a meta refresh, These are uncommon to see, but if encountered, they can be exploited in a similar manner to the first two examples given above.


I decided to then start looking a little more at dod.mil / defense.gov, since the only vulnerability I found so far in those domains was the Flash XSS which Cure53 identified. I want my own findings, rather than pasting someone else’s payload! Of course I still notified them of the Flash XSS vulns too, though.

I didn’t find much, but something that was found is actually something that became very useful at a later date. It’s only Open Redirection and/or XSS, and at the time, I thought it was only a vulnerability specific to DoD… but, turns out it’s a (currently still working) 0day exploit in some specific software used by lots of sites. The reason I’m still sharing this payload is because this particular payload no longer works. The software vendor has “patched” the XSS, although there is a bypass still available. I’m not going to be posting it as that would be irresponsible, but if you want to go find it and get a CVE for it, feel free.

Any of the sites operated by Military OneSource were vulnerable to this specific XSS. Some examples would be their “Military Installations” subdomain and the “USA4 Military Families” initiative.

The following payload was used:

https://www.militaryinstallations.dod.mil/MOS/f?p=MI:5:0::::URL=TYPE=EXTERNAL|URL=http://any.domain/%22%3E%3Csvg/onload=pr\u006fmp\u0074(1337)//

  • The payload must contain a URL (doesn’t need to be a valid one)
  • “> is required to break out of tag so you can open a new one
  • script tags are blocked so you need to rely on an event handler
  • “alert”, “prompt”, “confirm”, etc are blocked so you need to rely on encoding to evade filters (for example \u006f in place of “o” for the word “prompt”)
  • The closing > html tag cannot be used, so you need to close via // instead (or, you needed to at the time – since HTML5 is the standard now, you can just leave the closing tag open and itt’l still be treated valid)

Next up, the National Geospatial Intelligence Agency. First domain that caught my eye was their “msi” subdomain, which is the site for their Maritime Safety Information and Resources. Their use of JSP made them seem like an easy target, and boy was I right… The first thing I did after navigating to their site was inputting a simple XSS payload into their search form, and I didn’t get an alert.. but I did take a look at the GET Params associated with my search query which gave me an idea.. The following payload was used:

msi.nga.mil/NGAPortal/msi/query_results.jsp?MSI_queryType=BroadcastWarning&MSI_generalFilterType=Category&MSI_generalFilterValue=<script>confirm(1)</script>

  • To trigger the XSS, you need to make sure MSI_GeneralFilterType=category is being set
  • the reflection takes place in category section of the page, so you’d change filter type to category to have the value be reflected there (otherwise an alert wont pop at all)
  • “alert” was being filtered, but “prompt” or “confirm” worked fine

The fact that I had to change the value of a param to make the payload reflected via a separate param trigger elsewhere got me thinking… I thought about it for a while, and decided to return to the page.

This time, I took another look at the MSI_GeneralFilterType= param and decided to fuzz some values for it.

  • I quickly came across MSI_GeneralFilterType=query
  • I then set MSI_generalFilterValue to an SQLi payload while also having the FilterType param set to ‘query’ – nothing happened, or, so I thought.
  • Next, I decided to try the same thing, but with a blind injection payload.

I sent the following payload:

msi.nga.mil/NGAPortal/msi/query_results.jsp?MSI_queryType=BroadcastWarning&MSI_generalFilterType=Query&MSI_generalFilterValue=';waitfor delay '0:0:15'

Failed, yet again :/ but I wasn’t ready to give up quite yet. I considered the possibility that my input might be landing within the SQL Query in a less common place, so I tried playing around with some different options, and finally, this payload triggered the 15 second delay I was looking for:

msi.nga.mil/NGAPortal/msi/query_results.jsp?MSI_queryType=BroadcastWarning&MSI_generalFilterType=Query&MSI_generalFilterValue=1337'));waitfor delay '0:0:15'

SQLi in an intelligence agency (albeit one of the less cool ones) — still made me pretty happy 🙂 anyhow, I decided to dig a little further before moving onto the next target.

I noticed that they had a newsletter email sign-up form on one of their subdomains (datahost.nga.mil) – it would allow a user to input their email address, and it would then send then a confirmation email letting them know that they have subscribed to the newsletter.

First, I found some simple XSS there just by inputting a payload as my email address (it does no checks whatsoever to see if you are inputting a valid email), it worked via the following payload:

https://datahost.nga.mil/elist/email_escribe.php?type=<script>alert(1)</script>

I attempted Host header injection via emails, but it didn’t work… I then had another funny idea though. Did some playing around and it turns out they have no rate limits whatsoever on this form. Even if an email address is already registered for the newsletter, you can re-register them.. an unlimited number of times. Additionally.. you can pair this with HTTP Param Pollution to register them multiple times per request.

For example, https://datahost.nga.mil/elist/email_escribe.php?type=email@site.com would register someone for the newsletter (and send them an email thanking them for registering.

But, if someone were to send a request to https://datahost.nga.mil/elist/email_escribe.php?type=email@site.com&type=email@site.com&type=email@site.com&type=email@site.com then it would register them for the newsletter 4 times via a single request, and they would get four emails telling them they registered for the newsletter.

This, paired with zero rate limits and zero checks for multiple registrations could become extremely annoying as a means of spamming someone. Sure, it’s not a security risk, but it’s definitely something that could easily still be rectified.

Consider the following example:

<!DOCTYPE html>
<html>
 <head>
  <meta charset="utf-8">
  <meta http-equiv="refresh" content="1; URL=http://0xffff.info/mail_flooder.html">
  <title>Get flooded lol</title>
 <body>

<img src="https://datahost.nga.mil/elist/email_escribe.php?type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com" alt="lol" />

<img src="https://datahost.nga.mil/elist/email_escribe.php?type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com&type=me@mail.com" alt="lol" />





  • The meta tag refreshes the page every second
  • when the meta refresh takes page, the <img> tags attempt to load the image sources
  • this makes requests to the email newsletter URL
  • the HTTP Param Pollution is used so 50 sign ups happen within each <img> tag
  • this means the user is being signed up 100 times per second, and due to the complete lack of rate limiting, they will be receiving 100 emails per second.

Now, obviously this isn’t a huge security flaw or anything… but, not only will it be costing NGA money (for their outgoing emails), but itt’l also be annoying the shit out of whoever the victim happens to be.


Next up, the Office of the Secretary of Defense. Nothing too fancy found here, just more instances of XSS and Open Redirects.

First, we start with one of their less important targets. Their “Stars & Stripes” magazine. I think I could have found many vulns in this site, but by this stage I was running low on remaining time and wanting to get as wide of an attack surface as possible.

An XSS was identified at the following location:

https://estripes.osd.mil/index.php?archive=show&na=<svg/onload=alert(1)>

OSD’s Defense Manpower Data Center is also vulnerable to a trivial XSS with absolutely no filters whatsoever. The following payload will work:

https://dmdc.osd.mil/appj/dwp/searchResults.jsp?search=<script>alert(1)</script>

OSD’s refunds subdomain were using PHP_SELF (ive noticed lots of devs seem to think its secure) – meaning that it was reflecting the url back into the page (inside of a tag), so we could just inject our payload into the URL itself rather than needing to use a POST/GET param, like so:

https://refunds.ha.osd.mil/index.php/" onmousemove=alert(1) lol="/

And, finally, OSD’s Defense Technical Information Center is also vulnerable to XSS. In this case, it’s a DOM-Based Flash XSS via passing a javascript: uri to getURL(); — It’s the same attack vector used for my earlier example affecting army.mil

the following payload was used:

https://osd.dtic.mil/home/specials/iwojima/flash_detection.swf?flashContentURL=javascript:alert(1)

of course, it can be used for open redirection too, like so:

https://osd.dtic.mil/home/specials/iwojima/flash_detection.swf?flashContentURL=//evil.com


And, to finish things off, I spent the last 30 mins of my testing looking at navy.mil, of which three XSS vulns were found. The first one was in the “navysea” subdomain and is the Cure53 Flash XSS payload previously mentioned, triggered like so:

https://navysea.navy.mil/desktopmodules/SharedLibrary/Plugins/mediaelement/flashmediaelement.swf?jsinitfunctio%gn=alert%601%60

The other two vulnerabilities identified affecting navy.mil were both POST-Based reflective XSS, one being in their primary site triggered via the following:

URL: https://navy.mil/search/printadslist.asp

POST INPUT: terms=blah"><img src=x onerror=alert(1)&Go.x1=4&Go.y=2&Search_type=All

a fairly typical payload, with the only caveat being that you had to exclude the closing > tag from the XSS payload to have it trigger, due to the context in which it was landing.

Finally, took a look at navy.mil’s Chief of Naval Air Training domain. This one was even simpler than the one listed just above:

Screenshot_2016-01-13_18-02-53

As you can see, all I needed to do was input any XSS payload I wanted into the searchTextbox param and it would trigger. Also, due to how navy.mil’s cookies were setup at the time, it suffereed from teh same issue regarding being able to read cookies cross-domain (e.g. x.x.x.com can read x.com cookies)


0x03: Outro / Final Notes:

Well, that’s all for this post. Mainly just wanted to share this for historical purposes because it was a huge honour to be given the chance to test against DoD assets prior to them launching a VDP, especially when they said my findings helped sway their decision!

Part two of this post will be covering my thoughts on their VDP and how they have improved in terms of security over the years (and what they could do to continue improving), and I will also be posting some of my own personal (semi-redacted) findings from DoD assets after they laucnhed their VDP.

./mlt –out