Paranoia and a Terminal - Part 0x02 - URL Forensics

proxychains
curl
paranoia
url
forensics

(Security Architect & Founder) #1

Hello, 0x00’ers! Welcome to my third (Yes 3rd) instalment of Paranoia and a Terminal! In this episode we will explore URL Forensics - for the Paranoid. In other terms, viewing a site or viewing a link, without falling victim to a social engineering attack if our spidey sense rings alarm bells.

Scenario 1

We are at our terminal, plugging away writing some badass script, then all of a sudden, we receive a message from some random geezer, “Hello, how are you?”, we’ve never spoken to this individual before, this seems VERY fishy. Usually, we would just ignore messages like this due to our paranoia, but today we decide to engage him in conversation.

After some discussion and small talk; he replies “I’m glad you like ABC, I’ve actually been reading about that and I’ve found this http://bit.ly/2fc6P19, and I thought you might be interested”

To the truly trained and paranoid, this has so many things that send alarm bells ringing:

  • Link Shortener - Link shorteners are generally an attempt to grab you IP Address & User Agent, something very important during the reconnaissance stage.
  • Random link - Even if it wasn’t shortened, how do we know he isn’t running a sketchy chrome 0day on that baby? We don’t. We don’t want our boxes to be pwned!!
  • Random Person - This guy came out of nowhere, and now he’s sharing links? This guy seriously is asking for a beating :stuck_out_tongue:
  • Weird Concern for You - Yes, good people do exist, although when a stranger is unusually kind to you out of nowhere, sadly, in this day and age, you should be second-guessing their motives. Con-men + Social Engineering use this tactic to lure many people into the downfall of a company, or just their facebook password.

But hang on, @pry0cc, are you saying we can’t find out where the link goes at all? I just need to know so bad!

If you can avoid it completely, you can definitely avoid falling trap just by not clicking it at all. But there is no complete reason we should avoid it, after all, we are about to learn some really cool Forensic methods to uncover where it leads, without actually being a noob.

Turns out, there are actually services that offer URL expansion services, that will follow the link so that you don’t have to. I have actually written a super simple script to do this from the terminal (I’m a terminal junkie), but you can go directly if you need.

The first thing I do is run my unshorten script; copy and paste that sucker, and run:

$ curl "https://unshorten.me/s/http://bit.ly/2fc6P19"
>> https://bigscarywebsite.com

This will contact the unshorten.me website; and unshorten the link for us. If they were running a sketchy IP logger such as grabify, then all they would see is the unshorten.me service.

As we can see from running this command, we get a response of the expanded URL, AKA - where the rabbit hole leads. This is is really cool; now we just need to figure out how to find out what https://bigscarywebsite.com actually is.

At this moment in time; we could just pop open our browser and view the link - but remember - we are paranoid. We can’t do that. GASP. You never want to click on a ‘phishy’ URL naked. Yes, if you know me, you’ll know I say “naked” in terms of, connecting without any protection, connecting without any spoofing, proxies or anything. Connecting naked does exactly as the name suggests, it exposes you.

No no no, we must use a very clever method to view this link… If you choose, you can do the following from within a vagrant shell, personally, I find it acceptable to do this from my main machine naked.

The first thing you’ll wanna do is break out proxychains + tor. These two items may not cause complete anonyminity against government powers, however, that is not our target objective in this matter; our target objective is staying anonymous from our adversary.

If you don’t know how to use proxychains - @OilSlick did a sweet tutorial a while ago on it, so go check that out if you’re unsure.

Setting up tor is fairly simple:

# Install tor
$ sudo apt-get update && sudo apt-get -y install tor
$ sudo chown -R $(whoami) /var/lib/tor
$ tor

Tip
(Do this from a tmux window, or another terminal window as tor will take over your terminal.)

Now you can safely begin your Forensics. My swiss army knife to use is curl, curl is my baby, and curl allows me to do so much so easily.

Verify ProxyChains is working correctly

$ proxychains curl "http://icanhazip.com/"
>> 305.129.248.134

Note
(For the purposes of this tutorial; I have set up a very basic python webserver in order to mimic the logs an adversary may be keeping. As always, I will provide this code for you at the end of this article in a GitLab Repo).

Get Header Infomation

Before we start poking around at the source code of the site; let’s first begin by checking the headers, the headers will tell us a lot about the adversaries setup; server type and other quite interesting information.

$ proxychains -q curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30" -I "http://testserver.com:8000/"

Lets break down this command:

  • proxychains -q - this command routes curl through our proxies defined in /etc/proxychains.conf
  • curl - this is our command to pull data from the server
  • -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30" - this is our flag “-A”, which allows us to define a custom user agent. One of the many ways we can be identified is through our user agent. In this case, I’ve chosen to use a Mac running Safari, this user agent is very typical and would be hard to spot.
  • -I - this flag allows us to check the headers of the server we connect to
  • "http://testserver.com:8000/" - This is the server we’re connecting to, in my case it is my python web server address.

As we can see from this command we have uncovered several little nuggets of information without revealing much if any information to the adversary:

We have identified:

  • The server software they’re running and the version
  • The local time of the server (or the time setting on the server); this is very important as even if they are behind proxies; it might be able to tell us a lot about where the adversary is located.
  • The last modified time of the page, if this is very recent, then we can suspect it has been tailor made for us.

If we take a look at our server, we can see the information we have given to the adversary:

In this case; after running the -I (header) command, we have only told them our IP address, which if we have configured proxychains correctly, is just the IP of our proxy.

Get the Page Source

Now we know the server type, and other information, now it is time to uncover what they’ve really sent us. Is it a sketchy 0day? Is it just an IP Logger? Let’s have a look…

$ proxychains -q curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30" http://testserver.com:8000/

As we can see from this command, it has returned the source code of the page we are attempting to view. Since we are in curl, HTTP redirects or Javascript will not execute, neither will HTML5 code or any rendering of any kind. This is perfect for us Paranoid Penguins as it allows us to see exactly the process that occurs, sort of like a debugger; think of it like an Objdump or Radare2 for the web.

In this source code, we can see that the page attempted to load a script, judging by the name that appears to be an IP logger, it also displays a title and a paragraph. Nothing too sketchy, however, it easily could be.

If we take a look at our server again

We can notice we have much more information than before; this is because we have actually requested to see the contents of the page. This log result returns our user-agent, or in this case, our spoofed user agent.

You may notice this command is hardly different from the last command; all we have done is remove the “-I” flag. Apart from that, it is identical.

Conclusion

In this article, we’ve covered,

  • Unshortening URLs.
  • Using a proxy + a custom user agent to protect our identity.
  • Using curl to protect against data exposure and 0day attacks.
  • Exercise your curiosity although you are extremely paranoid.

Code for this tutorial: https://git.0x00sec.org/pry0cc/tutorial-code

I hope this comes in handy, and I hope you have learned a lot from this! Please tell me your thoughts about this article, and please suggest anything else you’d be interested in me covering. If you have any questions please ask them, as somebody else might have the exact same question as you! Have a good one guys, and as always, stay paranoid.

  • pry0cc

#2

Awesome article, bookmarked.


(Valentine) #3

Dude this might come in handy. Nice tutorial. :slight_smile:

Cheers.


(Security Architect & Founder) #4

Thank you worz! I’m glad it helped :slight_smile:


(Security Architect & Founder) #5

Epic! That was my intention!


#6

Excellent, this’ll surely help me avoid malicious shortened urls!
Great write-up!
For those of you that are interested, I added this as a shortcut to my .zshrc / .bashrc, to use it even more efficiently:

unshortenme() {
    URL=$1
    curl https://unshorten.me/s/$URL
}

This way you can just type: unshortenme https://example.com/example


([email protected] [email protected]) #7

Hey guys, I was bored and decided to make a simple cli tool for this! Have fun and stay paranoid :wink:


(Security Architect & Founder) #8

This topic was automatically closed after 30 days. New replies are no longer allowed.