So we start with crackmapexec

Crackmapexec is a recon tool for when you are on a Windows network. It is called the swiss army knives of pentesting tools, and I agree. As the readme.md file says, there are a selection of core functions that can be called using arguments, but you can read a man page, right?

Oh, awesome. I ran it and nothing happened.

It turns out that the alias that PTF puts in for crackmapexec doesn't work. I am not sure why. I consistently get a 'too few arguments' error when I tried to use it.  Instead, I needed to run /pentest/vulnerability-analysis/cracmapexec/crackmapexec.py directly (as su) to make it work.

So once I got that far, everything seemed smooth. The basic commands work well and scanned my network for shares here at POINT.

Interestingly, it had some problems with my NAS

If I got dig into the underlying Impacket, which drives crashmapexec, I find that there probably is an SMB issue:

Fascinating stuff, but did it get the shares? No, I apparently need to give it credentials. That's interesting.  There aren't very many things that you can do without creds as it turns out, so you at least need to know one user's login.  That's kinda a bummer, but I guess it depends on what you are looking for. As it is, I would file this under post-exploitation, rather than vulnerability-analysis, since it is for use after you are already in the network.  Maybe that's just me.

And it really is just for Windows PCs.  It saw my three Windows 10 workstations, a client's Windows 7 box, and strangely my NAS, which is a Synology DS412+. I'm sure the SMB shares are what kicked it off, and the non-windows underlying environment is what caused the user session failure.  Interestingly, crackmapexec didn't see my Windows 10 Rasberry Pi 2, or the Windows Phones that were on my network. Wonder why.

So, in the final analysis, crackmapexec looks like a really slick tool, almost could be a management tool for Windows environments given the ability to run a command on a number of machines. If the underlying code were a little more modular then some really great stuff could be done with it at the scripting level.  And it turned me on to Impacket, with which I was not familiar.

Well, no. As it turns out a lot of organizations use FTP to move files from app to app, from partner to partner, from location to location. Legacy apps exist, and they are a large percentage of the vulnerable applications out there. FTP is a reality that everyone checking security needs to consider.

ftpmap "scans remote FTP servers to identify what software and what versions they are running" according to the man file.  It's certainly something that should be in your 'hey lets look at this server' test group.  So let's give it a try.

Waaaiiit a minute. Error city. This shouldn't be happening! Guess that's why the PTF didn't put it on my system - something weird is missing:

Well, crap. A quick run of apt-get shows that I have the latest version of automake, so there must be something subtle wrong. Aah well, I don't see THAT many FTP sites out there ...

Some of you know that I am the curator of the Information Security desk at Wikistrat, a virtual strategy consulting company. We have fun over there, and a recent project was collating some predictions for 2016.

It's a little buzzword-rich, as these things are wont to be, but there is some cool stuff in there if you are into geopolitical stuff. I also submitted my take on the direction of cybercrime and malware, with an assist from Brent Huston.

Take a read, and let me know what you think.

there you have it - it will just test path after path.  That's what pentesting tools do well: patience. This toll will simply poke through everything on every platform to get a path to a file that isn't protected.  There are a lot of options for altering how the scan works, but I am not going to copy them all here.  Check out the examples here:

What we are talking about is things like checking for known default credentials, looking for unprotected CGI files, fishing for hidden content, deep header enumeration, and even pushing for exceptional error messages. It's a neat package, and it is customizable as a new level - the underlying tests are all stored in a database. No code changes are needed to add new checks.

One thing you should know though is this: the version in the PTF is not the newest. nikto is constantly updated, and you should update the PTF file if it hasn't been recently.  After that, you should run sudo nikto -update to get the latest versions of the attacks in the database. 

And as it turns out, Nikto is stupid easy to use. If you have a new host or a new server, you can do a quick check with 

nikto -host https://domain.com -output domain.txt

That will find a load of stuff on anything other than Azure or EC2. Seriously, if you have an application that someone decided to 'put on that server over there' then you should run this check. Just takes a second.  Well, OK, a few minutes. Still.

Some of the important parameters that I have used in the past to solve particular problems include:

Anyway, people that do vulnerability assessment use a lot of tools that help us find known vulnerabilities.  There are many problems that are well understood - both known flaws in existing software, and patterns that cause problems in new software.  These tools take the drudgery out of testing for all these known flaws, so we can spend our time looking for things that can't be scripted out easily, like business logic flaws.

There are a lot of tools out there, and many of them are crap.  TrustedSec, Dave Kennedy's security consultency, has compiled a cool installer that collects the best of the best tools, all of their prerequisites, and those weird mappings that we all need to make our lives easy. It's called the Pen Tester's Framework.

For the next several weeks, I am going to walk through most of the tools in the Pen Tester's Framework and give a developer's view into them. I'll break into lab machines, review code, look at usability, and generally make a mess of things. I hope you'll join me.

My environment will consist of my Acer Aspire S7 with Ubuntu 15 as the test machine, and mostly the OWASP BWA as the target.  I'll also probably be scanning the FALE lab occasionally, and probably my own dev lab as well; I'll describe those as I use them.  

To install the Pen Tester's Framework, you need to get it from Github.  For the simplest solution in Linux, just install git (sudo apt-get install git) and then clone the repository with:

In Windows, try the download link in Github. The URL you want to start with is https://github.com/trustedsec/ptf.

Once you have gotten the files in place you just need to execute the installer in Linux.  That just means:

That will put everything in /pentest. One thing I have to recommend is using this command often.  These tools are updated constantly, and you should respect that.  I ran into all kinds of problems with updates while writing the series.  The tools need their updates!

The PTF is divided into several sections, and I am going to start with ... guess it ... vulnerability analysis! Pretty awesome, eh? I thought so.  Some of these tools I know, and some are totally new. Looking forward to getting started.

There is a solvable set of problems that are causing the divide between infosec and development.  Almost all of it revolves around risk-averse infosec practitioners and risk-accepting developers seeing the same issue from different sides.  For instance, infosec may see a feature like framability as a risk (due to UI Redress) where developers see it is a nice thing to offer users. Even when a security flaw is found, differences abound. Infosec view and reports the flaw as a vulnerability, wheras to developers it is just a defect.  Severity is an issue; infosec inflates the severity of questionable vulnerabilities for legal or headline-grabbing reasons but developers just don't see the urgency.  This language shift is exaserbated by the divergent personality types in infosec and development.

That's not all though.  infosec fails to understand the basics of how a developer lives their life. The Software Development Lifecycle, or SDLC, be it a more traditional document-style or a newer agile-style process, rules the developer's day to day existence. Introduction of non-customer impacting bugs just doesn't have a slot in the process.  Also, information security needs to understand their products' underlying platform, along with it's strengths and weaknesses.

So now that we have a grip on the problem, what do we do? 

First, we automate. Some things in development just need to be autiomated.  Testing, deployment, and confirmation, for instance, are three areas where good, well vetted automation will make it a whole lot easier to focus on the real hard things. Give dev and QA the tools to automate their jobs, and teach them to use them.  When it comes time for application vulnerability analysis, put your static code analysis in the QA build, and let it focus on what it does best; same with the dynamic code analysis.  Don't make someone have to push a button, just automate it.

But some things a human does well. You can't have a report run from an automated scanner and then jsut thriw it over the wall to the devs.  Find the vulnerabilities that matter, focus on those, speak about them in terms of defects, and add them to bug tracking. 

There are other things that humans do too, like pentesting and code review. This is the human side of static and dynamic analysis. It must be understood that a grasp on the platform you are testing, and the business case in question, makes all of the difference.  If you take a report, especially from someone outside of the company with an imperfect understanding of your environment, the report will be of no use to the developers at all.

A third thing that humans do well is apply foresight.  Use of tools like the OWASP Proactive Controls or Application Security Verification Standard will make the transition into a security culture so much easier because the developer can see a path to more secure software.  They look ahead - way better for a dev than looking behind.

So what should you do today? Well, remember that devs like spicy food and expensive beer. Get your dev staff together over a few beers and don't just train - teach! A pattern that has worked well for me is to start with a 'test yourself' approach, then talk about secure coding, and then tie it down with security principles.  Or start with the principles.  Or start with the coding - just make sure to hit for the cycle. There are very few appsec specialists out there, so it behooves us all to make a few. Giving the developer the tools, and then teaching them how to use them, is more likely to make you an appsec person than just about anything.

We're in this fight together, folks, take it or leave it.  The end goal is to make usable AND secure software, in a reasonable amount of time and under a reasonable budget.  All of us do different things well, so if we agree to sit around the table and communicate, we can all get the job done.  Remember that security isn't developer's first concern and shouldn't be.  Give them the tools, teach them how to use them, and provide reasonable, valuable analysis of the apps, and you'll see things get better soon.

I probably should use this time to discuss the ins and outs of software testing, how it integrates with security, and why there is such a response to the joke. But that's all been done.

Instead, I'd just like to take a moment to marvel at the insane power of social media. I mean, that joke has touched over four MILLION people. That's a lot. And it's still going! If I go right now and look at my notifications, 42 more folks have retweeted it.

I have had to turn off my notifications on all devices, otherwise everything buzzes constantly. It's nuts!

But take a second and compare this 15 seconds of fame to the larger issue.  Take Ahmed Mohammed, who went from arrested at school to a white house invite in what, 36 hours? The whole internet stood up! I couldn't believe how aligned my timeline was.  But now, we start to learn that there might be two sides to that story, and that it might have all been a setup. How about that? Someone playing the Social Network? Like a fiddle? Say it ain't so!

With great power comes great responsibility, but what if that power is distributed? And anonymous? Who bears the responsibility? There are some things you just "don't do," but they get done all the time. Someone - someone anonymous, in the network - doxxes someone who the Social Network has decided is worth contempt and then WHOOPS, we were wrong. But now their life is in shambles, and the horde moves on to the next worthy adversary.

I don't really have a solution, but having had a taste of the immense power of the network in a very small way (seriously, 610 replies!) I can just imagine what it would have been like if one of my more off-color or politically or morally charged posts caught the interest of the horde.

Be careful what you share. Make sure your family does as well. You never know what's gonna catch on.

CodeMash 2.0.1.5 - Developer Security Training

Cleveland OWASP - Cracking and Fixing REST Services

Central Ohio Infosec Summit - Developer's Guide to Pentesting

The State of Security Podcast - Working with Developers 

Arena Tech Night - Why the Web  is Broken

Columbus ISSA - Weaving Security into the SDLC

CodePaLOUsa - Weaving Security into the SDLC and Developer Security Training

CircleCityCon - Developer Security Training

BSides Cleveland - Why the Web is Broken

Great Lakes Area .NET User Group - Developer's Guide to Pentesting

Converge Detroit - Weaving Security into the SDLC and Cracking and Fixing REST Services

Pittsburg OWASP - Cracking and Fixing REST Services

The rest of the year looks to be just as eventful, and I am very much looking forward to it!

Central Ohio .NET User Group - Developer's Guide to Pentesting (August 27)

DerbyCon - Developers: Care and Feeding (September 25-27)

DogFoodCon - Why the Web is Broken (October 7-8)

OSU CyberSecurity Day - Developer Security Training

Vermont Coder's Connection - Developer's guide to pentesting

Hope to see you at one of these awesome events!

For instance, if you use email address for username, when a user logs in your site has the option to tell them if their email address or password is incorrect.  If you are specific: "Email address not found" or "Password incorrect", then account enumeration is possible. I can send my list of 144 million email addresses and a password of 'asdf' to your login page, using ZAP Fuzzer. Then, those that said the password was incorrect mean that the email WAS correct, and I have a list of valid accounts.

So, anyway, I am here to tell you that simply making sure that you post a 'Your credentials are incorrect' isn't enough.,  Troy found a really good subtle indicator in his post, and to find those I recommend that you send each response to a comparer - both the failed username and password - to make a bitwise comparison. I have found stylesheets slightly different, an extra linefeed, all kinds of things.  But with the prevalence of hashing, I have discovered something even more interesting.

"But Hashing, Bill? I thought hashing passwords was a good thing!!"

You are right.

But.

Let's look at a login procedure.  In the POST action, you have something that looks a little like this:

checkCreds(username, password)

    user = LookupUser(username)

    if user then:

        hash= hashPass(password)

        if hash = user.hash then:

            makeSession(user)

Follow me? If the user exists then hash the password and compare. Seems like a pretty sensible model.

There is a problem, and I discovered it because I usually run tests with F12 tools loaded up. When I passed in the wrong username, the response took about 100 milliseconds. If I passed in the right username and the wrong password, the response took around 500 milliseconds. The time it took to hash that password resulted in account enumeration.

So I tossed my list of email addresses against it with a password of "password". Those that took 100 milliseconds I discarded. Those that took 500 milliseconds were valid accounts.

What's the takehome from this? Well first, get a application vulnerability analysis from a qualified auditor. These things are hard to find. Second, very carefully review the code for your login procedure. For the average attacker, this is the only page that is available for attack. Don't give away the freebies.