author: aman
Blog I - Part II - Day 02
At CEV, we basically focus on creating inquisitiveness rather than teaching a lot. After all we all are an autodidact, searching for motivation and peers around to learn, to what we call as "Classrooms".
Considering that, I am adding a subpart to the list below, which will be telling about a few very "well-known" CVE registered bugs.
Prerequisites
- a basic flow with the text below
In this micro-blog
- What am I talking about?
- Why am I talking about it?
- Have you heard before? (The "goto fail;", Heartbeat, Meltdown, Spectre)
- What the world is upto against such ____ ?
- Basic Challenges faced
- Unimportant sounding complete terms
- Motivation behind
Have you heard before? (The "goto fail;", Heartbeat, Meltdown, Spectre)
So this all came from around 6 years back, where the "STATUS" device manufactures, the APPLE was diasgoned with a severe bug, that could have caused(or possibly have caused!), the loss to personal information of millions of users. The bug, could be a mere mistake of the programmer(a simple command + c mistake), which actually left the SSL/TLS layer between the client and the server, that would have lead to a middle-man attacking the system to steal the sensitive information of OSx and iOS users. The bug is famously known as the goto fail; bug, registered as CVE-2014-1266[1] in the Common Vulnarabilities and Exposures[2] forum.
"CVE® is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities."
"CVE Entries are used in numerous cybersecurity products and services from around the world, including the U.S. National Vulnerability Database (NVD)."
Let's now go on with the first one
#1 goto fail; video
This came when, APPLE started rolling out an urgent security update in 2014, which caused a hot air among the security researchers. To make the stuff real clear, following is a code snippet from opensource.apple.com.
*Please ignore the random line no. I have put here, i have just put it for refering purpose in the follow up texts
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
1 OSStatus err;
...
34 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
35 goto fail;
36 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
37 goto fail;
38 goto fail;
39 if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
40 goto fail;
...
87 fail:
88 SSLFreeBuffer(&signedHashes);
89 SSLFreeBuffer(&hashCtx);
90 return err;
}
if you look very closely, you can find something strange in lines 37-38, and if you are aware about a normal if-else procedure, the flow will never reach line 39 and following up lines of code, as it is struck at an extra goto fail;, which makes the program flow jump directly to line 87, and thus skipping the very crucial signature verfication required for secure connetion.
Thus, compromising with the SECURITY & SAFETY of the APPLE DEVICES.. This vulnerability can be spotted "iOS from some point prior to 7.0.6 (I confirmed on 7.0.4) and also OS X prior to 10.9.2 (confirmed on 10.9.1). It affects anything that uses SecureTransport, which is most software on those platforms although not Chrome and Firefox"[3]
#2 HEARTBLEED video
What happens in a general communication between 2 devices, is called the HANDSHAKE, where Device-1 asks for something to Device-2 to ensure whether the other device is not-dead. This reciprocation of signals to assure the availabiilty of a device is called HEARTBEAT.
Now, this vulnerability, CVE-2014-0160[4], caused a major bug in usage of OpenSSL, which is usually an implementation to prevent MIDDLE-MAN Attackers from stealing the information between Device-1 & Device-2. In this, the signals are encrypted between the devices.
But during heartbeat suppose Device-1 says to Device-2 Hey! If you are online, send me back the word "HAT" 3 letters, the device-2 reciprocates with the same "HAT"!. [clear excerption from the video above]
But here, what if an attacker comes in between and modifies the messages to Hey! If you are online, send me back the word "HAT" 500 letters, the Device-2 returns HAT but this time with the following texts in its memory chunk, that could be any one, two or all of the following: • Primary key material: secret keys used for X.509 certificates • Secondary key material: user names and passwords • Protected content: personal and finance details like instant messages, emails and business critical documents. • Collateral: other details in the leaked memory content such as memory addresses, etc.
Doesn't it look scary people?
Well I have a lot to talk about bugs, I will just list the other two here, and will write another sublog to this if required. These are even more scary and super-advanced! Just think about the ability of people exploiting them.
#3 MELTDOWN, #4 SPECTRE [5]
I came across these "super-critical vulnerabilties" , when working with Dr Pramod, IITK, at his lab.
These vulnerabilities works in conjuction to one another. Their position of attack is the isolation between 2 application in your PC Processor. Whenever one app transmits data to another app, say browser to notepad, the information transferred goes through a transit, just where the MELTDOWN attack happens. (Since, already a very basic explanation is provided in the link above, I wish not to redundate the data.)
These bugs, are super-easy to make, but can have a catastrophic effects on the privacy of your sensitive data. Just as simple as they look(goto fail; bug), the higher vulnerability they carry!
Don't lose your heart, if you couldnt get the half of the content, just give it a re-read, with more focus, and if still not, wait more stuff to come.
Cheers!!!