#03: XSS, Session fixation, and input sanitization

Holy cow, it's been a busy week.  Who would have thought moving to a new vulnerability scanner would cause all kinds of issues.  What kills me about the number of vuln scanners I've used in the past is that all of them have their own findings, and none of them find everything.  Retina, Nessus, OpenVAS, Critical Watch...  all of them detect their own little things.  Some are better at finding OWASP issues, others are better at OS-level detection.  All of them suck at detection, but then, they can only do so much.

One of the major findings was multiple XSS errors.  That was easy enough to fix, developers just had to be mobilized to fix the issues.  Santize that input!!!!

The issue is with testing.  I'm not what you might call 'savvy' with all the OWASP issues.  Cross Site Scripting, Request Forgery, Session Fixation...  I have gone from 'things I hear on a podcast' to knowing how they work to now using specific tools that allow me to test for them.

My tools of choice in the last year has been Burp Suite.  I love it. A lot...  Not only do you get a powerful tool to show exactly what internet connections are going across (if you're using the 'Interceptor'), but if you've changed the Internet Explorer proxy settings, you can modify the HTTP connections BEFORE they are shipped back to the server, or change the incoming request from the server.  Add to that Burp Suite is free, and you have a tool that you should carry with you on a flash drive.  Burp Suite runs in Java, so that is the only dependency.

I find that I get better results testing XSS with Internet Explorer, because it's easier to disable the XSS protections.  There are ways to do it in Chrome, but a radio button in IE is just easier.  Also, we test for clients and what the lowest common denominator would use, and that is still unfortunately Windows, and Internet Explorer.

I am also looking at Cookie Flags, which are another method of reducing XSS attacks.  Next week, matter of fact, I will be testing as to whether the flags have been correctly set when visiting certain websites.  You can use Burp for this, but I have found the easiest method is to find a plugin, like "Edit This Cookie" to show you the flags.

This is just an example above.  According to OWASP, Setting the "Secure" flag and the "HTTPOnly" flags tells the site what cookies will be transmitted and when.  This tells the browser to transmit a cookie when encrypted communications is required, or in the case of this cookie, whenever HTTP traffic is generated.  This means both HTTP and HTTPS.  'HTTPOnly' is not the opposite of 'Secure'.

For me to test, it's as easy as visiting the site, and clicking on the icon.  I can also set the cookie flags if I want to.  This can be good for testing web applications that set multiple cookies... you can even break a site I'd imagine.

I've only scratched the surface with Burp Suite.  One thing I did have an issue with, and believe me, it's NOT an issue. When using Chrome 29 with Burp, I found that I could not do Google searches with burp Suite on...  Chrome complains that the site SSL certificate doesn't match.  That is fantastic!  Even with the intercept set to 'Off', Chrome will not allow someone to surf Google with a fake cert.  IE isn't so kind. I'm able to do everything I need to do, even Google Searches.

There are others, like Parosproxy, but I've been happy using Burp Suite.  I may try to get our organization to buy a license. There isn't a need to, because for what I'm using it for is available on the free model. I just think that good software should get supported.  And if I can socially engineer my boss into giving them some beer money, then I've done my good deed for the day.

#02: Vulscan and Nmap

While searching around on the Internet, it is amazing the things you'll find.  Nmap's ability to run custom scripts is a very powerful tool.

Vulscan, found at http://www.computec.ch/projekte/vulscan/ can be used in conjunction with Nmap as a 'poor man's Nessus' for a lack of better terms.  Using Nmap's operating system guess algorithms, you can then follow certain vulnerability databases, like OSVDB, CVE, and ExploitDB.  So far, I have tested this with a couple of servers at work...  but unfortunately, the servers are web sites, and for some reason, Nmap can't figure out what the OS fingerprint is.  I am wondering if the fingerprinting isn't somehow being affected by my router, because it's showing up as...

Nmap output from a webserver at work

Sorry for the size...  I'm still figuring this "import image" thing out... But I am damn sure we aren't running "Apple embedded" anything at work...  So, I thought I would try going through a different Internet connection, that being tethered to my phone.

LOL...  it's even worse tethered to my phone.  That same webserver that I scanned from my home, now on my phone is saying that it's a "Panasonic Webcam".  What the hell?  Guess I need to investigate further.  More on that later...

I fully intend to continue testing with Vulscan, maybe as a quick vuln scanner.  We just bought Nessus at work, and pairing OpenVAS with Vulscan will allow us to catch even more issues than previously.

#01: The tools we use...

**My opinions are not my employers, and thusly are mine and mine alone**

I am slowly coming around to understanding the nature of tools like Metasploit, Nmap, and the like. I thought that to become a security researcher, you have to understand exactly what the underlying code does, and you're required to grow your Unix-y beard and ponytail like everyone else.  I felt like Metasploit was a 'cheat' that people used to become pentesters.  I have been around long enough to see people get into positions they clearly were not ready for, and earned certifications because they could write a good test, yet had no knowledge of what they were doing.

I equate Metasploit to the blender a chef would use in a kitchen.  It's a tool, that automates a process that is time consuming or laborious.  Or a wrench that a mechanic would use to tighten bolts.  Everyone in a job has their tools, those little time savers that make work more efficient.  Someone else created the blender, and the wrench, but we gain an advantage by using them.

I always thought that I'd need to make my own exploits and learn C and Assembly, and I'd need to learn how to solder well enough to make my own circuits for hardware malware, etc.  While I would still love to have an in-depth knowledge of those ideas, I have realized that I ended up with a bit of scope creep, and that I need to dial it back a bit to keep from being overwhelmed.

That's why I'm learning Python, and someone else suggested Ruby (since Metasploit uses that)...  I do want to learn more about C, but right now, I just have the basics.  Plus, there isn't much in the way of C programming being used at my office, so I need to learn concepts that will relate directly to my job so I can keep my edge sharp...

So, Python and Ruby it is...  Also, gotta get back to shell scripting... I used to do it a lot in the past, but vulnerability scanning, and justification of firewall ACLs for PCI-DSS doesn't have a place for shell scripting...

I want to do a post once a week, even if it's just stream of consciousness shit.  The C|EH All-in-One book is a hard slog though... Just through the chapter on Social Engineering.  I realize now that we probably should give some kind of training on a regular basis to spot social engineering trickery, as well as proper disposal of papers with info on them... ooh... I wonder how difficult the shred bins locks are to pick...  Yep, even when you reduce scope, scope creeps back...

#00: the beginning

**My opinions are my own, and not of my employer**

I started this blog to help me to put down somewhere things that I am learning about with regard to security and things that interest me in the field of Security.  I don't want to say I'm an "Information Security Professional"... it's too constricting.  I mean, if you look out there, there is a whole world of security concepts and tasks, and you'd be hard pressed not to find something in there that doesn't tickle your fancy.

Security researchers these days are getting into all kinds things.  It used to be that networks (wireless or wired), servers and workstations, or databases were the only gems to exploit.  But in recent years, researchers like the late, great Barnaby Jack and others have been looking at SCADA systems, vehicles, medical devices, etc for security vulnerabilities. And let's not forget the whole mobile platform.  Tablets, phones, mini-PCs, all run a varied operating system with a user base that suffers from either lack of knowledge, or they don't want to know.

I got into security late into the game.  Sure, I've been doing it my entire career, whether that be Physical Security (access controls to COMSEC), or Network Security (typical IT admin stuff).  All the way up to what I'm doing with my current job, which is compliance, governance, and attempting to wrest control of the network out of the hands of users who just want to do what they feel is necessary to get the job done.

I want to start this blog to highlight my continuing journey across the Security "Sea".  It's vast, it's fraught with difficulties, and the metaphorical boat I'm riding on has holes in it, or tigers even (nod to "Life of Pi").  I want to talk about security in the news that matters to myself and others, but also to talk about things that I'm learning.  I'm reading the C|EHv8 All-in-One right now, and I am skimming through the fantastic "Metasploit: The Penetration Tester's Guide", and once I finish with the C|EH, I'll begin working on learning more on Ruby and Python, which run Metasploit.

There's just so much I want to learn, and I often feel like there's too much, and that I'll never learn it all, as though I'm just trying to keep my head above water.  So, making this will help me chart my progress, and who knows, it may even be fun.

Take care, and if you want to talk, I'm on Twitter  @bryanbrake