Thoughts on Krebs article about .gov URL shortener abuse

——————Update: 19 Apr 2016

Nearly a month later the same spam campaign is still attempting to use the virginia government website to refer spam victims to their strikenx.bid and assembled.accountant domains.. Either people are reading spammy emails a month late, or the idiots in charge of the campaign haven’t changed their spam campaign despite it not properly using the referral.

Of note, some other pushers seem to be trying to exploit the referral mechanism of an EPA website, but failing as well..
new_spam_campaign

new_spam_campaign2

One other thing that I was thinking about with regards to reconnaissance is the Witchcoven campaign that fire eye reported on. https://www2.fireeye.com/rs/848-DID-242/images/rpt-witchcoven.pdf

Although the profiling that you can do with the method I detailed below is much more limited than what the Witchcoven actors are using, there is one distinct advantage with my method. There is no infrastructure or indicators to uncover since you don’t need to compromise a legit server or even buy your own profiling servers. With no easy way to link the reconnaissance to the next step which would be delivering the targeted recipients an exploit based on their android kernel and browser it would be significantly harder to figure out if victims are random targets of opportunity or chosen…

——————–end update

——————Update: 31 March 2016

I found another “fun” use for the data coming off the developer stream for the bit.ly gov shortener 1usagov.

Everybody talks about how bad the Android ecosystem is for updates, and that the majority of phones in the field are vulnerable to something or other. It is nice to see the data myself though. By curl’ing the developer stream and then grep’ing for Android versions it’s pretty apparent. I’m not even going to bother making iOS comparisons cause that has been done to death. Needless to say the world is ripe for the droid malware ecosystem or worse.

android

curl --url http://developer.usa.gov/1usagov | grep -o 'Android [0-9].[0-9].[0-9]'

android2

XP is dead, long live XP!
——————–end update

xp
Brian Krebs reported on this issue last week and I did some poking today so I thought I would write a small article.

http://krebsonsecurity.com/2016/03/spammers-abusing-trust-in-us-gov-domains/

As reported by Krebs, bit.ly offers a URL shortener to government addresses such as .gov, .mil, etc. The main security issue as reported by Krebs is that if a spammer or malware pusher can find any sort of local or state government site that offers shortening services to any site, they can then in turn use the bit.ly service to shorten it into a more legitimate looking 1.USA.gov address.

On my linux box I ran the following command to find an active spam operation.

curl --url http://developer.usa.gov/1usagov | grep "VAURL

The results were a Russian spam operation attempting to abuse a va.gov domain, but failing at it since the virginia website was not correctly directing to their URL’s.
spam_campaign

Domains associated with this particular Russian IP, and the spam campaign.
spam_campaign3

The more interesting thing for me isn’t the shortening tactic, but the USA.gov developer view that Krebs reported.

http://developer.usa.gov/1usagov
developer

If IP’s were included this would be pretty close to the ideal control panel that you would want for running a malware/spam campaign.

What is interesting about this to me?

I can use a LEGITIMATE and unique url for a government website, send it to someone after doing the bit.ly shortening which gives it the http://1.usa.gov/…. and then know all the information about their browser, and their timezone. Normally I would have to use BEEF, cookies, etc.. Now I can do it without using cookies, or owning any public domains/IP’s.

My idea in practice.

Find a random unique gov address:

http://www.fsis.usda.gov/wps/portal/fsis/topics/food-safety-education/get-answers/food-safety-fact-sheets/meat-preparation/ground-beef-and-food-safety/ct_index

Shorten it through bit.ly
http://1.usa.gov/1drrCH6

Curl the developer API website for the unique URL:

curl --url http://developer.usa.gov/1usagov | grep "http://www.fsis.usda.gov/wps/portal/fsis/topics/food-safety-education/get-answers/food-safety-fact-sheets/meat-preparation/ground-beef-and-food-safety/ct_index"

And sure enough………. I get a hit on my OS, browser, language, and timezone which could be useful info to then target further messages for a spam campaign or malware. Since this is a unique address I sent to one person I know there won’t be a false positive. Well, at least there wasn’t going to be until I posted it in this blog.. 😉

Capture_me

TAAS – Tracking As A Service. Is that a thing?

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.

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

I think I’m PWND 101 for the non Reverse Engineer

There are the traditional AV (I actually recommend Microsoft AV) scans which have a decent(ish) chance of finding malware on your computer if it has been around awhile. However, if you believe you may of gotten infected recently and you don’t have any faith in your AV there are a few things that I recommend you do.

Step 1. Install packet capture software on a second laptop. (Wireshark FTW)

Step 2. Buy a cheap tap. SharkTap off of Amazon works fine for me. Alternatively you can run Wireshark locally, but you are running the dice that the malware doesn’t look for monitoring.

Step 3. Put cheap tap in between your potentially infected computer and the internet gateway/router…. So use your RJ45 port to connect to your home router through the tap, or use a span port on your wireless router and skip the tap altogether.

Step 4. Begin your packet capture on the laptop connected to the monitor port or tap.

Step 5. Reboot your potentially infected computer.

Step 6. Look for DNS requests in wireshark. You shouldn’t have any domains being resolved for anything but Microsoft and anything set to update. If you see a domain name you don’t recognize check it out on robtex.com, and urlvoid.com. If you see IP traffic and no DNS then check ipvoid.com Step 7. Agitate. Go visit email/facebook/bank websites and enter bad credentials. See if any of the dns/ip traffic in wireshark goes elsewhere. Look out for all the bs affiliate traffic that banners/advertising create. Vet them in robtex.com. Step8. Image your computer and change all passwords that have been entered on that computer. If you made it this far you are still going to be paranoid no matter what :/

Other tools that can help..

Before you install “questionable” apps you should use something like regshot which shows you what is actually happening during an install.

If you are installing questionable apps you should be in a VM environment so you can roll it back!!!

Process Hacker from Sourceforge or something similar lets you know which actual processes are creating outbound connections and you can also dump the strings on a process and then grep for things like wildcards (http://., etc)