Friday, 20 June 2014

Prequel - An Investigation Into TOR Pt. 1 - Telnet (In)Security




Having recently joined a large security company, we'd been discussing TOR during training and then I spoken to a friend about TOR being on the news alot lately. So, i've decided to do some on-going investigative research into TOR. Before we get deeply involved with the networking, i'm going to make sure all my readers have a basic understanding of protocols. For this post, we'll be taking a quick look at an un-encrypted protocol: Telnet.

The first step is to go to 'Programs and Features', turn on Windows Features - Telnet Server. It was at this point that I actually learned something very interesting during the course of this post. "Local Users and Groups" has been taken out of non-pro versions of Windows 8/8.1. This is rather annoying because when you try to Telnet INTO Windows 8, you need the user you're telnetting in to be a member of the "TelnetClients" group. So as you cannot seem to do this via the GUI, we'll have to do it by commands; Rich Baldry over at SuperUser.com posted a command which you'll have to use if you wish to replicate this post.

Use the command 'net localgroup' as follows. This works on non-Pro Win 8 as well.
  1. Open a privileged command prompt: Open Explorer and search for 'cmd.exe'. When it appears in the file list, right-click and select 'Run as Administrator'.
  2. Run the command: In the privileged command prompt window, enter the command as follows:
    net localgroup [groupname] [username] /add
    
    To see a list of local groups available, just type:
    net localgroup
    
    To see other options, type:
    net help localgroup
    
 So in my case, I had to open command prompt and type in: net localgroup TelnetClients Simon /add

 After making sure the Telnet server service was turned on in Windows 8, I started up Kali Linux so I could telnet from Kali over to Windows 8. I should mention that both Windows 8 and Kali were virtual machines. On my local computer, I had Wireshark running, capturing the packets that were flying around the network.

The first instance of telnet shows that the following flags were set: PSH and ACK. PSH is short for PUSH and all you need to know, is that TCP buffers data and that without a PSH flag, it wont be PUSHED forward instantly. If you want a more in depth look at PSH, click here.


A quick look at Wireshark's statistical protocol hierarchy shows that the traffic was communicated using ipv4 and a significant amount of traffic was TCP and Telnet - as we know, Telnet uses TCP and operates on Port 23.

Just to make the point, Kali's port 57600 was sending traffic to Windows 8's port 23. Port 57600 uses the Transmission Control Protocol aka TCP. TCP is a connection-oriented protocol, and it requires what is known as a 'hand shake' to set up end-to-end communications. Only when a connection is set up can a user's data can be sent bi-directionally over the established connection.

It's important to note that TCP guarantees delivery of data packets on port 57600 in the same order in which they were sent whereas UDP does NOT. UDP port 57600 would not have guaranteed communication, whereas TCP on port 57600 would.

Security

So, how is all of this relevant to TOR. Well, telnet is an insecure protocol. Data is transmitted un-encrypted, which means that anyone sniffing the packets traversing through the network can pick up on what data is being sent in plain text. So, I started Wireshark to run and sniff packets, then logged into Windows 8 via Telnet from Kali; then I used the 'dir' command to show the directory list.

So, now, as an attacker, let's see what i've just picked up:



Oh dear. If this was a real scenario, the attacker has just got my username AND password. They can also see commands I have ran whilst I was using Telnet. This is why Telnet isn't really used anymore (or shouldn't be, although I have seen it being run in an IT environment before!).

So, in my next post, we'll move onto SSH and then we'll begin working out how TOR works. This wasn't even the tip of the iceberg. SSH Sniffing will be posted here around 30th June.

Sunday, 15 June 2014

Cookies & Advertisements

 So, you like cookies, huh?




This month, i've decided to go 'back to basics' and discuss internet advertisements. There are a massive amount of users using browser extensions to block Ads - but do most users know exactly what they're blocking? For this post, I used IE 11 and Firefox 30.0 which were the latest at the time of writing.

For those of you who remember using dial-up, you'll be familiar with ads. Banner ads used to be extremely popular - and still are to a degree. Adverts generate money - this is the most important thing to remember. When you click on an advert - someone just got paid; more clicks = more money. I remember vividly trying to navigate around websites without clicking on ads back in the 90's, it was almost impossible.

Websites would 'trick' users by having ads that seemed like part of the website, when in actual fact, they were a 3rd party advert that would send you to an obscure website you'd never heard of. These websites would leave what's known as a 'cookie' on your computer - a cookie is a text file which stores personal information and user preferences which is used to identify a user when browsing a website.

There are 'good' cookies and there are 'bad' cookies. The bad cookies sell your personal information such as your email address to 3rd party companies. Ever wondered why you get spam emails and they magically know your name? Cookies.

So, what else can cookies do? Well, if you've ever browsed on Amazon for a PS3 console, then gone to another website and got an advert for a PS3 on Amazon - again - cookies are tracking your activity. Therefore, it's important to know about the different kinds of cookies:

  • Persistent cookies - remain after your browser has closed (and can also be re-used)
  • Temporary cookies - deleted when your browser closes
  • First-party & Third-party cookies - first party cookies originate from the website you're currently looking at in your browser. Third party cookies originate from a different website than currently have open but are related to the current website you're viewing. (The Amazon example above is an example of this).
Many sites uses adverts from third-party sites and those sites track your web activity for the sole purpose of advertising. Most browsers allow you to configure them and block cookies that don't ask permission to gather your personal information. Lesson here is: check your settings. Check what you're allowing cookies to do on your computer.

Back to advertising. Is there anything more annoying than Google Ads? Google scans your emails and picks up on keywords, which then allows them to bring you tailored ads which are known as 'targeted' adverts. Recently, a friend and I were emailing back and forth about VPS. Low an behold, look at the ad in my gmail (IE 11 without ad blocking software):


Crafty, huh? There are debates over this sort of thing - and people have different opinions. Personally - I don't like the fact that software is scanning my emails for keywords and who knows what else it's doing - we simply don't know. I was browsing a popular news website, and got the following ad along the right hand side of the page (again, IE 11 with no ad blocker):

 
Installing the ever-popular 'Adblock' extension to your browser will stop this kind of thing. Here is a screenshot taken from Firefox 30.0 with Adblock installed:


 The screenshot above shows that Google's ad has been removed. And below, you'll see the ad was removed from the news website, hence the blank space in the screenshot. Although these ads were 'legitimate' and not malware, Adblock can help to minimize the risk that ads present. Not all ads are genuine, in fact, there's an increasing number of ads out there that aim to not only track you, but get you to inadvertently install malware or viruses on your machine. So there you have it: cookies & advertisements - not as tasty as they sound! (Sorry, I couldn't help myself...)

Thursday, 29 May 2014

How To Use SOPIA Suite



DuFF - Duplicate File Finder



FiBS - File Investigation Bite-size



 

SHIFT - Simon's Hash Info Finder Tool




SPIES - Simon's Portable iPhone Exif-extraction Software

SOPIA Suite Overview

An overview of SOPIA Suite

 


You can download/contribute to SOPIA Suite here

Wednesday, 28 May 2014

iPhone Backup Forensics - Manifest.mbdb



When I think of iPhones, I remember my own iPhone 3g, 3gs, 4 and whilst I didn't own a 5C or 5S, my girlfriend and my sister owned them respectively, so I have used them. I've used Ipad's and Macbooks and I understand why people love iPhones - so do I. I think they're much better phones than androids, however, when need to do forensics on an iPhone backup, it's slightly time consuming.

As ever, I like to speed up processes. I like scripting, I like automation, and iPhone backups are crying out for some sort of automation forensic-wise. But fear not! It exists! But, let me tell you why it's needed. An iPhone backup is stored in the following locations:


  • Windows XP: %HOMEPATH%\Application Data\Apple Computer\MobileSync\Backup\{UDID}
  • Windows Vista/7/8: %HOMEPATH%\AppData\Roaming\Apple Computer\MobileSync\Backup\{UDID} or %APPDATA%\Apple Computer\MobileSync\Backup\{UDID} 
  • OS X: ~/Library/Application Support/MobileSync/Backup/{UDID}


The UDID is a 'Unique Identifier' and having worked as an app tester, a developer can provide you with an app they're developing that will only work on your UDID - but the important thing to take away, is that it's unique. Looking inside an iPhone backup, you'll see that it is full of files with funny looking names. These names are SHA-1 hashes and don't make much sense on their own, however, included in the backup are four important files:


  • Info.plist 
  • Manifest.mbdb
  • Manifest.plist
  • Status.plist


The Manifest.mbdb file is of great importance. Essentially, this file lists every file included in the backup, in plain-text. The downside, is that you have to manually convert each line to a SHA-1 hash. For example: HomeDomain-Library/Safari/Bookmarks.db would become F0EC7DF5C552FCA6871EDA5621AB225CB5EFEDA4 as a SHA-1 hash. Then we'd have to look through the files, but do you see how that would get annoying? Having to get a string and SHA-1 hash it? I created a python script with a batch file to help quickly turn the string into a SHA-1, which works, but I still wanted the process to be faster. You can download my script here.https://github.com/smc13/otherTools and look for shaConverter.

As I mentioned, I wanted a quicker, more efficient way of getting all strings converted to a SHA-1 hash. As mentioned above, the Manifest.mbdb contains all the files in the backup. After a quick search, I found the following tool: 'iPhone Backup Browser'. This tool can be found here and is created by a guy called Rene. What we're interested in, is the mbdbdump.exe file.

Once you export the Manifest.mbdb file into the same directory as the mbdbdump.exe, all you need to do is run this simple command: mbdbdump.exe > mbdbDump.doc (or .txt, or .csv etc). Once this is done, you'll see data in the following format:

record 7 (mbdb offset 6)
  key    25f31bdb3de9bdead048a0090097d5c1091296d2
  domain CameraRollDomain
  path   Media/DCIM
  mode   dir (488)
  time   28/02/2013 10:04:26
  data   41E8 00000000 0000003F 000001F5 000001F5 512F2BAA 512F2BAA 50CE9157 0000000000000000 04 00

We can verify the hash if we want by taking the domain (CameraRollDomain) adding a '-' and then appending Media/DCIM on the end, so it looks like this: CameraRollDomain-Media/DCIM and you guessed it, we get the same SHA-1 hash (see picture below)


(The software being used in picture is called 'Text Checksum' by Benoit Ferace and can be downloaded from the Windows Store)


So there we have it. There's no need to look in the Manifest.mbdb file and manually convert every string, just export the file and dump its contents. Happy investigating!



Tuesday, 20 May 2014

Domain Extension + The 28th



Domain Extension!

As my 3 year University course finishes, I decided to take a quick look at where this blog started. At the time of writing, it has been 9 months since the blog started. I was debating whether to revert to hackingtheperimeter.blogspot.com or whether to extend the domain name for another year.

Whilst the cost of this site is very low, the domain name and whois charges cost approx $15 per year. Statistics seem to show that I get hits from the USA and UK mainly and if I was to hazard a guess, i'd say I have 100+ regular readers. If those 100 readers clubbed together $0.15 each, that would be another year's domain costs paid.

Now, this isn't a post to beg you for your cash - I've just paid for a years renewal, because when I started this blog, I wasn't expecting 1 regular reader. To have at least 100 is amazing and I was more than happy to pay for another year of Hacking The Perimeter.

28th Day

One or two readers have let me know that they would much prefer me to post on a specific date rather than whenever I feel like it. I know some of my readers use RSS feed, but some don't. Therefore, I am now going to post once a month, on the 28th day of that month.

So....you're telling us there's only going to be 12 posts a year?!? ......Yes.....from me. That's where YOU come in. I will be asking YOU to write a mid-month article on anything IT-related. It could be cloud-computing, green energy reducing IT equipment, forensics, security, hacking - whatever. Each month there will be an opportunity for a reader to make a post. That means each month there *could* be two posts.

Quality over quanity, folks, quality over quantity!

Thanks for reading. Here's to another year of HackingThePerimeter!




Saturday, 17 May 2014

Old Doesn't Mean Useless (Priv Escalation)

I have what you could describe as 'geeky' friends - so geeky, that one of them set me a challenge. I'm in the process of re-locating and as i'm without internet access, my friend offered me his - but only if I could beat his challenge. After making my way to his house, I was greeted at the door by a grin and a laptop. The laptop was running Windows 7 64-bit. My mission, should I choose to accept it, was to gain root access.

All I had was a standard user account called 'local' and an Administrator account called 'Simon' - but I didn't know the password for this (see screenshot below).



I checked the machine for any signs of Windows updates - and it looked as if the system was installed and no updates had been downloaded, though the Administrator had installed AVG anti-virus 2014 - which I thought would destroy any hopes of downloading code and executing it on the machine - or would it? Now i'd posed the question, I wanted to test my theory. For those of you who have a better memory than me, you'll remember CVE: 2010-3888 - which was a 0-day exploit. Apparently the Stuxnet worm was using this to elevate privileges.

I however, didn't remember it, however, after a few minutes of Google searching, I figured it would be worth a shot. My main worry, would be that AVG 2014 would detect it and my friend would laugh at my feeble attempt. So, I proceeded to download the code and take some screenshots along the way.

To my amazement, AVG 2014 didn't flag the file once it had downloaded onto the desktop. As you can see in the screenshot below, I used 'cscript <script>' to run the file and it ran through with no errors.


I then checked to see whether an administrator account had been created and it had.


More proof:


I scanned the file with AVG 2014 and it wasn't detected!


Now, this exploit is 4 years old at the time of writing - in the real world, most, if not all machines will be patched, but it brings up an important thing to note: having an anti-virus DOESN'T mean you're protected, even if the exploit is old. I personally use Vipre Anti-virus when i'm using a Windows machine and I did check, and Vipre does pick up this code. This isn't to say AVG 2014 is bad, lots of anti-virus software don't pick up this particular script (according to the results from VirusTotal, where just 17/52 AV's picked up this malicious code!).


Until next time...