Information Security: [Essay Example], 2457 words GradesFixer
exit-popup-close

Haven't found the right essay?

Get an expert to write your essay!

exit-popup-print

Professional writers and researchers

exit-popup-quotes

Sources and citation are provided

exit-popup-clock

3 hour delivery

exit-popup-persone
close
This essay has been submitted by a student. This is not an example of the work written by professional essay writers.

Information Security

Download Print

Pssst… we can write an original essay just for you.

Any subject. Any type of essay.

We’ll even meet a 3-hour deadline.

Get your price

121 writers online

blank-ico
Download PDF

RFC 6520 allows peers to use a keep-alive mechanism to know they’re still connected to the TLS (Transport Layer Security) layer in a low-cost manor, with the intent of lowering client/server overhead with long-lived connections. The way heartbeat is implemented the client sends a packet heartbeat_request that contains an arbitrary payload and a field that defines the payload length. This request, when successful, receives a response from the server that contains an exact copy of the payload.

The Heartbeat functionality was introduced in version 1.0.1 of OpenSSL, with it unknown at the time containing the vulnerability, had it enabled by default, and making all implementations vulnerable. The vulnerability wasn’t discovered until roughly 2 years later by Neel Mehta at Google, with OpenSSL issuing a fix the day after in OpenSSL 1.0.1g. It is predicted that between 24-55% of all HTTPS services on the Alexa Top 1 Million being affected. The impact didn’t just affect HTTPS services, but also affected email servers, Tor Project, Bitcoin Clients and even Android devices (version 4.1.1). The vulnerability affected Major websites where affected by this exploit, such as Google, Youtube, Instagram and Netflix.

The cause of the vulnerability is simple, when the code was created, the developer trusted external user input without checking its validity, allowing for buffer overload to occur when an invalid input is given. For example, if they user put the payload as “KENT” with the field as length 4, the response from the server will be “KENT”. But if the client put the payload as “KENT” with the field as length 100, as the field length has not been compared to the actual payload length, the response given will be “KENT” plus, the next 96 characters in memory. These bits of returned memory can contain critical information such as cryptographic keys and login information, a substantial security risk.

The fact that the vulnerability got through the code review process shows there is a flaw in the practices OpenSSL had implemented in finding exploits in their code. It was discovered that Static Analysis tools were unlikely to find this exploit as the OpenSSL code was too complex for these tools by default, requiring a large amount of configuration to be affect. Most Fuzz-testing applications don’t look for Buffer Over-read, but rather Buffer Overwrite, so this form testing wouldn’t have discovered the vulnerability.

Different review processes would have discovered this vulnerability, such as Focused Manual Spot-checks of all trustless input fields, Negative testing to cause failures rather than success and Fuzzing with output examination to see if the output is what is expected.

The project could also have been implemented using a safer programming language. “The main factor underlying the Heartbleed vulnerability is that the C programming language used by OpenSSL doesn’t build in any detection mechanisms or countermeasures for improper buffer restriction, including buffer overwrites and overreads”. Although this approach would prevent vulnerabilities like this in the future, it would take a lot of effort to move the project to another language, as well as possibly making the program perform slower.

As OpenSSL is an open source project so they don’t receive the largest amount of funding ($2000 a year through donations), meaning code review processes are limited to the resources they have available. This limits the ways the software can be checked and prevents the project from being reviewed by more intensive processes. From this I have taken that open source projects should be better funded if so heavily relied on by big corporations, User input should never be trusted and always validated, and exploits cannot always be detected – even by the best static analysis tools. Having your code peer-reviewed can also reduce the changes of bugs making it through to release, as well as other techniques listed above. This also suggests that current testing procedures may not be sufficient, with possible changes needing to be implemented or adjusted.

FREAK SSL/TLS Vulnerability

The FREAK vulnerability in OpenSSL was caused because of a backdoor requirement put in place by The United States government, where any exported products that utilize ‘strong’ encryption, also had to apply ‘weak’ encryption (known as export-grade). The idea was simple, the export-grade key was limited to a 512-bit RSA key as this was still breakable in the 90’s, but required a supercomputer. This was great for intelligence agencies at the time, but as time went on computers became increasingly more powerful, allowing 512-bit RSA keys to be broken increasingly easy. With this, and the implementation of “Export Key” still being kept after legislation was lifted and the bug in OpenSSL meant a man-in-the middle attack could force users to use the weaker export key.

To negotiate between what key to use, a ciphersuite was implemented. The idea was to allow ‘strong’ clients to communicate with ‘strong’ servers, while allowing ‘non-strong’ compatibility for foreign clients.

The exploit works as follows:

  • In the clients hello message, it asks for a standard ‘RSA’ ciphersuite.
  • The MITM attacker changes this message to ask for ‘export RSA’ instead
  • Server responds with 512-bit export RSA key, signed with its long-term key
  • Client accepts the weak key, due to the OpenSSL/STL bug
  • Attacker factors the RSA modules to recover the corresponding RSA decryption key
  • When client encrypts the ‘pre-master secret’ to the server, the attacker can decrypt this to plaintext and inject anything they want.

One of the dangers of the FREAK vulnerability was that time wasn’t much of a limiting factor for it as generating new RSA keys is expensive. Some keys are generated on starting the server, and reuse that key for the lifetime of the server. “Apache mod_ssl by default will generate a single export-grade RSA key when the server starts up, and will simply re-use that key” (Green, 2015).

Once a key was obtained and factored, any session a man in the middle attack could occur on can now be instantly decrypted until the server is restarted.

The affect this exploit had was it made “secure communication” no longer secure, even if the clients browser says communication with the network is secure. This allows hackers to obtain confidential information such as usernames and passwords for any websites you visit. This also includes the submitting of information, such as inputting bank details to a website, leaving you extremely vulnerable to fraud.

To prevent these types of attacks, disabling export certificates is sufficient as keys can no longer be generated using the broken standard. Newer versions of OpenSSL fixed the exploit, so ensuring to keep all software updated to the latest patches is important.

Governments should not interfere with encryption standards as it leaves everyone vulnerable once the backdoor has been discovered.

Bypassing Firewalls

Phishing

Phishing is the attempt of obtaining credentials through persuasion, most commonly using emails. The contents of an email could have malware attached that’s disguised as recognisable file, with the hopes that you will run it. The most common methods of phishing are the “Spear Fishing” approach. For this approach, emails are constructed to look legitimate, containing personal information about a specific individual such as personal information, interests, associates. The style of the email will likely resemble that of a legitimate email, copying the style and contents.

A solution to preventing this type of attack is to block any material that originates from the internet into the network. Keeping the firewall up to date with the latest patches is also best practiced. Unidirectional gateways can be used to allow information out of the internal network but not in, preventing external access into to the system.

Attack Exposed Server(s)

Servers can be vulnerable to a wide range, some being completely preventable by keeping the systems they run up to data on the latest versions. Sometimes, attacks can be performed on software that has been implemented badly, such as SQL injection and Cross Site Scripting. Some attacks are difficult to protect from, such as denial of service attacks. Some Zero Day exploits are not preventable, although some anomaly based protection systems can detect them. Most known attacks can be prevented using host intrusion detection systems. After ensuring all default passwords have been changed, the next step is to not allow servers be accessed directly through the firewall, but place it behind a unidirectional gateway.

Social Engineering

Social engineering is the processing of obtaining information through observation and influence. Observations can include looking for login credentials on a desk or watching someone type their credentials into a computer. Attempts to access the system by contacting the IT Department or system administrator with a believable story is also another method of obtaining credentials. Sometimes keystroke loggers are installed onto computers in the hopes of capturing credentials.

Preventing this kind of attack can be achieved using two factor authentication, as an attempted login will generate a onetime code that can usually only be obtained by using different credentials. Using unidirectional gateways will prevent the attacker from communicating back into the server.

Hijacking User Sessions

Hijacking a user session can be achieved using man in the middle attacks. This can be done easily using free software such as the Firesheep extension for Firefox. You can run this software on a local area network, allowing you to intercept http steams. Commands can be inserted into these intercepted streams. Impersonating a hotspot network can also have the desired effect.

To prevent this form of attack, encrypting communication between the server and the client can prevent tampering of the commands. Informing users to report encryption messages warnings and to not continue should also be desired. Unidirectional gateways can be used to prevent commands from trustless networks entering the system.

Impact of Artificial Gummy Fingers on Fingerprint Systems

The purpose of this paper was to evaluate the security of fingerprint terminals, questioning if these devices can recognize and reject fake fingers made using readily available materials such as Gelatine and Silicone. This is an important question as biometric data cannot be changed like a pin or passcode, so protecting against abuse is import.

The paper discusses the many weaknesses of a fingerprint system, such as forced cooperation, poor False Acceptance Rate that accepts unauthorized fingers, severed fingers, artificial clones of fingers and error forced attack. They discovered that one of the terminals being tested would accept an inked fingerprint, not requiring an artificial finger at all.

Dishonest acts with artificial fingers where tested on the fingerprint systems, with the assumption that they will be accepted. Dishonest acts would consist of Enrolling real and gummy fingers into the system. Two of the artificial fingers where molded after real fingers, while one was created completely artificially. It was shown that artificial fingers, we it molded or completely artificial can be accepted and used for dishonest acts.

For the experiment they created Gummy fingers (Given the name because Gelatine has a similar texture to that of sweets) using a mould of a finger and another using residue fingerprint. Four types of tests were conducted, each having two stages. The first stage was to see if the finger could be enrolled into the system; the next was to see if the finger could be used for verification after the finger had been enrolled. These tests enrolled live fingers and gummy fingers, and attempted to verify them using the enrolled finger as well as their counterpart (e.g. enrolled real finger, attempted to verify with Gummy finger).

Preventing these types of attacks can be done using “live and well” detection. “live and well” detection is a collection of measurements that are used to evaluate if a finger is real by analyzing features not just found in a fingerprint, but those of a real finger. This can be approached by measuring the temperature, moisture, electrical resistance, bubble content and more. By allowing a terminal to analyze these features it allows the terminal to distinguish between a real and gummy finger with far higher confidence. Features analyzed by “live and well” systems can also distinguish if a finger has been severed.

If preventing access is of high priority, requiring more than one finger can dramatically increase the amount of time needed to stage an attack. Cleaning the terminal after access has been granted can also prevent someone from creating copies of a fingerprint using the residue left behind.

The Nothing to Hide Argument

The difficulty with the “Nothing to Hide” argument is that nobody can really agree on what privacy is, making it a broadly used term.

Agencies want to collect the most information possible about individuals, from their name, social media, location, images, private messages and more. The more data these agencies can collect can allow them to identify individuals who have committed, or have a high possibility of committing a crime.

This relationship will be built on trust. The trust to the people who have access to this data will not abuse it, and trust to those that store the data will not abused it and keep it secure. An example of where government agencies have broken this trust can be seen in a FOIA request on the Metropolitan police. Where you can see they have had 673 cases of computer misuse between 2009 and 2014, with a total of 145(20%) being reported of corrupt practice.

Some of these cases are misuse of intelligence system, such as MPS (Metropolitan Police System) and CRIS (Crime Record Information System), passing on details to a third party that are not police. If police are already abusing the systems currently in place, the damage they could cause to an individual with an increased amount of data such as messages and photos could be devastating, such as blackmail and extortion.

Data can already be used to predict where crime will likely be committed, allowing police to save resources by dedicate units to these areas. Systems such as PredPool have been in deployed in areas of kent, having the desired effect of reducing street violence by 6% and a 4% reduction in crime towards the end of the pilot. This shows that the data police collect can be used for good intent.

Census data is used for the purpose of planning, development and improve residents’ quality of life, containing up-to-date information about individuals’ personal details, such as religion, education, employment, income and disabilities. When this information is used with good intent the outcome is usually good. But history shows the even providing details such as these listed above can unexpectedly used as a weapon. An example of this is during World War 2, when Nazis would often use census data to target specific groups. This shows that even though the data was collected with good intent at the time, with these individuals having “nothing to hide”, as years passed this information became something used against them.

Remember: This is just a sample from a fellow student.

Your time is important. Let us write you an essay from scratch

100% plagiarism free

Sources and citations are provided

Find Free Essays

We provide you with original essay samples, perfect formatting and styling

Cite this Essay

To export a reference to this article please select a referencing style below:

Information Security. (2018, October 26). GradesFixer. Retrieved October 29, 2020, from https://gradesfixer.com/free-essay-examples/information-security/
“Information Security.” GradesFixer, 26 Oct. 2018, gradesfixer.com/free-essay-examples/information-security/
Information Security. [online]. Available at: <https://gradesfixer.com/free-essay-examples/information-security/> [Accessed 29 Oct. 2020].
Information Security [Internet]. GradesFixer. 2018 Oct 26 [cited 2020 Oct 29]. Available from: https://gradesfixer.com/free-essay-examples/information-security/
copy to clipboard
close

Sorry, copying is not allowed on our website. If you’d like this or any other sample, we’ll happily email it to you.

    By clicking “Send”, you agree to our Terms of service and Privacy statement. We will occasionally send you account related emails.

    close

    Attention! this essay is not unique. You can get 100% plagiarism FREE essay in 30sec

    Recieve 100% plagiarism-Free paper just for 4.99$ on email
    get unique paper
    *Public papers are open and may contain not unique content
    download public sample
    close

    Sorry, we cannot unicalize this essay. You can order Unique paper and our professionals Rewrite it for you

    close

    Thanks!

    Your essay sample has been sent.

    Want us to write one just for you? We can custom edit this essay into an original, 100% plagiarism free essay.

    thanks-icon Order now
    boy

    Hi there!

    Are you interested in getting a customized paper?

    Check it out!
    Having trouble finding the perfect essay? We’ve got you covered. Hire a writer

    GradesFixer.com uses cookies. By continuing we’ll assume you board with our cookie policy.