Sunday, May 17, 2020

#SecurityStories: Using OWASP Juice Shop for Teaching

Have you heard of OWASP Juice Shop? It's a project that's very dear to me and helped me massively over the last years.

Johannes Seitz was the first one who introduced me to this intentionally vulnerable application used to practice security testing hands-on. He facilitated an open space session at TestBash Munich 2017 with it, and I got hooked. Dan Billing also used this great application in his tutorial at Agile Testing Days 2018. I personally used Juice Shop for security testing workshops at my own company since beginning of 2019.

What I like about Juice Shop is that it's a full-blown application. It's working, and it's vulnerable. We can safely practice lots of techniques, whether manually or having automation support us. You're also not alone, it offers guidance in case you need it. What I love most of all: it's based on gamification, offering many challenges on various difficulty levels. The first challenge itself is to find the score board to get an overview on which tasks are there and what's your progress! Although I know that attackers would approach a productive application differently, the gamification approach is very appealing to me. It's simply fun and draws me further from one challenge to the next.

This kind of gamification also worked well for the people I've had in my workshops, introducing them to security testing. Challenges can be taking time and be quite frustrating - yet when you finally solve them, the moment of epiphany and heureka is invaluable and very memorable. In these workshops, I've also seen people learn how to make more use of tools when testing, like the browser's developer tools or REST clients. Despite them having used these tools before, Juice Shop triggered them to discover more possibilities and features they weren't aware of yet. Also, people shared lots of knowledge on how applications are built, which assumptions we make, which approaches we take.

My personal challenge this year is to tell #SecurityStories, so I thought of using Juice Shop again for teaching. Parveen Khan is currently on a testing tour and asked me to join her for a session. She knew about my #SecurityStories challenge, so we thought it's a great match to pair on security testing. Once more, Juice Shop it was.
I believe that pairing on Juice Shop challenges (or the like) will result in deepening my own understanding by sharing the concepts and approaches I've learned.
I know I'll have succeeded when my pair learned 3 new things from me.
Just around that time, a new shiny Juice Shop version got released! Perfect. In our pairing session, I helped Parveen set everything up and we also tackled the first challenges together. As I already knew the solutions, I held back with my knowledge not to spoil the experience for her. Instead, I led her through only nudging in certain directions, waiting for her to ask for hints. It worked! The first challenge was the hardest - it's a whole new application to get to know after all. Once getting the grips with Juice Shop, Parveen solved the second chosen challenge a lot faster. It was really fun doing this together with her! At the end, Parveen shared with me what she learned from this experience hat was completely new to her.
  • She knew how to look at information in the browser's developer tools, yet now she learned that she can also do something with it and how powerful these tools really are.
  • She always thought that security testing needs a hacker mindset and JavaScript knowledge and therefore concluded that she can't do that. Now she saw she can take first steps into security testing herself indeed and solve challenges to learn more.
  • She shared she never had much interest to learn about security, despite knowing that it's important. After having fun with Juice Shop, she's now open to learn more.
  • She learned that she could do security testing together with another person to have more eyes on the problem which makes things easier and more interesting.
  • She realized she forced herself to think in a different way, and she will always remember that. It was great to get through the experience without me giving away too much.
So I'd say, my experiment worked out well! This experience taught me once more how useful Juice Shop and security testing in general is to teach knowledge that also helps us in everyday testing life: understanding how applications work, what we need to check for under the hood of a shiny interface, which tools can help us, and more. Security testing is combining so much knowledge, learning about it is super useful for anyone involved in product development. This fit very nicely to my findings from doing security testing workshops at my company.
I could have stopped there when it comes to Juice Shop. However, there's something that bugged me. Despite knowing Juice Shop for quite a while, and frequently using it for teaching purpose, I haven't solved nearly as many challenges myself as I would like to. I decided that now's the time to change this. So here's my next experiment.
I believe that working on Juice Shop challenges, alone or with a pair, will result in increased confidence in my own skills.
I know I'll have succeeded when I've solved all challenges below 5 stars.
This fits well to what I learned during the AppSecDays: I need more hands-on practice. Off to new frontiers! Want to pair with me on this one? Feel free to reach out

Thursday, May 14, 2020

#SecurityStories: OWASP Virtual AppSec Days

When I heard that there will be a virtual conference by OWASP, hosted at a time I could easily join after work, I simply had to sign up. It fit too well to my personal challenge of telling #SecurityStories to let this opportunity pass by.
The OWASP Virtual AppSec Days April 2020 consisted of a free mini-conference with talks as well as two days of training, split into four hours each day. They also hosted a virtual capture the flag competition, yet I felt not ready to go full in yet.

The Talks

On the first day, three talks were presented in a row. In case you'd like to watch them yourself, their recording is available on YouTube.
  • "Building and growing an application security team - lessons from a CISO perspective" by Michael Coates. I liked this talk a lot. Nothing was really new to me, yet these important messages still need to be heard.
    • I keep finding lots of parallels when it comes to security testing and any kind of testing. In his talk, Michael made clear that it's not about eliminating all security bugs, and rather about building up risk management. There's always a healthy balance of risk in every organization. Fixing every single bug is not worth it, the effort is too high; yet we want to fix the most important ones. Sounds familiar? Here's another one: The goal is to empower business to move fast and make informed risk decisions. It's important to have both technical and business understanding. Secure code empowers the limitless exploration of technology and innovation. And another one: Put security in the hands of teams themselves instead of a security team approving something. This moves ownership of risk to the teams. If the teams know that they are responsible, it really changes their mindset. I can't agree more.
    • According to Michael's experience, a successful application security program uses a "Paved Road Approach", offering the teams an easy and secure route where they get support, and empowering them to take this route. They are not forced to, yet the incentive is high and teams usually prefer the easy way. If security issues are found, however, he advocated for taking the hard way and fixing the fundamental root cause instead of the symptoms. Make sure they cannot occur again or at least people get alerted if they do. To operate at scale, refrain from building your own solutions and rather integrate trusted existing systems. If you have a central security team, they don't own the risk, the single business units and product teams do - so they need to get the incentives to care. Last but not least, a successful program needs to be focused, prioritizing the most important risks. Every time you shift focus, you're saying that this thing is more important than what you did before.
    • When it comes to building a successful application security team, Michael emphasized the importance of senior team members letting go of easier problems and instead training less experienced people to solve them. Allow your juniors to grow, and have seniors focus on senior problems. Overall, creating a great work place where people get training as well as challenges is key. Having real one to one conversations, finding out people's motivation, encouraging them to blog, speak and contribute to open source are all parts of having the people create a great work place. We are the result of an amazing team around us.
  • "Certificate Revocation: Past, Present, Future" by Mark Goodwin. This talk taught me more about certificates as well as concepts and mechanisms I wasn't aware of before. Lots of approaches that are waiting to be explored further.
    • Certificates allow you to verify the identity of some entity, for example of a website. You trust certificates because some authority is satisfied enough to issue one, your browser trusts the authority enough to honor it, and you trust your browser to make good trust decisions. You can also trust that things, however, will go wrong. What if the site's private key is stolen? What if an authority mis-issues a certificate? What if an authority has its systems compromised?
    • Let's talk about remediation. There are certification revocation lists (CRL) you can check, yet it's hard to keep in sync with them. There is the Online Certificate Status Protocol (OCSP) where you can check just in time whether a certificate is still good, yet connection time causes latency. To work around this problem, there are methods like OCSP Stapling to bundle these requests, where Must-Staple is probably the best known way as of now.
    • What to do to prevent that things go wrong? HTTP public key pinning (HPKP) was used for quite some time but then phased out as it was open to abuse. Then there's the Certificate Authority Authorization (CAA), a DNS resource record mechanism which you can use to say that certificates for resources of a particular domain can only be provided by a particular certificate authority.
    • Finally, what about notification? Certificate Transparency (CT) is a cryptographically assured mechanism to allow clients to find out what certificates have been issued for a particular domain. Browsers can require certificate transparency. This way, after a certain date, all trusted certificates will be known.
  • "OWASP Top 10 2020" by Andrew van der Stock. An interesting look behind the scenes for one of the most commonly known OWASP projects!
    • If you haven't heard about the OWASP Top 10 yet, they are really worth a read. Although this document is sometimes mis-used as a standard, it's first and foremost meant for education purpose, as Andrew emphasized. It is a lightweight, developer-centric resource to raise awareness. An update was planned to be released in 2020, yet due to the current crisis situation we will have to wait for another year.
    • This talk allowed to have a look on how the top 10 are compiled. Andrew shared their difficulties to collaborate with organizations to obtain data, to perform data science and analysis, and also to get the desired industry attention and mindshare upon releasing a new version.
    • The group behind this project are collecting evidence from as many sources as they can. For the upcoming version they are aiming to improve their data science efforts as well as the community-driven qualitative process, having the community support the included risks. In addition, the project team is thinking about possibilities to allow anonymous data submissions. They also want to design a better look and feel, and offer more ways to consume the information to reach even more people.
    • What we can do to help is to donate data, help with the data analysis and data science part, respond to qualitative surveys, or peer review the content. If you can help, reach out to the project or any of their leaders.

The Training

Lots of different trainings got offered, yet in the end I opted for guided hands-on practice and picked the "Web Application Security Essentials" training by Fabio Cerullo. I cannot share the training content, yet I can share what it was based on - as I definitely recommend you to check it out for yourself.
  • The training focused on the first five of the current OWASP Top 10: injection, broken authentication, sensitive data exposure, XML external entities (XXE), and broken access control. We learned about the concepts behind as well as good practices to mitigate these risks.
  • To practice exploits and techniques hands-on, we used an application that was designed to teach them in lessons: OWASP WebGoat. The easiest way to have everything set up was to run the all-in-one WebGoat Docker image.
  • To help solve the exercises included in this application, we used the developer tools of FireFox or Chrome, as well as OWASP ZAP as a proxy. I got to know the FoxyProxy browser extension which helped easily switch proxy configurations.
For me personally, the training was great to observe myself and evaluate my current skills. For some techniques I understand the concept, yet I still need more practice to figure out a successful attack quicker. For some exploits, I still struggle to get my head around them. And then there are some challenges that feel way too easy and like everyday business. Things are relative, and practicing on my own in a guided manner made me realize once more: it's just a matter of practice. What I feel is easy, I've done a lot more often, even as part of usual "everyday" testing. The more tricky things are not more tricky themselves, I've just done them less and therefore it takes more time to get the syntax right or think of everything to consider.

I really like what Fabio emphasized at the end of the training. Security scanners are great tools that will check for certain rules, but they cannot help you to find flaws in your business logic. If you're serious about security testing you need highly skilled pen testers who also look at the business logic of your application. Testing is where imagination can take you. You see the response right away, notice a changed behavior in the application and see if you're on the right track. Proxies are useful to learn more about the application and get more information on potential issues, especially when developing or testing an API.

The Lessons

You may have noticed I didn't formulate a hypothesis for this experiment; I just jumped at the chance. Well, I decided to let it count as part of my #SecurityStories nonetheless. Yet if I would have had a hypothesis upfront, it would have probably looked like this.
I believe that attending the OWASP Virtual AppSec Days will result in new knowledge and inspiration.
I know I'll have succeeded when I learned about one new concept and had a new idea for another learning experiment in the area of information security.
Attending this conference was a great experience. It was tiring to do so three days in a row after work, yet I had the opportunity and don't regret I took it. Once more, I've learned more theory, I've got more tools in my tool belt, and I've practiced more. Inspiration for another learning experiment? Although I'm not yet sure whether I will pick it up or not, going through the other lessons of WebGoat would definitely be worth it.

Well, I can only hope you also learned something new in the area of information security from this post. If that's the case, then please leave a comment or drop me a direct message on Twitter. Let's continue learning!

Sunday, May 3, 2020

#SecurityStories: Ethical Hacking Courses Revisited

My first contact with security testing was back in 2016. My company offered us a Pluralsight account so we could benefit from their vast course catalog. As I had been inspired to learn more about security, this felt like the perfect match. I watched several of the security related courses offered on Pluralsight back then.

Four years later, Pluralsight granted everyone free access to their offer throughout April. This made me wonder: what if I revisited those courses with the security knowledge I have today? This felt like too good a chance to let go, and led me to the following hypothesis.
I believe that following parts of Pluralsight's ethical hacking courses will result in surprising knowledge and deepened understanding.
I know I'll have succeeded when I made a new connection of existing knowledge and realized that pieces of the puzzle were falling together.
What I remembered from 2016 was that these courses were worth it. Even though I had limited knowledge back then, they helped my gain a lot more awareness and insights into this vast area of expertise. Rewatching these courses now four years later, having a lot more security knowledge than before, was absolutely worth it as well. I found I had a better understanding these days, and I rediscovered aspects, techniques and tools I simply didn't memorize back then. If you have any chance to get a Pluralsight account (or make good use of the ten days trial) and you're in for learning more about security, these courses are top-notch in my eyes. Very informational, very well explained, able to follow also with limited previous knowledge - and you can also follow along hands-on if you want. This time I managed to watch the following courses, which represent about a third of the ones available.
While I can't and don't want to spoil all the course content, there are several points that frequently came up. Pieces of knowledge that I (re-)learned, that re-established or created new connections in my brain, and that are now (hopefully) etched on my memory.
  • It's hard to be an ethical hacker. 
    • To be able to review systems and infrastructure from a security standpoint, to test the current solution, create better solutions, and retest them, you need a lot of knowledge and skills. You basically have to be an expert with operating systems, programs and networks, proficient with vulnerability research, mastering hacking techniques, have a lot of software knowledge in general, be able to think outside the box, have great communication and management skills, lots of patience - and more. This quote from Dale Meredith really fits well: "Practice builds knowledge, knowledge builds confidence."
    • You have to follow a strict code of conduct. You need explicit permissions in writing before you can do anything. This includes your own employer! For practice, there are lots of intentionally vulnerable apps whose purpose it is to hone your skills. Yet whatever you find in real life, even by coincidence - report it. In addition, when it comes to penetration testing, a major part of the work consists of documentation. So document everything, report everything. Yet make sure to choose a secure medium to store findings, and a secure channel to report these findings. It's way too easy to do the job for the attacker and deliver all information on a silver plate.
    • You can't stop attackers, so the job is not to stop them but to discourage them, misdirect them, and slow them down. Time is on the attacker's side, not the ethical hacker's. An attacker only needs to find one opening, while being on the ethical side of things you have to find all of them and also make sure they're covered.
  • It's a lot about information gathering. Really, a lot.
    • The so called reconnaissance phase is probably the biggest and most important in the endeavor to penetrate a system. There's so much to find out about applications, infrastructures, organizations, individuals, and more. Much of the information is just freely and publicly shared, completely legal to retrieve, and easily accessible for everyone. Just using a search engine like Google can reveal lots of vulnerabilities; especially when you know what to look for and how to feed the advanced search options. So many places can give valuable information to attackers, among them also your own website (job offers are a great source!) or what employees share on social networks. The horrifying thing: this is just the tip of the iceberg, and you can find a lot without investing much effort. 
    • If attackers find interesting information, they might go further and start scanning your networks, i.e. looking for "live" systems and identifying them. Using a bunch of different scanning techniques they can discover what ports are open or closed, whether those systems are running any services, and more. They basically probe the target network to find out as much information as they can about the system. All this adds to what they already found during reconnaissance. Oh, and - we are probably being continuously scanned. Remember, time is on the side of attackers. Drawing out a network can help detect holes and remember them on the long run.
    • Fingerprinting helps as well to identify further information. Operating systems usually behave in certain ways that let you make conclusions about the system. You can determine the host via sending well-crafted packets, or use banner grabbing to check for welcoming messages that already reveal information about the target system.
    • When it comes to web applications - well, they reveal way too much information by nature already. You can see the whole frontend source code, all the JavaScript executed. If client-side security constructs are in place (which you shouldn't have by any means!), like password constraints, they are very easy to discover and work around. Browsers nowadays offer protection for several attacks. Still, there's a lot they simply cannot defend against, like parameter tampering (any input from client side is untrusted data!) or persistent cross-site scripting as then the malicious data is already in the database.
  • Ignorance, laziness and misconfiguration are way too common and make things way too easy. How many times have we just copied over a solution we found on the internet? How many times have we just made use of a new framework without a thorough security review of its source code? How many times have we even considered that this could be exactly the reason for its existence? How many times have we just kept the default configuration for applications, frameworks or servers; not to mention default passwords? Well, we all know the answer. It's hard to accept the truth - and frightening at the same time, as we can assume how many other people building products probably are sharing these feelings.
  • There is a plethora of tools out there to help all sides. As "plethora" is one of Dale Meredith's most favorite words, I simply had to include it in this post. But seriously, there's a tool for everything. Most of them are completely legal, as they also help for many other absolutely ethical and valid purposes. Yet as it is with any tool, they can be used for good and evil and all the shades of gray in between. Let's list some examples, yet be aware that they are not even scratching the tip of the iceberg. There are proxies like Burp Suite, OWASP ZAP or Fiddler. There are network tools like Nmap or netcat. There are website crawlers or copying tools like HTTrack or Netsparker. There is the Google Hacking Database or MetaGoofil for reconnaissance. When it comes to web apps, the browser's development tools might already be your best friend. To quote Dale Meredith once more: for each purpose, "pick a tool and learn it, love it, use it."
  • Social engineering is way too easy. People are usually the weakest link. Convincing them to reveal information does require social skills, yet with enough confidence these kind of attacks are scarily often successful. From looking over someone's shoulder to following someone holding the door into the building. From searching your trash (yes they do) to impersonating internal IT. From phishing attacks to distressed calls for support. This makes you think of your own behavior a lot. I haven't even re-watched the whole course on social engineering, yet in all the other courses this technique was referred to at least once. In the end - it's still all about the people, and our education is crucial.
  • Seemingly minor risks can be turned into full blown exploits. It's all about the context and how things can be connected. One information can help you to another, one exploit can lead to another. Again, time is on the side of the attacker. It's way too easy to discard an issue as too minor, not important, not revealing interesting information, simply not posing much risk. But - is it really? Let's not make this too easy.
(By the way, when reading all of the above - do you also see the similarities to testing in general?)

There's so much more I learned watching these courses. If you have the chance to check them out, I can only highly recommend them. I've only watched 26 hours of currently overall 79 hours of course material on the Ethical Hacking (CEH Prep 2018) path. I am eager to watch them all at some point. Some day I will.

All this really made me think even more about security in all areas. Not only when developing our application or interacting within an organization, yet also as an individual. In my eyes it's not about getting paranoid, but about stopping being careless. I wouldn't leave the door to my apartment wide open, either. That being said - I just revealed I'm living in an apartment. You never know what piece of information can help attackers. For example, I got a lot more cautious around sharing photos from my living areas on the internet; I wouldn't want to reveal my address there as well, and it's probably way to easy to conclude to it anyway. Well, doing a thorough check on my own behavior a well as the applications and infrastructure I'm using - that's definitely on my list as another experiment.

As always in this series of #SecurityStories: if you learned something new in the area of information security from this post, please let me know by leaving a comment or sending me a direct message on Twitter. Your feedback is much appreciated.