beepboopblogger

[beepboopblogger]

Something awesome update 4:

So after a whole night of troubleshooting I was able to finally get something running that acted as a key logger. I found out that there was a problem with how my keyboard was interacting with my computer. I realised after testing the example libraries with my mouse, which showed that there was no problem with my usb host shield as input was being detected when the mouse was plugged in. I borrowed my friends keyboard and I was finally getting some response! 

I reflashed my ESP module multiple times after watching a wide range of YouTube videos explaining how to correctly flash an ESP, and after doing so I was able to download a keystrokes.txt file. I thought that the device was fully functioning... but when I opened the txt file it was all gibberish. Quite frustrating but at least it was progress.  

I decided to change my method of attack and instead of using the WiFi module I would instead just have the keystrokes printed in the serial monitor within the arduino IDE. This seemed more effective and I was actually getting some keys logged. The main problem was that it was printing them out individually one character per line, which isn’t very useful information when trying to read whole sentences. 

Another problem that I had that they keys were not being passed through correctly, which meant that if you typed onto the keyboard, nothing would be typed onto the computer. This is obviously a problem as no one is going to be tricked into typing any information if they don’t see their keystrokes on the screen. 

So I began working towards fixing that and ran into a problem with special keys like space and return, where the correct keystroke was not being pressed. It was instead putting ,,,, commas in substitute for space which was obviously a problem. 

I could feel that I was close and after adding some edge cases for keys outside of the letter range, was able to get the keylogger functioning in a way that it could be useful. (sorry for filming in vertical) 

I’m glad that I actually got something working in the end... 

[beepboopblogger]

Something awesome update 3:

So final update before my demonstration tomorrow... and I still haven’t been able to get my keylogger to work! I was following a guide on how to build it and have tried everything I can. I looked extensively through the code that I was testing the device with and researching what each function and line does. Even after changing the settings and trying different examples from other sources I have deducted that there must be a problem with the hardware that I am using. My initial plan when designing this project was to test the device using the code written by Github user Spacehuhn and then once it was working using that, rewrite the code from the ground up. Due to the fact that I had little knowledge of coding an arduino or ESP wifi module before beginning this project I thought that it would have been an interesting learning experience. I still think that overall I have learnt a lot when it comes to troubleshooting and looking for potential errors with hardware and software, but unfortunately I was unable to produce a working final product. I think that this is due to a faulty USB host shield that I ordered from eBay. There were issues with how it was soldered, and even after trying a fix that I found online, the host shield still did not operate correctly with the arduino. Due to time limitations with shipping from overseas, by the time that I realised that this was the cause of the problem, I was unable to order another part. This could have been remedied by better initial planning on my part but that is how it is. 

The device still does have some basic functions like allowing the user to connect to a wifi network, but the main function, actually logging keys, unfortunately does not work. I was still able to make an educational “how to” video on staying safe from the threat of keyloggers, which at least satisfies my passing criteria. I was able to also create a more compact version of the initial design using jumper wires instead of a breadboard to connect all the components together, although this could be improved further by using a mini host shield, a pro micro arduino and/or shorter jumper wires. 

Even though my project might not necessarily be awesome I still had a lot of fun constructing the device and learning more about wiring, coding and how such devices could be used. It is also a great learning experience when it comes to things like planning and time management. 

Anyway this is what the end product looks like in all its nonworking glory: 

[beepboopblogger]

More Security Everywhere

I went to a music festival over the weekend and the security presence was quite interesting to observe. To start off with when you enter the festival in your car there are 10 lines that you get directed into. From these lines 2 cars will get fully searched to make sure that they are not carrying any contraband. Due to the fact that it takes a fair amount of time for a vehicle to be checked, barely any cars were actually searched upon entry, meaning that a lot of items which were not allowed were brought inside. It is interesting relating this to Richards M&M analogy of a tough exterior but soft interior. In this case, the festival had neither a strong exterior or interior as security also only went around inside the festival briefly. I also observed that due to the amount of people trying to walk into the festival the security guards would not thoroughly search each person’s bag. This safety in numbers as well as the amount of work and time it would take for each person to be searched by security meant that anyone trying to smuggle anything inside was free to do so. This can be related to cyber security where if a lot of people are trying to attack something it is very difficult to protect it if the security presence is not strong or thorough enough. 

[beepboopblogger]

Something awesome update 2:

As the due date is getting closer I thought I would do another update.  After testing my keylogger with another keyboard I realised that the initial problem that I talked about in my first update where my keyboard wasn’t working was actually cause by the USB host shield where there was solder missing on the board which caused it to become defective. I added solder to the spots below.

After doing this the host shield provided power to the keyboard.  I am still having issues with actually logging the keys but this should be fixed by the time the project is due. 

As for making the logger more stealthy, I got some jumper wires so that I can connect everything together without the use of a breadboard. 

Things to do: 

Make project video

Finalise keylogging code

Finish making logger more compact

[beepboopblogger]

Something awesome update 1:

After a lengthy period of waiting for parts to arrive from China I have finally begun work on building my project. Following this guide, I put together my keylogger.

As you can tell from this initial design it is obviously very bulky and there is no possible way that somebody would not notice that this was being used. I am planning on either getting a smaller bread board to put the ESP chip on, using jumper wires to connect directly to the chip or build a case that could be used to trick somebody.  

I also had a problem with how I uploaded the program onto my ESP chip. This caused me to be unable to connect to the webpage where the text file containing the logged keys was. I read somewhere that perhaps there was a problem with how the ESP had been flashed. I tried a range of solutions searching all over the internet on ways to correctly flash the settings onto the ESP. By doing this I feel like I developed a deeper understanding on the chip that I was using but in the end it was a simple issue on the settings used when uploading onto the chip. All I had to do was change the flash size from 4M (no SPIFFS) to 4M (2 SPIFFS). 

The next problem that I ran into was that the USB host shield was not providing enough voltage to my keyboard. This meant that my RGB gaming keyboard did not have enough power to work meaning that I could not use my keylogger >:( . Although this might just be a problem with my keyboard.

Things to do for the next update: 

Change which keyboard that I am using

Think of ways I could make the device more stealthy 

Improve on the code used

[beepboopblogger]

Threat Modelling

When threat modelling you have to look at your assets and discover your threats to those assets. You have to find out who’s attacking them and what measures need to be taken to protect them. If you were a hacker some potential assets, threats and mitigation might include: 

Assets  : 

Identity 

IP address 

MAC address

Data

Computer

Friend/Groups

Threats :

Australian Federal Police (AFP) 

Internet search provider (ISP)

Australian security intelligence organisation (ASIO)

Australian secret intelligence service (ASIS)

Australian signal directorate (ASD)

Mitigation: 

False trail

Frame somebody

Deniability 

IP 

VPN 

TOR

[beepboopblogger]

Case Study 1: Deepwater Horizon

Finally decided to put my case study notes onto my blog...  The Deepwater Horizon oil spill was a catastrophic failure where in April in 2010 a BP oil rig caught on fire, exploded and spilt oil into the Gulf of Mexico, killing 11 people and injuring 17 more. It was caused by a chain of events in which if even one of the events did not occur the failure might not have happened. Issues with testing and design ultimately led to the failure. Gas blasted through a concrete core which was supposed to seal the well and ignited on the surface of the rig. This caused the rig to lose power and this stopped the blow out preventer from operating correctly. This lead to thousands of barrels worth of oil to start spilling into the ocean. In a desperate scramble some stayed behind to try and fix the problem and others abandoned the rig on lifeboats, leaving those left behind stranded on the burning, sinking rig. There are a range of changes that could have been or should be implemented in the future to stop events like these from occurring. Higher qualifications should be required for supervisors so that in the case of emergency, workers look to their supervisor for the correct course of action instead of scrambling and creating panic. A third party constantly watching the rig remotely could provide immediate assistance and faster time to get to the rig in case of emergency. This could be coupled with a dedicated crisis staff who’s soul job is to assist in such circumstances. More escape options should be available to reduce deaths of those on board. Ultimately fuel alternatives that are safer than oil are the end goal so that the environment will not be damaged by future  spills.   

[beepboopblogger]

Security Everywhere!

I decided to move my security everywhere onto my tumblr. My previous post: here.

If you have ever gone into a club or bar you might have noticed that many of them use ID scanners at the door. This takes a picture of your driver licence and displays your date of birth and picture. If the bar wanted to they could collect all information such as driver licence number, address, DOB and what you look like from all patrons of their venue. This information could be abused and personal information could be leaked! If you are concerned about your privacy when entering the club use a fake ID so that you can’t be traced (not actual advice). 

[beepboopblogger]

Summary Week 3/4

WEEK THREE:

In the third week of COMP6441 we discussed the concept of risk. Risk is invisible and not always easy or possible to immediately detect. This is why it is very dangerous in the sense of security. Risk is always bad and even if nothing goes wrong, doing the activity with the risk there is still irresponsible and dangerous. Say you rode a bike without a helmet, even if you ride around and don’t fall off, the risk that you could fall and crack your skull open is always there. The public tends to only focus on something when something risky goes wrong. Risk can be assessed by using a risk matrix or a third party risk register. We also covered public key cryptography where there are two keys, one to encode a message and one to decode it. 

WEEK FOUR:

We talked bits and hashing. The security level is usually measured in bits where an attacker would have to do 2^n operations to crack something. In decimal 10^3 is 10 bits for reference. We then discussed hashing. A hash is generated by a formula which mathematically alters a message which can be decoded using the hash. A hash has an avalanche property such that a small change in the input results in a large change in the output. Most hash functions are designed to take a string of any length as input and produce a fixed-length hash value. A hash has to be resistant to pre-image attacks where there is an input that hashes to that output or a 2nd pre-image attack where two messages can have the same hash. A hash also has to be collision resistant so that it is hard to find two inputs that hash to the same output. Collisions may be found by a birthday attack if a hash isn’t collision resistant. 

[beepboopblogger]

Something Awesome Proposal Update

An example video demonstration: here GitHub example link: here

Pass:  Make video on what a key logger is and how to stay safe from the threat of a key logger

Credit: Build usb key logger using Arduino Leonardo, USB hub and Wi-Fi chip. 

Distinction: Improved design which is compact and stealthy.

High Distinction:  Test usage of key logger and design ways of collection information using it (passwords, bank details etc) 

[beepboopblogger]

Summary Week 1/2

WEEK ONE : 

We started off COMP6441 by first thinking - what makes a security engineer? Important ideas were discussed such as the need to analyse every situation and think how could this be prevented, could we have know earlier and to think about a range of options that could be a possible cause. Sometimes something extremely abstract could be a solution. You can also never be certain that you are safe or secure and that nothing could go wrong. To be a good security engineer you need to be able to think as both the attacker and the defender. 

We also began talking about confidentiality and some methods of encryption such as steganography (hiding a message in another message), substitution ciphers (substituting a letter with another letter) and Caesar ciphers (substitution cipher where each letter is shifted by the same amount).   

WEEK TWO :

For our second week of lectures we began talking about the recent ANU hack where a large amount of sensitive personal information was compromised. We discussed what could be done to prevent this. Penetration testers could be used to make sure that vulnerabilities are minimised and also design a system so that if one part fails the whole thing does not fail. This is an example of defence in depth. We also discussed security by design and how things should be designed from the beginning so that they are secure. Although you can never have full trust, infrastructures should be designed to be as close to perfection as possible. 

We then moved on to physical security. We discussed hardware and how it is both always weak and very difficult to destroy properly. Side channels were mentioned and that everything leaves a trace. A device should be designed so that it is tamper evident.

Back to ciphers... Entropy is the measure of uncertainty associated with a random variable. Different ciphers have a different entropy. Here is a list of ciphers we looked at during week 2: Vigenère cipher.  Kasiski examination. Enigma Cipher. One time pad.

We also discussed Type 1 and Type 2 errors. T1 predicts that something will happen but it doesn’t. T2 predicts that something won’t happen but it does.  It is hard to know which one is better to reduce and this is decided by your morals. 

[beepboopblogger]

Something Awesome Proposal

For my something awesome project for COMP6441 I want to develop and build my own key logger. I have seen some ideas online where an Arduino is used to build one where a usb keyboard can be plugged in and key strokes monitored.

Some things that I need to consider include:

- The cost of purchasing necessary components (Arduino, Usb Hub etc)  - The time it will take to build and design - limitations on my knowledge of coding (although could be an interesting learning exercise). 

I want to see how such a device could be used, especially due to the size of the device, and explore ways that people can stay protected from keylogging software and hardware. 

[beepboopblogger]

Life expectancy of a PC on the internet.

Looking into the life expectancy of a computer connected to the internet: 

According to https://www.empowerit.com.au/blog/it-planning/budgeting/laptops-desktops-how-long-do-they-last/  

“ the average lifespan of a desktop computer is around three years “. 

A computer can still be used after this lifespan but the hardware is impacted and degrades by installing software, making file and updates. 

although “ laptops have an even shorter lifespan of two-to-three years “ due to smaller form factor and reduced ventilation compared to the desktop counterpart. 

According to https://www.computerhope.com/issues/ch000985.htm 

“ users should replace their computers at least every four years “ 

this is due to factors like speed and wanting to upgrade to increase performance to meet new standards. 

[beepboopblogger]

this is my blog for cyber security