<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.
Thursday, September 26, 2013
Tuesday, September 17, 2013
#05: The Value of Research...
I had been stumped over the past few days by an issue that came up at work. A configuration issue 'seen' by our vulnerability scanner was making me and my co-worker pull out our hair, not to mention what occurred when it was known by management...
All attempts to use the information found in the methods of remediation supplied by our vuln scanner were less than useful. "Remove $SERVICE from use" "Stop using $Important_piece_of_data", and et cetera. Add to it that the CVE in question was from more than 10 years ago, and you have a recipe for disaster. (You'll forgive me for being vague above, but operational security prevents me from divulging much more than that.)
Now, I pride myself on being pretty good at doing my due diligence in finding out information. I rarely ask questions of things I do not know, because I want to find the answer myself. Google is my wingman usually, and then failing that, I try Bing and Yahoo. Dogpile used to be my search engine of choice back in the day, but most browsers don't have the search plugins for it anymore. I even used one called 'Vivisimo' for a few years, which clustered results from other engines, but I just faded away from it, for whatever reason.
It's amazing that in my quest to become a security professional, what did I find along the way? Pentesters MUST do research if they plan on attacking a target, because all the little breadcrumbs on the Internet can lead to a bigger picture of a person, or company that can be used to attack them. This is right up my alley. By finding out someone went to Purdue, or active on certain forums, that can give you a picture of who they are or what can be used in social engineering attacks
When my work colleague and I went through our pentesting and ethical hacking course, we learned that the Internet makes it super simple, heck, they'll even aggregate that information for you. Pipl.com is a good site for getting info about people, but they only give you certain info (name, DOB, places lived). But there are a grip of sites like this that will give you meta bread crumbs. You learn a woman's maiden name on one site, her address on another, even her phone number and if she's had a bankruptcy on a third. It's all about what information would be the chink in the armor. A bankruptcy? Send him/her an email at work from the 'lawyer' stating that there was a mistake in the judgment, and click on this PDF to read the summary... boom! one payload infected PDF later, and you have shell into their network.
I guess my point is that research is a very good way of getting where you need to go.
Oh yes, my original story... I managed to find a blog (much like my own) that talked about a program that I could use to test my appliance. Thankfully, it was already in my Kali Linux distro. After reading a bit of the help and man pages, I was able to query my appliance with it. I was pleasantly surprised to find that we were in fact not running what setting the vuln scanner suggested. So after agonizing over this issue, and getting management in a tizzy, we may be able to laugh this off over a couple of beers in a week or so...
So, next time you're asking yourself, "What's the capital of Swaziland**?" Get into the habit of grabbing your browser and doing your research. You'll find out on your own, which gives you a sense of empowerment, and you can leverage the various search engines to make your job easier.
Until next time...
**Swaziland, a country completely surrounded by South Africa, and Mozambique, has two capitals, Lobamba, the royal and legislative capital, and Mbabane, the administrative capital. And you thought you wouldn't learn anything here today.
All attempts to use the information found in the methods of remediation supplied by our vuln scanner were less than useful. "Remove $SERVICE from use" "Stop using $Important_piece_of_data", and et cetera. Add to it that the CVE in question was from more than 10 years ago, and you have a recipe for disaster. (You'll forgive me for being vague above, but operational security prevents me from divulging much more than that.)
Now, I pride myself on being pretty good at doing my due diligence in finding out information. I rarely ask questions of things I do not know, because I want to find the answer myself. Google is my wingman usually, and then failing that, I try Bing and Yahoo. Dogpile used to be my search engine of choice back in the day, but most browsers don't have the search plugins for it anymore. I even used one called 'Vivisimo' for a few years, which clustered results from other engines, but I just faded away from it, for whatever reason.
It's amazing that in my quest to become a security professional, what did I find along the way? Pentesters MUST do research if they plan on attacking a target, because all the little breadcrumbs on the Internet can lead to a bigger picture of a person, or company that can be used to attack them. This is right up my alley. By finding out someone went to Purdue, or active on certain forums, that can give you a picture of who they are or what can be used in social engineering attacks
When my work colleague and I went through our pentesting and ethical hacking course, we learned that the Internet makes it super simple, heck, they'll even aggregate that information for you. Pipl.com is a good site for getting info about people, but they only give you certain info (name, DOB, places lived). But there are a grip of sites like this that will give you meta bread crumbs. You learn a woman's maiden name on one site, her address on another, even her phone number and if she's had a bankruptcy on a third. It's all about what information would be the chink in the armor. A bankruptcy? Send him/her an email at work from the 'lawyer' stating that there was a mistake in the judgment, and click on this PDF to read the summary... boom! one payload infected PDF later, and you have shell into their network.
I guess my point is that research is a very good way of getting where you need to go.
Oh yes, my original story... I managed to find a blog (much like my own) that talked about a program that I could use to test my appliance. Thankfully, it was already in my Kali Linux distro. After reading a bit of the help and man pages, I was able to query my appliance with it. I was pleasantly surprised to find that we were in fact not running what setting the vuln scanner suggested. So after agonizing over this issue, and getting management in a tizzy, we may be able to laugh this off over a couple of beers in a week or so...
So, next time you're asking yourself, "What's the capital of Swaziland**?" Get into the habit of grabbing your browser and doing your research. You'll find out on your own, which gives you a sense of empowerment, and you can leverage the various search engines to make your job easier.
Until next time...
**Swaziland, a country completely surrounded by South Africa, and Mozambique, has two capitals, Lobamba, the royal and legislative capital, and Mbabane, the administrative capital. And you thought you wouldn't learn anything here today.
Saturday, September 7, 2013
#04: ... of nonces and mushrooms
We have been doing updates with regard to our web applications at work this week. Deploying a more randomized token for our Tomcat applications.
A nonce is a random or pseudo-random token that is generated by the server when doing authentication to reduce the chance of replay attacks, like Cross Site Request Forgery and Session Fixation. It's important that our clients, who are not technologically savvy, to be as protected as possible from replay attacks.
Also, as the discoverer of the issue on our application servers, I failed to understand that just because they have a dog in the fight, that they should be brought to the fight. There are just some people that hinder the incident response and they will do what they think is the 'proper' way to do it.
This has given me the idea that a proper incident response plan is more necessary that ever before... Every person knows their place in the process, and there is a proper level of escalation, and certain conditions must be met to reach a new escalation point. I failed in that respect, and wished that I had not invited everyone to the incident. After this, I will definitely do a lessons learned with management and draft a better incident response plan. Some people in the org just need to be mushrooms. Keep them in the dark... They are happier that way.
All in all, an odd couple of weeks. My plan next week is to school our testers and developers on using web security frameworks that will enhance our web applications. Cause we want to have a more secure environment before they deploy. We'll also be giving them a vuln scanner they can use to check against for possible future patching. And also showing them Burp Suite so they can test against various inputs to check for XSS and other OWASP issues, like SQLI...
It's hard to believe how far this organization has come from a couple of years ago...
A nonce is a random or pseudo-random token that is generated by the server when doing authentication to reduce the chance of replay attacks, like Cross Site Request Forgery and Session Fixation. It's important that our clients, who are not technologically savvy, to be as protected as possible from replay attacks.
Also, as the discoverer of the issue on our application servers, I failed to understand that just because they have a dog in the fight, that they should be brought to the fight. There are just some people that hinder the incident response and they will do what they think is the 'proper' way to do it.
This has given me the idea that a proper incident response plan is more necessary that ever before... Every person knows their place in the process, and there is a proper level of escalation, and certain conditions must be met to reach a new escalation point. I failed in that respect, and wished that I had not invited everyone to the incident. After this, I will definitely do a lessons learned with management and draft a better incident response plan. Some people in the org just need to be mushrooms. Keep them in the dark... They are happier that way.
All in all, an odd couple of weeks. My plan next week is to school our testers and developers on using web security frameworks that will enhance our web applications. Cause we want to have a more secure environment before they deploy. We'll also be giving them a vuln scanner they can use to check against for possible future patching. And also showing them Burp Suite so they can test against various inputs to check for XSS and other OWASP issues, like SQLI...
It's hard to believe how far this organization has come from a couple of years ago...
Subscribe to:
Posts (Atom)