I attend so much bad security training, it’s a rare wonder when I come across such gems as 7Safe CSTP. 7-Safe is a UK based training provider that partners with Fishnet Security here in the US to provide their courses. They focus primarily on forensics and penetration testing training and services and are one of several training providers for the CREST line of pentesting certifications. Back in February of 2011 I won a contest from http://ethicalhacker.net for free security training from Fishnet. One of the allowed courses was the 7Safe CSTP. **Author’s note – Previously I stated 7Safe was an authorized training provider for CREST. This is not the case as CREST does not endorse any training providers in this way but 7Safe does provide training programs that prepare the student for CREST. I apologize for the confusion.**
Huge thanks to http://ethicalhacker.net for selecting me!
The CSTP is the second part of the CSTA/CSTP combination that is supposed to prepare the student for the CREST Registered Tester designation. Don from ethicalhacker.net wrote a review of CSTA HERE. CREST is a big deal over in the UK and required by many organizations for all their pentesters. Over here in the US it has not seen the same degree of adoption, and due to the marketing machine that is EC-Council it is often overlooked in favor of the CEH. I have my own opinions about the CEH that I won’t go into here but suffice to say that CSTP was AMAZING. You’ll see what I mean as I walk you through the material. Before I do though I want to touch on the popularity of 7Safe courses and what that means for those of you in the US looking to take their training. It’s extremely difficult. As far as I know Fishnet is the only training provider in the US and it took me a year and a half to get the class scheduled. It’s not because it sucks, it’s because nobody here is asking for it. That’s part of the reason for this post. I want to get the word out because those of you taking lesser classes are really losing out on a great thing. OK, enough fluffing. On with the review. Fast Forward to My Conclusion
Format: Typically, the course is done in a classroom environment, but since I’d pestered the ever-living crap out of Fishnet for this course for so long they offered it to me and another student via their RLT or Remote Live Training method. This is a 2 day course with times based on the central time zone. Since I am east coast, class went from 10 A.M to 5:30 P.M. EST. The course was delivered using GoToMeeting with a Juniper VPN environment that the students used for labs. There are 18 labs for this course and the content is mostly mapped to the OWASP Top 10 with an added section on Web App Security Auditing. That’s a lot of labs for a 2 day course. the course breakdown looks something like:
This first section was focused on establishing expectations for the course and getting the students setup for the labs and included 2 labs of its own. This worked flawlessly for us even though this was a non-standard format for the class. We also did an HTTP refresher using Paros that wasn’t too onerous but ensured the students were on a level playing field moving forward. The application used to demonstrate most of these examples was a fake bank called Besurebank with components served from multiple servers. Unlike many other fake apps used for these types of the courses the page looked believable as a real application and there was sufficient complexity to model real world conditions. Hopefully most real banking apps are not as vulnerable as the one used in the class but the scenario provided lent to immediate credibility for the exercises.
Getting into the meat of the course, the first area was on injection and comprised of lecture, a handful of slides and 5 labs. We spent roughly 25% of the entire class time on the injection category and SQLi featured prominently on other exercises in additional sections. This was very nice because it demonstrated ways that multiple attack types could be chained together to accomplish attacker objectives. According to research conducted by 7Safe, they indicated 40% of data loss events involved SQLi in some way so it is understandable why there was so much focus on this category.
The first section here went into how SQL queries are constructed which was nice because so many courses I have attended just focus on ‘ OR 1=1– as if it’s a magical string that will rule the internet. The logic behind the SQL as well as a basic understanding of how queries were constructed and how to resolve such failures was addressed as well. We went into the rather arduous task of testing with Blind SQLi as well as using stored procedures like the xp cmdshell to run OS commands on the server as well.
Command injection (outside of xp cmdshell) was not covered in this section and if this was a longer course I would expect that to be a component as it does feature prominently in the OWASP injection category. Given the length of the course I feel 7Safe did well to prioritize time where they did, but additional research should be conducted here by the attendee. One of the areas I really liked here was the lab walking through how to get at the address bar for popups that don’t typically display it. That’s rather useful when the application is making GET requests that are hidden from the user, although they can still be accessed from within an interception proxy. It’s just easier this way.
The XSS section was the second largest with 4 labs. The focus was of course on Persistent/Stored as well as Reflective XSS. Almost nobody covers DOM based XSS which is a shame, but it’s really tough to explain to people and this is a relatively short class so again I’m not surprised here. One thing that was nice here was coverage of HTML injection and a mention that anything that was executable by the browser could be used in XSS attacks.
In this section, we started off explaining how to test XSS and then leveraging Outlook express to send spoofed emails to a target with Reflective XSS attacks embedded. The extent of impact covered by the labs stopped with redirecting form inputs, cookie theft and session hijacking, with a brief mention of other potential impacts. This would have been a fantastic place for a BeEF lab but I won’t hold that against what I think is otherwise a great module. Much of the work here including email pretexts and the cookie catcher script are already done for you and in a real world scenario the tester will need to know how to create these on their own.
Next we went into Broken Authentication and Session Management. One of the labs here leveraged what we already learned using SQLi to extract unencrypted credentials from the database. We’ve seen plenty of examples recently from IEEE, Yahoo, LinkedIN and others where passwords are being stored unencrypted or unsalted and millions of accounts compromised due to poor security practices. While the discussion did mention session based protection mechanisms and issues which I find to be a rather serious problem, the labs really did not reinforce that.
The 2nd lab here used Burp Intruder to leverage a dictionary attack against a login form using the Burp “Cluster Bomb” attack method which sprays username and password payloads from defined lists. This was a well done lab that also went further into setting up filters in Burp to look for responses that contained the “Invalid” string. You may notice that the version of Burp being used is pretty old but for the purpose of the labs it really did not matter. Many of the labs in this course tend to favor either Paros or Burp and while I appreciate the exposure to multiple tools I tend to prefer using Burp or Zed Attack Proxy for everything within a test as it just makes my workflow move more smoothly and aids in documentation efforts. If you are in the Paros camp I’d definitely recommend checking out Zed Attack Proxy as it’s the only actively maintained fork of Paros and the team is doing great things there. Oh and it’s free.
There were no labs in this section, but an example was given which pretty clearly demonstrated a potential issue here by using the Set-Cookie: parameter to reference a domain not authorized to be managed by the current session owner. The book only contains 4 slides here and we moved through this section pretty quickly. I’d definitely recommend attendees spend a bit more time than this course gives on this issue.
CSRF was also pretty quickly glossed over here but it was referenced in several other sections like the XSS portion of the class. That makes a lot of sense given that XSS is commonly used to invoke CSRF attacks. Sufficient information was given here to explain the impact of CSRF style attacks and some discussion around the usage of CSRF tokens or requiring re-authentication for sensitive transactions. This was one section that I really felt needed a bit more time as CSRF is prevalent across most of the internet, is sometimes hard for people to understand and is often dfficult to completely resolve without re-architecting the web application. CSRF is in my opinion one of the top 3 worst security risks on the internet today and this could certainly have lent itself well to a lab exercise.
Security misconfiguration is one area that continues to contribute to breaches as internal IT folks do some pretty dumb stuff sometimes like exposing the IIS Remote Administration Tool to the internet. The 1 lab in this section covers exploiting this particular misconfiguration to use burp Intruder once again to compromise the administrator account credentials and then permit telnet access to the server as can be seen below.
This was another area that was glossed over a bit, but the instructor took the time to discuss real world impact and examples of some of these issues. The previous lab on using SQLi to extract credentials from the database also spoke to this area as well so it’s not like the students were not properly exposed to the concepts. This is one of these areas where the advice tends to be to salt passwords but frequently there is no mention of how to manage salts or what encryption functions to use. The instructor took the time to engage in dialogue with the students on this area and there were some good takeaways not explicitly covered by the course content. There were other examples of this sort of things throughout the course and if the instructor I had always teaches this course then perhaps it’s not such a big deal.
I don’t do a lot with IIS web servers so this was a module that I learned an interesting trick using trace.axd to access sensitive information in server logs. Depending on how frequently I find this file exposed in the future it may be one of the really great tricks I take away from the course. This is exactly the issue I described a bit in my post on the Toshiba MFP vulnerabilities a few months back.
There were 2 labs here, the first involved using trace.axd to harvest a session ID and then leverage Paros (I used Burp) to intercept a request and hijack the session using “Cookie: ASP.NET_SessionId=XXX”
The second lab involved information leakage from web application logs and injecting arbitrary strings into the logs to confuse CSIRT responders. Anytime you can leverage an attack to write to a server there is usually lots of fun to be had.
This module consisted primarily of “Use TLS, don’t be a retard” and talked a little about Firesheep. I think most of us know we should be doing this but I continue to see many sites not using SSL at all, which is one reason I’ve been finally migrating from Yahoo! mail to my own personal domain mail that’s hosted by Google Apps. it still amazes me that yahoo! email is all over vanilla HTTP. One thing that is also really interesting to me is how many web services are transporting sensitive data unencrypted because nobody can see the lack thereof in their browser. Mobile apps do this all the time. I really wish more of these courses would discuss web services but I have yet to find any that spends more than 5 minutes on the topic.
This module talked about unvalidated redirects and forwards and I think many of us have seen this issue in one form or another as many sites offer open redirects. This is where the 1 lab from this section focused. Outlook Web Access had this issue for a long time where you could send someone a link to OWA and the redirect would trigger when they logged in to take them to whatever evil site you wanted. There are many examples of this found on the internet today. What’s not so easy to spot are unvalidated forwards within the site to sensitive locations like an admin.jsp page. Thankfully this course covered the issues well and provided some advice for defending against such issues.
Web Application Security Auditing
This last section before wrapup with the conclusion was a module on web application auditing. This section really did not go into any methodology at all which I think is probably the biggest failing of the course. There was a single lab which consisted of automated scans using Paros and Acunetix. There was no mention of how to tune these tools for things like excluding the page for account deletion or logout or defining scope or how to deal with other issues that arise from using automated scanners. It was made clear through the lab how to work through discovery when the site has not been fully spidered and included some manual methods to help the scanner operate more comprehensively. That being said, I found this section to be more of an afterthought than anything else and it should probably either be removed or rewritten.
The exam was pretty straight forward and was well written. The questions were all formulated in such a way that understanding of the material was required to answer the question. It was not a simple regurgitation of what tools would you use for which attack like many other lesser certifications. Several of the questions required you read and understand the code being sent in an attack string and understand the implications on the security of the site. The exam is 50 Multiple Choice or True/False questions long and you only need 50% to pass. I would not consider it a difficult test but I don’t know many employers asking for CSTP either so it’s more of a validation that you understood the concepts in the class.
My Own Conclusions of the Course
The biggest win here was the instructor. Fishnet has a really strong instructor for the course and I took him off course in my typical way with all the annoying questions I ask. He managed to come back with an answer almost every time or if he couldn’t answer the question we were able to work out an answer with some side research on the topic.
The next thing I really liked about the course was chaining attacks together to achieve an objective and the use of a realistic application to leverage attacks against. This was huge in achieving credibility for the courseware and helped in not just delivering information but helped the student gain knowledge. Sometimes I’m attacking a problem and I know theoretically in my brain some piece part of the solution but being able to practically apply the knowledge to combine techniques in this way is very valuable to me.
This is a very lab driven course. The instructor fleshed out much of the missing content with his own experiences and knowledge but the bulk of the learning here was derived from hands on hacking. That’s how I learn and I’ll wager most of the rest of you do too.
There are some missing components of this course but it’s a 2 day class. I’d like to see this extended or perhaps take the CAST 3 day course but it’s not currently being offered in the US as 7Safe has not gotten the exposure here yet. So next time you are talking to your Fishnet rep, tell them you want to see CAST and more 7Safe courses in the US. You won’t be disappointed!
My rating 8.5/10