March 3 2019, 8:59 PM

This was the final week of the Cyber Security summer studio, and our task was to compile our research and technical development into a final portfolio.

The week begun with a presentation from an industry professional named Ruben, who was proficient in reverse engineering and begun a workshop demonstrating how to read reversed code, how to follow memory and extract information from it.

It was a little difficult to understand at first, and my team mates were being able to solve some of the challenges in a ‘faked’ way by using some translator software online to read line by line to find flags, but I was determined to do it the correct way within the debugger software itself. I used Ruben’s assistance to ask him if I was on the right track[1], and essentially wound up correcting the mistake by following method definitions and reading the gdb manpages and shortcuts, and learning how to use breakpoints properly. It took a little longer getting the first flag than hacking it the easy way, but it made up for the effort because the next flag took me about 30 seconds to find while my teammates still haven’t solved it a week later.[1][2][3]

I also started attempting Carrier again, however even after knowing exactly how to get to the point I was at before, since it was a free instance the server kept getting refreshed, as for whatever reason that specific machine is reset every 5 minutes, and can easily be ddosed as a semi-ddos is part of the first steps to gain an initial foothold.

Final Reflective Statement

Throughout the entire subject, not only were our tutors industry professionsal themselves, and provided constant guidance, but we were also granted the opportunity to meet with industry professionals for different topics. I started with 0 knowledge about the topic at all, and progressed in 4 weeks to being able to take down complicated and medium rated machines on HackTheBox due to the help from them.

I was able to define a set goal that I had planned at the beginning of the semester, which was to improve my technical knowledge enough that I felt comfortable in taking a certification exam such as the eLearnSecurity cert or OSCP, which I considered the problem I wanted to work towards this semester.

Design Thinking in this subject would refer to the topic of enumeration. This is where we use experience and practice in defining our own step by step lists in how to iterate through possible solutions to a problem. Enumeration was a brand new technique that I learned this semester, and through these blogs, writeups and reflections I have acquired new tools and steps that I can add to my list that I can bring with me to the future of my career if I choose to continue Security engineering.

The evidence of this design thinking process can be found more specifically in the writeups for Chaos and Curling in the pwn/hackthebox pages of this portfolio, as well as the formal security report in the previous post. I detail my steps of enumeration and design thinking to identify and respond to a problem that I have not yet encountered.

The technical skills I have learned and demonstrated can be found in my writeups for the pwns and ctf pages of this portfolio. Whether it be methods of enumeration or actual commands/tools used for exploitation, full writeups are available that will outline the use of these.

As part of the consistent delvierables for this subject, we were required to present our week’s worth of findings as a presentation, as well as have a quick 10 minute collaboration at the beginning of each class, in which we share with the class what we’ve done in the week, any progress we’ve made and most importantly the challenges and failures we encountered.

We presented topics based on ROKRAT, which is one of the first posts of this portfolio and has a write up available there; BeEF, which was a group presentation based on a certain security tool that we wanted to demonstrate and explain how it works; as well as some solo presentations.

The majority of communication during this subject however happened via Microsoft Teams, where we have a public chat channel that I used multiple times for assistance and was open to everyone. We also had a team based chat channel that was monitored by the tutors, and we used that for the primary communication of our team.

In communicating this way, I was able to feel a lot more comfortable in gaining information from other classmates, instead of just relying on google or a youtube video, as some students already had multiple years of experience in these subjects and had the answers to a lot of my questions.

All in all, I believe I have achieved my personal goals of gaining enough knowledge from this class in order to have a solid understanding of how to proceed independantly in the future, in gaining some more experience, gaining certifications or perhaps seeking employment in this field.
Early on in the class, the pressure was intense as the pace of the subject was very fast and there was a ton of content that I had to learn, but as I found myself more comfortable, and doing the homework and required tasks on time, I felt that the class became easier and easier to manage, even though the topics themselves were increasing in difficulty. This made me think back to where our tutor Luke described the best way to become knowledgeable in this field, which is to just practice, practice and practice. I definately understand now why that advice was so correct, as even just a little practice has made the content so much easier.

The only difficult part of this subject was trying to adapt the requirements of the Summer Studio itself into the requirements of the Cyber Security studio, as the type of content that is presented in this blog may not be appropriate, or technically correct for the requirements of the Summer Studio. We didn’t have a tangible model, design or plan to create some ultimate project, as our project was just to work every week to increase our knowledge step by step. This subject would be an incredible semester session or Summer session subject, as we have gained an incredible amount of industry specific knowledge in only 4 weeks, that having 12 full weeks could possibly cover a year or more of self study at a slower pace.

Regardless, I believe I wrote up these deliverables to the best of my knowledge and tried not to repeat much, but instead attempted to prove that I have achieved the Summer SLOs by linking to my previous posts and writeups.

Conclusion

I had an incredible time with this subject, and have learned an even more incredible amount of new content. This subject has given me the motivation to continue this type of work into the future, and has gotten me interested in the culture surrounding security. I have always wanted to be a part of this clique, however always found it difficult to approach or find entry.

I feel like I have been able to meet my intended problem statement that I defined earlier in the session, to gain a foothold and clear a path for my learning towards the eLearnSecurity or OSCP certifications and find a job in that way.

Cyber Security - An Offensive Mindset

Progress/Portfolio report Summer 2019

the pwning of teacher

Executive Summary

The popular e-Learning framework used in millions of schools and universities, Moodle, is vulnerable by design to exploitation. A student with stolen credentials or a malicious teacher will be able to upload code via Moodle in a number of ways in the goal of attacking the computer that runs the Moodle instance. This attack can provide full remote access to that machine, including the modification of any sensitive data, as well as the breach of the internal network, in which a number of other attacks can be done to compromise the entire school network.

The compromise of a school network can easily lead to identify theft, fraudulent modification of grades, access to the billing systems aswell as classified data between non students.

This report will identify a method of attack using a custom quiz question which provides initial access to the Moodle server. Enumeration methods will also be identified that allows the traversal of a non-priviledged user into full remote access via insecurities within the database data structures, as well as highlighting the effects of poor password concealment.

Objective

The objective of this report is to highlight the journey of my technical development within Offensive Security, culminating at the 4 week mark in the total exploitation of a machine that is highly rated as a ‘real-life’ scenario.
The machine in question is ‘Teacher’ from HackTheBox.eu, which involves the exploitation of the Moodle e-Learning framework and privilege escalation due to poor security of passwords. Both of these scenarios, especially a poorly secured password are highly prevalant in the every day world, and this knowledge is beneficial for my professional development, as the experience gained here can easily be applied to the real world. This experience will be needed if I pursue my security career in order to identify the low-hanging fruit of threats such as passwords or vulnerable software, and provide solutions to help secure an environment.

I will also explore my methods of enumeration, which is the thought process and order of operations that I have built for myself that will help me in achieving the exploitation of a machine. As I practice on real world machines and vulnerable machines provided by a hobby website, my list of enumeration steps expands, and helps me in achieving an initial foothold in the exploitation. This step is incredibly important, as not only does enumeration grow vertically in number of items to iterate through, but through experience it also grows laterally - using the same steps in different methods, or paying closer attention to the simpler steps in order to find a foothold.

Tools

To connect to the HackTheBox environment, we are given an OpenVPN package which we connect to, esentially installing a tunnel between our machine and their network. The machine that we decide to work on is given a single or a range of private IP addresses, which we can then access as we are inside that network.

kali

The bulk of work done in the exploitation of the machine is within the Kali Linux operating system. Kali is a flavour of Linux specially built for penetration testing and exploitation, and includes about 3000 different tools, scripts and frameworks already installed, a selection of which we will be using.

nmap

Tools to be used are generally classified in different categories, such as auxiliary scanners, vulnerability scanners, exploitation tools and payloads.
Initial work is done using an auxiliary scanner such as nmap, which essentially communicates with the target computer and abuses the full capabilities of the TCP/UDP networking protocols to provide us as much information about the target as possible.

Dirbuster

Another avenue of auxiliary scanning is possible if the target machine is running a web server, as was the case of the Teacher machine. A tool named Dirbuster can be used, which guesses at possible web pages that the server can contain by using a dictionary of a few thousand of the most common web page names (such as index.html, /blog.php, /wordpress etc). Since initially we will have no idea about the structure of a website, we must use a tool like this to identify specific pages of interest. Moodle is an example of a page of interest that would not be found using any other type of tool.

hydra

Since a primary vulnerability was the user password, we can use tools such as Hydra, which acts like a brute force guesser of passwords given a specific dictionary. This attack involved creating a custom dictionary to launch a guessing attack against a password which was mostly known barring some missing characters.

netcat

Once we have scanned the target and have identified potential channels of attack, we can then use a tool that will allow our machines to communicate to each other via that open channel. Netcat is an example of that tool, in which we can send commands back to our computer once we have infiltrated remote access on the target server.

reverse shell

The primary workhorse of this attack was the use of a Reverse Shell. A reverse shell is a program which we can execute on the target machine in clever ways in order to allow access to it from our computer. In this scenario, we have exploited Moodle to incorporate a reverse shell into the Moodle server, which lets us connect to it via netcat as mentioned above, and thus begin to take control of the machine.

Recon

The first step of enumeration is reconnaissance - the art of gathering as much information as we can about the subject.

The very first step I take for recon is run an nmap scan, which will tell us exactly how the target machine appears to the outside world. It’ll tell us about all the channels it’s communicating with, which services it’s sharing with the world and show me potential footholds for attack.

I run this using the command:

1

nmap -sV -v -T4 -A {ip address}

The structure of this command is as follows:

-sV - A parameter that lets us view the Version of any services it is running.
-v - Run in verbose mode, which tells the program to output more information than normal back to us while running, including non critical things like status of the operation, problems etc.

-T4 - Run the program with 4 Threads. A thread is similar to a lane of traffic of a highway, but for the CPU of the computer. This parameter lets us run the command using 4 lanes of traffic, which can help parallelize and quicken the operation.

-A - Attempt to gather information about the OS, including OS name, version, traceroute and potential scripts running

The output of the command may look something similar to this:

Straight away we can see that there is an open TCP port at port 80. From experience, I know that this is the port that HTTP traffic communicates on AKA the tangible internet that we can access via a web browser. This means, if we type in http://10.10.10.153 into a web browser, we should be able to see what that web server is offering us.

Great - We have a public facing website. We can then use some more reconnaissance tools such as Dirbuster to guess at which else comes after 10.10.10.153/ so we can laterally traverse the website without having any knowledge of it.
Dirbuster usually requires a wordlist, which is essentially a large text file containing the most popular variations of page names, and then begins guessing and trying to reach those pages. If it fails, then the web server will simply display a 404 error, which means the requested content was not found. If Dirbuster guesses right, it’ll let us know.

We can use dirbuster in the following way:
dirb http://10.10.10.153 /usr/share/wordlists/dirb/common.txt
This will use the ‘common’ wordlist, which contains maybe 3000 different variations. If time is not a problem, you could opt for an even larger wordlist.
After a few minutes, dirbuster can reveal some interesting information:

Dirbuster has found a moodle page, which is something that we would not be able to find via the front page of that website if we looked.
Moodle is a piece of software running somewhere on that web server. A piece of software that is likely to have vulnerabilities, which it’s now time to scan.

Vulnerability Scanning

Vulnerability Scanning is essentially a research project on it’s own. There are a few main sources of the information, but Google will be the primary source.
Exploit-DB.com is also an excellent source of viewing published vulnerabilities of software and their intended target version. We begin by searching for our potential software flaw using Exploit DB:

There are many avenues of attack we can use, however after reading through each of these exploits they mostly involve getting access to a teacher’s account within moodle. We don’t have an account at all, nor can we create one.

Before we proceed, we need the credentials for a teacher account. We must traverse laterally back to what we have discovered in our enumeration already to see what we missed. At this point, we have only found a website, so we can begin by going back and looking at the website itself.

After a bit of manual trawling through the pages, we can see our first anomaly. This gallery of teachers has a broken picture at the very top left.

This is a cause of investigation. We can view the source code of the website by pressing the View Source button if we right click anywhere on the page. We are then greeted with this:

images/5 is the only image that has an ‘onerror’ tag within the HTML. This means that possibly someone has purposely made this image invalid in order to provoke that error mesage into the console.
If we try and access that image by itself we can see that the browser cannot display it:

I know from experience that if you attempt to open some file that has been renamed an image, or was not originally an image in the first place will cause the browser to give this message. We can then begin forensics of this file to determine what is is.

To begin forensics, we need to download this image, use our Operating System to see if it knows what type of file it is, then view it:

We got the image, used Kali to tell us what it is, then displayed the contents of the supposed text file. We now know that a user named Giovanni has the password Th4C00lTheacha* - with the asterick representing an unknown character.
If you refer back to the previous image where we found the Moodle page - we noticed that the Algebra class was taught by a Giovanni. We now have a potential vector for credentials. As a caveat, this is probably the most unrealistic situation in this environment. However, the teacher’s password could be gathered another way in the real world. As an example, the teacher may write down their password on a post-it note or notebook somewhere and simply leave it at their desk. It would be a trivial exercise to ask for a meeting with the teacher at her desk or office, the secretary asking you to wait near that room while she gets the teacher, then performing some physical recon or lockpicking in, having a peek at the password and gaining credentials in that fashion.

This vulnerability is the human one - A password is meant to be kept secure, unique and not easy to be guessed. This is a rule that is broken incredibly often, and is most likely the cause of 99% of security breaches in the world.

Exploitation

So we have part of a password, and now we need to break in to Giovanni’s account. Since we only have to guess 1 character, we have to map out each possibily of alphanumeric or symbolic characters.

Here we have created a text file with every variation. We can then feed this to a tool named Hydra, which will guess every single possibility of passwords using those characters we have entered in the wordlist.
We can use hydra in the following fashion:

hydra -l Giovanni -P /wordlist.txt 10.10.10.153 http-post-form "/moodle/login/index.php:username=^USER^&password=Th4C00lTheacha^PASS^:Invalid login, please try again" -Vv

Here is this command broken down:
-l - login as user Giovanni
-P - use a Password file, the one we made and called it wordlist.txt
http-post-form - A Post form is essentially just a form that we submit to a website, like a login screen, shopping cart, etc.
"/moodle/login/index.php" - The location of the actual login page in your browser’s address bar.
username=^USER^&password=Th4C00lTheacha^PASS^ - Use the username we supplied at the beginning, then the password we supplied with the file. Since we know most of it, we can just add the ^PASS^ segment to the end of the line
:Invalid login, please try again - The message we see on our screen that indicates failure to log in. Hydra needs to know when it has failed.
-Vv - Enable Verbose level 2, this means we want a lot of information to be played back.

After we run this command, we may see some output like the following:

Hydra has announced a success - We now have a password, and can begin exploiting the Moodle software itself, since the methods we researched involved teacher access.

After logging in and prodding around the environment, we stumble across a page that lets us upload custom questions for a Quiz. This is exactly the page we needed, as previous research has indicated that this version of Moodle has a security flaw which allows a teacher to execute code within the custom quiz creation

Since we have done the research, we can exploit this immediately. That web page suggests we enter the following code into the Question field, and then manually adjust the URL at the top of the browser to execute whatever we need it to:

We now need a method of creating a reverse shell

Without revealing the exact method of opening the reverse shell, we ask the Moodle server to initiate a netcat connection to our machine, and ask our machine to listen for that connection from the Moodle server.
We can begin listening using the following code:
nc -nlvp 5555
The structure of this command is as follows
-n - numeric IP addresses only, don’t resolve the actual name of the website
-l - listen mode. We are asking our computer to listen for a connection
-v - verbose mode. Output more information about the running process
-p - port number. The port number indicates from which channel we are listening on. In this case, we will listen on port 5555, which means we have to send the request from the Moodle Server from port 5555.

We now have direct terminal access to the machine, but as an unpriviledged user. With a UNIX based server, any sort of service must be run by a user account. In this case, the web server is run by the ‘www-data’ account. This account has absolutely no permissions to do or see anything except files neccessary for the web server to operate. We must then use a technique of enumeration called Privilege Escalation in order to log in to the terminal access as another account, preferably another user. This means we need to find some more user credentials

Our first step of terminal enumeration is to see exactly what is running on the machine itself, in the hopes we can find something to exploit. We can run the following command:
ps aux
This command will show us the current processes running, while the aux parameter will let us know exactly where this process is running from, what arguments are run with it and more.

This command, for this scenario, has revealed a Relational Database system named MariaDB. Upon trying to log into MariaDB, we are asked for yet another password.
This is where the human vulnerability comes into play again, as usually, the password for this system is hardcoded on the configuration file. So we can read this file, get some credentials, and attempt a log in in that way.

As you can see, the password was written in plain text as Welkom1!, which we were able to use to log into MariaDB. Now that we are here, all we need to do is view a database table - specifically the table for users, and see if MariaDB has stored the user’s password in an unsecured fashion.
We can write an SQL query like the following:
Show tables - First we need to figure out where the Users are stored via a table name, so we can query the database
We find out that the table is called mdl_user, so we can then query that table to return a username and password like so:
SELECT username, password FROM mdl_user

From the output above, we can see that the passwords were encrypted. From experience, I know that the first few passwords shown are encrypted with a strong algorithm, possibly SHA256 with a salt, which would mean that these passwords are impossible to crack. However, there was a password listed here for a backup user that was only 32 bits long, which I recognized as being possibly an MD5 hash. I used an online tool to confirm my suspicions. This means that password can easily be cracked:

We now have a password for a user named Giovannibak - I assumed this to be a historical record for Giovanni’s details, and hopefully she doesn’t change her passwords much. I tried to log into the machine using her details directly using ssh:

ssh giovanni@10.10.10.153 - Then logged in using her password. This worked, and I was now logged in as a normal account with permissions.

Now we have to begin enumeration again. This time, as a privileged user it’s quite easy. We can look at all of Giovanni’s personal files and find anything strange using the ls command to list all items in our ~ home folder.
I have watched some tutorial videos in the past for unrelated machines, and what I saw remined me of a video I saw called Joker by Ippsec, in which this same technique of priv esc is used.
After looking at the home directory on the right, we can see some backup files, which are regenerated every 30 seconds from some source. The backup file just creates a copy of the current home directory.

The techniques I learned in this video can be used here - We can trick that timed backup to backup a different file by pretending that the folder that the backup process is backing up is somewhere else through the use of a symbiotic link.
A symbiotic link in a UNIX system is essentially a shortcut saying ‘This file is actually somewhere else’. So, I tricked the backup process into backing up the root directory of the computer, which will contain information about the end level of this machine - the administrator.

So then I just had to wait 30 seconds, and that backup file has backed up the entire root directory. From here, I can just open the backup file and read the contents, and obtain the root password.

Mitigation

Mitigation for this attack will include keeping software up to date at all times, especially if it is closely related to other sensitive systems, such as the user database.
A stronger password policy will also need to be applied, as passwords were kept insecurely. An immediate refresh of all passwords via a linux administration system, as well as disabling the setting of the password if it does not meet minimum complexity requirements.

A scheduled process should also be used to ensure that all software is kept up to date, as this particular exploit of Moodle was patched fairly quickly.

February 24 2019, 7:50 PM

This week in our Cyber Security studios, we focused on the actual penetration of real machines, including learning more steps of enumeration, a real-world example of a pentest job via the ApointB web application and an example VM from Deloitte.

In keeping up with this week’s theme, I managed to crack 4 boxes on HackTheBox (Chaos, Curling, Teacher, Irked) and have some significant progress on Carrier. There are 2 pretty easy boxes in there (Curling, Irked) but the other 3 are around the mid level, and I have learned or am learning an absolute ton about enumeration in the progress, as theres nothing too technical or challenging in these boxes, just testing how thorough your enumeration is. A big reason why I didn’t manage to beat Carrier yet is because it keeps getting DoS’d either intentionally or otherwise by other users on the free server, as the first step involves some pretty serious dirbuster and UDP scanning, which I guess takes it’s toll. I managed to get admin credentials on the web app and found a possible vector for remote code execution, but navigating any further just led to timeouts. Sad.

The sheer fact that I was able to do 4.5 boxes in this week alone after having started from 0 when I started this course is a really great feeling. I’m getting positive feedback during class aswell, and having great chats with other students in the class. My tutors and the other students have been probably the number 1 influence on my learning and motivation, and it feels great having them there. I left a quick SFS feedback saying out of the 5 years of Uni i’ve done, this class was definately the most enjoyable. I feel like i’ve been able to manage my time well, but theres still the big hurdle of the portfolio+next weeks deliverables that I haven’t started with yet, so i’ll probably have to be a little more humbled and focused to try and nail that part [5]

As a group, we were tasked to present about a skiddie tool we researched, it’s effects, purpose and how to use it, however I was absent on class on that day. I did try to contribute in a little way by writing 2 slides, but that tool (BeEF) was so interesting to me when I was studying it, and I had a lot to share. I trusted my team to do a good joob regardless, which they did, so in the end it wasn’t all that bad.

In Class

In class on Friday, I was met with Shaun from ApointB, who was happy that I found a bug in their web application that leaked the entire database of users information. He seemed very well versed in the business strategy side of security vulnerabilities, and explained to me that while that bug wasn’t a huge security flaw, it definately needs to be fixed as it creates a big hole in their app for others to do recon on. Shaun explained to me that if some competitor was to find this database, all they’d have to do is call up each of the users in that list, and provide them a competetive offer to the software solution that ApointB offers them. I never really thought about this, and was grateful that Shaun could provide me a little perspective from the business side of things, as a SOC analyst is going to have to provide these sorts of discussions to a client or management in order to justify some work.

I may have surprised Shaun a little bit when I talked about the next attack I tried - I registered the account 'rupport@apointb.com‘ with 0 verification using that email domain, and attempted a session cookie bitflipper attack, in where I tried to bruteforce my cookie to hopefully provide me the session token for 'support@apointb.com‘, which I assumed to be an administrator account. This wasn’t successful, but we still had a chat that perhaps the registration of accounts with email domains that you don’t have access to should be looked at.

Shaun also provided me some new vectors of exploitation to try, including possibly linking a custom domain to the ApointB nameservers and finding a vulnerability in that fashion, as well as closing the possibility of bruteforcing the list of possible admin accounts, as they have all been passworded using LastPass, which cannot be bruteforced.

In conclusion to the ApointB challenge, I learned a lot about business strategy in dealing with security vulnerabilities, my first experience in writing documentation of the flaws that I did find, and what I did try and failed at, and at the same time had a lot of fun doing so. [1][2][3]

I had a crack at the Deloitte VM aswell, which taught be a few things about popular SSL vulnerabilities, especially heartbleed.
My initial enumeration of the Deloitte VM led to some of my SSL enum scripts detecting that the machine may be vulnerable to CRIME, which is a rabbit hole that I willingly dove deep into. It sucked out a lot of hours trying to figure out how to exploit CRIME, as it was more than just a metasploit moduel.

I asked Jai for help, and he confirmed that it wasn’t CRIME, but another one, and that it could be found on metasploit. My 2 options here were Heartbleed and some sort of oracle attack. I assumed it was heartbleed, as when I ran the exploit, a result came back saying [Leaked]. I was a bit confused, as there was no other output, so I asked Jai for help again and he suggested the dump option. I guessed that my metasploit was setup incorrectly, or maybe Heartbleed was another rabbit hole as that option still did not do anything, so I left it for Friday.[4]

In Friday’s class, I asked Jason if the commands I used was meant to work, and he said yes, and told me to dump the output. Again the dumping option did nothing for me, so I looked at the documentation for metasploit. There was a global variable called verbose that I could set to true, so I set that, ran Heartbleed again, and I finally had some output. [4]

Unfortunately, since I ran a bunch of enum scripts on the Deloitte VM, the heartbleed output didn’t show anything worthwhile, so I had to convince it to show relevant output again by launching a POST on the login page, then running heartbleed after. I got my credentials, and getting root after that was easy.

These little things, alongside my breaking of the HTB machines, has taught me to slow down and be thorough on my enumeration and process. I could have rooted the box within a few minutes on Wednesday, but because I rushed straight into it, and didn’t think about anything else once I had the slightest idea of one method messed me up and slowed me down in the end.[5]

I’m not going to write up my walkthroughs for Curling or Irked, even though they did trip me up (Especially root on Irked - I have never dealt with SUID bits before, and that was an interesting introduction to it), as they are pretty simple, but I plan to crack Carrier this week at some point when it’s less busy on the free servers, and I’m sure it’s going to teach me a ton about lateral traversal, a brush up on networking and linux networking administration. I have written a write up on the Teacher machine, and right now am trying to figure out how best to format it in a PDF and password protect it.

1: SLO 1
2: SLO 2
3: SLO 3
4: SLO 4
5: SLO 5

For my Friday Deliverables - I have decided to write up my documentation on 2 rooted boxes on HTB, Chaos and Curling. These writeups can be found here

I also submitted a report for the real world example site, but have not yet written up documentation for it.

February 17 2019, 11:34 AM

This week in our Cyber Security studios, we focused a bit more on web application security and penetration, and having a larger emphasis on the definition of our problem statement and the ultimate shape of our portfolio for this subject.

This week I also started my first professional job, working as an Apex developer, which is the language used in Salesforce CRM products for a small startup, which is an incredibly different environment from working in Help Desk for a law firm generating $1 billion a year. I went from structure, including service management, specialized team management staff, incident management into being thrown in the deep end with an almost unused incident management system. Self study is needed to keep myself afloat in this new job, as while i’m experienced in programming Java already (of which Apex is very similar to), theres still a ton of new concepts that will take my limited time away.

This sudden dissapearance of my free time, time that is meant to be commited to this subject, has cemented the idea that my time management strategy sucks (ie there is none), and the firsts steps I have taken to rectify this is to begin being more vocal in class if I need more insight in what is to be achieved during the week in terms of milestones, as I think a defined list of milestones is how I best operate.[5]

An example of this would be spinning up my old VPS and Software Engineering Project, I had a talk with our tutors for cyber sec and I had the idea that I could use this project, insecure as it is, as my learning experience to achieve my SLOs.

• It’s a web application, so it fits in perfectly with the content we’ve been learning the past 2 weeks
• It wasn’t designed to be secure, which highlighted a problem with our SDLC
• I have good understanding of how the entire thing is structured, so nothing will be blind (I know where all the endpoints are, which saves a few hours (at my skill level) with burpsuite)
• I have root access to the server behind the application, so I can always have a look at logs [2][3]

Another benefit, is that since it’s hosted on a private VPS that I signed a permission form for penetration testing, I could even see if I can pwn my own box as a change of pace.
This is still an ongoing idea, and more talk is needed with my tutors, as they ultimately know whether or not my application is viable or not. [1]

Progress this week

I started off this week (on Wednesday) by being asked to present a Problem Statement we have defined the week prior. I blame my poor time management in this case, as I didn’t have any presentation prepared, and my blog write up was still sitting undeployed on my home desktop. The second way I messed up was misinterpreting our tutor’s instructions earlier on how to define a problem statement. I know now that a Problem Statement is what you can present to some CEO of some company, define a problem, what it’ll affect (his bottom lines), and how you’ll fix it, all under 1 minute.

Since I didn’t have any presentation prepared, I decided to accept my fate and talk about what I studied previously on the weekend, which was about why exactly XSS was so prevalent. You could formulate this to sound like an executive problem statement but I leaned on the technical side.

By sheer luck, I wasn’t asked to present before the break, so during lunch I slapped together a quick presentation and talked about exactly why XSS was so prevalent. It’s prevalent because of DOM-based XSS attacks being the majority of xss attacks, since they rely solely on human failure by clicking on a crafted link, and exploiting raw text within the DOM processor of a browser. It’s much easier to sanitize stored and reflected XSS, but the threat of a DOM based xss attack is there if you have any user-influenced raw text displayed in a browser at all.

So I talked about the why, the how and how to fix it, but didn’t talk much about what it might do, since I mistakenly made this a technical presentation, and assumed the audience knew what XSS does. I still managed to fit in the entirety of my presentation in 2:59 with a time limit of 3:00 so I’m happy with that.[4]

I then studied by tackling a medium-hard level HackTheBox web challenge called I know Mag1k. I did a write up of it here.

It exposed me to a whole new level of exploit involving an Oracle attack, new tools and a new path of enumeration for my further studies.

What’s Next

Next week we’re starting actual box pwning, which means I need to be ahead of it since I’ll also have some crazy work stress to deal with aswell. I need to catch up to Bandit 30, Natas 15 and hopefully pwn the Help machine on Hack the box. I’ll also end up asking the tutors at some point if they have any walkthroughs for retired machines.

1: SLO 1
2: SLO 2
3: SLO 3
4: SLO 4
5: SLO 5

Creating a self-hosted vulnerable web target

Last semester, I completed a Software Engineering project and wrote a Node-js app called Mastodon. It was intended to be a UTS registration portal for booking medical appointments with in-faculty medical staff or medical students, as currently the only way to book an appointment is to call a helpline, which can only be reached during business hours.

The app runs on Node.JS, with no middleware and Mongo for it’s record collection.
After researching web exploitation, and understanding that a vast majority of web-related attacks are XSS based, it has helped me formulate a plan to attack my own system using a variety of XSS attacks and tools.

This can be a strong learning experience, as the app itself was not designed for security in mind barring basic input validation. I have the advantage of knowing exactly how the application is structured internally, and in case I ever get stuck, the app will be hosted on a private VPS that I can share to the class and ask them to rip it apart. I can then check logs to see exactly what damaged they did, and potentially find out how.

Initial research has brought me to focus on 2 main tools:

• Burpsuite, which I have covered a little bit already on my Hack The Box progress
• BeEF, which is a brand new tool I have 0 experience with, and am invested to learn about.

The application was constructed after a mentor reviewed design process and Software development lifecycle, which means that this could potentially be a pretty accurate representation of a lower-tier hosted web app, such as a small time shop or blog, that hasn’t had the privilege of an experienced developer who knows how to properly secure a website.

Are you better off killing insects for your bug bounties?

February 14, 2019, 8:53 PM

A bug bounty is a deal offered by companies in order to tempt security-versed individuals into breaking into their systems with various exploits and vulnerabilities.

A good range of large companies actually do offer these bounties, there even exists some aggregation websites that will list a bunch of currently available bounties, ranging from $50 to $50,000, or some other questionable websites that will buy your 0 days for up to $2,000,000

On the flip side, some bug bounty programs exists, such as the Open Bug Bounty community, that relies on people to post whatever disclosure they want, and a good will system encouraging the affected website to pay the reporter.

Ever since the release of the first bug bounty program in 1995, for the Netscape Navigator browser, there has been a generally positive outcome from these programs. Even the US Government’s Pentagon have their own version of a bug bounty,and in 1 month from April 18 to May 12, 138 unique security flaws were identified, and $71,200 was paid out.

The only reason these bug bounties are successful is because they usually include a Reasonable Disclosure program.
An RD is an agreement between an exploiter and a vendor that the exploit is targeted to in where that vulnerability is only disclosed after a period of time that allows for that vulnerability to be patched.

A Reasonable Disclosure report format can be used for my Problem Statement in an attempt to emulate the documentation that security researcher or a whitehat will need to write up for any piece of work they may be doing.

Sources:

https://www.mcafee.com/enterprise/en-au/threat-center/advanced-threat-research/disclosure.html
https://www.cert.gov.au/critical-infrastructure-big-business/report-incident/vulnerability-disclosure-policy

CTF Training

February 9, 2019, 1:52 PM

For this weeks studio progress, I decided to start upon some CTFs and try and start from scratch. My progress is logged here

Installing SSL on a Github/Gitlab pages static webpage

February 6, 2019, 12:37 PM

Github offers a student education pack, and within that pack also offers 1 free year’s registration on a customized .me TLD alongside a free year of SSL certification.
Sounds great right?
The problem is, Github is not a web hosting platform and only hosts static web pages at a bare minimum capacity, which means theres no real way to use that SSL certification if you’re using Github hosting.

You’re going to have to rely on some other service to provide an SSL redirect for you, which namecheap doesn’t provide.

One such service is Cloudflare, which lets you register a single website for free, which will provide a SSL activated nameserver for your domain, which means for a browser to connect your websites name to an IP address, It’ll ask Cloudflare first.

1. Register an account for Cloudflare here
2. Put your .me or .github.io link in the next box
   

3. Let CloudFlare scan current DNS records associated with the domain name, and confirm if they look correct (Look at your Namecheap panel to confirm)

4. Click the free plan, and continue once you see the new records it will apply

5. CloudFlare will then give you 2 nameservers that you’ll need to apply to your registrar (Namecheap in this case) so name resolution requests will go through CloudFlare services instead
   

6. Now, pop over to your Namecheap control panel Advanced DNS section
   

7. Now, replace every CNAME and A record currenty in (but leave MX alone) with this:

   • A record for @ pointing to 185.199.108.153
   • A record for @ pointing to 185.199.109.153
   • A record for @ pointing to 185.199.110.153
   • A record for @ pointing to 185.199.111.153
   • CNAME record for www pointing to your username.github.io or username.me domain

8. Save your progress, and head on over to the Nameservers section in your control panel
   

9. Choose Custom DNS, and enter the 2 CloudFlare nameservers that were given to you earlier
   

10. After this, you should be all done! Nameserver updates take around an hour, but eventually you’ll be able to access your .me domain with SSL enabled

CVE-2018-4877 and the ROKRAT Payload

February 5, 2019, 5:17 PM

We started our Summer Studio on Cyber Security by presenting our own research on a recently exploited vulnerability, it’s avenues of attack, it’s impact and it’s remediation.

Adobe Flash Exploit CVE-2018-4877

The CVE-2018-4877 exploit was first reported on the 6th of February 2018, and at the time, Flash was still a core component of most browsers.
The vector of attack for this exploit originated via an error in the code module dealing with Media Player handling of listener objects.

A pointer was used in the code to reference a specific memory address. After this memory is freed, and allocated to another pointer, the original pointer was not freed correctly (IE Probably just set to “” instead of NULL), and thus deferencing this pointer points to somewhere within the new allocation, and corrupts the memory contained within the address.

This corruption can be manipulated into pointing instead to valid memory address, which could contain the location of valid shellcode, thus allowing the execution or arbitrary code remotely.

This exploit was leveraged via an Encapsulated PostScript (EPS) object that was found within a word processor document. The shellcode connects and downloads a payload called ROKRAT from an internet source,
disguised as .jpg files.

The ROKRAT Payload

ROKRAT was a HTTP based payload that gathered information about the victim such as keystrokes (via a Keylogger), Running processes, Machine information and
BIOS information.
It also listened to the attacker’s social media for commands, and was able to receive orders by checking the last message on a Twitter timeline.

The orders could be either execute a command, move a file, remove a file, kill a process or download and execute a file.

Yandex, a Russian internet platform was also used by the attackers in this payload as a source of downloadable/executable files as well as the destination to
upload any stolen documents.

Mediafire, a file hosting platform, was used in the same way as Yandex.

ROKRAT’s impact was significant due to being a completely HTTP based RAT. This is in contrast to a typical RAT which communicates via RDP (Remote Desktop Protocol), which can
easily be identified by a corporate firewall and blocked naturally. The 3 social media avenues that ROKRAT used would seldom be blocked by corporate policies, as companies
may have a justifiable business case in the use of these networks.

Forensic Analysis

ROKRAT actively attempted to hide from analysis by running a fake subroutine if it detected a running process that was flagged.

These flagged processes are below:

If ROKRAT detected any of these processes running, then it would generate fake HTTP traffic by sending HTTP GET requests to 2 sources:
. https://www[.]amazon[.]com/Men-War-PC/dp/B001QZGVEC/EsoftTeam/watchcom.jpg
. http://www[.]hulu[.]com/watch/559035/episode3.mp4

These would display a image from an Amazon game called Men of War, whilst the Hulu URL would attempt to stream an episode of an anime called Golden Time.

It is thought that the purpose of this fake subroutine would be to trick any surface level analysis, or network logging done on the host machine.
Sources
https://blog.talosintelligence.com/2018/02/group-123-goes-wild.html">https://blog.talosintelligence.com/2018/02/group-123-goes-wild.html
https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/november/rokrat-analysis/">https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/november/rokrat-analysis/
https://blog.talosintelligence.com/2017/04/introducing-rokrat.html">https://blog.talosintelligence.com/2017/04/introducing-rokrat.html
http://cwe.mitre.org/data/definitions/416.html">http://cwe.mitre.org/data/definitions/416.html
https://nvd.nist.gov/vuln/detail/CVE-2018-4878#vulnCurrentDescriptionTitle">https://nvd.nist.gov/vuln/detail/CVE-2018-4878#vulnCurrentDescriptionTitle