tsoyuzhu

[tsoyuzhu]

COMP 6441 Job Proposal

Analytic Skills Time Management Community and Professionalism Something Awesome

[tsoyuzhu]

Job Proposal: Community and Professionalism

Contribution to course environment

I produced some write ups for Jazz’s reverse engineering crack me challenges. These were documented on the GitHub wiki page and can be found here: 

Crackme Solutions 

Teamwork

In week 7, I participated in SecSoc’s Term 2 CTF which took place on a saturday. I worked in a team with 3 other people and we placed 7th out of 35 teams. You can read about it here: SecSoc Term 2 CTF

Communication and Feedback

On Slack, I kept an eye out for any questions i thought i might be capable of answering. While this was very rare, I contributed where possible. This post is going on tumblr so I have censored all names involved including my own. You may have to take my word that this is actually me. If you would like more substantial proof I can also provide it. 

Occasionally, tumblr would recommend me a blog by a fellow student for me to follow. I did so and left likes and comments on their posts If I particularly enjoyed their content. I have some friends who are doing the same course who I more frequently liked and commented. To post them all here would be a wall of images so i will only post a few. I understand that this is pretty pathetic proof so again, more substantial proof can be provided upon request.

Responsible Data Handling

I did not analyse any real companies in my case studies outside of Deep Water Horizon. Throughout my security everywhere posts, I ensured that there was not sufficient information to identify any vulnerabilities I may have noticed. I made quite a few technical blog posts regarding the development of rootkits and crackme challenges. I regard these as more safe since it is knowledge that is openly available on the web. The crackme challenges were designed to be solved and did not comprise any real systems. I did not knowingly provide knowledge into existing exploits or vulnerabilities.

[tsoyuzhu]

Job Proposal: Time Management

Admittedly, my time management this term could have been better. I prioritised non-assessable content ,such as my research for my something awesome and solving challenges, over the course content and open learning activities. My blog posts were consistent throughout the term but you can clearly see spikes in the graph below where I had more time to dedicate than usual. Compared to some of my peers, my blog posts are consistent, but they blogged more regularly.    

With regards to preparation for the midterm exam, I started early and I feel like this was effective as I was satisfied with my exam mark. I blogged about my preparation here: 

Mid-semester Exam Preparation

With regards to my something awesome, I made consistent contributions throughout the term, which is reflected in the timestamp of my blog posts. Despite my consistent work, I failed to meet my criteria upon doing further research into the difficulty of my task. In the end, I spent more time researching rather than implementing. This may be considered as poor time management. Something Awesome Progress Report 1

Something Awesome Progress Report 2

Something Awesome Progress Report 3 

Something Awesome Progress Report 4 

Something Awesome Progress Report 5

Something Awesome Progress Report 6  

But I did make it on time to the mid-semester exam. That is kinda good. 

[tsoyuzhu]

Job Proposal: Skills

In preparation for the mid semester exam, I spent a lot of time doing cryptograms, particular substitution and transposition ciphers. Unfortunately, many of these weren’t documented. The ones that were you can find here: 

Solving Jazz’s Cipher

Mid-semester Exam Preparation

I spent a fair amount of time on solving reverse engineering challenges in order to improve my technical skills. In addition, my something awesome involved writing a basic Linux rootkit with simple functionality. This required knowledge of C, Linux kernel programming and operating systems. You can find my findings for the challenges documented on the GitHub wiki page for the repo: 

Crackme Solutions

You can read about my something awesome in the dedicated blog post: Something Awesome Project  I attended 2 security related workshops throughout the semester. One of which kick started my interest in improving security related skills through challenges. 

These were:

Reverse engineering by Jazz

Memory exploits by Adam T

But I didn't blog about this one because it was too insane for my puny brain to handle and could not make enough sense of it. I demonstrated my skills at the SecSoc Term 2 CTF and we placed 7th out of 35 teams. You can read about it further down in my job application under the Community and Professionalism - Teamwork section. The relevant blog post is here: SecSoc CTF Term 2

[tsoyuzhu]

Job Proposal: Analytic

Throughout the semester I have been working on technical challenges and extending my knowledge through videos watching videos. 

Research

I kept an eye out for potential vulnerabilities in everyday scenarios and blogged about them.

Security Everywhere 1

Security Everywhere 2

Security Everywhere 3 

Security Everywhere 4 

Security Everywhere 5 

I conducted research for homework activities and broadened my understanding of course content outside what was provided in lectures: 

The Life Expectancy of a Computer

Some Type 1 and Type 2 Errors

Homework Secure Cryptoprocessors and Hardware

ATM Attacks

Outside of course content, I watched some videos of security talks in order to broaden my technical understanding. In particular:

Weaknesses in assembly code 

Psychological defence against reverse engineers

Reflection

Here are some times where I reflected on cases we studied in class and other things security related. 

Deep Water Horizon Week 1 Reflection Week 4 Case Study Week 4 Human Weakness A Sad Reflection Tutorial 7 Reflection

Application Most of my application of theory came through my something awesome where i tested different implementations of rootkits. You can read about it in my reports below.  Something Awesome Progress Report 1

Something Awesome Progress Report 2

Something Awesome Progress Report 3 

Something Awesome Progress Report 4 

Something Awesome Progress Report 5

Something Awesome Progress Report 6  

Reverse engineering was my other main form of application. I applied my knowledge through crackme challenges through the SecSoc Term 2 CTF reverse engineering challenges which you can read about later.  Crackme 0x03

Ciphers were an easy way to apply theory into practice. Lack of entropy is something which allows us to break defences much faster than brute force. Documented here are times i applied this to substitution ciphers. Unfortunately i did not document my work on transposition ciphers. Solving Jazz’s Cipher 

Mid-semester Exam Practice 

[tsoyuzhu]

Job Proposal : - SOMETHING AWESOME -

The Idea

My objective was to increase my understanding of Linux root kits and build a root kit with a set of features. My criteria reflected features of increasing levels of difficulty. The intention was that the best way to learn something was to build it. The Criteria Something Awesome Criteria

Pass:

Be able to build and load the root kit as a kernel module.

Be able to remain undetected from listing running processes and listing loaded modules.

Be able to escalate privileges for a user level processes.

Credit:

Be able to hide/unhide processes by process ID.

Be able to hide/unhide files and directories.

Distinction:

Listen (and possibly record) keystrokes of user.

High Distinction:

More advanced method of remaining undetected.

Progress

I worked regularly on my project. My time was spent researching existing implementations and reading articles about root kits and the linux operating system. I documented my findings and my progress through blog posts:

Something Awesome Progress Report 1

Something Awesome Progress Report 2

Something Awesome Progress Report 3

Something Awesome Progress Report 4

Something Awesome Progress Report 5

Something Awesome Progress Report 6

The Result Partway through my project, I realised the difficulties with actually implementing a good linux root kit with a robust set of features. I found my own implementation to be basic and easily detectable. In addition, implementing other features involved making use of the Virtual File System layer in Linux. This was both exciting but also very advanced. I failed to fully understand the code and decided not to implement something I did not have a firm grasp of. In regards to my criteria, I only scraped a pass. I am okay with this. I was able to appreciate the difficulty of my task and also had the opportunity to write something cool and customise it. In the future I will definitely continue to build upon this and implement inline function hooking instead of syscall table hooking. Above is a video demo of my Something Awesome. In the demonstration:

I show that the root kit is installed and visible under the modules list.

I make a write call by echo-ing ‘hide_me’ and the rootkit intercepts the write_syscall and finds this command, hiding the rootkit.

I show that the root kit is no longer visible under the modules list. I forgot to show that the root kit is also hidden from the sys/modules folder.

I use whoami to show that I am accessing the machine

I make a write call by echo-ing ‘give_me_root’ and the rootkit intercepts the write call and elevates my current process to root level.

I use whoami once again to show that I now have root access.

The Code

https://github.com/Tsoyuzhu/numpty_noodle_rootkit

[tsoyuzhu]

Security Everywhere #5

Yeah I haven’t done one of these in a long time. I was eating on campus at a particular store which shall remain unidentified. I found that on one side of the restaurant, the seats were actually low-profile cabinets with a cushion placed on top of them. These had no locking mechanism on them. I took a sneaky peak inside the cabinets to which i found many cases of soft drinks, which suggested that this was where they stored their additional supply of beverages.  The area is covered by security cameras which would identify somebody attempting to steal drinks. But this would require the staff to recognise that theft had occurred. It is a deterrence but does very little to stop theft from happening (although its just soft drinks so maybe its really not that bad).  The main point of this short blog post was to identify that security via obscurity is used VERY regularly in everyday life and we may not necessarily realise it unless we go explicitly looking for it. I myself had never noticed that the seats were actually cabinets until I went searching for things.  On another note, in the same restaurant, there is a socket at the back near the table which connects to the stereo. By trial, I found that if you turn the switch off, the stereo turns off and music in the restaurant stops. This is good because they only have the stereo connected to it (compartmentalisation). This is a bit bad because this is a very trivial case of mixing control with data. Perhaps I am over analysing.  I would have liked to accompany these security everywhere posts with pictures but anonymity needs to be preserved here. 

[tsoyuzhu]

Capture the Flag

Today i participated in SecSoc’s Term 2 CTF. It was my first CTF and it was very humbling to find that I sucked. Fortunately, my team carried me and we placed 7th. 

It was lucky that each team member had different strengths. I focused on the RE challenges but only succeeded in completing 2 of them (the poet one and the full monty one). The others were difficult (furious refused to be disassembled by binary ninja and IDA, I did not have a windows machine to run the meme challenge exe, and I failed to figure out the crypto one). My contribution to all other CTF challenges was quite minimal which pretty much made me the anchor of the team (lol). What I found difficult was working through the RE challenges purely through the assembly. Another member in my team had a plugin which compiled the program into C and this made the process many times easier (although I am unsure if this is demonstrating particularly good RE skills). At one point, I misinterpreted a negative number for a very large number. I should have used common sense to deduce this but it is not easy to tell from assembly (if anyone reading this blog post knows a method to tell I would greatly appreciate some input). Upon seeing the C code, It was much clearer.  Overall, the day was very fun and I learnt a lot. It was a bit of a wake up call to go develop skills in the areas I was lacking (literally all the other areas). I also regretted not having attempted the buffer overflow exploit challenges yet as I failed them in the CTF.  Thx to my team members who carried me @public-insecurities @alexpanaman and Bryan. (Also thnx @public-insecurities for letting me steal your photo). 

[tsoyuzhu]

Tutorial 7: ROP

This blog post is my attempt to remember and summarise the series of buffer overflow exploitations and mitigations we have been discussing in our tutorial.  We started the discussion a couple weeks ago by introducing buffer overflows. Where the program calls a function which naively reads user input without checking the length of the buffer (fgets() is usually the biggest culprit), an attacker can enter a long string which does not fit inside the buffer. The buffer is a local variable on the stack, located before the return address (if you draw memory from left to right with the 200 IQ strat). The rest of the string which does not fit inside the buffer will overflow onto the stack, overwriting whatever was in memory. We aim to purposely onto the return address in memory and overwrite it with our own address. The value we overwrite it with depends on what is available to us inside the function. If we have a window function somewhere inside the code, we can overwrite the return address with the address of the window function. When the program finishes executing, it will pop off the return address (which is now the address of the window function we want to execute), load it into the program counter register and the program will jump to the window function providing us with a shell. In the event where we do not have a window function located in the program, we can write our own code to execute a shell function and store the binary in the buffer. Now, we jump to the start of our program stored in the buffer instead of the window function. This accomplishes the same thing.  Stack canaries are one defense mechanism against these kinds of attacks. There is a value written in memory before the return address. In this way, any attempt to overflow the buffer onto the return address will also result in the stack canary value being overwritten. The operating system (i think its the OS but could be wrong) checks whether this value has been modified before popping off the return address. If it finds the canary to be modified, it does not proceed. Instead i think it throws an error.  ASLR (Address space layout randomisation) is another defense mechanism. Here, the regions of memory are moved in such a way that their positions change but their relative order is still the same. This is to prevent the program from knowing what value we need to overwrite the return address with. We don’t know where we should jump to as the offset of the function relative to our buffer is no longer known.  ROP (return oriented program) is a method used to bypass  Fuck its too late for this. I will finish writing this post tomorrow.

[tsoyuzhu]

Something Awesome Progress Update 5

Having spent 4 hours today researching and studying rootkit implementations, I have come to the conclusion that writing a proper and useful root kit is much more difficult than I originally imagined.

It is easy to write a proof-of-concept that demonstrates a functionality but which is practically useless in application. Unfortunately, my Something Awesome project is at this stage and will unlikely become much more sophisticated before the deadline.  As of now, I have only succeeded in creating a ‘rootkit’ which re-directs the pointers of the syscall table to my own functions. I have replaced the sys_write system call with my own which checks for a passphrase in every write call and gives root privileges to the process which writes a specific phrase. This is clearly not very practical in reality. The passphrase is a word and will eventually be accidentally written by the multitude of programs which use sys_write. Not the best to have processes accidentally elevating themselves to root.  The point of this post is not particularly to trash my something awesome project (although it is pretty weak). Rather, it is to appreciate the amount of skill actually required to write a rootkit implementation that is robust to different kernel version, difficult to detect, and easy to use.  Having attempted to understand more sophisticated means of implementation, I am quite convinced I will not be able to improve my something awesome much past this point. Perhaps it is better to accompany my presentation with my findings rather than attempting to implement code i do not necessarily understand. 

[tsoyuzhu]

Hiding Linux Rootkits

In progressing in my Something Awesome, I am more concerned in exploring more sophisticated methods of implementation than amassing features. One particular area is in hiding files using the rootkit.  Most implementations hide the kernel module by altering the module list so that the module wouldn’t show up in lsmod. Implementations differ when using the rootkit to hide files. One method involves hooking the syscall_table and replacing the sys_write() system call with our own. This system call would check for any strings involving the files or directories we want to hide and neglect to write it, instead printing out an error message. If the system call did not find any of the files or directories, it would execute the default sys_write(). This approach is okay. However, if somebody suspected there was a rootkit, it would be easy to look through the syscall_table and notice that the pointers to particular functions have been modified. Since modifying syscalls is a fairly standard practice, outside of root kits, this method is not particularly stealthy. 

A more sophisticated solution involves utilising the virtual file system (VFS). This requires a deeper understanding of the VFS which i am going to look into. The VFS is a layer of abstraction that sits between the programmer and other filesystems. There is no need for the programmer to understand how the underlying file systems work, they only need to interact with the VFS layer. This simplifies the code may requires deeper understanding of what is happening. 

A resource I am following is not updated for linux kernels 3.11 and higher. This means that i will have to fully understand what is going on so i can write code which works. Cannot depend on having available code to guide me. Sed. 

[tsoyuzhu]

An update

I have not blogged in a couple of weeks and have not made substantial progress on my something awesome. I have also fallen behind in regards to open learning activities. A large part of this is due to me contributing a vast majority of time into my thesis. It seems as though everything is to be due in week 8 so I will need to get my shit together. Over the next few days, I will make substantial progress on my something awesome and portfolio.  Fek. 

[tsoyuzhu]

Crackme Solutions

Over the past week I’ve been procrastinating by writing up some guides for Jazz’s crackme challenges. Completing the challenges were very insightful and improved my knowledge of C and assembly code. My first attempts involved naively patching the control flow and hoping the program worked as I intended. After spending more time on them, I found solutions easier to identify after understanding the assembly code. I highly recommend these challenges to everyone who has interest in reverse engineering (even if you don’t currently have an interest you may develop one after attempting the challenges).  You can find the repository here: https://github.com/jtalowell/crackme The github wiki page has useful links for setting up and some guides for working through the challenges if you get stuck. 

[tsoyuzhu]

A sad reflection

Holy fuck i thought a pointer was one byte long i am actually a scrub 

[tsoyuzhu]

Something Awesome Update #4

Having done a modest amount of research into building rootkits, I now have some design decisions which i must make. This is what is quite set in stone - - Rootkit will be implemented as a loadable kernel module. - Rootkit will need to have an initialisation function and an exit function. - In order to hide the module, the rootkit will need to delete its entry in the proc/modules list and the sys/modules list.  This is what is up for consideration -  - Load kernel module as a char device file?  This implementation makes writing and reading to and from the device file pretty easy. On the other hand, setting up a device file is annoying because the device file has restricted permissions upon creation. A normal user cannot write to the file. 

To get around this, I can either: - modify the udev configuration file which is not practical since the file affects the whole computer and the modification in the file is easy to find. - chmod it upon the device files creation which might get messy.  There is a possibility that making this isn’t required -  There are many implementations of rootkits on the web. Without greater understanding of the linux operating system, it is difficult to verify for myself which of these are most effective. That said, some of these do not create char device files in order to service commands to the rootkit.  I can hijack the write syscall and check it for a particular activation word each time a write call is made. This may be an alternative method. The downside of this is that somebody searching through the syscall table memory addresses will likely notice that the table has been hooked.   Having practiced some of these implementations, I will rewrite my rootkit after some more research. 

[tsoyuzhu]

Week 4: Human Weakness

(image from national geographic)  On 28 January 1986 the Space Shuttle Challenger broke apart 73 seconds into its flight, killing all seven crew members. The accident was caused by a flaw in the O-ring design, which had not been tested at the temperatures experienced on that morning.

The launch proceeded, partly due to pressures from multiple launch delays, and also due to manager disregard of warnings from engineers about the dangers of launching at such a low temperature, and their failure to pass that advice on to their superiors. Analysis: Similar to the catastrophe at Deep Water Horizon, this disaster could have been avoided had one of the vulnerabilities been addressed. The engineers knew of the dangers and fulfilled their responsibility of passing it to their managers. The manager disregarded the warnings due to the pressure of launch delays. This is to be expected from a corporate organisation where money is a very powerful factor (arguably the sole influence) - humans are greedy. It is possible that the manager also did not want the embarrassment of having to delay the launch again.  The engineers also have part of the blame to take. Having had their advice dismissed by their managers, they had the opportunity to blow the whistle and pass the advice to superior authority. Whistle blowing is an ethical dilemma as it compromises the engineers job security. They do not want to be labelled as the reason for another launch delay. In addition, approaching higher authority regarding the issue would be acting against the decision of their manager. The risk was not guaranteed and it is arguably a difficult decision to make.  In both cases, the manager and the engineers had something they stood to lose had they taken the ‘safe’ option. Human weakness is the reason why we often choose the selfish option, the one which benefits us the most with the highest probability. Sometimes, others need to pay the price for our selfishness. 

[tsoyuzhu]

Week 4 Case Study

Protect the hypothetical Google research facility at Randwick. Assets: - The researchers - The data or the research - Other companies affiliated with the research

Threats: - The hooligans of Randwick - Rival companies  - Insiders/Moles Mitigation Strategies: Segregation of Research  It is possible to structure the team such that no researcher knows all the data. In this way, if there is an insider they should not know all of the information at the facility. However, there is likely a higher authority that collates all the research and this point will be vulnerable to attack. This also allows false information to be leaked to each sector or research. Knowing what information has been leaked allows you to pinpoint the source of the leak.  Physical Security Biometric scanners will prevent outsiders from entering the facility but will not prevent insiders. Since our threat model of external parties includes the hooligans of Randwick (who are not well resourced) and other companies (who may be better resourced but must be willing to commit a high level of crime), biometric scanners are a reasonable deterrence. Another way is to keep the existence of the research facility secret and disguise the facility as a different building of little interest. Doing this is likely more affordable and may be equally as effective although you will need a system in place to prevent people accidentally walking in.  Encryption of Data It is likely that information will need to be transferred to and from this facility. Using encryption on all data when it is not in use should mean that even if data is stolen, it is useless to the a person who does not have the means to decrypt it. The key should be kept out of hands of the researcher so that attackers will have to strike further up the chain of command. Hopefully this is reasonable deterrence.  Protecting the Researchers People are always a source of vulnerability in a system. Forcing the researchers to stay on-site is a method to decrease the risk of them being compromised. This plan is not fail proof and is difficult to implement. People don’t want to have to live secluded for the rest of the world. Even after they quit and leave the facility they become vulnerable.