Suramya's Blog : Welcome to my crazy life…

June 5, 2022

Hacking a computer using Ham radio transmissions is now possible!

Filed under: Computer Security,Computer Software,Tech Related — Suramya @ 11:59 PM

Hacking a computer by getting them to listen to a Ham Radio station broadcast seems like the plot of a bad movie or TV series about ‘hackers’ but this is not a fictional story. It is now in fact possible to hack a WinXP & Windows 10 computer over the air, All we need to do is ensure that the target is using WinARPS on their computer to listen to the broadcast and then they are fair game.

I am in awe of this finding because figuring out how to generate radio packets that will cause a memory overflow/corruption and then figure out who to generate the packets in a way that allows you to get RCE (Remote Code Execution) requires phenomenal hacking skills and understanding of the underlying systems.

WinARPS is unlikely to get a fix for the issue because the author no longer has an environment to build/test the software as the last update to the code was back in 2013. However the author is aware of the problem and who knows they might get the environment working again and fix the issue.

Video demo of the issue on a Windows 10 machine (Credit:

This bug does show us that we can have the world’s most protected / isolated system but if there is any way to get external information/input then the system can potentially be attacked.

You can read the full walk through of the process at: Hacking Ham Radio: WinAPRS – Part 5

– Suramya

May 4, 2022

Using reflection in pupils in public selfies to figure out the different ways a user can hold a device

Filed under: Computer Software,My Thoughts,Tech Related — Suramya @ 11:58 PM

Users in TV/Movies have been able to zoom enhance photo’s that look like they were taken with a broken down webcam from the 80’s to give crystal clear images for a while now. In fact the Zoom/Enhance trope has become so common that there are a whole bunch of meme’s out there for it.

Till recently such activities were possible only in the fictional world, thanks to advances in photo technologies and the increasing no of mega-pixels (plus other things) in the modern camera this is now possible in the real world as well. A few years ago, a Japanese stalker was arrested after he stalked and assaulted a 21-year-old “Japanese idol” at her home by zooming into a high-resolution selfie posted by the singer to view the train station reflected in her eye.

Now, a group of researchers from Keio University, Yahoo Japan, and the Tokyo University of Technology are using publicly posted selfies by users to examine the reflection of the smartphone taking the picture in the pupils of the photo to figure out how the phone is being used i.e. the different ways a user can hold a device like a smartphone: with both hands, just the left, or just the right in portrait mode, and the same options in horizontal mode. There are a bunch of potential uses for this technique and it is interesting and unique research.

But it also highlights the fact that we need to be careful of what we post/share as there might be information in the picture that we didn’t want to share. If you search for ‘photo sent caught cheating’ you will find multiple instances of folks sending pics that got them in trouble because there was something in the pic that gave the game away, such as this one or this one

Source: Using Pupil Reflection in Smartphone Camera Selfies

– Suramya

April 29, 2022

Malware in Windows: TPM Bypasses & Firmware level persistence

Malware is the short form for Malicious Software and is basically software that allows attackers to infect a computer system or device to steal information, disrupt operations or gain access to sensitive data. It is a general term that includes viruses, worms, trojans, spyware, rootkits etc. (Cisco, 2021)

Conceptually the foundations for creating malware were laid almost simultaneously with the creation of the first computers. In 1951, John von Neumann proposed methods on how to create self-replicating automata (Neumann, 1951) and a few years later in 1959 Lionel Penrose published his paper on ‘Self-Reproducing Machines’ this paper was used as the basis for creating replicating machine code that were the basis of the later generations of malware. In 1970’s the creeper virus infected the ARPANET (Milošević, 2013) followed shortly after by Rabbit (Milošević, 2013) which spread rapidly to computers and created copies of itself overloading the machine and impacting system performance. (Milošević, 2013)

In the 1986, the first malware called Brain.A that targeted the PC platform was released. (Milošević, 2013) It used floppy disks as the infection mechanism by infecting the boot sector of every floppy disk used in an infected computer. Other viruses of the time used similar mechanisms to propagate and were quite prevalent by the measures of the time. Once Microsoft Windows was released viruses were created that targeted the new operating system with WinVir being the first virus for the new operating system, it gained persistence by modifying the Windows Executable files. (Milošević, 2013) It spread to new systems over floppy disks.
For almost a decade, infected disks and CD’s remained the primary method of infection for computers. In 1998 this changed with the release of Happy99 in late 1998 that spread via email attachments. Another popular vector for virus infections was macro viruses that infected Microsoft word files which were shared frequently with other users allowing the virus to spread. With the increasing popularity of the Internet, the new malware created during this time leveraged the internet as a transmission vector.

In early 2000, Code Red worm was created that leveraged vulnerabilities in the IIS webservers to propagate. (Milošević, 2013) This opened a new infection vector where the malware would scan for and exploit systems running vulnerable software.

Over the years, malware has become more and more common and has evolved to gain persistence using multiple methods such as using rootkits to infect the OS kernel and other such methods. The one constant throughout the years was that we could clean up a malware infection by formatting the infected drive and restoring from a clean backup. As long as the backup and the installation media were clean we could be confident that the infection was cleared.

Unfortunately, this is no longer the case with new strains of malware using sophisticated techniques to gain persistence using the computer firmware.

A. UEFI malware – The early years

UEFI rootkits were referenced in various leaks and were considered mostly theoretical. The Hacking Team referenced something called ‘rkloader’ in their internal presentations and the Vault7 leaks referenced ‘DerStarke’ which was an EFI/UEFI boot implant. But there was no real evidence of these being used so they were considered mostly theoretical for the most part.

This changed in 2018 when the first rootkit that leveraged the UEFI to achieve persistence was discovered. This malware called Lojax was created by the Sednit APT group. It used a malicious UEFI module written into the SPI flash memory to ensure that it was able to execute malware during the boot up process. (ESET Research, 2018)

B. UEFI Malware – Infecting SPI flash memory

The LoJax malware used the kernel driver RwDrv.sys to access the UEFI settings. The driver is distributed with RWEverything, a freeware utility that can read the BIOS information in most computers. (ESET Research, 2018)

The malware used this driver to read the contents of the SPI flash memory into a file, by running a file called ReWriter_binary.exe. The data in the SPI is stored in volumes using the Firmware File System (FFS). It then parses the volues to search for the Ip4Dxe file. This file along with DXE Core is then modified to add the malicious UEFI module to it post which the entire file is written back to the SPI memory. If the configuration allows write access to SPI the malware immediately writes to the SPI memory but if write access is disabled it exploited a race condition vulnerability in the BIOS locking mechanism to bypass the write protection in SPI flash memory. (CERT, 2015)

C. MoonBounce: UEFI Bootkit

The MoonBounce Bootkit is the third instance of malware that uses UEFI to gain persistence, with Lojax and MosaicRegressor being the other two instances where it was used.

MoonBounce is a lot more sophisticated than the previous iterations and it executes completely in the system memory without writing anything to the hard drive making it a lot harder to detect than the previous iterations of the malware. It stages the execution and deployment of payloads over the internet allowing the attacker to deploy payloads on the system to achieve specific tasks.
MoonBounce was detected in spring 2021 and like the previous iterations attacks the DXE Core module in UEFI to infect the SPI Memory.

D. Using TPM Module & Trusted Computing to protect against this attack

The TPM Module in the modern machines is designed to provide hardware-based, security-related functions and allows the system to secure the system using integrated cryptographic keys.

If TPM is enabled and is being used correctly then it gives the system a way to ensure that all firmware and boot files are unmodified. If any of the files are modified then they will not pass the cryptographic check and the boot process will be halted. This would prevent the infected SPI memory from being loaded and would warn the defenders that their system has been breached.

Unfortunately, it is possible to disable the TPM chip for historical compatibility reasons, so the malware can do the same. One of the ways to disable the check and bypass the Secure Boot & TPM check is to modify the registry files in Windows. The steps to do so are very simple and are shown below (Tibbetts, 2021):

  • At the run prompt type in regedit, and press Enter.
  • Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup
  • Right-click on Setup and click New > Key. Name that LabConfig
  • Click on LabConfig, then right-click on the right pane, and click New > DWORD (32-bit Value).
  • Name the entry as BypassTPMCheck and change its Value data to 1
  • Create two more DWORDS and change the Value data to 1 just like you did above and name them BypassRAMCheck and BypassSecureBootCheck.

This removes the check for Secure Boot and while it can be desired at times it does open up the system to risk so should only be used for specific use cases where no other option is available.

Protecting against malware using firmware level persistence

To protect against this threat, we need to ensure that all components of the operating system and software on the computer are patched and updated to the latest version. We should enable end-point monitoring and IDS on the network to detect infection attempts. This will allow us to detect the malware before it infects the system and block it pre-emptively. The internet and email gateways should scan all incoming files to detect and block malware. In addition to the standard precautions to protect against malware, we should also ensure that all systems on the network are running the latest version of the UEFI/BIOS available.

Unfortunately, the remediation of the security issues in UEFI is a hard problem and doesn’t have an easy solution. So, the best way to protect against the threat is to try to prevent the system from getting infected in the first place.

Another option to detect infected SPI Memory is to create a tool that periodically creates a dump of the SPI memory and compares the checksum of the dump with a known clean dump. If the values don’t match then there is a high probability that the memory is infected and the administrators can then take steps to clean the firmware by flashing it with a known clean version of the firmware.

With the new methods of persistence available to the malware writers the best way to protect the assets is to try to ensure that you prevent the infection from happening in the first place. Once the machine is infected the task becomes harder and we would need to spend extra time and effort to clean and restore the systems to a clean state.
Done correctly this will decrease the risk of data exfiltration but no technique to detect infection is perfect so a lot of review and audits need to be done on a periodic basis to ensure that the system is still secure.


CERT. (2015, January 5). CERT/CC Vulnerability note vu#766164. VU#766164 – Intel BIOS locking mechanism contains race condition that enables write protection bypass. Retrieved March 21, 2022, from

Cisco. (2021, July 30). What is malware? – definition and examples. Cisco. Retrieved March 21, 2022, from
ESET Research. (2018, October 9). Lojax: First UEFI rootkit found in the wild, courtesy of the Sednit Group. WeLiveSecurity. Retrieved March 21, 2022, from

Neumann, J. V. (1951). Massachusetts Institute of Technology. Theory of Self Replicating Automata. Retrieved March 21, 2022, from
Tibbetts, T. (2021, July 10). How to bypass secure boot & trusted platform module. Providing Free and Editor Tested Software Downloads. Retrieved March 21, 2022, from

This was a paper for my Class in Q1 2022 which is why it is more formal than my usual posts.

April 24, 2022

Smart-contract bug locks away $34 million highlighting major weakness in smart-contracts

Filed under: Computer Software,Emerging Tech,Tech Related — Suramya @ 9:57 PM

Over the years I have had many conversations with people about Blockchain and how it is supposed to solve all our problems, but for the most part I think Blockchain is overrated and doesn’t solve any problem that can’t be solved in an easier way using less resources. Then as if Blockchain’s were not enough someone went and created smart contracts which are basically programs stored on a blockchain that run when predetermined conditions are met. They typically are used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when conditions are met.IBM Smart-Contracts Def

The major issue with a blockchain contract is that the contract is immutable so if there is a bug in the program no one can modify it to fix the issue. When warned about this potential problem the proponents of the smart-contract pretty much handwaved the concerns away stating that the issue is not that big a deal and people were just opposing them because they dislike smart-contracts and are sticks in mud etc etc.

Unfortunately, this is no longer a theoretical issue as the developers of the AkuDreams contract found out over the weekend. Due to a bug in the contract code $34 million, or 11,539 eth, is permanently locked into the AkuDreams contract forever. It cannot be retrieved by individual users or by the dev team..

This shows how dangerous it is to have a program that can’t be modified because no matter what we do we can’t ensure that code written will be 100% bug free in all the cases. When there is a bug in regular software be can push out a patch to fix it, but that is not an option for smart-contracts and that as you can see becomes an expensive issue.

Source: $34M permanently locked into AkuDreams contract forever due to bad code

– Suramya

April 22, 2022

Implications and Impact of Quantum Computing on Existing Cryptography

As all of you are aware the ability to break encryption of sensitive data like financial systems, private correspondence, government systems in a timely fashion is the holy grail of computer espionage. With the current technology it is unfeasible to break the encryption in a reasonable timeframe. If the target is using a 256-bit key an attacker will need to try a max of 2256 possible combinations to brute-force it. This means that even with the fastest supercomputer in the world will take millions of years to try all the combinations (Nohe, 2019). The number of combinations required to crack the encryption key increase exponentially, so a 2048-bit key has 22048 possible combinations and will take correspondingly longer time to crack. However, with the recent advances in Quantum computing the dream of breaking encryption in a timely manner is close to becoming reality in the near future.

Introduction to Quantum Computing

So, what is this Quantum computing and what makes it so special? Quantum computing is an emerging technology field that leverages quantum phenomena to perform computations. It has a great advantage over conventional computing due to the way it stores data and performs computations. In a traditional system information is stored in the form of bits, each of which can be either 0 or 1 at any given time. This makes a ‘bit’ the fundamental using of information in traditional computing. A Quantum computer on the other hand uses a ‘qubit’ as its fundamental unit and unlike the normal bit, a qubit can exist simultaneously as 0 and 1 — a phenomenon called superposition (Freiberger, 2017). This allows a quantum computer to act on all possible states of a qubit simultaneously, enabling it to perform massive operations in parallel using only a single processing unit. In fact, a theoretical projection has postulated that a Quantum Computer could break a 2048-bit RSA encryption in approximately 8 hours (Garisto, 2020).

In 1994 Peter W. Shor of AT&T deduced how to take advantage of entanglement and superposition to find the prime factors of an integer (Shor, 1994). He found that a quantum computer could, in principle, accomplish this task much faster than the best classical calculator ever could. He then proceeded to write an algorithm called Shor’s algorithm that could be used to crack the RSA encryption which prompted computer scientists to begin learning about quantum computing.

Introduction to Current Cryptography

Current security of cryptography relies on certain “hard” problems—calculations which are practically impossible to solve without the correct cryptographic key. Just as it is easy to break a glass jar but difficult to stick it back together there are certain calculations that are easy to perform but difficult to reverse. For example, we can easily multiply two numbers to get the result, however it is very hard to start with the result and work out which two numbers were multiplied to produce it. This becomes even more hard as the numbers get larger and this forms the basis of algorithms like the RSA (Rivest et al., 1978) that would take the best computers available billions of years to solve and all current IT security aspects are built on top of this basic foundation.

There are multiple ways of classifying cryptographic algorithms but in this paper, they will be classified based on the keys required for encryption and decryption. The main types of cryptographic algorithms are symmetric cryptography and asymmetric cryptography.

Symmetric Cryptography

Symmetric cryptography is a type of encryption that uses the same key for both encryption and decryption. This requires the sender and receiver to exchange the encryption key securely before encrypted data can be exchanged. This type of encryption is one of the oldest in the world and was used by Julius Caesar to protect his communications in Roman times (Singh, 2000). Caesar’s cipher, as it is known is a basic substitution cypher where a number is used to offset each alphabet in the message. For example, if the secret key is ‘4’ then each alphabet would be replaced with the 4th letter down from it, i.e. A would be replaced with E, B with F and so on. Once the sender and receiver agree on the encryption key to be used, they can start communicating. The receiver would take each character of the message and then go back 4 letters to arrive at the plain-text message. This is a very simple example, but modern cryptography is built on top of this principle.

Another example is from world war II during which the Germans were encrypting their transmissions using the Enigma device to prevent the Allies from decrypting their messages as they had in the first World War (Rijmenants, 2004). Each day both the receiver and sender would configure the gears and specific settings to a new value as defined by secret keys distributed in advance. This allowed them to transmit information in an encrypted format that was almost impossible for the allied forces to decrypt. Examples of symmetric encryption algorithms include Advanced Encryption Standard (AES), Data Encryption Standard (DES), and International Data Encryption Algorithm (IDEA).

Symmetric encryption algorithms are more efficient than asymmetric algorithms and are typically used for bulk encryption of data.

Asymmetric Cryptography

Unlike symmetric cryptography asymmetric cryptography uses two keys, one for encryption and a second key for decryption (Rouse et al., 2020). Asymmetric cryptography was created to address the problems of key distribution in symmetric encryption and is also known as public key cryptography. Modern public key cryptography was first described in 1976 by Stanford University professor Martin Hellman and graduate student Whitfield Diffie. (Diffie & Hellman, 1976)

Asymmetric encryption works with public and private keys where the public key is used to encrypt the data and the private key is used to decrypt the data (Rouse et al., 2020). Before sharing data, a user would generate a public-private keypair and they would then publish their public key on their website or in key management portals. Now, whoever wants to send private data to them would use their public key to encrypt the data before sending it. Once they receive the cipher-text they would use their private key to decrypt the data. If we want to add another layer of authentication to the communication, the sender would encrypt the data with their private key first and then do a second layer of encryption using the recipient’s public key. The recipient would first decrypt the message using their private key, then decrypt the result using the senders public key. This validates that the message was sent by the sender without being tampered. Public key cryptography algorithms in use today include RSA, Diffie-Hellman and Digital Signature Algorithm (DSA).

Quantum Computing vs Classical Computing

Current state of Quantum Computing

Since the early days of quantum computing we have been told that a functional quantum computer is just around the corner and the existing encryption systems will be broken soon. There has been significant investment in the field of Quantum computers in the past few years, with organizations like Google, IBM, Amazon, Intel and Microsoft dedicating a significant amount of their R&D budget to create a quantum computer. In addition, the European Union has launched a Quantum Technologies Flagship program to fund research on quantum technologies (Quantum Flagship Coordination and Support Action, 2018).

As of September 2020, the largest quantum computer is comprised of 65 qubits and IBM has published a roadmap promising a 1000 qbit quantum computer by 2023 (Cho, 2020). While this is an impressive milestone, we are still far away from a fully functional general use quantum computer. To give an idea of how far we still have to go Shor’s algorithm requires 72k3 quantum gates to be able to factor a k bits long number (Shor, 1994). This means in order to factor a 2048-bit number we would need a 72 * 20483 = 618,475,290,624 qubit computer which is still a long way off in the future.

Challenges in Quantum Computing

There are multiple challenges in creating a quantum computer with a large number of qubits as listed below (Clarke, 2019):

  • Qubit quality or loss of coherence: The qubits being generated currently are useful only on a small scale, after a particular no of operations they start producing invalid results.
  • Error Correction at scale: Since the qubits generate errors at scale, we need algorithms that will compensate for the errors generated. This research is still in the nascent stage and requires significant effort before it will be ready for production use.
  • Qubit Control: We currently do not have the technical capability to control multiple qubits in a nanosecond time scale.
  • Temperature: The current hardware for quantum computers needs to be kept at extremely cold temperatures making commercial deployments difficult.
  • External interference: Quantum computes are extremely sensitive to interference. Research at MIT has found that ionizing radiation from environmental radioactive materials and cosmic rays can and does interfere with the integrity of quantum computers.

Cryptographic algorithms vulnerable to Quantum Computing

Symmetric encryption schemes impacted

According to NIST, most of the current symmetric cryptographic algorithms will be relatively safe against attacks by quantum computer provided a large key is used (Chen et al., 2016). However, this might change as more research is done and quantum computers come closer to reality.

Asymmetric encryption schemes impacted

Unlike symmetric encryption schemes most of the current public key encryption algorithms are highly vulnerable to quantum computers because they are based on the previously mentioned factorization problem and calculation of discrete logarithms and both of these problems can be solved by implementing Shor’s algorithm on a quantum computer with enough qubits. We do not currently have the capability to create a computer with the required number of qubits due to challenges such as loss of qubit coherence due to ionizing radiation (Vepsäläinen et al., 2020), but they are a solvable problem looking at the ongoing advances in the field and the significant effort being put in the field by companies such as IBM and others (Gambetta et al., 2020).

Post Quantum Cryptography

The goal of post-quantum cryptography is to develop cryptographic algorithms that are secure against quantum computers and can be easily integrated into existing protocols and networks.

Quantum proof algorithms

Due to the risk posed by quantum computers, the National Institute of Standards and Technology (NIST) has been examining new approaches to encryption and out of the initial 69 submissions received three years ago, the group has narrowed the field down to 15 finalists and has now begun the third round of public review of the algorithms (Moody et al., 2020) to help decide the core of the first post-quantum cryptography standard. They are expecting to end the round with one or two algorithms for encryption and key establishment, and one or two others for digital signatures (Moody et al., 2020).

Quantum Key Distribution

Quantum Key Distribution (QKD) uses the characteristics of quantum computing to implement a secure communication channel allowing users to exchange a random secret key that can then be used for symmetrical encryption (IDQ, 2020). QKD solves the problem of secure key exchange for symmetrical encryption algorithms and it has the capability to detect the presence of any third party attempting to eavesdrop on the key exchange. If there is an attempt by a third-party to eavesdrop on the exchange, they will create anomalies in the quantum superpositions and quantum entanglement which will alert the parties to the presence of an eavesdropper, at which point the key generation will be aborted (IDQ, 2020). The QKD is used to only produce and distribute an encryption key securely, not to transmit any data. Once the key is exchanged it can be used with any symmetric encryption algorithm to transmit data securely.


Development of a quantum computer may be 100 years off or may be invented in the next decade, but we can be sure that once they are invented, they will change the face of computing forever including the field of cryptography. However, we should not panic as this is not the end of the world as the work on quantum resistant algorithms is going much faster than the work on creating a quantum computer. The world’s top cryptographic experts have been working on Quantum safe encryption for the past three years and we are nearing the completion of the world’s first post-quantum cryptography standard (Moody et al., 2020). Even if the worst happens and it is not possible to create a quantum safe algorithm immediately, we still have the ability to encrypt and decrypt data using one-time pads until a safer alternative or a new technology is developed.


Chen, L., Jordan, S., Liu, Y.-K., Moody, D., Peralta, R., Perlner, R., & Smith-Tone, D. (2016). Report on Post-Quantum Cryptography.

Cho, A. (2020, September 15). IBM promises 1000-qubit quantum computer-a milestone-by 2023. Science.

Clarke, J. (2019, March). An Optimist’s View of the Challenges to Quantum Computing. IEEE Spectrum: Technology, Engineering, and Science News.

Diffie, W., & Hellman, M. (1976). New directions in cryptography. IEEE Transactions on Information Theory, 22(6), 644–654.

Freiberger, M. (2017, October 1). How does quantum computing work?

Gambetta, J., Nazario, Z., & Chow, J. (2020, October 21). Charting the Course for the Future of Quantum Computing. IBM Research Blog.

Garisto, D. (2020, May 4). Quantum computers won’t break encryption just yet.

IDQ. (2020, May 6). Quantum Key Distribution: QKD: Quantum Cryptography. ID Quantique.
Moody, D., Alagic, G., Apon, D. C., Cooper, D. A., Dang, Q. H., Kelsey, J. M., Yi-Kai, L., Miller, C., Peralta, R., Perlner R., Robinson A., Smith-Tone, D., & Alperin-Sheriff, J. (2020). Status report on the second round of the NIST post-quantum cryptography standardization process.

Nohe, P. (2019, May 2). What is 256-bit encryption? How long would it take to crack?
Quantum Flagship Coordination and Support Action (2018, October). Quantum Technologies Flagship.

Rijmenants, D. (2004). The German Enigma Cipher Machine. Enigma Machine.

Rivest, R. L., Shamir, A., & Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2), 120–126.

Rouse, M., Brush, K., Rosencrance, L., & Cobb, M. (2020, March 20). What is Asymmetric Cryptography and How Does it Work? SearchSecurity.

Shor, P. w. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings 35th Annual Symposium on Foundations of Computer Science, 124–134.

Singh, S. (2000). The code book: The science of secrecy from Egypt to Quantum Cryptography. Anchor Books.

Vepsäläinen, A. P., Karamlou, A. H., Orrell, J. L., Dogra, A. S., Loer, B., Vasconcelos, F., David, K. K., Melville A. J., Niedzielski B. M., Yoder J. L., Gustavsson, S., Formaggio J. A., VanDevender B. A., & Oliver, W. D. (2020). Impact of ionizing radiation on superconducting qubit coherence. Nature, 584(7822), 551–556.

Note: This was originally written as a paper for one of my classes at EC-Council University in Q4 2020, which is why the tone is a lot more formal than my regular posts.

– Suramya

April 21, 2022

It is possible to plant Undetectable Backdoors in Machine Learning Models

Machine learning (ML) is the big thing and ML algorithms are slowly creeping into all aspects of our life such as unlocking your phone using facial recognition, evaluating the eligibility for a loan, surveillance, what ads you see when surfing the web, what search results you get when searching for stuff etc etc. The problem is that ML algorithms are not infallible they depend on the training data used, confirmational bias etc. At the very least they enforce the existing bias for example, if a company only hires men 25-45 for a role then the ML data set will take this as the input and all future candidates will be evaluated against this criteria because the system thinks that this is what a success looks like. The algorithms themselves are getting more and more complicated and it is almost impossible to review and validate the findings. Due to this decisions are being made by machines that can’t be audited easily. Plus it doesn’t help that most ML models are proprietary and the companies refuse to let outsiders examine them due to Trade secrets and proprietary information used in them.

Another problem is that these ML models is adversarial perturbations where attackers make minor changes to the image/data going in to get a specific response/output. There are a lot of examples of this in the past few years and some of them are listed below (Thanks to Cory Doctorow for consolidating them in one place)

These all take advantage of flaws in the ML model that can be exploited using minor changes in the input data. However, there is another major exploit surface available which is incredibly hard to protect against: Backdoors in the ML models by creating a model that will accept a particular entry/key to produce a specific output. The ‘best’ part is that it is almost impossible to detect if this has been done because the model will function exactly the same as an un-tampered model and will only show the abnormal behavior for the specific key which would have been randomly generated by the creator during the training. If done well then the modifications will be undetectable for most tests.

A team for MIT and IAS has written a paper on it (“Planting Undetectable Backdoors in Machine Learning Models“) where they go into details of how this can be done and the potential impact. Unfortunately, they have not been able to come up with a feasible defense against this attack as of this time. Hopefully that will change as others start focusing on this problem and how to solve it.

Given the computational cost and technical expertise required to train machine learning models, users may delegate the task of learning to a service provider. We show how a malicious learner can plant an undetectable backdoor into a classifier. On the surface, such a backdoored classifier behaves normally, but in reality, the learner maintains a mechanism for changing the classification of any input, with only a slight perturbation. Importantly, without the appropriate “backdoor key”, the mechanism is hidden and cannot be detected by any computationally-bounded observer. We demonstrate two frameworks for planting undetectable backdoors, with incomparable guarantees.

First, we show how to plant a backdoor in any model, using digital signature schemes. The construction guarantees that given black-box access to the original model and the backdoored version, it is computationally infeasible to find even a single input where they differ. This property implies that the backdoored model has generalization error comparable with the original model. Second, we demonstrate how to insert undetectable backdoors in models trained using the Random Fourier Features (RFF) learning paradigm or in Random ReLU networks. In this construction, undetectability holds against powerful white-box distinguishers: given a complete description of the network and the training data, no efficient distinguisher can guess whether the model is “clean” or contains a backdoor.

Our construction of undetectable backdoors also sheds light on the related issue of robustness to adversarial examples. In particular, our construction can produce a classifier that is indistinguishable from an “adversarially robust” classifier, but where every input has an adversarial example! In summary, the existence of undetectable backdoors represent a significant theoretical roadblock to certifying adversarial robustness.

The paper is still waiting for the peer-review to complete but the concept and methods they describe seem solid so this is a problem we will have to solve sooner rather than later considering the speed with which ML models are impacting our life.

Source: Schneier on Security: Undetectable Backdoors in Machine-Learning Models

– Suramya

April 14, 2022

Ensure your BCP plan accounts for the Cloud services you depend on going down

Filed under: Computer Software,My Thoughts,Tech Related — Suramya @ 1:53 AM

Long time readers of the blog and folks who know me know that I am not a huge fan of putting everything on the cloud and I have written about this in the past (“Cloud haters: You too will be assimilated” – Yeah Right…), I mean don’t get me wrong, the cloud does have it’s uses and advantages (some of them are significant) but it is not something that you want to get into without significant planning and thought about the risks. You need to ensure that the ROI for the move is more than the increased risk to your company/data.

One of the major misconceptions about the cloud is that when we put something on there we don’t need to worry about backups/uptimes etc because the service provider takes care of it. This is obviously not true. You need to ensure you have local backups and you need to ensure that your BCP (Business Continuity Plan) accounts for what you would do if the provider itself went down and the data on the cloud is not available.

You think that this is not something that could happen? The 9 day and counting outage over at Atlassian begs to differ. On Monday, April 4th, 20:12 UTC, approximately 400 Atlassian Cloud customers experienced a full outage across their Atlassian products. This is just the latest instance where a cloud provider has gone down leaving it’s users in a bit of a pickle and as per information sent to some of the clients it might take another 2 weeks to restore the services for all users.

One of our standalone apps for Jira Service Management and Jira Software, called “Insight – Asset Management,” was fully integrated into our products as native functionality. Because of this, we needed to deactivate the standalone legacy app on customer sites that had it installed. Our engineering teams planned to use an existing script to deactivate instances of this standalone application. However, two critical problems ensued:

Communication gap. First, there was a communication gap between the team that requested the deactivation and the team that ran the deactivation. Instead of providing the IDs of the intended app being marked for deactivation, the team provided the IDs of the entire cloud site where the apps were to be deactivated.
Faulty script. Second, the script we used provided both the “mark for deletion” capability used in normal day-to-day operations (where recoverability is desirable), and the “permanently delete” capability that is required to permanently remove data when required for compliance reasons. The script was executed with the wrong execution mode and the wrong list of IDs. The result was that sites for approximately 400 customers were improperly deleted.

To recover from this incident, our global engineering team has implemented a methodical process for restoring our impacted customers.

To give you an idea of how serious this outage is, I will use my personal experience with their products and how they were used in one of my previous companies. Without Jira & Crucible/Fisheye no one will be able to commit code into the repositories or do code reviews of existing commits. The users will not be able to do production / dev releases of any product. Since Confluence is down users/teams can’t access guides/instructions/SOP documents/documentation for any of their systems. Folks who use Bitbucket/sourcetree would not be able to commit code. This is the minimal impact scenario. It gets worse for organizations who use CI/CD pipelines and proper SDLC processes/lifecycles that depend on their products.

If the outage was on the on-premises servers then the teams could fail over to the backup servers and continue, but unfortunately for them the issue is on the Atlassian side and now everyone just has to wait for it to be fixed.

Code commits blocks (pre-commit/post-commit hooks etc) can be disabled but unless you have local copies of the documentation stored in Confluence you are SOL. We actually faced this issue once with our on-prem install where the instructions on how to do the failover were stored on the confluence server that had gone down. We managed to get it back up by a lot of hit & try methods but after that all teams were notified that their BCP/failover documentation needed to be kept in multiple locations including hardcopy.

If the companies using their services didn’t prepare for a scenario where Atlassian went down then there are a lot of people scrambling to keep their businesses and processes running.

To prevent issues, we should look at setting up systems that take auto-backups of the online systems and store it on a different system (can be in the cloud but use a different provider or locally). All documentation should have local copies and for really critical documents we should ensure hard copy versions are available. Similarly we need to ensure that any online repositories are backed up locally or on other providers.

This is a bad situation to be in and I sympathize with all the IT staff and teams trying to ensure that their companies business is running uninterrupted during this time. The person who ran the script on the other hand on the Atlassian server should seriously consider getting some sort of bad eye charm to protect themselves against all the curses flying their way (I am joking… mostly.)

Well this is all for now. Will write more later.

January 27, 2022

New MoonBounce UEFI Bootkit that can’t be removed by replacing the Hard Disk

Filed under: Computer Security,Computer Software,My Thoughts,Tech Related — Suramya @ 1:05 AM

Viruses and malware have evolved a lot in the past 2-2.5 decades. I remember the first virus that infected my computer back in 1998, it corrupted the boot sector and the partition table to the point where I couldn’t even format the drive as it wasn’t detected by the OS. I tried booting via a floppy and running scandisk on it (this is on DOS 6.1/Windows 3.1) but it wouldn’t detect the disk, same issue with Norton Disk Doctor (NDD). Was scared to tell the parents that I had broken the new computer but after a whole night of trying various things based on conversations with friends, suggestions in books etc I managed to get NDD to detect the disk and repair the partition table. After that it was a relatively simple task to format the disk and reinstall DOS. Similarly all the other viruses I encountered could be erased by formatting the disk or replacing it.

There were a few that tried using the BIOS for storing info but not many. I did create a prank program that would throw insults at you when you typed the wrong command every 5th boot. The counter for the boot was kept in the BIOS. But this didn’t have any propagation logic in the code and had to be manually run on each machine, plus it had to be customized manually for very new BIOS type/version so wasn’t something that could spread on its own.

With the new malware/viruses that have come out in the past few decades we are seeing more advanced capabilities of propagation and persistence, but till now you could still replace the drive infected with a virus and be able to start with a clean slate. However, that has now changed with the new MoonBounce UEFI Bootkit which can’t be removed by replacing the Hard Drive as it stores itself in the SPI flaws memory that is found on the motherboard. Which means that the bootkit will remain on the device till the SPI memory is re-flashed or the whole motherboard is replaced. Which makes it very difficult and expensive to recover from the infection.

Securelist has a very detailed breakdown of the Bootkit which you should check out. The scary part is that this is not the only bootkit that uses this method, there are a few others such as ESPectre, FinSpy’s UEFI bootkit that prove that the capability is becoming more mainstream and that we should expect to see more such bootkits in the near future.

Source: Slashdot: New MoonBounce UEFI Bootkit Can’t Be Removed by Replacing the Hard Drive

– Suramya

January 25, 2022

Intentionally breaking popular opensource projects for… something

Filed under: Computer Software,My Thoughts,Tech Related — Suramya @ 10:23 AM

Recently Marak Squires, the developer of extremely popular npm modules Colors & Faker decided to intentionally commit changes into the code that broke the module and brought down thousands of apps world wide. Initially it was thought that the modules were hacked as others have been in the past, but looking at the commit history it was obvious that the changes were committed by the developer themselves. Which brings us to the question of why on earth would someone do something like this? Marak didn’t explicitly state on why the changes were made but considering their past comments it does seem like this was done intentionally:

In November 2020, Marak had warned that he will no longer be supporting the big corporations with his “free work” and that commercial entities should consider either forking the projects or compensating the dev with a yearly “six figure” salary.

“Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn’t much else to say,” the developer previously wrote.

“Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.

The aftermath of the changes is that NPM has revoked the developers rights to commit code, their github account has been suspended and the modules in question have been forked. Now Marak is pleading for his accounts to be reinstated because the issue was caused due to a ‘programming mistake’ which seems like a far fetched excuse. Especially given how they made fun of the problem right after people reporting it. That doesn’t seem like the reaction we would see if this was a legitimate mistake.

My guess is that they thought this would play out differently with companies falling over themselves to give them money/contracts etc or something but didn’t anticipate how it would blow back on them. I mean if I was hiring right now and their resume came up I would think twice about hiring them because of this stunt. They have shown that they can’t be trusted and what is to stop them from making changes to my company’s software and bring it a screeching halt because they felt that they were not being paid their dues? I mean they have already done it once, what is to stop them from doing it again? This looks like a textbook example of what not to do in order to get people to work with you/hire you.

One of the things that I have heard from detractors of OpenSource software when I was pushing for it in my previous companies is the question about how can we be sure the software will be there a year for now and who do we blame if the software is broken and we need help. Stunts like this don’t help improving the image of Open Source software and this person is now reaping their just deserts.

The positive side is that because the code is opensource, it has already been forked and others have taken over the codebase to ensure we don’t hit similar issues going forward.

– Suramya

January 22, 2022

Malware can now Intercept and fake an iPhone reboot

Filed under: Computer Security,Computer Software,My Thoughts,Tech Related — Suramya @ 1:50 AM

Rebooting the system has always been a good way to clean start your system (phone or computer). Some of the phone malware specifically don’t have the ability to persist so can be removed just by rebooting the phone (Especially on the iPhone). Now, researchers from the ZecOps Research Team have figured out how to fake a reboot on an iPhone. Which allows malware/surveillance software to spoof the shutdown / reboot of a phone. As you can imagine, this has massive security impact. The first problem is that we can’t be sure that the phone has been rebooted so malware can’t be removed. Secondly, some of the folks shutdown their phones while discussing sensitive information. Using this technique the attackers can pretend that the phone is switched off, while it is still on and eavesdrop using the phone’s camera and mic.

We’ll dissect the iOS system and show how it’s possible to alter a shutdown event, tricking a user that got infected into thinking that the phone has been powered off, but in fact, it’s still running. The “NoReboot” approach simulates a real shutdown. The user cannot feel a difference between a real shutdown and a “fake shutdown.” There is no user-interface or any button feedback until the user turns the phone back “on.”

The problem is exacerbated due to there not being any physical method of powering the device off. Earlier phone models had removable batteries which allowed a user to physically remove the battery when they wanted to secure the device. Now the battery is built in and there is no way to remove it without dismantling the device and voiding your warranty in the process. I have discussed this with various folks over the years that it is impossible to ensure a device is powered off when we shut it down because we can’t remove the battery.

A silver lining around this is that it looks like hard reboots are harder to spoof so if you want to be sure that your phone is actually off, you can shut it down using a hard-reboot. Another solution is to carry a Faraday bag with you and put your phone inside when you need to be off-grid.

Source: Schneier’s Blog: Faking an iPhone Reboot

– Suramya

Older Posts »

Powered by WordPress