<rant> I am so tired of hearing 'checkbox security'. For me, that term means we aren't doing enough, and just trying to get by. When I was in the Navy, you could just get by just doing the minimum, and people notice. Were there days when I felt like doing the minimum? Heck yes, but not when it came to my job protecting my network.
I need to switch that term back to what it should be called... 'Compliance'. COMPLIANCE !== SECURITY. It's the bare minimum to start with if you want security. Or at least be more secure. I'm tired of just getting by doing the minimum, and I'm gonna change that next week. I'm gonna rise up and make some shit happen.
</rant>
I finished with the excellent C|EH All-in-one book, written by Matt Walker (ISBN: 978-0-07-177228-0). If you're a n00b to the arena of ethical hacking and pentesting, like me, then you'll want to check this book out, especially if you're working toward getting your C|EH. I was dismayed to find the C|EH test is just another multiple choice test. You regurgitate what you 'know' and pass. Much like the CISSP. I think I am a little confused by how you go about taking the exam. I've read the All-in-One, did fairly well on the practice tests in the back, and have attended a week-long ethical hacking course given by our local ISSA chapter. Plus, there are tons of practice tests and questions that are free on the Internet. Guess I just need to sit down, fill out the form and take the exam.
Now that I'm done reading the CEH book, I've started in earnest on learning Python. Using the excellent 'Wood Rat' (Neotoma Muridae) book from O'Reilly, I usually read at night as I am going to bed. I can usually knock out about 10-12 pages a night. To augment this, I saw that Vivek Ramachandran over at SecurityTube (http://www.securitytube.net/) has started the "Pentester Academy" which allows you to take advantage of all of his excellent video training. I have started the "Securitytube Python Scripting Expert" megaprimer/track that has Vivek explaining concepts like tuples, immutable strings, and if/when type loops. The loops are nothing new, but I've not worked with scripting to the level I am about to learn with this. Python is a freaking powerful language, and very VERY flexible.
I initally balked at the cost. It's $99 for the first month, plus $39/month thereafter. But I figure with the book I'm reading and this, I can learn a lot. Vivek does a good job of explaining concepts and I am fairly confident that I can/will learn Python using him and the O'Reilly book as an augment to the training. You can find Vivek on Twitter @securitytube. He doesn't pay me to say any of this, and his site really has a lot of great content, even Metasploit training. And I heard on last week's Pauldotcom security weekly podcast that he is working on a Burp Suite series, which I'm highly excited about. You can find his interview with @pauldotcom here: http://pauldotcom.com/2013/09/episode-346-guest-interview-wi.html
Lastly, we made our PCI milestones this quarter. While I abhor the concept of 'compliance' frameworks, it's nice not to have that 500 pound gorilla on our collective backs, at least for a few days (that gorilla being 'management'). A lot of the stress was learning the processes for submitting reports to Tenable, our new QSA and inital setup of Nessus. If you haven't find a good QSA, or are looking for a good vulnerability scanner, Nessus is very easy to learn, and the reporting is nice, concise, and easy to parse, and Tenable's QSA's are very knowledgeable and very efficient at explaining what is needed for the burden of proof.
Thanks for reading this. You might be the only one.
Blog talking about security, privacy, legal, and compliance topics, as well as follow-on content from the 'Brake'ing Down Security Podcast...
Showing posts with label Nessus. Show all posts
Showing posts with label Nessus. Show all posts
Thursday, September 26, 2013
Saturday, August 24, 2013
#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.
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.
Sunday, August 18, 2013
#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...
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.
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.
Subscribe to:
Posts (Atom)

