Wednesday, May 9, 2018

Testing Tour Stop #7: Pair Penetration Testing with Peter

Continuing on my testing tour, I had the pleasure to pair with Peter Kofler. The first interesting thing was that Peter does not identify as tester, but as developer. He read about my tour and was intrigued by the approach. He had gone on coding tours himself before as well as did a lot of remote pairing sessions, but normally longer sessions on programming. We were both curious what we would learn from a common testing session of only 90 minutes.

My original experiment was designed to pair only with testers of other teams or companies. So what about having a developer this time? Well, I decided to stick with what I preach: titles are just words, and roles are just words as well. We should not let them limit ourselves but contribute where we can provide value. So from my point of view, nothing speaks against pairing with another one interested in learning more about testing.

Our Topic: Security & Penetration Testing

When writing back and forth on Twitter discussing potential topics to pair on, we decided to go with security and penetration testing in the end. A huge area of expertise which is so important and which we both wanted to learn more about.
When exchanging ideas, Peter suggested to target Dan Billing’s Ticket Magpie, an intentionally vulnerable application intended to practice penetration testing. A great choice! We went for it and simply ran it locally in a Docker container, which provided us a perfect playground we could freely explore without worrying about breaking anything.

A few days before our session, Peter came up with a quite typical question I received from several pairing partners already: "Shall / must I prepare anything for our session?" I answered as always along the following lines: "You don't have to prepare anything (though I won't hold you back), I'll prepare the basis and we'll find our way together during the session." As a result of this brainstorming discussion, Peter came up with the idea to go for the OWASP Top 10 or try a tutorial on security testing. As I learned about Burp Suite in Santhosh's security testing tutorial at Agile Testing Days 2017, but never used this tool myself, I suggested the idea to learn more about it and see how far we would get with it. All in all, we had some ideas to start with, which was good enough for me.

A Successful Learning Session

We started the session with a short personal introduction. We had only exchanged some messages on Twitter but had never seen each other in person, so we needed a common ground to start collaborating from. Afterwards I explained the high level structure of my pairing sessions and that I'd like to pair the strong-style way. Peter shared he was not the biggest fan of strong-style, but would be willing to give it a try. Only when I started my mob timer application, he realized I really meant to do strong-style with frequent rotations, and shared that he normally rather uses Pomodoros where you always have a break after a defined period of time. Interesting idea for one of my next sessions! Well, we started with a rotation of four minutes but then quickly gave up sharing remote control and stopped the timer, having me keep control and trusting our communication to balance our power dynamics. As both of us already had sufficient experience with pairing, this worked out really well for us.

We had several options to start attacking Ticket Magpie.
  1. Blackbox: Explore the application looking for vulnerabilities in order to penetrate the system.
  2. Whitebox: Check out the source code and look for vulnerabilities.
  3. Tool support: Use tools like Burp Suite to discover vulnerabilities.
We decided to start with the blackbox option and see how far we got. We said we could still move on to the other options later on.

I don't want to spoil the fun of detecting the exact Ticket Magpie vulnerabilities on your own or show an easy way how to do it. I can only tell you it was indeed a lot of fun! We started out with the mission to get user access to the system, at best as an admin. And we did! :) We considered ways how to get more information from the database, and decided we would use tooling for that. We postponed it for later.

We then focused on getting access to the actual passwords, and found it was indeed feasible. Instead of mere guessing, changing parameters and sending requests one by one, we now really wanted to benefit from tooling. We experimented with Selenium IDE to record a request to quickly repeat it (but we couldn't find a way to insert values from file input), curl (but we found we were missing the required parameters to provide), and Postman (we thought about the tool's pre-request scripting functionality but didn't try it). In the end we only ran out of time due to lack of tooling knowledge.

Throughout the session, we both did some research which often provided the next idea to try. Some of the sites we found useful were the following:

Retrospective? We Wouldn't Have Done It On Our Own

From time to time, we would stop each other from going to fast or in the wrong direction. I really appreciated Peter asking me at the end of our session whether I had felt dominated by him as he learned he sometimes tended to do so. Truth is, I have to actively hold myself back sometimes as well not to dominate the other one. In our session I did not have the impression that one dominated the other, and neither did Peter. Great. In general our collaboration was really smooth, although I was cautious about it in the beginning as we did not know each other. We didn't stay at one point too long or got stuck.

It was really cool to see the practice application Ticket Magpie. I really liked the progress we made, only in the end I had the feeling that we turned a bit in circles. However, I have to agree with Peter's remark that it was also really valuable to see which tools do not help in certain situations.

We found that both of us had taken notes during the session and both of us needed them to structure where we are and where next to go. We decided to share them in a Google document and use them as starting point for our next session - as there indeed will be a next session. We already agreed on a date for it. In that next session we'd like to improve actively pausing together from time to time during the session, do note taking together, and go from there together. We agreed to not set a fixed goal upfront, just like this time; we both felt doing so would limit our exploration. As it was clearly communicated like this in the beginning, this was fine for both of us.

All good, but the main thing is: We both thought we knew nearly nothing around security. We both found we indeed did know some things already, more than we thought. We might have been able to do the same on our own, it might have just taken more time. But although we both wanted to learn more, we just didn't do it on our own. This might be the biggest benefit of pairing: Together, we tackled the topic, learned about ways to penetrate an application and practiced it hands-on in a safe environment. What more could we want?

Thank you, Peter, for a great session. I'm already looking forward to our next one, diving deeper into security and penetration testing!

No comments:

Post a Comment