HP JetDirect in the news… when it isn’t actually news

Last week my twitter feed had a posting noting an article which got coverage about thousands of HP printers allowing anonymous ftp access via the JetDirect protocol.Screen Shot 2016-02-07 at 14.55.37

This was a bit surprising. Not cause of the vulnerability, but because it was making the news since it was actually really old information. The vulnerability in the JetDirect protocol (port 9100) used by HP Printers has been known for years. I first learned about it in 2012 from a team member on a Red Cell, no idea how long he had known about it. Here is an article explaining it in 2013. https://www.nowsecure.com/blog/2013/01/14/exploiting-printers-via-jetdirect-vulnerabilities/

Not ragging on the guy that reported it, but all of his headline making security news articles have been nothing more than searching Shodan results for already known issues.

The vulnerability is semi useful on internal networks for hosting malicious files (sometimes code coming from an internal IP is trusted or evades CIRT scrutiny). In theory this makes them the ideal place for miscreants to host malware since http(s) traffic is the best way to blend in with normal traffic and avoid firewall rules.

What this article failed to acknowledge is that 95 out of 100 times uploading a very small file to the HP through JetDirect will crash the service and the server from my testing. In my opinion the threat that these unsecured printers pose on the internet is minimal at best with regards to this. The miscreants that push malware can buy cheap server space using stolen credit cards or anonymous payment methods. Additionally, real web servers that can handle traffic can be infected via WordPress vulnerabilities and misconfigurations nearly as easily as these HP printers with the aid of Shodan.io for targeting. The last thing a criminal wants is for the spear phishing to be successful but the infections to fail due to crappy hosting for the malware.

A more accurate assessment of this threat would be to comb the Shodan results for “Port:9100” looking for malicious files hosted on these HP printers. I am guessing the number would be nearly non-existent and not cause the malware pushers don’t know about the opportunity. Cause it isn’t worth their time.

IMHO a more worthy use of multi function devices for malicious purposes would be trying to configure any digital sender functionality to go through your personal SMTP gateway so that you can take copies of internal documents. If they are using LDAP for authentication that also opens up the possibility of stealing credentials if you can pipe the queries through the attacker box.

Screen Shot 2016-02-07 at 16.56.38

Another printer bites the dust after uploading a file…

Thoughts on expanding your scope

I know I have been fairly inactive on here lately, so I figured I would start the new year off on the right foot by posting an article even if it is rather non technical.

Clients looking to have an assessment of their IT infrastructure and personnel via a penetration test always have to spell out what is in scope so nobody gets into legal issues or crashes production systems. Unfortunately when you are the good guy you have pesky things to worry about that Sergey in his Adidas tracksuit never has to think about. “What if my banking RAT spreads onto the HR systems and accidentally steals PII?” – said no attacker ever. In the long run clients usually want a test to be as real world as possible, but they certainly don’t want to have downtime or lose money. It is a reasonable accommodation because as Wu-Tang elegantly puts it Cash Rules Everything Around Me (CREAM).

Things can get a bit more ambiguous with scope if you are using enterprise services from third parties (Google EC2, Dropbox Enterprise, etc) but most of them do have fine print and proper forms which can be filled out which would allow the penetration test to include your assets hosted on their servers. Let’s face it, the day and age of a static IP range of company owned hardware is behind us for the most part. On top of this modern organizations have a complex and sometimes undocumented attack surface which includes servers and services co-located, leased, virtualized, and on-demand which can encompass multiple countries with their varying cyber laws.

What a client tells you is their IT assets rarely lines up with all the potential ways they can be digitally compromised.

On a recent assessment I came across some vulnerabilities unknowingly (to the client) created by the company they contracted to create the website and mobile app. This got me thinking about how rarely anyone includes third party developers in the scope of a penetration test even though they often times still maintain and keep clones or testing versions of your target.

You come in as a pen tester to look at the finished or nearly complete website/app that is provided to you by the client. That’s great and all, but don’t forget that at some point there was likely dozens of versions created and tested back at the web/app developers network. Unless you make an effort to uncover where those assets are you might be missing out on an expanded attack surface in your assessment.

What I am not saying is that without clearly defined guidelines can you can compromise an outside developers network in order to gain access to your client. What I am saying is that at a minimum you should be looking at them for data which can be leveraged in a pen test. If your client paid to have a website created, and a clone of it is sitting on a separate subdomain you should attempt to have that included in the scope. If that is not doable, then there is plenty that you can do as a sort of pentest light which keeps you legally cleared. Below are the very well known tools that can be done passively (ish) and still give you good results. Notice I am not mentioning using burp for sql injection or anything agressive.

Passive Recon of Developer Networks:

Robtex.com (the old site is still more functional) – look to see what lives in the IP range of your client AND the company that made the website/app. Look at the reverse lookups to determine if the company had something live dev.yourclient.webcompany.com. This can also be a place to find developer companies with duplicates of your clients SSL certificates…..

shodan.io – Not even sure I have to say this. What can not be overstated is that if there is a glaring vulnerability documented by shodan that you are certainly not the first to find this. In addition to the dangers of leaking data, database structures of the testing db (can help with sql injection on the production network), don’t underestimate the dangers of giving access to a test database. How is the testing/dev backend being brought online for production? As is the case currently, thousands of MongoDB’s have anonymous read/write access. What’s to stop me from putting in an account on the testing database if I know it is going to be replicated over once it goes into production?

Case in point, here is a common sight if you do db searches.Screen Shot 2016-01-02 at 17.38.16

Google.com – Don’t laugh. Use special searches to look for juicy info that might be unlinked, or intended to be internal. I have found dozens of sensitive documents, PII spills, and change request docs using this method. Example: inurl:dev.company.gov Internal Use Only Google has a knack for indexing documents which companies forget about because they are not linked to websites anymore. Even if it is gone now you might be able to get the text of the document cached if you are lucky. On a recent assessment I found the developers decided to put all their internal Change docs off of an indexed directory for some odd reason. In one of those documents they duly noted that they Backdoored the website with the account “Developer:1234”. To think i was wasting time reversing an Android apk file to look for credentials….

Webburp spider – The staple in every webapp testing toolset. Let the spider run on the domain of your client, AND the developer’s website. Developers have a way of leaving behind testing url’s or directories inside comments in javascript files for some reason.

Maybe more to come… Have fun.

Mallory in the Mobile (MitM)

No, I’m not trying to re-invent the MitM initialism. However, I do want to detail setting up the Mallory intercepting proxy for use in mobile application assessments. Mallory is a useful tool for intercepting non-HTTP traffic. On a recent engagement, I had a need to proxy IMAP/S traffic to determine how the mobile application I was testing handled messaging. Alas, trusty Burp suite couldn’t help me here, so I turned to Mallory, as Mallory can intercept and tamper with non-HTTP protocol traffic.

Continue reading Mallory in the Mobile (MitM)

Configure an Upstream Proxy for Burpsuite

I had the need to proxy traffic from Burpsuite to another proxy during web app testing this week. There are a few ways to do this, but this method was the easiest since I already had Burpsuite’s TLS certificate installed. For more information on this, see the Burpsuite help. To configure an upstream proxy for Burpsuite, such as OWASP ZAP, follow these steps:

First, configure your upstream proxy that will sit between Burpsuite and the web application to listen on a different port since they both bind TCP 8080 by default. Here I’ve configured ZAP to listen on port 8082 :

Configuring ZAP's Proxy Port
ZAP Proxy Port Configuration

Then, edit Burpsuite’s configuration to point to the upstream proxy. Here, I set a wildcard destination host using ‘*’ and set the proxy host to ‘localhost’ and proxy port to ‘8082’:

Configuring Burpsuite's upstream proxy
Configuring Burpsuite’s upstream proxy


Make a Connection

This post was inspired by a client who came to me and said “I do not understand all of these findings, can you explain them to me?”, referring to my web application penetration test deliverable. We spoke for an hour, as I described the various findings to him. I corrected him when his understanding was shaky, and I confirmed where his understanding was solid. He had a development background, and was studying for a security certification, but he was managing a large security project for a well-known company and I was surprised to learn he was a security newbie. At the end of our conversation, he thanked me and said “Now I understand, and I’ll make sure my manager does as well!”

This is what we should strive to hear from our clients.

Continue reading Make a Connection