lockingishard

[lockingishard]

Job Application COMP 6441

Analytical skill

Skills

Something awesome

Time management 

Community and professionalism

[lockingishard]

Job Application: Time management

To ensure basic commitment, weekly activities (module activities) were completed at an average rate of 3 activities per week. Other than that, most of the time for this course has dedicated to reading up maths proof of particular concept on stack exchange (E.g. proof of repudiation of MAC and WEP vulnerability) and watching interesting but non-examinable Youtube videos.

Blogs are posted regularly and reflections/research were made throughout the term as summarised in the Analytical Skill section. However, deep analysis were not conducted regularly and frequently compared to my peers.

Cipher cracking exercises were done quite regularly prior to midterm exam after being traumatised by failure attempt at tutorial. Some of the exercises were even done on the bus to make sure I catch up with the course. The improvement was recorded here:

Substitution cipher drill

Something awesome project was officially started two weeks before the deadline, due to the long wait for delivery of Arduino Leonardo clone and inability to grasp the concept explained in the hak5 video in a efficient way. As reflected in the timestamp in my update posts, poor time management has indirectly led to failure of my project. Another hardware board could’ve been bought for proper testing if I started a week earlier.

Something Awesome Update 01

Something Awesome Update 02

Something Awesome Update 03

Something Awesome Update 04

Something Awesome Update 05

[lockingishard]

Job Application: Community and professionalism

Contribution to course environment:

During week 7′s Wed tutorial, I presented to the class a lightning talk about principle behind WEP and its major vulnerabilities. The talk was rather spontaneous, as WEP was originally something that I’ve been struggled with and heavily researched on the day before tutorial took place. Since Jazz encouraged us to talk about things that we’ve learnt over the week, I thought sparing others from the struggle would be a nice thing to do.

Awareness of the community:

Throughout the term I’ve paid attention to the community around me looking for security-related issues. I reflected upon my observation and came up with mitigation that people can do at individual level, in an attempt to engage people into building similar mindset and taking actions to push forward for greater change.

char *SecurityEverywhere01

char *SecurityEverywhere02

char *SecurityEverywhere03

char *SecurityEverywhere04

Universities forging ranking data

Teamwork:

Helped a bit on the course notes (a bit on explanation on AES and CTR), but unfortunately the changes were made anonymously.

A trivial example would be walking peers through cracking substitution cipher during the midterm help session, but that wasn’t recorded either :( (And pros shouldn’t be)

Communication and feedback:

Occasionally I would come across some really sophisticated posts the Tumblr recommended to me. After following them I would like and comment on their Tumblr posts to give moral support:

I tried to respond to comments even though there aren’t many:

When revising for midterm I came across this typo and immediately reflected on the issue in comp6441 slack channel: 

[lockingishard]

Job Application: Something Awesome Project

Finalised work:

Video and script

Objective:

To accumulate experience with unfamiliar devices/language/hacking gadget. These include programmable device/hardware Arduino Leonardo, powershell and getting to know more about rubber ducky itself since I’ve never heard of it before (or maybe not in that name). My criteria is derived from different layers of the above objective to reflect gaining of new skill at each stage.

Criteria:

Pass:

Make a video on the major threats of a rubber ducky and how it works

Credit:

Build a functioning rubber ducky with Arduino Leonardo, USB cable and a button (able to run simple automated commands)

Distinction:

Successfully implement file exfiltration AND password hack using the built rubber ducky

High distinction:

Successfully Implement both functions above AND defend against both attacks

Bonus mark:

Come up with a creative hack using the built rubber ducky

Progress:

Something Awesome Update 01

Something Awesome Update 02

Something Awesome Update 03

Something Awesome Update 04

Something Awesome Update 05

Result:

Due to my negligence of possible failure of hardware, I only achieved a concrete Pass for my project. 

Things I did achieve:

Completed the video introducing rubber ducky

Built a rubber ducky that once worked

Password exfiltration and file exfiltration attacks could be run smoothly on Powershell alone

When rubber ducky was working, I was able to defence against my own attack through customised shortcut key combination, different language input and changing network setting.

However, the absence of practical testing combining the two marks the failure of the project in alignment to its criteria. Nevertheless, as I summarised in the last update:

“The project was overall a pleasure to work on. I got to deal with things that I’m extremely unfamiliar with, from the concept of rubber ducky itself to the language I use/device/hardware management. As much as I felt unfortunate for the failure of my project, I am happy with my decision of going with it in the first place.”

[lockingishard]

Job Application: Skills

Weekly learning activities:

Weekly activities were done to expand my skill set as a security engineer. Completing these exercises not only strengthens my understanding of the role of security engineer and motivates me to think like an attacker, but also allow me to truly enjoy the course and hold a genuine interest in security engineering.

Week 1: NSA Crypto (See ‘Cipher cracking’ session)

Week 2: Shredding analysis | Dumpster diving | Crypto challenge (image 1 below) | Coincidence index (image 2)

Week 3: Penguin heist | Merkle puzzle (Cracked others using the same key I used for my own message) | RSA (Submitted)

Week 4: Bits of security (Submitted) | Challenge Disaster | Magic trick | Hash function (Calculated answer as 122, classical length extension attack)

Week 5: Drop a bomb | OWASP Top 10 | Hashing gone wrong (Comment on others)

Week 6: One time pad

Week 7: Block cipher | (Knowledge-based authentication | Trump phishing | Social engineering)

Week 8: Google Yourself | Spot the fake | S/KEY

Cipher cracking:

In preparation for midterm I did quite a few cipher cracking. Early walkthrough of my growth is reflected in the blog below. Last-minute cipher cracking was not blogged at that time as I was under time constraint (right before the test), but was posted later to make up for it.

Substitution cipher drill

Last-minute cipher

In addition, during the help session running up for midterm I asked some peers about cipher distinguishing exercise given by Jazz. Apparently we have to identify transposition cipher first (via observing pattern in the first 4/5/6 letters), then substitution, leaving behind the poly-alphabetic enigma cipher.

Research skills:

My something awesome project has been a major learning incentive for me this term. It has built my ‘Google everything myself’ mindset and I’ve improved my research efficiency significantly this term. Main takeaways are:

Change PID & VID of a hardware device

Learning powershell and networking

Defence against rubber ducky

What I gained from my project

[lockingishard]

Job Application: Appendix

Appendix for Job Application: Skill

[lockingishard]

Job application: Analytical skill

global char *heading = Throughout the term I have constantly analysed relevant security concepts, researched topics in lecture that was not understood fully, and have integrated them into everyday life.

Research:

uint 000001 = For homework activity I researched about average PC life cycle and reflected on my own consumption/technology usage behaviour in here.

uint 000010 = For preparation of case study analysis in week 1 I watched an hour youtube video on the Deep Horizon accident to clear everything up. I blogged about the tutorial discussion later.

uint 000011 = For my something awesome project I had no idea what options were there for me to pick, so I did some research to learn about some of the popular hacking gadgets out there.

uint 000100 = In week 4′s lecture Richard brought up MAC and integrity property in cryptography. I had no idea what that was so I did some days of research and blogged about it. See Ways of authentication.

uint 000101 = In week 5′s kahoot there’s a question asking how is SHIM used in lock-picking. I didn’t know the answer so I watched a bunch of lock-picking videos later that week.

uint 000110 = Spectre and meltdown was brought up in lecture when side-channel attack was mentioned. I watched some youtube videos and blogged about it in my lecture reflection that week. It was later briefly talked about during tutorial but not explained in details, so I interpreted the concept in my own way :(

uint 000111 = During midterm and the week after, I noted down all the concepts that I was not familiar with for future research when I had time. After reading several papers I blogged about things that I struggled most with. See Merkle-Damgard Construction/WEP/Diffie-Hellman algorithm.

uint 001000 = For midterm preparation I went to the consultation session on Tuesday and discussed some questions from the practice exam with Caff and Jazz. I didn’t blog about this one because my poor brain was busy being f**ked by midterm preparation, and it was quite late to blog about preparation when the midterm has finished. Main argument between Caff and Jazz revolved around if MAC provides authentication or not (turns out it does because of the shared secret key involved in the hashing process). Main diversion between Jazz and I was if MAC provides non-repudiation or not (a property hadn’t been covered in lecture yet). Jazz’s opinion was that although A and B both know they share the secret that no one else knows, neither of them could prove it to others. I went to do further research and realised he was right.

uint 001001 = Homework activity required background knowledge of Crib dragging, so a bit reading was done.

uint 001010 = Researched about Block Cipher Mode related to lecture content.

Reflection:

Here are some of the reflection that I did after lecture to ensure I fully grasp the relevant ideas and establish my security mindset.

char *Lecture reflection01

char *Lecture reflection02

char *Lecture reflection03-05

char *Lecture reflection05-07

char *CaseStudy01

char *CaseStudy04

char *Type_I_II_Error

Application:

Application of relevant course concept is mainly through strengthening awareness of security issues in daily life.

char *SecurityEverywhere01

char *SecurityEverywhere02

char *SecurityEverywhere03

char *SecurityEverywhere04

[lockingishard]

Big company is watching you

It’s not 1984...probs?

It took a day for Google to prepare my data and for me to actually download it. Some of the data was expected to be in the folder, including all the documents I upload on Google Drive, transactions through Google Play, my emails and youtube watching history. But some of the documents really freaked me out. I had no recollection of linking my contacts in the phone to any Google service, yet it shows up in one of the folder. Search history, including text, image, video and shopping history are all stored. I looked through the history closely and it seems like I forgot to log off on my dad’s laptop so now I have a list of his past searches on Youtube (mostly old movies and political commentaries), which is pretty sneaky (but funny).

I don’t use Google Play much so there’s nothing interesting there for me to discover. However, it seems like Google has linked the calendar of my Apple account to itself. Damn I need to stop putting meeting with friends into the calendar.

When I thought I’ve traversed through everything I came across the purchase/reservation record...HOLY SHIT they have all the flight tickets I bought, including the name of the airline and the seat number. They also have a copy of the clothes and shoes I bought online, which were clearly not bought on any website associated with Google.

Other things include:

Android devices linked to my Google account

Chrome extensions and browser history

Bookmarks

Location I’ve been/searched on Google Map (expected huh!)

[lockingishard]

Security everywhere #04

This week’s seminar has talked about issue revolving user privacy, specifically data collected by applications. Coincidentally, the day after when I was studying with my friend on campus, she received several phone calls from strangers over span of a few hours, all of which appeared to ask if she needed some service provided (didn’t pay attention to what the service was). She told me that this had been an issue ever since she left her contact details in an advertisement on the newspaper, which was intended for offering tutoring. Although technically speaking her details are put out in public area, hence she has sort of already given consent to forgo this part of privacy, it is still concerning as to how this piece of information will be used by malicious people to compromise further of her other accounts linked to phone service.

Another incident happened a day after (convenient timing!) when my friend and I were discussing on phone what type of snacks we usually buy. Neither of us gave permission for any apps to record audio. But when my friend opened a shopping app (Taobao, which was essentially Chinese Ebay), he found ads of some of the snacks we’ve talked on phone call popping up as “you may also like”. Again, although developers’ intention may just be to offer better shopping experience, peaking through someone’s curtain to deduce their taste of fashion from their daily outfit is unacceptable.

How do we close the Pandora box? It is hard to come up with a generic solution for everyone. Some of my friends who have already entered workplace use one phone number for work and one for private life, attempting to draw a line between public and private area. Check permission setting periodically to ensure tabs are not mysteriously turned on by the apps; link bank account least used to shopping websites (or all website if feasible) then transfer the exact amount of transaction to the account whenever a purchase is needed. Comment in apps store on the privacy issue the app to remind others may also help give warning to the unethical companies, although oligopoly/monopoly in the market in certain field means the effort is trivial.

So the simplest solution is, chuck away your phone and embrace a life in reality :)

[lockingishard]

Compromising S/KEY

S/KEY:

A secret key (salt, i.e. W) is shared between user and the authenticator, and number of iterations of hash function (n) is specified by the server. The user then applies hash function n times to the salt, producing a hash chain of n one-time passwords, namely H(W), H(H(W))…Hn(W).

Initial salt W is discarded, leaving user with the list in reverse order (I.e. Hn(W)…H(W) ). The system only keeps the last computed password, namely Hn(W).

The user provides the server with Hn-1(W), and discard it immediately. The server computes H(Hn-1(W)) and compares it to the stored Hn(W) to authenticate. Upon success, the server stores Hn-1(W) for future authentication.

The process repeats with the user providing password Hi(W), which is computed by the server and compared to the Hi+1(W) stored previously.

Barbara is likely to use one of the 10 one-use only passwords when she is social engineered to work on a computer that she’s unfamiliar with, such as public library. If she uses S/KEY for authentication, then man-in-the-middle attack can be performed by intercepting the password the user sends to the server, computing the hash of it and providing it to the server before the user. Race conditions may also be used to eavesdrop all characters in the password except for the last one, and brute-force all valid last character for the server to validate until it is successfully cracked. Since the hash has complexity of 2^64, collision of the hash provided by the user may also compromise the security.

[lockingishard]

Social engineering exercise

Phishing emails:

Common phishing attack targeted at credentials usually involve some sort of “security concerns” that require victim to input their password in a forged website. This one is not hard to come up with, but the trick is to address the victim by their name to make the email more authoritative and the request legitimate.

To ask for bank transfer is a bit tricky. Some recon of the website reveals that David is in charge of operation, hence is the right person to approach in regards of financing issue. The address at the bottom of the website reveals that the organisation is located in city, highly likely being rented. A suitable spoofed identity would be the real estate agent asking for rent. However, requesting transaction through email is suspicious, so it is crucial to leave the victim little time to think about the legitimacy of the request. Therefore, the consequence of not taking immediate action is emphasised to push David into panicking state. Assurance of security is also included to eliminate last bit of suspicion if there is any.

Trump phishing:

Phishing emails usually involve something that the victim would most likely be concerned with. Lots of other responses involve some sort of security alert given out by social media IT team. To add creativity to the answer I simply picked a controversial issue that Trump held strong opinion about. The name CIA could be replaced by name of specific individual who is responsible for communication with the White House, so some recon is needed for this to work.  

Knowledge-based authentication:

A conclusion drawn by my friend and I was that phishing questions generally involve terms such as “first”, “last” or produce answers that are hard to change periodically. While this kind of authentication is still in use, make sure to set questions that you will be skeptical of if someone “casually” brings them up in real life (E.g. last name of your mum/favourite teacher).

[lockingishard]

Block cipher

Stream cipher: A fixed length key (usually 128 bits) is used to generate a pseudorandom key stream. Each bit of plaintext is combined with corresponding bit of key stream to produce a digit cipher text

Confusion: Each bit of cipher text should depend on a different part of the key, and there’s no relation between the cipher text and key.

Diffusion: Change one bit of plaintext will result in theoretical change in half of the bits in the cipher text

Avalanche effect: small changes to plaintext result in huge change in cipher text

SP boxes/substitution-permutation network: (operation applied to block cipher):

Each plaintext block is divided into sub-blocks. Round key is derived from the general key, and combined with sub-blocks in each round to form input sub-blocks. 

Sub-blocks go through different substitution boxes (S-boxes) or permutation boxes (P-boxes) to produce the cipher text block. S/P - boxes are applied in alternating rounds. S-boxes are like substitution cipher, whereas P-boxes distribute any bit to as many S-boxes input as possible

Change in one input bit to S-boxes result in huge change of output bits

Satisfy confusion and diffusion principle

Fiestal Networks: Each plaintext block is divided into two equal sub-blocks. Right block is combined with round key Ki to be fed into round function F, output is XOR with left block to produce the right block for next round. Left block for next round equals to right block in previous round.

Encryption: L(i+1) = Ri; R(i+1) = Li XOR F(Ri,Ki)

Decryption: Ri = L(i+1); Li = R(i+1) XOR F(L(i+1), Ki)

Block cipher mode: 

Electronic code book: Divide the plaintext into blocks and encrypt them separately. Same blocks of input will result in same block of output. Copy and paste the plaintext and observe that cipher 1 and 5 have repetition in its encoded blocks, so are ECB.

Cipher block chaining: XOR previous cipher text block with plaintext block then encrypt using the same key (first block XOR with an IV. Same input block will result in different output block, but not parallelisable. Cipher 3 and 4 produce different cipher text blocks with the same plaintext blocks, so are CBC.

Counter mode: A pseudo-stream cipher. Instead of XOR with a bit of pseudorandom key stream, each bit of plaintext is combined with a bit of random nonce and counter value encrypted together. Since counter is increased for each subsequent block, same bit of input results in different bit of output. Since encryption of each block doesn’t require previous output, hence is parallelisable. Adding one character of plaintext doesn’t change the previously encrypted bit, hence cipher 2, which behaves like a stream cipher, is CTR.

[lockingishard]

Spot the fake

An example of something that has been faked:

Data that is used to calculate university ranking. A most recent example on the news is five universities in the U.S. “misreporting” figures used to calculate ranking to the U.S. News, including University of California - Berkeley and the Scripps college. Johnson & Wales University has been reporting its financial budget for all campuses for its financial budget for the Providence campus. Financial resources expenditures per student accounts for 10% of the Best Colleges ranking. UCB has been incorrectly included pledges in the alumni in its reported average alumni giving rate (reported figure in 2016 was 11.6%, when the correct figure was 7.9%), which accounts for 5% of the Best Colleges ranking.

How it was achieved:

The official statement of U.S. News says it “relies on schools to accurately report their data, and U.S. News reviews the Best Colleges data in a number of different ways. This includes flagging year-over-year discrepancies, comparing data against federal government sources when available and asking a school official to sign off on the school's data.” This means that if an uni wants to spike up its ranking, there’s few (probably student loan default rates or federally-tracked documents) that it can’t manipulate.

How it can be prevented:

External auditing of financial statements should be conducted more rigorously, and the ranking system should be re-structured to rely more on open-source, transparent data to lessen colleges’ incentive to manipulate.

Things that can be spoofed:

Membership of studios/shops. Most of the dance studios have 10-class packages which are cheaper than buying single class. However, the only authentication they use to check is asking you to sign your name each time you go to a class, and count the number of people in each room to see if the number matches, then go to the system to check access right of each name on the sign-on sheet. Since they never check whether you are really the person you sign, transfer of classes can effectively happen at no cost. There’s one time my friend and I split the cost of 10-class passes and “share the same name” to save money when neither of us need 10 classes at that moment.

Attitude towards a relationship. People can breeze through a “relationship” faking that you love someone by saying sweet things, giving little gifts and faking that you have something in common by just watching a few episodes and heaps of memes of piece of entertainment your target is interested in.

[lockingishard]

Ducky video and scripts

Last update for the project:

What is a rubber ducky and why is it dangerous: https://vimeo.com/350243591

Password stealing/file exfiltration scripts (Win10):

https://github.com/HelenaCutie/Ducky-scripts

[lockingishard]

Something Awesome final update - TRIED

Now the hardware, scripts, video and possible defence against rubber ducky are all done. I’ll mark this the end of my something awesome project :)

My initial criteria was as followed: Pass - Make a video on the major threats of a rubber ducky and how it works; Credit - Build a functioning rubber ducky with Arduino Leonardo, USB cable and a button (able to run simple automated commands); Distinction - Successfully implement file exfiltration AND password hack using the built rubber ducky; High distinction - Successfully Implement both functions above AND defend against both attacks.

Since things didn’t really go in the way I expected, so I’ll just drop some notes on things I’ve learnt along the way.

Pass: Learnt video editing for the first time. In my video I briefly explain how a ducky attack is usually conducted, why it works and common threats associated with it.

Credit: Soldering things up/dealing with small programmable device for the first time in my life. Definitely unforgettable experience. Despite Arduino being a pain in the arse to deal with (the board went dead after I uploaded quite a few times of large sketches, disconnected itself every time I tried uploading even after 10 times of manually resetting the board with a screwdriver to connect the GND and RST ports), I am glad to say that it kind of inspires me into further looking into the possibility it will bring in the future. During troubleshooting with hardware I came across multiple posts in the Arduino forum that ask about issues encountered when building small internet service points and other amazing projects. I’ve never thought of actually implementing small projects at home but now I’m sort of interested. 

Distinction: Although scripts were written and tested with powershelgl and Windows terminal, the attacks were unable to perform on the Arduino Leonardo board itself, which was extremely unfortunate. However, my first time experience with Powershell and a range of system commands was rewarding on its own. It seems that I haven’t explored the power of computer enough, especially dealing with lower level stuff. But on the bright side, I picked up some piece of knowledge regarding networking and user access rules along the way. Besides, the power of my rubber ducky was incredible when it was still alive, which suggests greater threat of the genuinely functioning ones. I’ve never had a clear concept of rubber ducky until I came across it when I researched and implemented the whole project. I might order another board and write some small scripts in the future to make positive use of it. Eh, who knows.

HD: Again defence can’t be demoed now, but I’ve noted down all my findings in the blog. The biggest takeaway from this stage is that it is damn hard to think like an attacker if you are just imagining things without actually doing practical experiments to refine your attacks, hence harder to think like a defender. As I came up with different ways to defend against my own ducky scripts, I was in constant denial of those methods as I could immediately think of some ways to get around them if I were to actually attack someone. Useful defences are the ones that I as a hacker cannot prevent even if I know they’ve been put in place, and sure enough they are hard to come up with.

The project was overall a pleasure to work on. I got to deal with things that I’m extremely unfamiliar with, from the concept of rubber ducky itself to the language I use/device/hardware management. As much as I felt unfortunate for the failure of my project, I am happy with my decision of going with it in the first place.

Code will be uploaded with another post, and that should be the end of it.

Quack!

[lockingishard]

Something awesome update #04 - Defence against rubber ducky

In my criteria for HD, I am asked to propose defence against file exfiltration and password stealing ducky attacks. My Arduino Leonardo board is pretty much dead now after yesterday’s fiddling (will post reflection later), so unfortunately I cannot provide video of successful defence against my own script. Nevertheless, my experience and research are still worth sharing.

Junior approach of defence: These are some tips I came up with during development of the project before researching systematic defence against keystroke-injection attacks. They are noob-friendly, do not require low-level configuration of OS or installation of software, and should mainly be implemented at individual level instead of enterprise-wide.

Disclaimer: Some tips may not defend against more advanced ducky attacks and may only work against crappy ducky script such as my ones. 

Customise own shortcut key combination. This is something I noticed while experimenting my ducky on my friend’s 2014 old MacBook Pro. Her laptop did not enable GUI+SPACE combination to open up Spotlight, basically disrupting the attack flow right from the start. Most ducky scripts I’ve seen online, mine included, utilise shortcut key combination at some point during the attack, mainly to open up dialogue window and navigate through options (such as ALT+ ‘Y’ to permit access when you try to open up terminal and Windows asks if you allow this programme to make changes on your computer). Although attackers with physical access to the computer can deliberately insert some delay time around code that utilises shortcut key, and manually click things to make attacks flow, the extra time needed to perform the attack already defeats the purpose of rubber ducky - the more time they spend around the computer the more likely they will be found out. This method works best against scenarios with absence of attackers, such as dropping USB drives and waiting for victims to pick up/social engineering asking them to plug USB into the computer. Disadvantage: Effect is trivial if attackers take this defence into account and have physical access to the computer.

Different input language method. This is something I came across when I did initial testing on my ducky script. If the victim computer uses language input other than English, the whole attack flow will be disrupted. Surely, recon/social engineering can be done prior to attacks to observe the input method preference on victim’s computer, and modifications on code can be made to ensure attack flow. Attackers can also put delay right at the start to allow time for manually switching input language with physical access guaranteed. But this is something simple and elegant that works against attacks when hackers do not have opportunities to conduct thorough recon. Disadvantage: Same as above.

Antivirus softwares. This is a cliche one but still worth mentioning. As I’m using Mimikatz to realise the password stealing part of my ducky script, this method successfully defends my own attack. Some antivirus applications have mitigations specific to Mimikatz. The app I originally installed on my laptop (360 antivirus app) automatically deletes Mimikatz.exe every time I try to execute it. This defence can be used against other malware-injection attacks performed by ducky as well. Disadvantage: Does not work against advanced ducky attack, such as ones incorporating root kits.

Add inbound/outbound rules for your network (Windows). The password stealing code initially utilises port 587 which is prohibited by my laptop by default. It is suggested that you add rules to restrict use of common smtp port such as 587, 25 and 465, which are most widely used by attackers to send stolen files to themselves. Disadvantage: This defence is specific to attacks making use of network, hence not generic enough.

Tamper-evident methods. This is a hypothetical solution as I don’t have time to try it out myself. The main sort of tamper-evident method I came up with was logging the keystroke activity. This can be done by attaching an unnoticeable key-logger to your computer and reviewing the keystrokes periodically to identify any evidence of a ducky attack. There are several softwares out there, including Keyboard Tracer, to do the same job for you. After each session of typing, owner can type a special combination of keystrokes to signal the end of session, so that when reviewing keystroke activity owner input can be differentiated from malicious input. Disadvantage: Reviewing keyboard log can take up quite a bit of time, and the special combination of keystrokes may be revealed by recon/social engineering. Security through obscurity is never the best option.

Senior approach of defence: After research I found some more generic defence that might be taken into consideration by enterprise/public environment.

Blocking device inputting abnormal typing sequence. This is a hypothetical system/software design proposed by this paper. Since ducky attacks need to be done as quick as possible, the keystrokes sent by such devices usually significantly differ from human keystroke-injection pattern, with average ducky keystroke injection speed being 6 ms and average human typing speed > 80 ms. One mitigation relies on authentication of HID devices based on such difference in typing dynamics to protect computer against ducky attacks. If the USB host monitor has access to timing information of the received USB packets, and is able to detect a sequence of keystroke input s at speed faster than a given timing threshold, then it can ask the operating system to uninstall the device driver for the abnormal HID keyboard, and switch off the USB port for certain amount of time. To disable this piece of software multi-factor authentication is needed. Disadvantage: Trade-off between Type-I and Type-II errors. If users can indeed reach the typing speed of the set threshold, then occasional interruption of normal keystroke flow (Type-I error) will be the price for preventing malicious keystroke input (Type-II error). One scenario when Type-I error will occur is usage of Yubico YubiKey, which is used for two-factor authentication by typing OTP and other information on behalf of the person being authenticated. This trade-off, however, is deemed necessary on a larger scale of user environment.

Black/whitelisting USB devices. A more complete USB authorisation framework has been published targeting Linux users (apology for not installing Linux yet), which can be found here. Other methods black/whitelisting rely on configuring a list of trusted USB drives with certain VID/PID, and blocking all other devices. Disadvantage: Practicality of this method in public environment or large companies is in question; hackers, me included, are able to flash their USB devices with firmware of whitelisted devices to present authorised PID/VID, hence attacks will remain unnoticed.

Ducky hunt script. Proof-of-concept can be found here. Idea is that we search for all devices with action type “PnpDeviceConnected” and type “HID Keyboard”, then monitor their processes to identify ones that start their process very shortly after loading (<10 s) that involves executing terminal/powershell/bash script/other common features of ducky attacks. Disadvantage: Assumption of the process used by hackers means this defence is likely to have a few misses. Nevertheless, it is better than nothing.

[lockingishard]

Something awesome update #03 - Learning powershell & Major work finished

Spent the past week exploring how idiot I am:

Summary: Now that I’ve finished the scripts for password stealing (Windows) using Mimikatz and file exfiltration (OSX), just a few more tests needed to be done to adjust the delay time to the system response speed.

The script for password stealing basically downloads Mimikatz from GitHub repository, runs the Mimikatz.exe corresponding to the 32/64-bit system, puts in some simple commands then outputs the activity log to designated folder, which is sent to the attacker’s burner-email. All evidences, including files downloaded and created, windows run history and command line history, are cleared.

ToDo: Video on the threats of rubber ducky; ways to prevent the above attacks and other attacks by ducky in general.

Major progress:

Had no experience with powershell at all, so did a bit research before I started to figure out the correct way to implement my idea. Some of the methods, such as invoke-WebRequest, did not work for me and I wasted a few hours figuring out that it’s probably due to different versions. So I searched up some methods that actually worked for my powershell 2.0 (E.g. System.Net.WebClient).

Spent a solid day on trying to figure out why I couldn’t download file using System.Net.WebClient. Error message read: “Exception calling"DownloadFile" with "2" argument(s):"An exception occurred during a webClient request.” Somehow in the first few hours I searched up “web client access denied” instead of “web client exception” which showed no useful information and got me stuck in a deadlock. Eventually I was reminded of my own stupidness by solution here - the second parameter should have the filename appended to the path as well.

Then, half a day of research was dedicated to “the remote server returned an error: (403) Forbidden”. The eureka moment was brought by this answer, which suggested that the problem might be “Scripts should use an informative User-Agent string with contact information, or they may be IP-blocked without notice.” So I went on to search up how to set up user-agent header in powershell, and this dude here saved my life.

To unzip the downloaded mimikatz: this solution here doesn’t really work for me, so after an hour of trial-and-error I simply got rid of the loop and it worked…computer is amazing.

Attempted to send email via smtp but error message popped up “server not specified” when trying SMTPInfo.send. This dude suggests a possibility of firewall rules blocking access to server, but requires testing with telnet. Research was done to figure out how to install telnet. Tested “telnet 101.198.198.198 587” resulted in “cannot open connection to server. Port 587: Connection failed”. Another half of day of research was dedicated to hook that connection up :( Some suggested to add inbound and outbound rule to allow port 587 to connect to ISP server, but sadly that did not work for me.

Changed the port from 587 to 25 solved the problem. Speechless.

Gmail automatically blocks email from suspicious senders, so in order to receive the attachment we have to enable less secure apps in Google Account of our burner email. Aw, Google you’re nice and ethical.

Researched on how to clear up Windows run history. This solution pointed me the right direction. Further research such as here, here and here allowed me to arrive at the right place.