Introduction

Oh hey it's me

Hi, my name is Jason, I’m currently taking 41151 Summer Studio B 2019 for the next four weeks. I’m in my second year student enrolled in the Bachelor of Science in IT course, with an Enterprise Systems Development major and a Network Security minor. I am extremely passionate about both software development and cyber security, I think that both disciplines offer a great creative outlet that allows me to challenge myself by solving problems, whether they’re security or software related.

As for my motivations for doing this particular studio, I chose to do this because I wanted to learn more about the cyber security field, in particular finding out more about what is involved in a security role in industry, the baseline technical knowledge required to be even considered for such roles and overall I wanted to expand on my technical knowledge about more than just web-app based hacking.

Previous association with the UTS Cyber Security Society has given me a wealth of information about practical security techniques, but I find that more often than not, my knowledge of certain subjects can be deemed too ‘high level’. I definitely want to be able to understand intricate details of exploits, and in particular learn more about the ‘low level’ techniques involved in binary exploitation/reverse engineering. The opportunity that this studio provides has already demonstrated itself in he first week with a visit from Rob Mitchell from the GitLab security team. The insight he provided in his presentation was personally very valuable to me, in particular his experiences in the field and his advice on how to get a foot in the door of the security field.

What do I want out of this workshop?

  • A portfolio that I can use to find employment
  • More in depth technical knowledge
  • Gain enough experience/knowledge to start hunting bug bounties on the side
  • Actually get employment in security role

Week 1

SLO 1: Engage with stakeholders to identify the problem

After the presentation with Robert Mitchell, a member of the security team at GitLab, it became evident that the element of human error is a common and substantial factor in almost all security breaches. Although the specific level of human error varies, the most prevalent problem is that people just don’t know about whether the products they are using are misconfigured, or about the different ways that malicious actors use everyday situations/circumstances to their advantage, for example sending emails to executives of a company whilst posing as the CEO of that company in order to get a malicious file opened on the internal company network.

Just the excuse of “We didn’t know about that” in the event of a data breach just isn’t good enough anymore, companies should be active in their defence of user data and should employ a wide range of methods to secure their infrastructure from attacks. Methods of attack against systems seem to be developing much faster, and it’s unfortunate but in most instances, it seems that a data breach has to happen or an attack has to succeed so that we’re aware that such an attack is possible. The problem of human error and its role in security breaches should be minimised as much as possible, this seems to require that employees undergo mandatory education courses that inform them about possible attacks and safe work habits on computers. Third party system auditing, whether it be a bug bounty program or a penetration test by a consultant organisation is vital in ensuring that a companies system is secure.


SLO 2: Apply design thinking to respond to a defined or newly developed problem

Our presentation focused on aspect of ‘Bug Bounties’, specifically what they are and what you should expect when implementing a bug bounty program as well as a use case that demonstrated how a bug bounty program could be beneficial to an organisation. After Robert Mitchell’s presentation, human error was identified as a common factor in most data breaches, however most of the time, people aren’t acting maliciously, they are simply unaware of how vulnerable they are, and the ways that they can fall prey to a malicious actors actions. It is also worth nothing that software misconfiguration is also a leading cause in data breaches, fact of the matter is that, most organisations find out about these misconfiguration only when whey become breached.

Applying design thinking in this instance, people would rather not have their data stolen and released, it seems that auditing of systems needs to happen in order to have a bias free guarantee that an organisations systems are safe. Any audit that happens should not have organisation staff involved at all, bias could be a factor that causes staff to look over potentially devastating security vulnerabilities that someone who has no investment in the system might not overlook.


SLO 3: Apply technical skills to develop, model, and/or evaluate design

When my group the Super Secret Hacking Club (SSHC) decided upon bug bounties as a topic of investigation for our presentation to the class, we mainly used the BugCrowd and HackerOne bug bounty platforms as examples to outline what bug bounties are and what is involved in hunting for bugs. Browsing both these platforms revealed the types of vulnerabilities that bounty hunters were discovering and getting compensated for finding.

In general, these bugs were web application based, meaning that the organisations websites were examined and probed for vulnerabilities, upon further research, the OWASP Top 10 contained a list of the top 10 vulnerabilities plaguing the web app landscape.

Further examination of these web vulnerabilities allowed me to understand and apply these attacks on the OWASP Juice Shop vulnerable web app that was deployed as a beginner CTF for the class. I was able to execute SQL Injection on the juice shop login panel using the string ' OR 1==1-- on both the email and password fields to login as the admin.

I was also able to leverage information gained from preparing for the Cyber Security Australia Challenge 2018 (CySCA) to complete another challenge, logging on as the admin without SQL Injection. The process I used as follows:

  1. After logging into the admin panel using SQL Injection, I opened up the developer tool and navigated to the ‘Network’ panel. Step 1

  2. Refreshing the page, I looked for the cookie, noticing that the cookies began with the characters ey, I remembered that JSON Web Tokens began with the same characters. Step 2

  3. Copying the token of the cookie, I entered it into the JSON Web Tokens site to translate the contents of the cookie into something readable. Step 3

  4. The password parameter is especially interesting, from previous experience during CySCA, the first web challenge in particular, I noticed that the password was hashed using the insecure MD5 hashing algorithm, using this Hash Cracker that I found online, I was able to obtain the password admin123. Step 4

  5. Logging on with the credentials admin@juice-sh.op as the email and admin123 as the password successfully completes the challenge. Step 5   Step 5.1

So far, I feel quite confident with my ability to complete the objectives of this SLO each week, however I was able to achieve them this week mainly by relying on previous knowledge of certain vulnerabilities and my experiences with them. I would definitely like to learn about other aspects of security, i.e. Binary Exploitation/Reverse Engineering and be able to solve related challenges from previous CTF’s or doing challenges on Hack the Box.

I really want to step out of my comfort zone in regards to solving security challenges, so for next week I definitely want to be able to achieve this SLO by utilizing exploits/vulnerabilities that I am not familiar with, i.e. Binary Exploitation, XML External Entities (XXE) challenges, Remote Code Execution (RCE).


SLO 4: Demonstrate effective collaboration and communication skills

As mentioned above, my group the Super Secret Hacking Club (SSHC) decided to focus on Bug Bounties as our topic of investigation, the presentation can be found here. After presenting this as a group, I felt that we sufficiently demonstrated the potential huge impact of our case study, the Steam CD Key bug, which would have amounted to possible reputation and financial loss, potentially numbering in the millions.

As for my experiences with the interactions in my group, I found that we worked really well with each other, each member of our team comes from a different background, and with this diversity, it allows for more perspectives to be examined and more experience from differing backgrounds all contribute to a more intensive investigation into identified problems. Upon being put together into a group, we made a Facebook Messenger group for faster communication and a team on Microsoft Teams, we utilised both to set a meeting for Tuesday in order to complete and practice the presentation for Wednesday. We also outlined a plan of action with Planner on Microsoft Teams, assigned team members to the action card and set up a checklist to complete.

This presentation didn’t offer much in the way of separation of duties for the presentation, it was more of a all together collaborative effort, in future it might be a better idea to separate and assign individual tasks properly to track the everyone is pulling their weight. Both meeting plans can be found below.

Step 4   Messenger Meetup

The presentation itself went pretty well, I hope that the subject matter was interesting to our audience, which was fellow students as well as Rob Mitchell and the studio leaders. The feedback I received individually was quite good, I performed well and communicated my points across well, although I’m not too sure about how we performed as a group, the time limit for the presentation was 6 minutes and our group went over the time limit by a fair few minutes.

As for collaboration, there didn’t seem to be an emphasis on group collaboration this week in the sense that you only collaborated in the groups you chose for the presentation. Rather it feels like the whole class itself is a group and that the experience that students bring can enrich the experiences of the whole class, in particular, on Friday I enjoyed helping out Junwei and showing Nick how I completed certain challenged on the CTF and on the Natas.

Weekly sprint retrospectives that are held on Friday morning are great, they serve to inform other members of the class of what you’ve accomplished this week, what you are struggling with, how you plan to overcome those struggles and what you plan to do in the next sprint. It helps to see who else in the class has the same obstacles that you do and how they have or how they plan to overcome those hurdles. Personally, I talked about my struggles of making the most of my time and being productive as my main obstacles, and how I plan to have more effective time management strategies in place to mitigate the lost productivity. I felt that I was able to effectively communicate my progress this week at the stand-up, although feedback on stand-ups from studio leaders could be beneficial in ensuring that we are achieving this SLO.

This blog itself can be considered a demonstration of effective communication, although primarily with studio leaders. Personally for me next week, I will be putting a greater emphasis on communication within out group, I feel as though this week group communication was mainly for the purposes of finishing the presentation, but the big picture is that communication should carry on throughout the next few weeks for the purposes of making sure that members are handling challenges okay and whether or not they need assistance.


SLO 5: Conduct critical self and peer review and performance evaluation

Gaining feedback from the studio leader Larry, I was told that there was nothing for me to really improve on, he was satisfied with the way in which I presented our investigation. In my opinion, there is always some room for improvement, I believe that in future speaking slower and with a clearer voice so that I can help the audience understand the point that I’m trying to make with my presentation.

The feedback in this instance was only for individual performances, however I am at fault of making no move to talk to other team members about their performances so that as a group we can grow and improve our presentation skills. It could also be beneficial for studio leaders to make observations about the synergy of groups during presentations so that groups themselves can be made aware of areas that can be improved to maximise group presentation skills. In the coming week, I will be putting a greater emphasis myself on working with my group and making sure that they are improving and have the tools/support to do so.

Personally for me, I think that I should be spending more time reading about exploits and tutorials for how to leverage vulnerabilities, especially those in the OWASP Top 10. This week, I’ve mainly been doing the assigned work and getting my blog up and running, but for next week, I need to be doing more to get the most out of my studio experience.

Documenting more artefacts is something that I need to do more of next week, I don’t think that I’m documenting enough about my experiences during the week and more proof is needed. It seems that the only handwritten documentation I’ve done with regards to my problems, is this failed attempt at documenting how I created my blog (a blog post about how I created the blog is on the way!)

The Best Documentation Ever