cs2107 - semester iv 2015-2016 introduction to information

103
NATIONAL UNIVERSITY OF SINGAPORE SCHOOL OF COMPUTING CS2107 - Semester IV 2015-2016 Introduction to Information and System Security The Projects for CS2107 (Computer Security) Singapore, July 2016.

Upload: others

Post on 12-Dec-2021

0 views

Category:

Documents


0 download

TRANSCRIPT

NATIONAL UNIVERSITY OF SINGAPORE

SCHOOL OF COMPUTING

CS2107 - Semester IV2015-2016

Introduction toInformation and System Security

The Projects for CS2107(Computer Security)Singapore, July 2016.

ii

Table of Contents

Various attacking techniques on Personal Computers. . . . . . . . . . . . . . . . . . . . . . . . .1Eng De Sheng, N Ramakrishnan,Kee Siyun Cheryl and Shalom Lau Li Yin (Gp 1)

Comparing between Windows NT Security,UNIX Security and Mac OS Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Alamer Rawan Zaid A, Chu Ying Yu and Steffi Wong Wai Kay (Gp 2)

Quantum Information Science. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Ronald Ong Ke Yu and Yong Jia Wern (Gp 3)

An Analysis of Application-Layer Vulnerabilities inAndroid Smartphones and Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Amarparkash Singh Mavi,Kar Chaudhuri Anirban and Patrick Cho Chung Ting (Gp 4)

Overview of Security Issues of Public Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Chan Lup Seng, Low Pei Hua,Ng Yong Khuang and Tan Jia Liang (Gp 5)

Cross-Site Request Forgery (CSRF) and Other Techniquesfor Attacking Web Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Jiarui Han and Xuan Su (Gp 6)

Comparison between Tamper-Resisting Techniquesfor Software Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Li Zhikai, Damian Goh Jun Yi,Lim Han Yang and Lee Chun Hung (Gp 7)

Double-Spending & Related Attacks on Bitcoin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Ng Ching Ann James, Joel Tan Xingyu and Xie Peiyil (Gp 8)

Case Study on NFC Technology of NUS Student Card. . . . . . . . . . . . . . . . . . . . . . 67Adam Chin, Daniel Low, Lim Yi Hong and Shee Zhi Xiang (Gp 9)

Electronic Voting Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Guo Jiaqi, Han Xue, Li Yinan and Yan Hongwei (Gp 10)

iii

Table of Contents

Social Engineering Penetration Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Reshmi Sinhahajari, Evangeline Ong Yiling andKor Chin Yew Kenwick (Gp 11)

Public Key Infrastructure - Attacks and Precautions. . . . . . . . . . . . . . . . . . . . . . . . 91Thenaesh Elango, Ivan Koh, Patrick Koh and Claurence Lee (Gp 12)

Testing Program for Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Kwok Jun Kiat (Gp 13)

iv

Various attacking techniques on Personal Computers Eng De Sheng

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected] Kee Siyun Cheryl School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

N Ramakrishnan School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected] Shalom Lau Li Yin School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

ABSTRACT Since 1970s, personal computers have rapidly become an important tool in communication and handling of information. The increased use of personal computers, especially in the past decade, by organizations to provide remote services for their customers have also attracted the attention of attackers seeking out sensitive information for malicious purposes.

The paper will present the findings of a preliminary survey on the various popular attacking techniques on personal computers, and discuss the possible ways of preventing such attacks based on the mechanism. Specifically, the paper will provide an overview on DDoS and Phishing attacks, as well as the old-fashioned technique of bait and switch adapted for this digital age. This paper will also investigate some proof of concepts such as the Hot Potato exploit in Microsoft Windows OS and the various novel techniques in bridging air-gapped systems.

Categories and Subject Descriptors D.4.0 [Operating Systems]: Security, Windows, Linux, Macintosh

General Terms Security

Keywords Windows, Macintosh, Cross-Platform, Air-gapping, DDOS, Phishing, Hot Potato, Bait and Switch

1. INTRODUCTION In the current information age, personal computers (PCs) have become an integral part of our lives. According to a report by Gatner1, more than 280 million units of PCs were shipped in 2015 despite a decrease of 8 percent in total shipment when compared to 2014 [1]. PCs has enabled people to be connected with the rest of the world through the Internet, and provide access to many services without the geological limitations. Management of personal information such as medical records and banking statements can be now done conveniently through the use of PCs.

However, the increased usage in PCs for services has also attracted the attention of criminal organizations and evil-intentioned individuals. Kaspersky Lab, an international

1 Gartner, Inc is a technology research and advisory company.

software security group, reportedly repelled over 790 million Internet-based attacks worldwide in 2015 [2]. Hence, there is a need to understand the various attacking techniques on PCs to better protect our personal information from the malicious attackers.

The following sections of this paper will examine some of the more popular attacking techniques employed against PCs, discussing the mechanism behind these techniques. In addition, the paper will also explore some proof-of-concepts for newly discovered attacking techniques.

2. DISTRIBUTED DENIAL OF SERVICE (DDoS)

2.1 Definition and aim of DDoS A distributed denial of service (DDoS) attack is an enhanced technique of a simple denial of service (DoS) attack which targets the network infrastructure of an online service or a particular individual [3].

The main aim of a DDoS attack is to interrupt or disable the network activity of its target through a coordinated swamp of DoS attacks which saturates the victim with huge volume of network traffic from multiple sources. As DDoS attacks target the victims’ network activities, they do not rely on any platform specific vulnerabilities and are effective against all PCs connected to the Internet.

2.2 Purpose of DDoS There are various motivations [4] behind most DDoS attacks, ranging from personal to political reasons. These includes hacktivism2, cyber vandalism, extortion, personal grudges and even business rivalry.

During the duration of DDoS attacks, the victim’s network and Internet activities are essentially disabled, preventing them from accessing the Internet and its services. Hence, the victim is effectively disconnected from the Internet and will not be able to offer any form of services or commentaries to their target audience.

The effectiveness of DDoS attacks has made it a popular choice amongst attacking techniques, with more than 2000 attacks daily worldwide.

2 Hacktivism is the act of hacking a website or computer network in an effort to convey a social or political message (Technopedia)

1

2.3 Mechanism of DDoS

Figure 1: DDoS Attack3

Since a DDoS attack is essentially a concerted DoS attack by multiple systems (see Figure 1), they are generally orchestrated through botnets4. The popularity of botnets to command DDoS attacks can be attributed to various benefits for the perpetrator, such as remaining anonymous through the distributive nature of botnets. These botnets are usually capable of Application Layer Attacks (ALA) and Network Layer Attacks (NLA) [5].

2.3.1 Application Layer Attacks (ALA) ALA involves flooding the victim through launching an abnormally large number of requests beyond the victim’s server’s handling capacity. Some attack vectors for ALA include HTTP flooding and DNS query flooding.

2.3.2 Network Layer Attacks (NLA) NLA implements flooding by sending the victim a huge amount of random data in order to exhaust the victim’s network bandwidth. The attack vectors for NLA include UDP flooding, SYN flooding, NTP amplification and DNS amplification.

2.4 Case study In January 2016, Sony’s PlayStation Network (PSN) which hosts the game servers for online play on the PlayStation gaming consoles, was victim to a DDoS attack. The PSN network was kept offline worldwide for almost 24 hours [6], rendering the service unusable for potentially 110 million users.

Regrettably, this was not an isolated incident. Sony’s PSN had faced multiple outages over the years, including one within a month after the January 2016 attack. Although the attackers who claimed responsibility did not specify their motivations, it showcased their DDoS capabilities by successfully bringing down Sony’s PSN despite the sheer size of its network infrastructure.

2.5 Prevention of DDoS attacks As DDoS attacks are basically a competition of bandwidth, it is a cat and mouse game between the victims and attackers. It is almost impossible to completely prevent a DDoS attack but there are viable control measures to minimize the impact of an attack.

Some control measures include monitoring network traffic for anomalies such as spikes in network traffic, expanding the bandwidth of the network and filtering UDP traffic. Services offering DDoS attack protection such as CloudFlare5 are also

3 Image taken from http://www.animeherald.com/2014/12/30/crunchyroll-taken-massive-ddos-attack/

gaining popularity for their effectiveness in mitigating most DDoS attacks.

3. PHISHING 3.1 Definition and aim of Phishing Phishing attack is a common technique used by attackers to gain access to private information of their victims through impersonating the target or a trusted entity [7]. This is done over non-physical communications such as phone calls and Internet account logins.

Its earliest appearance could be traced back to the 1990s on America Online (AOL) network systems. At that time, attackers will impersonate a false identity to provide fake billing information. As a response to this situation, AOL set new requirements for users to provide their credit card information so as to verify the legitimacy of their billing identity. This preventive measure in turn changed the objective of the attackers into acquiring accounts of other users to gain free access to online services. This is done through the use of AOL’s messaging service to impersonate an AOL employee, to request the passwords and authentication details of legitimate users.

Due to the success of this attack, attackers have been motivated to craft, refine, and seek new ways and mediums beyond the AOL systems.

3.2 Purpose of Phishing Phishers no longer just impersonate as AOL employees, but various other public and trusted organizations. Their main purpose has expanded from obtaining the access of various user accounts to obtaining credit-card and authentication details, as well as billing information for fraud, theft, or money laundering.

The primary motivation for using a phishing attack is the ability to acquire sensitive or financial information without raising any suspicion from the victims or the service provider. Unlike other modes of attack such as brute-forcing the password, phishing has a relatively low risk of raising alarms, especially in services which grants access to sensitive information protected by mechanisms preventing multiple failed logins.

The appeal of phishing is also due to the possibility that the explicit permission granted to the attacker in a successful phishing attack will allow the attacker unrestricted access into other secondary services belonging to the victim, effectively taking over the victim’s identity in the Internet.

3.3 Mechanism of Phishing A phishing attack consists of three roles – mailers, collectors, and cashers.

Mailers have the ability to impersonate other organizations and send large amount of fraudulent emails to many users. This is commonly done through the use of botnets. Their main purpose is to lure victims to a phishing website.

Collectors, who have already set up the malicious websites, will convince victims into providing confidential information.

Cashers will then make use of the information acquired by the collectors to achieve pay-outs [8].

4 Large clusters of connected devices infected with malware that allows remote control by an attacker without owners’ knowledge 5 https://www.cloudflare.com/ddos/

2

Figure 2. Phishing Attack6

Phishing can be conducted over various mediums, as long as trust is established between the attacker and the target. Attackers often exploit the popularity of the use of emails and phone calls for communication between legitimate sources and their customers to attack unsuspecting victims. Phishing attacks are typically carried out over emails to steal information required for the impersonation of the victim (see Figure 2).

3.4 Case study In 2015, the Infocomm Development Authority of Singapore (IDA) discovered a fake SingPass website, which was set up to collect the usernames and passwords of SingPass users [9]. The phishers involved in this attack sent emails to many victims with the title “SingPass account security info verification”, and disguised themselves to come from a trusted source through the use of an email resembling the official email – “[email protected]” [10]. This phishing attack has led to the imposition of the 2-factor authentication project by July 2016, introducing an additional security token for user authentication.

3.5 Prevention of Phishing There are various ways to prevent us from falling victim to phishing. In order to ensure that private information is not compromised, anti-malware software can be used. This will prevent potential phishers from getting the required information to carry out phishing attacks.

In addition, authenticity of online services should be verified before entering any sensitive or confidential information. This can be done by checking the validity of the website’s SSL certification and ensuring that it is issued by an entrusted source such as GlobalSign [11].

4. BAIT-AND-SWITCH 4.1 Definition and aim of Bait-and-Switch Bait-and-switch operations are historical marketing tactic which involves baiting customers with very attractive offers, and switching their focus to a more expensive product when interest is expressed to the offers [12]. Similarly, attackers are able to adapt such technique to compromise the security of their victims’ PC and personal information.

4.2 Purpose of Bait-and-Switch There are multiple motives behind the use of bait-and-switch operations to attack PCs. Such techniques are often used as a means to introduce malwares to the victims’ PCs. This allows the attackers to carry out subsequent attacks or steal sensitive

6 Image taken from https://courses.cs.ut.ee/2015/infsec/fall/Main/SocialEngineering

information available on the PC. Besides malwares, bait-and-switch techniques can also be used for the financial gains of the attackers by redirecting unsuspecting victims to websites to generate advertising revenue.

4.3 Mechanism of Bait-and-Switch The main mechanism behind bait-and-switch operations is to lure the unsuspecting victim into compromising exploits, or actions which will benefit the attacker. Unlike many other forms of attacking techniques, bait-and-switch are hard to detect by the victims, since they are usually only aware of the “bait” aspect of the attack. As a result, successful attacks will allow the attacker to achieve his objectives without much obstructions from the victim.

4.4 Case study In March 2016, attackers successfully conducted a bait-and-switch operation on the distribution of Transmission, a popular BitTorrent client for Macintosh (MacOS) [13]. The attackers compromised the official website and replaced the original files with a recompiled version containing malicious payloads. Using the update release as a bait, attackers are able to get victims to download the malicious installer and infect them with a ransomware, KeRanger. In addition, KeRanger was signed by a valid development certificate, and thus prevented the flagging of any suspicious files by MacOS’s malware protection. As a result, the attackers were able to successfully encrypt the files on the victims’ PC and demand ransom in exchange for decryption of the files.

4.5 Prevention of Bait-and-Switch Bait-and-switch techniques are often carried out by exploiting the trust of the users in the services that they are familiar with, and the naïve belief of what-you-see-is-what-you-get. More often than not, bait-and-switch operations can be thwarted by verifying the expected behavior and authenticity of every action.

For instance, the SHA-1 hash of a downloaded file should be checked against the hash provided by the developer to ensure that it is the exact same copy. Doing so will prevent successful switching in bait-and-switch attacks.

5. HOT POTATO 5.1 Definition of Hot Potato Hot Potato is a platform-specific exploit which enables privilege escalation attacks on the Microsoft Windows Operating Systems (OS), namely Windows 7, 8, 10, Server 2008 and Server 2012. The exploit capitalizes on known security issues in the mentioned OS, allowing attacks to escalate local privileges in limited permissions configurations. In essence, it enables any user to gain administrative or root permissions regardless of their given privileges.

5.2 Background of Hot Potato The exploit is first discovered by researchers at Foxglove in 2014, and their findings were presented at the ShmooCon Security Conference in January 2016 [14].

Hot potato exploit makes use of two known security issues in Microsoft Windows – NT LAN Manager (NTLM) and NetBIOS Name Service (NBNS) spoofing. Despite being aware of these vulnerabilities since 2000, Microsoft has yet to patch them completely due to backward compatibility commitments.

3

5.3 Mechanism of attack Attacks utilizing the Hot Potato exploit are slightly different between the different variation of Windows OS. This is due to the changes that were introduced in the behavior of the system.

Attacking Windows 7 is fairly straightforward. Through spoofing the NBNS, the attacker can setup fake Web Proxy Auto-Discovery Protocol (WPAD) servers and launch an attack against the NTLM authentication protocol. Doing so will enable the attackers to elevate any user to administrator privileges instantaneously.

However, in Windows 8 and 10, WPAD is no longer checked during Windows Update. Instead, in the newer versions of Windows OS, certificate trust lists (CTLs) are updated daily automatically [15]. Since updating of the CTLs still utilizes WPAD, the exploit is still viable. The only drawback is that instead of an instantaneous attack like that in Windows 7, the attacker has to wait up to 24 hours for the CTLs update to execute. Once the CTLs update is executed, NBNS spoofing can be used to start the privilege escalation attack in the similar way as Windows 7.

5.4 Proof of Concept

Figure 3. Hot Potato exploit granting administrative rights

Currently, Hot Potato is mostly a proof of concept shown by the researchers rather than a full-fledged malicious exploit (see Figure 3). Despite being flawless in a theory, execution of the exploit in Windows OS can be inconsistent and unpredictable.

In addition, local access to the target machine is required to bypass the existing firewall which blocks attacks through remote access by the attacker. Hence, the frequency of Hot Potato attacks is minimal currently.

5.5 Reducing possibilities of Hot Potato attacks Given the requirement of the Hot Potato exploit, it is possible to reduce the risk of being successfully attacked through the exploit. Server Message Block (SMB) signing is one method which may theoretically block a Hot Potato based attack. Another way of preventing the such attack is to enable the “Extended Protection for Authentication” option in Windows [16].

6. AIR-GAPPING 6.1 Definition and aim of Air-Gapping Air-gapping is a form of network security measure used to prevent systems from potential attackers attempting to steal data remotely through the Internet or unsecured networks [17]. Air-gapped systems are used mostly in situations and organizations which demand high level of security.

6.2 Air-Gapping implementations There are various ways of implementing air-gapped systems. Some networks rely on software-based air-gaps through the use

of customized firewalls between secure and unsecure devices within the networks, while some other air-gapped networks employ end to end dedicated cryptographic devices to introduce algorithmic air-gaps with other devices.

Since software-based solutions may still contain security loopholes and are generally susceptible to security breaches and failure, they do not offer the full guarantee of air-gapping. Hence systems, such as the classified military networks and public infrastructure networks, which requires maximum security often implement air gaps by physically isolating the systems from the internet and other unsecure networks.

6.3 Motivation of Air-Gapping Air-gapping has become a popular way to ensure a secure network, as seen from the increase in implementation of air-gapped systems. One such instance is the requirement of public servants in Singapore to use separate machines for Internet access and accessing internal network in bid to tighten information security [18].

The main motivation behind air-gapping is the perceived impenetrable security in air-gapped systems over the network. It was believed that attacks on such systems would have to be physical in nature, since the attackers would not be able to otherwise gain access. This was especially true in the physical implementation of air gaps in high security networks, where the secure network and the unsecure one are physically separated.

6.4 Mechanism of Air-Gap bridging While air-gapped systems might seem impervious to unauthorized access, assuming sufficient physical security, this could not be further from the truth. Breaches in air-gapped systems without requiring physical access had occurred, and many other possible attacks have been recorded in research papers.

6.4.1 Infected storage drives (Stuxnet) One technique of bridging the air gap is through the use of infected storage drives by authorized personnel on the air-gapped system. An example of such attack will be the Stuxnet malware which targets air-gapped industrial systems controlling nuclear facilities.

6.4.1.1 Mode of attack Stuxnet spreads by taking advantage of the need for file transfer regardless the nature of networks, unsecure or air-gapped.

It first infects PCs through an infected storage drive. These infected PCs then serve as carriers, infecting any storage drive which are connected to them [19]. Stuxnet is also capable of spreading within the network, and thus compromising entire networks once a connected PC is infected.

To avoid detection on the infected PC and networks, Stuxnet was digitally signed with stolen private keys of trusted certificate authorities, and only attack systems which satisfy its target criteria [20].

Furthermore, it employs man-in-the-middle attack to mask its existence on the target systems. Hence, the carriers of the malware were unaware of its existence, and this contributed to its rapid propagation, thus eventually spreading into its targeted air-gapped networks of nuclear facilities in multiple countries.

6.4.1.2 Reason for bridged air-gap This technique of attacking air-gapped system is possible due to poor practice in transferring files into sensitive environment, as well as the lack of awareness of possible attack vectors among the staff.

4

6.4.2 Radio frequencies (AirHopper) Another technique which has been proven capable of overcoming air gaps is through the use of radio frequencies to transfer information from air-gapped systems to mobile phones nearby. A proof of concept for such attack, named AirHopper, has been demonstrated by researchers.

6.4.2.1 Mode of attack Unlike Stuxnet which was designed to disrupt its target system independently, AirHopper is used to siphon sensitive data off infected systems without physical access. The only similarity between Stuxnet and AirHopper is the initial spreading of the malware – through infected carriers.

Using the findings of a prior research on generating signals from flat-panel displays [21], AirHopper was able to generate radio signals on infected systems which are then received by a FM radio receiver nearby [22].

Figure 4: Example of a targeted AirHopper attack

As most cell phones have a built-in FM radio receiver, they are good examples of everyday devices which can then be used to collect information from air-gapped systems without physically accessing them (see Figure 4). Other tools such as stronger FM radio signal receiver can be used from a longer range to more covertly transfer information from the air-gapped system.

6.4.2.2 Reason for bridged air-gap This technique of attacking air-gapped system is possible due to the inherent nature of electromagnetic devices, which leaked the signals that are being exploited to broadcast the unauthorized data.

6.4.3 Heat signature (BitWhisper) The use of heat signature is a novel technique which has recently been demonstrated by researchers in bridging air-gapped systems. This technique of attack, named BitWhisper, allows for bi-directional transfer of information between two systems by manipulating their heat signatures.

6.4.3.1 Mode of attack Like AirHopper and Stuxnet, the target system has to be first infected with malware. Information between nearby systems are transferred across the physical air-gap through regulation of heat and the built-in thermal sensors.

Through regulating the heat emission of the PC, binary information can be transmitted as specific heat signals received by the thermal sensors of the adjacent PC. These heat signals are then decoded back into binary information and transmitted to the attacker over an unsecure network [23]. This technique is only achievable when the infected PCs are in close proximity.

However, the technique can be further enhanced over the shown capabilities in the proof of concept. Networked devices such as scanners and printers can be used as proxy by the infected PC to communicate with air-gapped systems within their workable range, and thus overcoming the attack range limitation [24].

6.4.3.2 Reason for bridged air-gap This technique of attacking air-gapped system is possible due to PCs from unsecured networks being in close proximity to air-gapped networks. As a result, the air-gapped systems are susceptible to the thermal changes of its surrounding devices, providing possible attack vectors.

6.5 Prevention of Air-Gap Bridging Given that most of the techniques employed in bridging the air-gapped systems with unsecured networks require some specific requirements, such as initial installation of malware or physical proximity, such attacks can be prevented.

Personnel working with these systems should always comply with security requirements, such as only using trusted and secure peripherals. Air-gapped systems can also be housed in isolation, far from unsecure networks to reduce the possibility of attacks like AirHopper and BitWhisper.

7. CONCLUSION In this paper, we discussed the mechanism of some attacking techniques on PCs, and proposed some of the preventative measures which can be adopted to avoid being a victim of such attacks.

In addition, many of the attacking techniques discussed are platform-independent, allowing attackers to indiscriminately attack most PCs. This has made changing operating systems to prevent attacks no longer viable as an option for organizations and individuals looking to secure their PCs. However, we are able to conclude that through basic actions such as data validation and separation of sensitive materials, users are able to minimize the PCs’ risks of being attacked.

This paper has also provided better insights into the existing and possible attacking techniques, allowing us to glimpse into the future possible techniques of highly adaptive and novel PCs attacks.

8. ACKNOWLEDGEMENTS We would like to show our appreciation to Dr. Hugh Anderson from the National University of Singapore for giving us the opportunity to write this paper.

9. References [1] Christy Pettey. Gartner Says Worldwide PC

Shipments Declined 8.3 Percent in Fourth Quarter of 2015. Retrieved July 21, 2016 from http://www.gartner.com/newsroom/id/3185224

[2] Maria Garnaeva, Jornt van der Wiel, Denis Makrushin, Anton Ivanov, and Yury Namestnikov. 2015. Kaspersky Security Bulletin 2015. Overall statistics for 2015. (December 2015). Retrieved July 21, 2016 from https://securelist.com/analysis/kaspersky-security-bulletin/73038/kaspersky-security-bulletin-2015-overall-statistics-for-2015/

[3] Justin Chan. 2010. The Motivation and Goals Behind DDoS | DOSarrest Internet Security | DDoS Protection. (July 2010). Retrieved July 21, 2016 from https://www.dosarrest.com/ddos-blog/the-motivation-and-goals-behind-ddos/

5

[4] Understanding DDoS. Retrieved July 21, 2016 from http://www.digitalattackmap.com/understanding-ddos/

[5] Denial of Service Attacks. Retrieved July 21, 2016 from https://www.incapsula.com/ddos/ddos-attacks/denial-of-service.html

[6] Jeremy Seth Davis. 2016. Sony PSN downed; hacking group claims DDOS attack. (January 2016). Retrieved July 21, 2016 from http://www.scmagazine.com/sony-psn-downed-hacking-group-claims-ddos-attack/article/463065/

[7] Margaret Rouse. 2015. What is phishing? - Definition from WhatIs.com. (October 2015). Retrieved July 21, 2016 from http://searchsecurity.techtarget.com/definition/phishing

[8] Markus Jakobsson and Steven Myers. 2007. Phishing and countermeasures: understanding the increasing problem of electronic identity theft, Hoboken, NJ: Wiley-Interscience.

[9] IDA warns of fake SingPass website. (July 2015). Retrieved July 21, 2016 from http://www.straitstimes.com/singapore/ida-warns-of-fake-singpass-website

[10] IDA warns users about SingPass phishing email. (June 2015). Retrieved July 21, 2016 from http://www.channelnewsasia.com/news/singapore/ida-warns-users-about/1939468.html

[11] SSL Certificates. Retrieved July 21, 2016 from https://www.globalsign.com/en-sg/ssl-information-center/what-is-an-ssl-certificate/

[12] Bait And Switch Definition | Investopedia. Retrieved July 21, 2016 from http://www.investopedia.com/terms/b/bait-switch.asp

[13] Claud Xiao and Jin Chen. 2016. New OS X Ransomware KeRanger Infected Transmission BitTorrent Client Installer - Palo Alto Networks Blog. (March 2016). Retrieved July 21, 2016 from http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/

[14] Hot Potato – Windows Privilege Escalation. (January 2016). Retrieved July 21, 2016 from https://foxglovesecurity.com/2016/01/16/hot-potato/

[15] An automatic updater of untrusted certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. Retrieved July 21, 2016 from https://support.microsoft.com/en-us/kb/2677070

[16] Vijay Prabhu. 2016. Hackers Can Take Control Of Your Windows 7/8/8.1/10 PC With Hot Potato Exploit. (2016). Retrieved July 21, 2016 from http://www.techworm.net/2016/01/windows-7-8-8-1-10-vulnerable-to-hot-potato-exploit-by-hackers.html

[17] Hacker Lexicon: What Is an Air Gap? Retrieved July 21, 2016 from https://www.wired.com/2014/12/hacker-lexicon-air-gap/

[18] Irene Tham. 2016. Singapore public servants' computers to have no Internet access from May next year. (June 2016). Retrieved July 21, 2016 from http://www.straitstimes.com/singapore/singapore-public-servants-computers-to-have-no-internet-access-from-may-next-year

[19] Aleksandr Matrosov, Eugene Rodionov, David Harley, and Juraj Malcho. Stuxnet Under the Microscope, ESET.

[20] Nicolas Falliere, Liam O. Murchu, and Eric Chien. 2011. W32.Stuxnet Dossier, Symantec.

[21] Markus G. Kuhn. 2005. Electromagnetic Eavesdropping Risks of Flat-Panel Displays. Privacy Enhancing Technologies Lecture Notes in Computer Science (2005), 88–107. DOI:http://dx.doi.org/10.1007/11423409_7

[22] Mordechai Guri, Gabi Kedma, Assaf Kachlon, and Yuval Elovici. 2014. AirHopper: Bridging the air-gap between isolated networks and mobile phones using radio frequencies. 2014 9th International Conference on Malicious and Unwanted Software: The Americas (MALWARE) (2014). DOI:http://dx.doi.org/10.1109/malware.2014.6999418

[23] Mordechai Guri, Matan Monitz, Yisroel Mirski, and Yuval Elovici. 2015. BitWhisper: Covert Signaling Channel between Air-Gapped Computers Using Thermal Manipulations. 2015 IEEE 28th Computer Security Foundations Symposium (2015). DOI:http://dx.doi.org/10.1109/csf.2015.26

[24] Swati Khandelwal. 2015. Hacking Air-Gapped Computers Using Heat. (2015). Retrieved July 21, 2016 from http://thehackernews.com/2015/03/hacking-air-gapped-computer.html

6

Comparing between Windows NT Security, UNIX Security and Mac OS Security

Alamer, Rawan Zaid A

A0144908Y

Chu Ying Yu

A0138516A

Steffi Wong Wai Kay

A0141727H

Abstract

Computers are now as much a part of our lives as

the food we eat; available in great varieties to the

masses and extremely essential (to most). When

choosing a computer, we are faced with a

multitude of choices, one of the these being the

choice of operating system. Undisputedly, the

criteria that comes to the forefront of our minds

when we compare the different operating systems

with one another is performance: how fast the

device can run, how sharp the graphics are, how

much can be stored on it. Yet, one of the main

concerns plaguing today’s society seems to have

been neglected in the selection process: security.

In a world where everything is interlinked and

convenience is the biggest motivation, security is

a major issue and should be one of the main

considerations when choosing between operating

systems. In this paper, we have drawn up a

comparison of the security of some of the most

common operating systems: Windows NT, UNIX

and Mac OS (Mac OS X to be more precise). By

evaluating the security features of each operating

system, we have concluded that the Windows NT

security is the most effective out of the three and

this paper will take you through why we feel so.

On a side note, while this may serve as a guide

for those who are choosing between the

aforementioned operating systems, it is not the be

all and end all; the decision should not be made

based solely on the contents of this paper.

1. Introduction

The importance of security increases as

technology advances. With the significant

developments in technology today, we are able to

do things that just a century ago would not even

cross the minds of people. We can now share our

lives with people across the globe; the tedious

process of immigration has been simplified in the

form of an application; and even grocery

shopping can be done stepping a foot out of the

house. However, with the convenience that such

developments offer us comes the downside of it

all; the ease at which hackers with malicious

intent are able to infiltrate our computers and

steal our personal information. Thus, security of

our computers has become something we cannot

afford to neglect, especially when our computers

have become our very own database; where we

store every bit of information of our lives.

Therefore, it is imperative that we are aware of

how effective the security of our computer’s

operating system is, and whether there are

operating systems that have more effective

security features than others.

This paper aims to provide a comprehensive

comparison of the security between the some of

the more common operating systems; Windows

NT, UNIX and Mac OS.

2. Security: Window NT vs UNIX vs Mac OS

Windows NT (or Windows New Technology) is a

series of operating systems developed by

Microsoft, the first of which was released in July

1993. It is a processor-independent,

multiprocessing (the use of two or more central

processing units within a single computer

system), multi-user (a computer system that

allows multiple persons to use it simultaneously)

operating system. [1]

National University of Singapore

7

Quite similarly, UNIX is a series of general-

purpose (broadly applicable across application

domains), multitasking (ability to carry out

multiple tasks simultaneously on a single

processor computer), multi-user computer

operating systems produced in the 1970s at the

Bell Laboratories research centre. [2]

Deviating slightly from the similarities of the

previous two operating systems, the Mac OS is a

series of graphical user interface-based operating

systems created by Apple Inc. for their line of

Macintosh computer systems. [3]

To evaluate the security features of the

aforementioned operating systems, we have

dissected the vast spectrum that the word

‘security’ covers into several sections. The

following points shall convey our opinions on the

relative effectiveness of the different operating

systems in comparison with one another.

2.1 User Accounts

The user and group account system plays an

integral role in validating the user and thus, in

deciding whether the user is able to access the

operating system and the information stored on it.

While the Windows NT, UNIX and Mac OS X

operating systems share similarities in the user

security features implemented, there are still

some measures taken to secure user and group

information which are unique to certain operating

systems.

The Windows NT operating systems assign

unique security IDs (SID) to both user and group

accounts for identification (Appendix 1).

Whereas the UNIX (Appendix 2) and MAC OS X

(Appendix 3) operating systems use the user

identifier (UID) and the group identification

number (GID) for the same purpose, user and

group permissions are then set based on the

identifiers. Despite the similarities in the

measures adopted by all three types of operating

systems, the one that Windows NT adopted is

much more secure. The SID assigned to each user

and group account is unique and can never be

reused, even if the account had been deleted. On

the other hand, the same UID or GID might be

used for different user or group account. The

danger in this is that accounts with the same UID

or GID will be treated as the same account, even

if their usernames and passwords are different,

and the same permissions will be applied to all

such accounts.

In addition, the UNIX (Appendix 2) operating

systems is much less secure as compared to the

Mac OS X (Appendix 3) operating systems. This

is due to the fact that in UNIX operating systems,

the superuser root account, which allows full

control of the operating system, is enabled by

default; an attacker can easily gain full access to

the operating system as long as the user account

has the same UID as the root account. And we

have seen, as mentioned above, that it is entirely

possible. This is in comparison to the Mac OS X

operating system, where the root user account is

disabled by default, only enabled when necessary,

which is a more secure design principle.

2.2 Passwords

The Windows NT system, by default, encrypts

user account passwords in two ways: the LAN

Manager one-way function and the NT one-way

function. The encrypted passwords are then

stored in the Security Account Manager

(Appendix 1). The UNIX system encrypts user

account passwords using Data Encryption

Standard (DES) and they are stored in a specific

file directory: /etc/passwd (Appendix 2). User

account passwords in the Mac OS X system are

stored in the Open Directory Password Server in

either recoverable or hashed forms (Appendix 3).

The encryption methods adopted by the three

types of operating systems are adequately secure;

however, the point of contention here is where

the passwords are stored after encryption.

Password security in the UNIX system is

particularly weak when we take into account the

8

directory in which encrypted passwords are

stored. The /etc/passwd directory allows read

access to everyone, be it user, group or other.

While improvements have been made:

transferring the hashed form of the passwords to

shadow files, access of which is restricted the

root user only, attackers could gain access to

these files if they were able to hack into the root

account (the likeliness of which we have

discussed in the previous section). In comparison,

password security in the Windows NT (Appendix

1) and Mac OS X (Appendix 3) operating

systems are seen to be stronger.

2.3 File and Directory Protection

Superficially, the Unix system is advantageous in

the fact that its file protection mechanism is

rather simple: the users are grouped (by the

system) in three categories and a set of access

modes is applied to each group (Appendix 2). In

comparison, the Windows NT File System

(NTFS), which allows you set permissions for

each user (Appendix 1), and the Mac OS X Open

Directory, where you set privileges for each file

and directory (Appendix 3), seem a tad bit more

complicated. However, in the essence of ensuring

file and directory security, the NTFS and Open

Directory would be much more appropriate. The

NTFS offers far greater versatility in terms of

security settings. For example, restrictions placed

on users can differ even if they are under the

same group (Appendix 1). Quite similarly, Open

Directory allows you to set different privileges on

the different files that you have stored on your

directory domain, privileges that are independent

on those set on the parent folder. The only

difference here is that in NTFS, the permissions

are set on the users, whereas for Open Directory,

the privileges are set on the files and directories.

On the other hand, the Unix system does not offer

the same flexibility; those of the same category

will share the same permissions (Appendix 2).

For all the similarities between the NTFS and

Open Directory, the effectiveness of the security

that the NTFS offers, in our opinion, will gain the

upper-hand. This is because of a flaw that we

have found in Open Directory: by default, guest

access is turned on, in which guests (or

anonymous persons) are able to access your

directory domain (Appendix 3). Thus, while you

can set many privileges on all your files and

directories, carefully planning how much access

you are going to grant, if it had somehow slipped

your mind to turn off the guest access, all your

efforts would have been for naught. Hence, we

feel that unless this glitch is fixed, the NTFS will

always have the upper-hand (assuming the NTFS

maintains its security effectiveness as of now).

2.4 Printer Protection

It is quite clear that Windows NT has a more

secure printer protection protocol than the Unix

system and Mac OS X Print Service. You are able

to set permissions on particular groups and/or

users with regards to the access of shared printers

using the Windows NT security features

(Appendix 1). However, both the Common Unix

Printing System (CUPS) server and the Mac OS

X Print Service do not have any such features in

place (Appendix 2 & 3). The CUPS server can

only offer recommended courses of action in

order to counter the loopholes in its system

(Appendix 2) while the Mac OS X Print Service

only allows you to hold a print job for an

indefinite amount of time, which essentially just

means that you can stop a print job from being

printed but you cannot stop print jobs from

joining the queue (Appendix 3). Protection of a

shared printer should be focused on restricting the

print jobs being allowed to join the queue and the

users who are allowed to send such print jobs.

Thus, in this aspect, we feel that the protocols

that the Windows NT system has in place are

most effective.

Between the CUPS server and the Mac OS X

Print Service, we are of the opinion that the Mac

OS X Print Service is more effective in protecting

shared printers than the CUPS server. While the

Mac OS X Print Service does not have any

9

security features or protocols in place, at least

there are settings that allow you to control the

print jobs that have been sent to the printer’s

queue; where you can change the priority of the

print jobs or when it is allowed to be printed, if at

all (Appendix 3). All the CUPS server has to

offer is a list of recommended actions to take

should you meet a security issue, a reactive

approach that is not at all encouraged.

2.5 Registry Protection

The default settings of Windows NT are such that

anyone who is able to connect to your computer

will be able to access your registry and alter your

configuration information (Appendix 1), although

users are able to change the settings to suit their

needs. The problem here is that should any data

in these registries become corrupted, the whole

system may crash. [4] In addition, if all the

settings had not been not stored in the registry –

this is a frequent occurrence as many applications

use individual files – then it would be more

difficult to backup the registry. Also, the number

of files stored on the registry can grow rapidly

and there may still be files left despite the

uninstallation of the application, resulting in a

much slower performance of the Windows NT

operating system as compared to a Mac OS. [4]

The Mac OS and UNIX operating systems do not

have registries as the applications are self-

contained (Appendix 3). This means that Mac OS

and UNIX operating systems will operate faster

as compared to the Windows NT operating

systems. Hence, this allows the applications to be

moved from one system to another while

preserving the configuration. However, these files

are not storage efficient.

Attacks on the Windows registry are more

common as it is easier to change the

configuration of many systems simultaneously

than in a Mac OS or UNIX system. Property lists

on a Mac OS or UNIX system are usually thought

to exceed the registries as they tend to be more

hackable and will continue that way for years to

come. [4]

2.6 Auditing

The Mac OS auditing tool (Appendix 2) stores

and audits all the information your computer

generates by default. Although it is stored in

binary, it still takes up a decent portion of the

memory and its size is constantly growing on a

daily basis. However, you are given the option to

change the default settings and select the classes

that you would like to be logged. [5] It is very

useful for live system monitoring, detection of

obstruction and post-mortem analysis. However,

not all systems can be auditable, for instance,

login sessions done through Xorg-based displays

would not be logged.

The auditing tool available in Windows NT is

similar to that of the Mac OS. Unlike the Mac

OS’s auditing tool, this tool is disabled by

default, which, depending on user preference,

could serve as an advantage over the Mac OS’s

auditing tool as it will not consume memory and

slow down the system. However, for Windows

NT users who are unaware of the default setting,

this could be considered as a disadvantage as

users are likely to be slightly more vulnerable as

compared to Mac OS users. The auditing tool

allows you to track the time and date of a failed

login attempt or a successful deletion of a file as

well as identify the user who had authorised such

actions; this adds another level of security. [6]

The UNIX system does not have an auditing tool

preinstalled. This puts users of the UNIX system

at a more vulnerable position when compared to

the other operating systems. While there are many

third-party applications, such as Lynis (Appendix

3), if users are not aware that their computers do

not come pre-installed with an auditing tool, there

is little use of such applications.

3. Conclusion

10

In conclusion, after evaluating the effectiveness

of the different operating systems in the above

categories, we feel that the Windows NT

operating system is much more secure than the

Mac OS and UNIX operating systems. The

Windows NT operating system has implemented

a much more holistic security system, offering

great flexibility such that the user is able to

customise security features according to his/her

own preferences. This is extremely essential as

the security needs of each individual will be

different and an effective security system will

need to adapt to such versatility; this is something

that is rather lacking in the other two operating

systems. That is not to say that the Mac OS and

UNIX operating systems are absolutely insecure,

just that they have a lot more room for

improvement as compared to the Windows NT

operating system.

11

Appendix 1: Windows NT

User and Group Accounts

When user and group accounts are first created,

they are automatically assigned security IDs

(SID) -- a unique number that identifies the

account -- which gains them authentication from

the computer and allows them domain access. For

example, for a user logging into a computer, the

user’s identity must be verified by the computer

in order to gain access to the Active Directory. In

the Active Directory, there are two access control

lists (ACLs) which control the access of the user

and group accounts: discretionary access control

lists (DACLs), which identify the access

permissions set on each user and group accounts;

and system access control lists (SACLs), which

identify the user and group accounts for auditing

when they succeed or fail in accessing an object.

Once the account authentication is confirmed by

the Active Directory, the Local Security

Authority (LSA) will generate a user access token

and associate a SID to the user account. The

information stored in the access token is used to

determine the level of access to objects that is

allowed when the user attempts to access them.

The SIDs in the access token are compared with

the list of SIDs that make up the DACL for the

object to ensure that the user is granted

permission to access; the access control process

identifies user accounts by SID rather than by

username. [7][8]

The default user accounts in the Windows NT

system are Administrator (which has full control

of the system and is only used for tasks that

require administrative credentials), guest (which

is used for users without an account stored in the

domain) and HelpAssistant (which is used to

establish a Remote Assistance session). [7]

Passwords

Security of the user account is ensured by the

Windows NT password policy, such as requiring

the passwords to be of a certain complexity and

also prompting regular changes of passwords. For

Windows NT, there is password policy to control

the safety of the user, such as change the

password regular and complexity to prevent from

the password attacks. Windows NT has many

ways of storing passwords; for user

authentication purposes, the NT one-way function

is used, where the password is hashed using the

MD4 algorithm and stored. There are many ways

and purpose for Windows operating systems to

store passwords. The LAN Manager one-way

function is a more complex hashing method.

When a user logs into the computer, the password

that the user inputs is hashed using both functions

and held in memory through the Local Security

Authority Subsystem Service (LSASS) process. If

the user is using a local account for

authentication, the hashed form of the password

obtained using the NT one-way function is

compared against the locally stored NT hash; if

there is a match, the user successfully logs in. The

Security Account Manager (SAM) is a database

that stores the user account and password in the

local computer. [9][10]

File and Directory System

Windows NT server allows you to share your

resources with others. For example, when you

share one of your directories, authorised users can

connect to the directory (and access its files) from

their own computers. Once you have shared a

resource, you can set restrictions on its

availability to certain users. These restrictions

(called share permissions) can be customised for

each user and these are set using the Windows

NT file system (NTFS). On NTFS volumes,

setting file permissions on files and directory

permissions on directories specifies the groups

and users that have access and the level of access

that is permitted. These permissions apply both to

users working at the workstation or server where

the file is stored and those accessing the file over

the network through a shared directory. Share

permissions for NTFS volumes are borne of a

12

combination of file and directory permissions.

[11]

Printer Sharing

Using Windows NT security features, you can

control access to printers, track printer use and

ownership, and take ownership of printers. Any

shared printers created are, by default, accessible

by all network users. Thus, to control printer

access, you need to modify the printers’

permission setting for a particular group or user.

There are four types of permissions that apply to

network printers: no access (overrides all other

permissions), print, manages documents (the user

is able to manage all documents sent to the

printer), and full control (the user is able to

change the permissions on a printer). [12]

Registry Protection

Typically all configuration and initialization

information is stored in the registry. Hence, it is

crucial that these files are protected. The

Windows NT registry protection feature helps to

restrict remote access to the registry. However,

the default is set to letting any administrator have

remote access to the registry. If the default

settings were not changed this means anyone that

is able to connect to your computer will be able to

access your registry and alter your configuration

information.[13][14]

Appendix 2: UNIX

User and Group Accounts

The UNIX system issues a unique identification

number -- user ID (UID) -- to each user.

Likewise, each group is associated with a group

ID (GID). Each user may belong to a group that

shares the same access permissions. Access

permissions are attached to each UID or GID, not

to the individual username. For example, if the

UID for the root account is 0, and the user creates

an account with username “root” with UID 100, it

does not share the same access permissions as the

root account. However, if the user creates an

account with username “king” with UID 0, then it

will share the same access permissions as the root

account. It is important to note that it is possible

for different accounts to have the same UID or

GID. The common user accounts in the UNIX

system are root, daemon, sys, agent, guest, ftp,

uucp, news, lp, and nobody. [15]

Passwords

Similar to that of Windows NT, the UNIX

password policy secures account passwords by

reminding users to change their passwords after a

fixed period of time. Account passwords pass

encrypted using the Data Encryption Standard

algorithm and are then stored in shadow files,

which are only accessible by the root account.

[15]

File and Directory System

The Unix system enables you to control which

users have access to your files and directories and

what access modes are permitted. Unix has three

access modes: read (the user is able to read data

from the file), write (the user is able to change the

data in the file), and execute (the user is able to

run the file); and these modes operate

independent of one another. As for directories,

you must have execute access to gain access to

anything inside the directory. To see the list of

contents in the directory, you must have read and

execute access. And you must have write and

execute access to create, remove or rename

objects in the directory. When you try to access a

file or a directory, the system places you into one

of three categories: user, group, or other, and each

category has its own set of access modes. Should

you try to access the file or directory in a mode

not allowed for your category, the system will

deny you access. [16]

Printer Sharing

13

When you share printers and/or enable remote

administration, the Common Unix Printing

System (CUPS) server will use Basic

authentication for administration tasks. Basic

authentication essentially places the clear text of

the username and password on the network and

since CUPS uses the system username and

password information, this information could be

used to gain access the possibly privileged

accounts. It is thus recommended that you enable

encryption to hide the password and username

information. [17]

Auditing

Lynn's is an open source auditing tool that

assesses the security protection of a UNIX based

system. It performs hundreds to tests to evaluate

the system, some of these tests are: firewall

auditing, incorrect file permissions and expired

SSL certificates. This application seems to be the

best that's in the market right now, however,

Lynis is targeted to professionals and some basic

users may not understand the reports given back

by Lynis to the user. [18][19]

Appendix 3: Mac OS

User and Group Accounts

Similar to the UNIX operating systems, Mac OS

X operating systems also use UID and GID for

user and group account identification. The main

difference is that the root account in Mac OS X is

disabled and it will not appear in Users &

Groups, Users, or Accounts preferences. The

common account types in Mac OS X are

Administrator, Standard, Managed with Parental

Controls and Sharing Only. [20][21]

Passwords

In the Mac OS X operating systems, account

passwords are assigned a unique password ID

which is stored in the directory domain. During

authentication, the directory domain will send the

password to the Password Server to search for the

user’s actual password. The Password Server is

based on a standard known as the Simple

Authentication and Security Layer (SASL); this

standard allows the Mac OS X to authenticate

several network user authentication protocols that

are used by clients of Mac OS X Server services,

such as mail and file servers. The Mac OS X has

the following encryption algorithm available:

MD5, APOP, SHA-1, and AFP 2-Way Random.

The type of password stored in the Password

Server is based on the network authentication

protocols enabled. If APOP or 2-way Random is

enabled, the Password Server stores a recoverable

(encrypted) password, else, only hashes of the

passwords are stored. [22]

File and Directory Systems

Every Mac OS X computer has a local directory

domain and it is the first domain checked when

the user is logging into the computer or

performing some other operation for which data

stored in a directory domain is necessary. The

Mac OS X Open Directory searches the

computer’s local directory domain for the user’s

records when the user is logging into the

computer and if the records are present (and the

password correctly typed in), the user is granted

access to the computer. That is to say, the user

will be successfully logged in. After this, should

the user wish to connect to a file server running

on the computer, the Open Directory then

searches for the user’s records in the server’s

local directory domain. If the records are found,

the user will be allowed access to the file

services. If, however, the records are not found,

the Open Directory will automatically search for

the user’s records in any shared domain to which

the computer has access. Multiple Mac OS X

computers are thus able to share administrative

data by storing said data in shared directory

domains. In addition, every file has its own

privilege settings that are independent of its

parent folder’s privileges; users are able to set

privileges for files and folders that they have

14

placed on the server, and the server administrator

is able to do the same for share points. It is,

however, important to note that the default setting

on the server allows guests to access it without

needing to log into the computer. [23][24]

Printer Sharing

The Mac OS X Print Service allows users to

share network printers with clients using the same

server by setting up print queues for them. When

users submit print jobs to a shared printer, the

jobs automatically join the printer’s queue, where

they stay until the printer is online or the criteria

set by the administrative user is met. For

example, the administrative user can set the

priority of the different print jobs in the queue,

the date and time at which a job is allowed to be

printed, or holding a job in the queue for an

indefinite amount of time. Unfortunately, there

are no security features in place to protect the

printers shared, and protection of print jobs and

data rely on that of the Mac OS X Open

Directory. [25]

Registry Protection

Property list are what applications usually

organize and store their configuration and

initialization information in. they also make data

transportable and storable while still being

effective. [26]

Auditing

The tool pre installed onto a MAC is called

openBSM. This tool creates audit records that are

logged chronologically in a directory that is

usually /var/audit, however, this always depends

on the individual's system. [5]

15

References

[1] Orlowski, A. (2013, August 20). Windows

NT: Remember Microsoft’s almost perfect 20-

year-old? The Register. Retrieved from

http://www.theregister.co.uk/2013/08/20/nt_at_2

0/

[2] Ritchie, D. M., & Thompson, K. (1978, July-

August). The UNIX Time-Sharing System. The

Bell System Technical Journal, Volume 57 (6).

Retrieved from

https://ia902709.us.archive.org/21/items/bstj57-

6-1905/bstj57-6-1905.pdf

[3] (2016, July 9). Mac OS. Retrieved from

https://en.wikipedia.org/wiki/Mac_OS#cite_ref-

leopard_unix_cert_1-0

[4] Kirk, D. (2013, February 20). Windows

Registry versus OS X Property List Files.

Retrieved from http://www.tech-

recipes.com/rx/38451/windows-registry-versus-

os-x-preferences/

[5] Gagliardi, R. (2015, January 8). Audit in a OS

X System. Retrieved from

https://www.scip.ch/en/?labs.20150108

[6] Microsoft Corporation. (2016). Monitoring

Events. Retrieved from

https://www.microsoft.com/resources/documentat

ion/windowsnt/4/server/proddocs/en-

us/concept/xcp09.mspx?mfr=true

[7] Microsoft Corporation. (2016). User and

computer accounts. Retrieved from

https://msdn.microsoft.com/en-

us/library/cc759279(v=ws.10).aspx

[8] Microsoft Corporation. (2016). Access control

in Active Directory. Retrieved from

https://msdn.microsoft.com/en-

us/library/cc785913(v=ws.10).aspx

[9] Microsoft Corporation. (2016). Security

Account Manager (SAM). Retrieved from

https://technet.microsoft.com/en-

us/library/cc756748(v=ws.10).aspx

[10] Microsoft Corporation. (2016). Passwords

Technical Overview. Retrieved from

https://technet.microsoft.com/en-

us/library/hh994558(v=ws.10).aspx

[11] Microsoft Corporation. (2016). Managing

Shared Resources and Resource Security.

Retrieved from

https://www.microsoft.com/resources/documentat

ion/windowsnt/4/server/proddocs/en-

us/concept/xcp04.mspx?mfr=true

[12] Microsoft Corporation. (2016). Setting Up

Print Servers. Retrieved from

https://www.microsoft.com/resources/documentat

ion/windowsnt/4/server/proddocs/en-

us/concept/xcp05.mspx?mfr=true

[13] Microsoft Corporation. (2016). Securing the

Windows NT Registry. Retrieved from

https://msdn.microsoft.com/en-

us/library/aa266903(v=vs.60).aspx

[14] Microsoft Corporation. (2016).

Understanding Windows NT Security. Retrieved

from https://msdn.microsoft.com/en-

us/library/aa266936(v=vs.60).aspx

[15] Garfinkel, S., & Spafford, G. (1996, April).

Practical UNIX and Internet Security. (2nd ed.).

Retrieved from

ftp://ftp.itsinternet.net/pub/Linux_and_Unix_Boo

ks/O'Reilly%20-

%20Practical%20UNIX%20And%20Internet%20

Security.pdf

[16] Losen, S. Unix File Protection Overview.

Retrieved from

http://people.virginia.edu/~scl/permission.html

16

[17] Apple Inc. Server Security. Retrieved from

https://www.cups.org/documentation.php/doc-

1.4/security.html

[18] Huston, B. (2014, March 21). Tool Review:

Lynis. Retrieved from

http://stateofsecurity.com/?p=3339

[19] CISOfy. (2016). Lynis - Security auditing

and hardening tool for Linux/Unix. Retrieved

from https://cisofy.com/lynis/

[20] Apple Inc. (2016). OS X Mountain Lion:

Create a new user account. Retrieved from

https://support.apple.com/kb/ph11468?locale=en

_US

[21] Apple Inc. (2016). Enabling and using the

"root" user in OS X. Retrieved from

https://support.apple.com/en-sg/HT204012

[22] Apple Computer, Inc. (2002). Mac OS X

Server: Administrator’s Guide. Chapter 3, p.121-

204.

http://images.apple.com/jp/server/pdfs/Mac_OS_

X_Server_v10.2.pdf

[23] Apple Computer, Inc. (2002). Mac OS X

Server: Administrator’s Guide. Chapter 2, p.65-

120.

http://images.apple.com/jp/server/pdfs/Mac_OS_

X_Server_v10.2.pdf

[24] Apple Computer, Inc. (2002). Mac OS X

Server: Administrator’s Guide. Chapter 5, p.221-

266.

http://images.apple.com/jp/server/pdfs/Mac_OS_

X_Server_v10.2.pdf

[25] Apple Computer, Inc. (2002). Mac OS X

Server: Administrator’s Guide. Chapter 7, p.315-

336.

http://images.apple.com/jp/server/pdfs/Mac_OS_

X_Server_v10.2.pdf

[26] Apple Inc. (2010, March 24). Property List

Programming Guide. Retrieved from

https://developer.apple.com/library/mac/documen

tation/Cocoa/Conceptual/PropertyLists/Introducti

on/Introduction.html

17

18

Quantum Information ScienceRonald Ong Ke Yu

National University of Singapore 9815 6417

[email protected]

Yong Jia Wern National University of Singapore

9336 2819 [email protected]

ABSTRACT In this paper, we would be first introducing the Quantum Information Science and how Quantum Cryptography came about. We would then focus on the phenomenon of Quantum Entanglement and look at its applications in the field of Quantum Cryptography and Quantum Information Science. Applications that would be discussed are Quantum Key Distribution (QKD) and Quantum Teleportation.

Categories and Subject Descriptors D.4.6 [Software]: Security and Protection – authentication, cryptographic controls, information flow controls

E.3 [Data]: Data Encryption – code breaking, public key cryptosystems, standards

K.6.m. [Computer Milieux]: Miscellaneous – Security

General Terms Security, Theory, Verification.

Keywords Quantum Cryptography, Quantum Entanglement, QKD, Quantum Teleportation

1. INTRODUCTION Quantum entanglement is a term referred to by Austrian physicist Erwin Schrodinger, and is the backbone of quantum physics. Two entangled particles are described by their joint behavior. This would mean measurements on the individual particle will lead to random outcomes but perfect correlation between them, no matter how far are they apart. Albert Einstein called quantum entanglement a “spooky action at a distance”. (Poppe et al., 2005) Development in quantum information science used this phenomenon to come up with new theories. In particular for this paper, QKD and quantum teleportation are the theories that are going to be discussed in detail.

2. QUANTUM INFORMATION SCIENCE Information Science is a relatively new field, starting out in 1982 by Richard Feymann. (Quantum Device Lab, 2013) He claimed that a computational device based on the quantum mechanics would be the most appropriate in simulating large scale quantum systems. A classical computer would be able to accomplish it but it would be inherently inefficient due to the fact that classical computers can only store information in binary as compared to quantum computers. This will be discussed further in the paper.

Quantum information science is a broad field encompassing all things related to computation, communication, storage, encryption, etc. which are based on the laws of quantum mechanics. It also tries to formulate procedures and suggest

experiments to better understand basic properties of quantum systems and develop intuition for the predictions of quantum mechanics through experiments. (Quantum Device Lab, 2013) This paper focuses on quantum cryptography and quantum computing.

3. CRYPTOGRAPHY Cryptography is the art of rendering a message unintelligible to any unauthorized party. To achieve this goal, an algorithm is used to combine a message with a key to produce a cipher text. This process is called encryption. The reverse of this process is decryption, whereby the key is combined with the cipher text to return the plaintext. For the encryption and decryption to be secure, both processes should be impossible without the key. The goal is to maintain the secrecy of the information for as long as it is valuable. (Gisin et al., 2002)

3.1 Public Key Infrastructure Public key infrastructure is an infrastructure that maintains the running of cryptographic applications. It is used to create, save and disseminate digital certificates which can justify that a particular public key represents the certain entity. This is how the process goes: a particular individual applies for a digital certificate for a public key through a registration authority (RA). The RA verifies his information and sends a request to a certificate authority (CA). The CA is a trusted third party who generates and authorises a digital certificate that binds his identity and his public key. The certificate is then sent to the individual as well as uploaded to a directory or repository. The public key is made known to outsiders for them to encrypt messages for the individual. The PKI enables the use of public key in a secure manner and prevents man-in-the-middle attack. (Tan et al., 2014) A common algorithm is the Rivest, Shamir, & Adleman (RSA) algorithm.

3.2 RSA RSA is still a widely-used algorithm to generate asymmetric keys for the purpose of cryptography. The following steps outline the process required in order to generate the public and private keys for the encryption and decryption. (Steyn, 2012)

Key Generation Steps:

• Generate 2 prime numbers, p and q • Multiply both numbers together to get their modulus, n

= pq • Calculate totient of n, φ (n) = (p - 1)(q - 1) • Get a random prime number from the range 3 ≤ e < φ(n)

where greatest common divisor (gcd) of e and φ(n) is 1 i.e. gcd (e, φ(n)) = 1

• Get d, which is an inverse of e with respect to mod(φ(n)) i.e. d⋅ e ≡ 1 mod (φ(n))

19

• The public key will be (e,n) while the private key will be (d,n).

The encryption process follows this formula:

c = me (mod n) Where c is the cipher text, m is the message, e and n are from the public key. The decryption process follows this formula:

m = cd(mod n) Where m is the message, c is the cipher text, d and n are from the private key. The RSA is a strong algorithm as it would require a long time in order to decipher the encrypted message by brute force or classical means as 1024 digit prime numbers are typically used for RSA. However, RSA can be easily broken by Shor’s algorithm in theory, which makes use of quantum computing.

3.3 Shor’s Algorithm This algorithm was invented by Peter Shor, a Mathematics professor in 1984. The algorithm manages to factorise large prime numbers into their factors in polynomial time as compared to general number field sieve which solves it in sub-exponential time. The effectiveness of Shor’s algorithm is due to its implementation quantum Fourier transform and modular exponentiation by repeated squaring. (Awwad, 2014) Shor’s algorithm is made up of 2 parts: 1) a reduction of the factoring problem to the problem of order-finding and 2) a quantum algorithm to solve the order-finding problem. Let N be an odd composite number which has factors p and q. The algorithm is as follows:

1. Pick a random number, q, such that N2< q < 2N2 2. Pick a random integer, x, and calculate the gcd (x,N)

using the Euclidean algorithm. 3. If gcd (x,N) ≠ 1, N has been factored. Or else, continue

with the algorithm. 4. Create two entangled quantum registers such that:

a. Input register: must contain sufficient qubits to represent numbers as large as q - 1

b. Output register: must contain sufficient qubits to represent numbers as large as N - 1

5. Load the input register with an equally weighted superposition of all integers from 0 to q -1

6. Load the output register with all zeros 7. Apply the transformation of the periodic function (xa

mod N, where a represents 0 and positive integers) to each number in the input register, storing the result of each computation in the output register.

8. A measurement on the output register will be taken. This will collapse the superposition to represent just one of the results of the transformation. Let this value be c.

9. Since the two registers are entangled, measuring the output register will have the effect of partially collapsing the input register into an equal superposition of each state between 0 and q-1 that yielded c (the value of the collapsed output register.)

10. Quantum Fourier transform will be applied on the partially collapsed input register. This process raises the probability amplitudes at integer multiples of q/r as the

superposition states no longer have the same probability. r is the desired period for the algorithm.

11. The factors of N can be determined by taking the gcd of N with respect to xr/2 + 1 and xr/2 - 1. This computation will be done on a classical computer.

12. Repeat Step 2 by taking a new value x value. Steps 4 to 10 happen in a quantum computer whereas the other steps happen in a classical computer. An attacker could harness Shor’s algorithm to determine what values are p and q in order to get the public and private keys. RSA is, hence, breakable. New methods are required in order to protect systems and communications from quantum attacks.

4. QUANTUM CRYPTOGRAPHY Quantum cryptography is the synthesis of quantum mechanics with the art of code-making. (Lo et al., 2008) Its goal is to perform tasks that are impossible with conventional cryptography by making use of quantum no-cloning theorem and Heisenberg's uncertainty principle. Quantum cryptography was the idea formulated to help deal with the increasing need to defend ourselves from quantum attacks. Before we proceed further, we feel that it is essential to define a few terms for ease of discussion.

4.1 Definitions 4.1.1 Qubit Qubit refers to a quantum bit. A traditional bit has one of two possible states - 0 or 1. On the other hand, a qubit has many more states. We can think of a qubit as a sphere, whose states can be represented as ‘coordinates’ on this sphere. In this sense, a qubit seemingly contains an infinite amount of information because there is an infinite sequence of possible coordinates in the sphere. However, in order to extract information from the sphere, we would need to take measurements. Quantum mechanics dictates that once an observer observes/measures a quantum system, it no longer remains in a state of uncertainty; it needs to have a definite set of properties. The same does for the qubit. Once we measure the qubit to get information from it, it will become an ordinary bit of 0 or 1.

Figure 1: Comparison between Classic Bit and Qubit

(QOQMS, 2016) The quantum state of a qubit is

|Φ⟩= 𝞪|0⟩ + 𝜷|1⟩

4.1.2 Quantum Entanglement Entanglement is a property of two or more quantum systems whose quantum states cannot be described individually; rather it

20

can only be described as one whole system. For the ease of the rest of the discussion, the ideal case is assumed where two qubits are maximally entangled. There are four possible maximally entangled states of two qubits known as The Bell states. They are formally written as:

These states have an interesting feature. If a specific operation is performed on only one of the two qubits, then its state can be changed to any of the other three Bell states, regardless of which initial state it had before the operation. (Horodecki et.al, 2009)

4.1.2.1 Creation of Entangled States There are various ways to create entangled states. It is actually difficult to implement some quantum gates and to perform the required measurements.

1. Experimental generation using special physical phenomena. While progress has been achieved in creation of bipartite entanglement, design of multipartite entanglement is still in infancy.

2. An application of some unitary operations to separable states. For example, all Bell states can be obtained if XOR operation is applied to the separable states |φ >|a> where a ∊ {0, 1} and |φ> is a suitable qubit state. A two-qubit gate is called entangling if it can create an entangled state when applied to a separable state. Entangling gates are very important. A two qubit gate forms with one-qubit gates a universal set of gates if and only if it is an entangling gate.

3. Entanglement swapping is a transformation, by measurement only, of distant, and never-before-interacting, particles into entangled ones. If particles P1 and P2 are in the EPR-state and so are particles P3 and P4, then the Bell measurement of particles P2 and P3 makes particles P1 and P4 to be in the EPR-state. Entanglement swapping was already experimentally verified.

4. Measurement of separable state with respect to a basis consisting of entangled states. (Gruska, 2003)

4.2 Quantum Key Distribution As mentioned before, Shor’s algorithm prompted us to develop new ways of communicating securely. One such method that is currently being worked on is the QKD.

4.2.1 Overview QKD is a technology that makes use of quantum mechanics to generate and distribute provably secure keys over unsecured channels, namely a quantum and a classical channel.

Figure 2: How QKD works (QKD, 2016)

It is important to note that QKD is only used to produce and distribute a secure key; it is not used to transmit any data. That is why it is given the name Quantum Key ‘Distribution’. The key should then be used together with another known encryption and decryption algorithm to transfer the message. There are many known protocols for QKD. However, out of all the protocols, the BB84 and its variants are the only known provably secure QKD protocols. (Mink et.al, 2009) As such, we will present only the BB84 protocol in this paper.

4.2.2 BB84 Protocol This protocol was proposed by Charles Bennett and Gilles Brassard in 1984; hence its name BB84. (Lloyd S., 2009) This protocol commonly uses photon polarization to encode the qubits that are to be sent. In particular, two polarization bases are used in this protocol, namely the rectilinear basis and diagonal basis. (Chong et.al, 2010) The rectilinear basis could be either vertical or horizontal, while the diagonal basis could be either 45° or 135°. The process:

1. Alice chooses one of the classical bits ‘0’ or ‘1’ at random and encodes it with one of the bases. After that, she polarises a photon by randomly choosing a basis according to the table below:

Table 1: Possible Choices of Basis

2. After polarizing the photon, she then sends it to Bob via

a quantum channel. 3. Steps 1 and 2 are repeated. While performing steps 1

and 2, she has to keep track of the classical bit she chose and the basis used for each of bit. On Bob’s end, he will also choose a random sequence of basis.

4. He then measures the polarization of each photon that Alice sends.

5. If Bob chose the same basis as Alice, then he will measure the same polarization. If the basis is different,

Basis 0 1

+ (Rectilinear) | -

X (Diagonal) ╲ ╱

21

then Bob will be measuring a random polarization in his chosen basis.

6. Upon receiving all the photons from Alice, Bob will now communicate with Alice over a classical channel.

7. Both will compare basis choices. If their basis choices match, then they will use the bit for that basis as part of the shared key between Alice and Bob. Otherwise, they will discard the basis and the corresponding bit. They now have their shared key and will compare their key to ensure that they are the same; they might be different if there is an eavesdropper.

8. Below is an example of the entire process in table form.

Table 2: Summary Table of the Entire Process

Alice’s Basis X X + X + + + X

Alice’s Bit 1 0 0 1 0 1 1 0

Alice’s photon polarization

╱ ╲ | ╱ | - - ╲

Bob’s Basis X + + + X + X X

Bob’s measured polarization

╱ - | - ╲ - ╱ ╲

Shared secret Key 1 0 1 0

As seen, it is not surprising that, on average, Bob will correctly guess the basis 50% of the time. Hence, it is expected that half the bits randomly chosen by Alice will be used on average. This is assuming that there is no eavesdropper. Suppose now Eve decides to listen in on their transmission and decides to intercept all of Alice’s photons before passing them on to Bob (to make as though there is nothing wrong). Since Eve would not know what basis Alice is using, Eve also has to choose a random sequence of basis. If Eve chooses the same basis as Alice, then Eve would measure the correct polarizing state and would be able to send the correct state to Bob. The problem for Eve lies in the fact that she chooses a wrong basis 50% of the time. In this case, the polarizing state measured by Eve would be random (since the basis is different). If Bob originally had the same basis as Alice, he now only has a 50% chance of getting the same polarizing state as Alice; where if Eve was not present, he would definitely get the correct polarizing state. It can be seen that in this case, Bob will have a key string that has 0.53 = 12.5% chance of errors. Hence, when Alice and Bob compare keys and discover discrepancies, they will know that Eve is listening in and can decide to perform the process again or change their key.

4.3 Quantum Teleportation Quantum teleportation refers to the transfer of a qubit exactly from one location to another, without the qubit being transmitted through the intervening space. Usually, to completely specify the quantum state of a system, an infinite amount of information is required, even for simple systems involving merely two qubits.

Furthermore, one of the main ideas in quantum mechanics is that any measurements done on a system will immediately alter the state of the system. Hence the transfer of quantum information from one system to another (which requires that measurements be taken on the first system and operations be performed on the second system) should seem virtually impossible. However, quantum entanglement enables this to happen. (Hänsel et al., 2004)

4.3.1 Process Before we begin the process proper, suppose that:

1. Alice would like to send one qubit in an unknown state . This state has to be unknown to

Alice, otherwise she can just phone Bob to tell him the details of the state and Bob will be able to recreate the state in a particle he possesses.

2. Alice and Bob have a classical telephone that is capable of transmitting two classical bits. There needs to be two classical bits because Alice and Bob need to ensure that all four entangled Bell state can be represented uniquely.

3. Alice and Bob share an entangled Bell state

That is, Alice has one half of the entangled pair of photons, while Bob has the other half. This is fixed by mutual agreement before the process begins between Alice and Bob. It does not really matter which state is chosen, as long as one of the states is chosen.

Initially, the state of the three qubits is

This can be rewritten as

Figure 3: Final Equation (Horodecki et. al, 2009)

To perform the teleportation, Alice first needs to measure the system she has. In other words, she has to perform a measurement on the unknown qubit she has and half the entangled photon. This measurement causes Alice to randomly obtain one of the Bell states:

To ensure that she is able to communicate the information to Bob regardless of which state she obtains, two bits of classical information is needed (this is the minimum because 22 = 4). Alice’s measurement process is itself entangling, and the entanglement between Alice’s and Bob’s original particles is now broken. (Horodecki et.al, 2009) On Bob’s side, the measurements

22

caused Bob’s particle to change its state into one of the four Bell states (due to the Heisenberg Uncertainty Principle and the entanglement between Alice’s and Bob’s particle). The problem is that all four states ‘look very similar’ to the original qubit that Alice has, and there is no way for Bob to determine which is the correct one without further information. This is where Bob waits for Alice’s phone call over the classical telephone. Alice sends the two bits of classical information she obtained from her measurements to Bob and Bob now know exactly which of the four states he is in. He can then apply an operation to his system to obtain the original qubit in the desired state

. Note that because of the entanglement between two of Alice’s original particles, her original qubit is no longer in this state. Hence, it is as though it has disappeared from her side. On Bob’s side, after performing the operation, his particle will take on the state . The ‘disappearance’ of the particle from Alice’s side and ‘reappearance’ of the particle in Bob’s side is the reason why this is called teleportation.

Figure 4: Quantum Teleportation

5. FUTURE OF QUANTUM INFORMATION SCIENCE 5.1 Challenges Quantum technology may be its own limiting factor. A quantum computer can only function if the information exists long enough for processing. The coherence of the qubit ensures that the quantum information remains intact. Research has discovered that the coherence, and hence the stored information, spontaneously disappears over time even without external noise. (NOSR, 2005) This could impede or even extinguish the possibility of developing a quantum computer. Also, the cost of making a quantum computer is still too high. A group of physicists estimated in order to make a quantum computer for any practical computing power, it would require

about 100 billion optical components. (Johnston, 2015) The technology needed for the computer to be in working condition is also beyond the current technology scientists have now, making this an even harder goal to achieve. Technology and the cost of making this technology feasible are severely limiting the advances in quantum information science.

5.2 Developments Though progress in quantum information science remains stagnant, scientists have extended the knowledge and application of quantum dynamics to other fields. In recent years, research in quantum information science has expanded into the field of biology, specifically in the area of quantum biology. Though the entire process is not fully understood, quantum coherence and quantum entanglement are important in the energy transport in photosynthesis, magnetic sensing in birds and olfaction. (Cai, 2016) A more elaborate development is the creation of a quantum informative protocol that simulates biological beings in a natural selection environment was successfully created. (Alvarez-Rodriguez, 2016) It describes artificial life that aims at reproducing fundamental biological behaviours with controllable quantum platforms. The artificial lives are quantum individuals that can be born, evolve, interact, mutate, and die, while they propagate and de-cohere in a common environment. These concepts are designed to be implementable with current quantum technologies. The future of quantum information science remains exciting. Being a relatively new area of interest, there is a lot of potential and unknown territories to discover. Though the immediate outlook of quantum information science is bleak given the major constraints in technology and costs, perhaps more research is required in order to bypass and overcome them. New links are being drawn at the same time to bring two seemingly different fields together opens up a new area of research.

6. CONCLUSION This paper gave a general overview of quantum information science and quantum cryptography. It also explored the phenomenon of quantum entanglement. Quantum entanglement, though it is a fairly simple phenomenon in quantum mechanics, has led to various theories being developed. It went on to describe two applications of the phenomenon and despite there are not for any practical use yet, we remain hopeful as to there will come a day when sufficient technology advancement allows a suitable application of it.

7. ACKNOWLEDGMENTS We would like to thank Dr Hugh Anderson for kindly lending us the book, “Introduction to Quantum Information Science”.

8. REFERENCES [1] Alvarez-Rodriguez, U., Sanz, M., Lamata, L., & Solano, E.

(2016, February 08). Artificial Life in Quantum Technologies. Sci. Rep. Scientific Reports, 6, 20956. doi:10.1038/srep20956

[2] Awwad, O. (2014, April 13). Shor's Algorithm. Retrieved from Department of Computer Science | Western Michigan

23

University: https://www.cs.wmich.edu/elise/courses/cs6800/shorsAlgorit hm.ppt

[3] Cai J M. Quantum biology: explore quantum dynamics in biological systems. Sci China Inf Sci, 2016, 59(8): 081302, doi: 10.1007/s11432-016-5592-y

[4] Chong, S., & Hwang, T. (2010). Quantum key agreement protocol based on BB84. Optics Communications, 283(6), 1192-1195. doi:10.1016/j.optcom.2009.11.007

[5] Gruska, J. (2003). Quantum entanglement as a new information processing resource. New Gener Comput New Generation Computing, 21(4), 279-295. doi:10.1007/bf03037304

[6] Hänsel, W., Häffner, H., Roos, C. F., Benhelm, J., Blatt, R., Riebe, M.. . Körber, T. W. (2004). Deterministic quantum teleportation with atoms. Nature, 429(6993), 734-737. doi:10.1038/nature02570

[7] Horodecki, R., Horodecki, P., Horodecki, M., & Horodecki, K. (2009). Quantum entanglement. Reviews of Modern Physics,81(2), 865-942. doi:10.1103/RevModPhys.81.865

[8] Johnston, H. (2015). Light-based quantum computers will come at a great cost ... Retrieved July 23, 2016, from http://physicsworld.com/cws/article/news/2015/oct/26/light-based-quantum-computers-will-come-at-a-great-cost

[9] Lloyd, S. (2009). Retrieved from Massachusetts Institute of Technology: http://web.mit.edu/2.111/www/notes09/spring.pdf

[10] Lo, H., & Zhao, Y. (2012). Quantum Cryptography. Computational Complexity, 2453-2477. doi:10.1007/978-1-4614-1800-9_151

[11] Mink A., Frankel S., Perlner R. (2009) Quantum Key Distribution (QKD) and Commodity Security Protocols: Introduction and Integration International Journal of Network Security & Its Applications (IJNSA), Vol 1, No 2, July 2009. http://arxiv.org/pdf/1004.0605v1.pdf

[12] Netherlands Organization for Scientific Research. (2005, July 18). Fundamental Limitation To Quantum Computers. ScienceDaily. Retrieved July 22, 2016 from www.sciencedaily.com/releases/2005/07/050708060942.htm

[13] Poppe, A., Fedrizzi, A., Hubel, H., Ursin, R., & Zeilinger, A. (2005). Entangled state quantum key distribution and teleportation (Abstract only). 31st European Conference on Optical Communications (ECOC 2005). doi:10.1049/cp:20050837

[14] QOQMS | Research - Quantum Computing. (2016).Qoqms.phys.strath.ac.uk. Retrieved 19 July 2016, from http://qoqms.phys.strath.ac.uk/research_qc.html

[15] Quantum Device Lab (2013). Introduction to Quantum Information Science. Retrieved 23 July 2016, from http://www.qudev.ethz.ch/content/QSIT13/QSIT.pdf

[16] Quantum Key Distribution - QKD. (2016).Cse.wustl.edu. Retrieved 20 July 2016, from http://www.cse.wustl.edu/~jain/cse571-07/ftp/quantum/

[17] Tan, S., Yau, W., & Lim, B. (2014, June 13). An implementation of enhanced public key infrastructure. Springer Science, 74, 6481-6495. DOI:10.1007/s11042-014-2119-7

[18] Steyn, B. (2012, May 26). How RSA Works With Examples. Retrieved July 24, 2016, from http://doctrina.org/How-RSA-Works-With-Examples.html

24

An Analysis of Application-Layer Vulnerabilities in

Android Smartphones and Lessons Learned Amarparkash Singh Mavi

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected]

Kar Chaudhuri Anirban School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

Patrick Cho Chung Ting School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

ABSTRACT

Smartphones have become much of a necessity today owing to its

vast capabilities. Many of these capabilities can be attributed to

the sophisticated platforms they operate on. The Android

operating system, in particular, has become the most dominant

smartphone operating system today. The immense popularity of

this platform has also attracted the attention of cybercriminals on

a similar scale, making Android the most attacked mobile

operating system. A significant portion of these attacks are

attempted through the Android application markets. In this paper,

we analyse application-layer vulnerabilities in Android

Smartphones, focusing on both the technical vulnerabilities of the

Android security architecture as well as the non-technical

vulnerabilities of the Android ecosystem. This paper derives

lessons learned from these Android vulnerabilities in a bid to

provide recommendations to mitigate, or even eliminate, these

vulnerabilities. These recommendations are targeted at three main

stakeholders, namely the Android platform developers, the

Android application developers and the Android users.

Categories and Subject Descriptors

D.4.0 [Operating Systems]: Security, Android

General Terms

Security

Keywords

Android, Application Sandboxing, Inter Component

Communication, Fragmentation, Application Distribution

1. INTRODUCTION In current times, the computational and storage capabilities of a

smartphone resemble that of a traditional PC [10]. Possessing vast

amounts of data and personal information, these smartphones

have turned into attractive targets for cybercriminals. The

capabilities that smartphones possess are mostly attributed to the

sophisticated platforms they operate on. While multiple platforms

such as Google’s Android, Apple’s iOS and Windows 10 Mobile

exist, the mobile platform of interest is certainly Android, which

has been, and continues to be, the most attacked mobile operating

system since 2011 [36]. As of 2015, the percentage of mobile

malware targeting the Android Operating System (OS) stood at

97% [25]. A major reason for this is the dominance of the

Android OS in the smartphone market [1]. In 2015, Android was

known to possess an overwhelming market share of close to 83%

(see Figure 1) [20].

Figure 1. Worldwide Market Share of Smartphone OS in 2015

Being such a popular mobile platform, Android boasts a vast

community of users that cybercriminals can target and exploit.

The popularity of Android amongst users and cybercriminals

gives us the motivation to analyse the Android platform in greater

detail, through this paper. Furthermore, according to Takamasa

Isohara et al., “The most major threat of Android users is malware

infection via Android application markets.” [17]. Given that

Android applications are a popular medium for propagating

malware, our paper focuses on application-layer vulnerabilities

associated with the Android platform. The paper is structured as

follows. In Section 2, we provide a brief overview of the Android

software architecture. Following this, in Section 3, we discuss

some application-level attacks that exploit the architecture. In

Section 4, we analyse some non-architectural vulnerabilities of the

Android platform that encourage the propagation of malicious

applications. In Section 5, we provide lessons learned for 3 main

stakeholders namely, the Android platform developers, the

Android application developers and the Android users. This

includes lessons that can be drawn from existing security

frameworks of other OS such as Apple’s iOS. Lastly, in Section 6,

we provide some concluding remarks.

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee.

Conference’10, Month 1–2, 2010, City, State, Country.

Copyright 2010 ACM 1-58113-000-0/00/0010 …$15.00.

25

2. ANDROID SOFTWARE

ARCHITECTURE In this section, we present a brief overview of the Android

software architecture.

Figure 2. The Software Stack of Android

2.1 Software Stack The Android software stack is divided into a few main

components (see Figure 2) [31]. The bottom layer is a Linux

Kernel, which performs low level functionality such as process

management, memory management and device management [28].

On top of this Linux Kernel sits the process Virtual Machine

(VM) of Android. This process VM is the runtime environment of

all Android applications that works in a similar way to the Java

Virtual Machine (JVM). Older versions of Android use the Dalvik

Virtual Machine (DVM) while newer ones (after Android 4.4

“KitKat”) use the Android Runtime (ART) for better performance

and lower power consumption [13].

At the top of Android’s software stack sits the Application

Framework and Applications Layer. Android application

programs are written in Java and the individual files are compiled

to .class format. These .class files are then merged into a single

Dalvik Executable (.dex) which contains Dalvik bytecode that

runs on either DVM or ART. A critical file present in all Android

applications is a file titled AndroidManifest.xml. This file contains

important meta-data such as the permissions required for the

application to be installed [12].

2.2 Application Sandboxing Each Android application has its own set of permissions. For

instance, it is reasonable for Google Maps to be given permission

to use the phone’s GPS while it may be less so for a game like

Angry Birds. These permissions have to be approved by the

Android user prior to installation [31].

Android implements these varying application permissions

through application sandboxing. Specifically, Android

implements the Linux Discretionary Access Control (DAC),

where each application gets a unique User ID (UID) that is

generated based on a Public Key Infrastructure (PKI) certificate

signed with the developer key [12]. The Linux kernel then

sandboxes each individual application based on their UID and

enforces security between applications through standard Linux

facilities [2]. Since any software above the Android Linux kernel

is run within an application sandbox, any code executed by an

application is done so only in the context of that particular

application.

Android further protects network access through its Paranoid

Network Security. This is done by assigning a Group ID (GID) to

applications [12]. For instance, a GID may be titled “internet

only” and all applications that have internet access only would be

assigned this GID. Since Android sandboxing is done on the OS

level, DVM and ART are not concerned with runtime security.

This is unlike JVM, which uses a Security Manager to control

access to resources external to JVM [11]. Doing so allows Dalvik

to interoperate with native code without any security constraints

[30].

2.3 Inter Component Communication Although all applications are sandboxed, Android allows

applications to communicate with each other through its Inter

Component Communication (ICC) mechanism [12]. Android

applications are built using 4 types of components: activities,

services, broadcast receivers and content providers [4]. When an

application component initiates ICC, it does so through an

Android messaging object known as intent [15]. The Android

Reference Monitor (RM) then performs Mandatory Access

Control (MAC). It does so by comparing the permissions of the

application the intent originates from with the required

permissions of the destination component. Concretely, there are

two types of permissions that can be specified in the

AndroidManifest.xml file - ‘permissions’ and ‘uses-permissions’.

‘Permissions’ are application specific and specifies the

application’s permissions. ‘Uses-permissions’ are component

specific and specifies what permissions another application needs

to have before it can perform ICC with it [3]. Hence, if

application A’s component 1 communicates with application B’s

component 2, the Android RM checks if the ‘uses-permissions’ of

component 2 is a subset of application 1’s ‘permissions’. Only if

the subset is fulfilled, will ICC be allowed. An Intent’s target

component can be specified either explicitly or implicitly. Explicit

intent is specified through the package and class names while

implicit intent is specified through the intent’s action, category or

data fields [15].

3. ARCHITECTURAL VULNERABILITIES Many of the application-layer attacks on Android phones can be

attributed to the architectural vulnerabilities of Android. In this

section, we look into some of the more popular attack techniques

that have been used on Android, focusing on application-level

attacks that are carried out through the ICC mechanism.

3.1 Application-Layer Privilege Escalation

Attack (ALPEA) An ALPEA occurs when “an application with less permissions (a

non-privileged caller) is not restricted to access components of a

more privileged application (a privileged callee)” [9]. Figure 3

illustrates a high-level example of how an ALPEA might occur

[23]. When installing 2 individual applications, an Android user

only needs to consider whether the privileges of each application

is sound. For instance, it is reasonable for a Contacts Manager

application to have access to Contacts Data. It is also reasonable

for a Weather application to have access to internet. Since the 2

applications are sandboxed, contact information should be

protected since such data cannot be transferred to the internet.

26

However, if there is a communication channel between these two

applications, it becomes possible for the contacts information to

be leaked to the internet. As such, the contacts manager

application would have escalated its privilege to one with internet

access.

Figure 3. High-level example of ALPEA

There are two main types of ALPEA: Confused Deputy Attack

and Collusion Attack.

3.1.1 Confused Deputy Attack A Confused Deputy Attack occurs when a malicious application

exploits some vulnerable component of another (confused)

application with higher privileges [4]. Referring back to the prior

example, the Contacts Manager application can act as a malicious

application while the Weather application is the confused deputy.

For instance, the weather application could have a component that

listens to implicit intents. This component reads the data from

these implicit intents and sends the data to a server. The

component only expects to receive GPS input, with which the

server would return a weather forecast. However, the Contacts

Manager application can send an implicit intent containing

contacts data instead. If written in the right way, the Weather

application component may get confused and send the data to the

server, even though the data represents phone numbers rather than

GPS coordinates. Thus, the Contacts Manager application would

have confused the Weather application and, in doing so, escalated

its privilege to gain internet access.

A Confused Deputy Attack can be done even on a secure

application through transitive means. Such an attack would

involve 3 or more applications, an example of which is shown in

Figure 4 [9].

Figure 4. Example of Confused Deputy Attack

involving three applications

In this attack, application A is the malicious application,

application B is the vulnerable application and application C is

the target application. The attacker wishes to use application A to

communicate with application C. Unfortunately, application A is

unable to communicate with any of the components of application

C since all these components have ‘uses-permissions’ specified

and application A has no given ‘permissions’. However, an attack

is still possible via vulnerable application B. The attack begins

when component 1 of application A communicates via ICC with

component 1 of application B. Component 1 of application B

does not contain any required ‘uses-permissions’ and therefore

RM allows this communication to take place. Subsequently,

component 1 of application B communicates with component 1 of

application C. Component 1 of application C requires a ‘uses-

permission’ of p1 which application B has. Hence, the Android

RM also allows this communication to take place. In this manner,

application A is now able to gain a transitive communication

channel with application C. This attack exploits the fact that the

Android security framework only attempts to secure point-to-

point inter component communication but not transitive ones.

More importantly, it is not mandatory for each component of an

application to have specified ‘uses-permissions’. Consequently,

an application with poorly written ‘uses-permissions’ can be

utilised as an exploitation medium. Given the large number of

applications in each phone, the number of possible transitive

communications is very high. Hence, ALPEA via Confused

Deputy Attack is highly probable.

3.1.2 Collusion Attack A Collusion Attack is another form of ALPEA. Concretely, an

attacker can develop 2 colluding applications, such as a weather

application and a phone contacts application as before. The

attacker can then give both applications the same public key

certificate while granting the applications different permissions.

As mentioned in the previous section, Android applications are

sandboxed according to their UIDs, which are in turn determined

by the application’s public key. Since both applications have the

same public key, they have a shared user ID. Hence, both

applications can now access each other’s permissions and

resources [12]. In this example, the contacts manager application

can read the contacts and save them in a shared file. The weather

application can then read this shared file and upload the contacts

through the internet. A collusion attack done through shared

system files is said to be done via covert channels [4]. This attack

exploits the fact that Android application UIDs are not truly

‘unique’. A malicious attacker can therefore easily breach the

Android application sandboxing model.

3.2 Intent-Based Attack As mentioned in the section on Android Software Architecture,

there are two main types of intent: implicit and explicit. An

explicit intent is done by specifying the target component’s

package name and class name. On the other hand, an implicit

intent specifies the action, category or data fields of the target

component. A common but poor developer practice is to use

unique action strings when doing intra-application

communication [7]. For instance, we might have a component in

an application that is in charge of accessing private data. Once

this private data is accessed, the component sends an implicit

intent with a unique action string of “GotData” and the private

data attached. A separate component on the same application is in

charge of showing this data. The latter component has an intent

27

filter that specifies the same action string “GotData”. Since the

action string of the intent matches that of the intent filter, Android

passes this intent to the latter component. Such a practice is

vulnerable to two forms of attack: eavesdropping and intent

spoofing.

3.2.1 Eavesdropping A malicious application can eavesdrop on the aforementioned

application by specifying a component with an intent filter with

the same action string, “GotData”. In this scenario, since multiple

intent filters are compatible, the user is prompted to choose where

the intent is directed to [15]. If the user chooses the malicious

application, the malicious application will get hold of this private

data. While it is usually clear which application the user should

choose for the intended intent recipient, the malicious application

can disguise itself as another application through techniques such

as application repackaging [12], which will be discussed in a later

section. As such, it is much harder for the user to discern the

intended intent recipient.

3.2.2 Intent Spoofing A malicious application can also send malicious intents and such

an attack is known as Intent Spoofing. Figure 5 illustrates an

example of Intent Spoofing attack [6]. In this example, a

malicious injection application sends an intent with the action

string “showtimesNoLocationError”. The IMDb application

component which updates the UI of the application keeps

receiving this intent and believes that there are no show times. It

therefore generates the error shown in the screen on the right.

Figure 5. Example of Intent Spoofing attack

It is possible to prevent such an attack by specifying an export

flag for the IMDb application component and setting the value to

false. However, any component that has an intent filter is exported

by Android by default and is therefore made publicly visible to

other applications [7].

Eavesdropping and intent spoofing attacks are made possible

because Android allows intra-application communication to be

done via implicit intents, even when such a communication

channel seems insecure [15].

4. NON-ARCHITECTURAL

VULNERABILITIES Besides vulnerabilities that exist in the Android software

architecture, there are also non-architectural vulnerabilities of the

Android platform that encourage the propagation of malicious

applications. In this section, we will discuss some of these

vulnerabilities that make it more convenient for malicious

applications to thrive on the Android platform.

4.1 Fragmentation A major loophole in the Android model is the phenomenon of

fragmentation. Fragmentation refers to different Android versions

being run by users due to the unavailability of updates [12]. This

unavailability is caused by a delay in the Android update cycle. A

representation of the update cycle is shown in Figure 6 where it is

obvious that Android specific events D-G are responsible for the

delay in the eventual release of updates to users. [33].

Figure 6. Android update cycle

This lengthy update cycle arises due to the open-source nature of

the Android OS. The Android Open Source Project (AOSP),

which is administered by Google, is the platform through which

the source code for the Android OS is updated and managed [12].

The cooperation between Google, the Original Equipment

Manufacturers (OEMs) and telecommunication carriers is

bounded by the Open Handset Alliance (OHA) which was created

by Google. As part of this alliance, Google provides the base open

source operating system through the AOSP. This OS can then be

further customised by OEMs and telecommunication carriers in

the bid to acquire a competitive advantage, by distinguishing their

devices from other Android devices [33]. The OHA implies that

the OEMs and carriers have the final say with regards to the

deployment of updates to users. It is apparent that a significant

delay results because the update needs to be port to the

customised version of the operating system and hardware to

ensure compatibility [33]. There have been cases when major

updates took over 10 months to be deployed to users [19].

Moreover, OEMs and carriers may even disapprove of the

deployment of updates as their incentives might overshadow the

importance of security. For instance, OEMs might disapprove of

the deployment of OS upgrades that might potentially cause

performance degradation due to compatibility issues between the

software and hardware [24]. Essentially, the OEMs may not risk

doing anything that might tarnish their user reputation.

Furthermore, cost issues might also discourage OEMs and carriers

from deploying updates [19][24].

28

In essence, the significant delay or disapproval of the deployment

of updates results in an unavailability of updates for users, thereby

causing fragmentation. In October 2012, less than 2% of Android

devices had the most current version, 4.1 Jelly Bean, which was

already released in June 2012 (see Figure 7). This can be

contrasted with iOS where over half of the devices had iOS 6,

which had only been released 2 weeks before (see Figure 7) [24].

Figure 7. Levels of fragmentation for Android and iOS

Such significant levels of fragmentation leave users vulnerable to

cybercriminals. It is found that most malware applications

detected in the official application store (Google Play) and third-

party application stores exploit vulnerabilities that have already

been neutralised in updated versions of the OS [24]. However,

given that a vast majority of users are still using older versions of

the OS, they remain vulnerable and continue to provide a viable

platform for malware to operate. In addition, given that the

deployment times for updates might differ across OEMs, attackers

can easily employ reverse engineering techniques based on

devices with the update to identify the vulnerabilities that exist in

the devices without the update for subsequent exploitation [33].

4.2 Application Distribution A significant vulnerability lies with Google’s model for the

distribution of applications through application stores. Besides

Google’s official application store (Google Play), the Android

platform also supports applications from third-party application

stores. In this section, we shall examine the vulnerabilities that lie

in these two separate channels of application distribution.

4.2.1 Google Play With regards to Google’s official application store, Google Play,

there are considerably low barriers to the publishment of an

application. The cost of publishing an application is an

insignificant one-time fee. Furthermore, Google employs a highly

permissive approval process that grants publication approval with

negligible latency [8]. Such a process model appeals highly to

cybercriminals who perceive it as a viable platform to propagate

malware through malicious applications. Google has attempted to

enhance the security layer of this process model through the

service, Bouncer that was introduced in 2012. The main purpose

of Bouncer is to scan an application for malicious intent before

being uploaded to Google Play [21]. However, research has

shown that Bouncer can be successfully evaded [19] as malware

writers are able to obscure their malicious payload in the

application [32]. The ease of circumventing Bouncer essentially

implies a lack of robust security barriers against malicious

applications on Google Play.

4.2.2 Third-Party Application Stores In addition, Google permits the distribution of applications

through alternative third-party applications stores. While this

resonates well with Google’s open approach, it does give rise to

more avenues for malware to propagate into Android phones.

Research done by cyber security company, F-secure, in 2013

showed that although Android is a target of 97% of all mobile

malware, merely 0.1% of applications on Google Play had

malicious payload [18]. Instead, most of the malware originate

from third-party application stores in Asia and the Middle-East

which are much less regulated than Google Play, if at all [25].

Android159, an example of such an alternative third-party

application store, had a third of its applications possessing

malicious payload [18].

A common technique employed by malware writers for

propagating malware through third-party application stores is the

repackaging of applications. To repackage an application, an

attacker first downloads a popular application from Google Play.

The attacker then decompiles the Dalvik bytecode. Once

decompiling is completed, attackers can inject their malicious

code into the application and reassemble it into a trojan

application. This trojan application is then signed with the

attacker’s certificate and is usually distributed via third-party

application stores that have minimal defences against malware.

One possible usage of this attack technique is to replace the

application’s advertisements with the attacker’s advertisements,

thus redirecting ad revenue to the attacker. Figure 8 illustrates an

example of this attack [35].

Figure 8. Example highlighting differences between an original

application and the repackaged version

The user is oblivious to the differences (highlighted in bold)

between the two versions of the application and therefore is

unable to distinguish them. Such repackaging techniques also

cause the creation of malware variants, which are different

repackaged applications having the same malicious payload, and

damage the reputation of the original applications’ developers. To

illustrate the prevalence of this attack technique, [35] found that

between “5% to 13% of applications hosted on studied

marketplaces are repackaged”.

29

Google’s open approach towards application distribution presents

multiple avenues that cybercriminals could exploit to deliver a

malicious application. While Google does attempt to neutralise

malicious applications on its official store through initiatives such

as Bouncer, such efforts are unlikely to act as effective deterrents

to malware writers. That is because, malware writers can simply

divert the propagation of mobile malware to other application

stores which have negligible control barriers.

5. LESSONS LEARNED Given the vulnerabilities that exist in the Android platform, it is

crucial to identify the lessons that can learned. This is in a bid to

provide recommendations in eliminating these vulnerabilities or at

best, mitigate the effects of these vulnerabilities. In this section,

we provide lessons learned for 3 main stakeholders namely, the

Android platform developers, the application developers and the

users.

5.1 Android Platform Developers

5.1.1 Lessons from iOS In this section, we provide recommendations to the developers of

the Android platform based on comparisons with the iOS Security

Framework.

5.1.1.1 Application Sandboxing The first difference between Android and iOS security principles

lies in the way they perform the sandboxing of applications. Table

1 shows some of these differences [31].

Table 1. Differences between Android and

iOS Application Sandboxing Android Sandbox iOS Sandbox

All applications announce

permission requirements

Most applications have the

same permissions

Each application has a unique

ID (UID).

Most applications run as a non-

privileged user called

“mobile”. Instead, each

application has a unique home

directory.

Permissions require

installation-time approval

Permissions require first-usage-

time approval

A vital difference in the two application sandboxing models is

that permissions are checked at first-usage-time on iOS while it is

only checked at installation-time on Android. The iOS principle

of checking permissions when it is first required adheres to

Salzer’s principle of least privilege [29]. All permissions are kept

to the minimum and only given when required. On the other hand,

Android applications require installation-time approval of

permissions. Thus, users would have to give permissions to an

application even before they have the chance to use the

application and evaluate the necessity of such permissions. Such a

policy usually results in Android applications being given more

permissions than necessary. [24] reports that more than 42% of

Android applications request for more permissions than required.

We suggest that Android ought to move to a policy of first-usage-

time approval of permissions to ensure that Salzer’s principle of

least privilege is adhered to.

Since Android applications are self-signed by developers, it is

possible for a single developer to give two applications the same

signature and perform collusion attacks through shared UID.

While the policy of allowing shared UID is useful for developers

to share resources between applications, the consequences of a

collusion attack will likely be very severe and outweigh this added

convenience. Hence, we believe that instead of giving developers

some convenience of sharing resources, Android should instead

look into enforcing a unique ID for every application. The

mechanism of doing so is closely related to the policy of code

signing.

5.1.1.2 Code Signing Instead of allowing developers to self-sign their applications, code

signing on iOS is done by Apple. According to Apple, such

“mandatory code signing extends the concept of chain of trust

from the OS to applications, and prevents third-party applications

from loading unsigned code resources or using selfmodifying

code” [16]. By issuing Apple certificates, Apple ensures that all

iOS applications have a different public key. While it might be

difficult for Google to sign all applications due to the presence of

third-party application stores, we propose a possible workaround.

Firstly, Google issues certificates for applications on their official

application store. Simultaneously, Google acts as an authority to

verify that other third-party application stores perform similar

security checks and also issue their own certificates. In this way,

reputable application stores will attempt to obtain Google’s

verification, while insecure ones will not be verified and will

therefore become less reputable and popular over time.

5.1.1.3 Application Verification in Google Play Android focuses on allowing applications to be uploaded to

Google Play seamlessly. Before 2015, when only Bouncer was

used to detect malware, applications were uploaded to Google

Play almost immediately, with Bouncer being limited to 5 minutes

of testing [26]. With increasing malware found in Google Play,

Google added a human test element in its application review

process which increased the time taken for an application to be

uploaded to the store to a few hours [27]. However, the store’s

application verification process is still much shorter in time as

compared to Apple’s App Store, which reviews applications for a

few days [34]. Assuming a similar efficiency in application

review, Apple will be able to perform a more thorough application

review. As such, Google should invest more effort in making the

application review process robust.

A suggestion would be for Google to incorporate static analysis in

its review process. While Google’s Bouncer conducts only

dynamic analysis, Apple also goes through static analysis in its

review process [5]. Dynamic analysis involves testing an

application in runtime environment. Hence, if there is code that is

unreachable during the runtime test, the code will not be tested.

Since Google’s Bouncer was limited to 5 minutes of testing [26],

it is highly likely that parts of the application code remain

untested. Static analysis, on the other hand, involves reading the

code manually and reasoning whether the code may be malicious

or not. Hence, if there is malicious code that is only run a

significant time after download, only static analysis would help in

detecting the attack. Google should therefore also add some form

30

of static analysis to accompany Bouncer for a more thorough

application verification process.

5.1.2 Unsafe Practices in Android The Android security framework is structured in such a way that

the components of all applications by default have no ‘uses-

permissions’. Hence, by default, ICC will allow all applications to

communicate with these components. This property is a major

reason for the occurrence of ALPEA, with many developers either

forgetting or being too complacent to add these ‘uses-

permissions’ to make the application secure. In order to achieve

Salzer’s principle of fail-safe defaults [29], we suggest that

Android should instead assume that all components have the same

‘uses-permissions’ as the permissions given to the application. In

this way, all other applications will need to have a similar or

higher permission to send an intent via ICC to all of the

application’s components. Instead, if a component requires less

stringent ‘uses-permissions’, a developer can then modify it

accordingly. Such an opt-out approach would make applications

much more secure against ALPEA. Moreover, as mentioned in

Section 3 on Architectural Vulnerabilities, when a component

uses an intent filter, it is exported by Android by default, thereby

allowing the component to be accessed by other applications.

Such a policy once again violates Salzer’s principle of fail-safe

defaults [29] and increases the chances of intent spoofing. We

believe that Android should not export the component by default.

Instead, the export flag should be made explicitly true by the

application developer.

The Android security framework also allows intra-application

communication to be done via implicit intents, which exposes the

application to intent-based attacks. We suggest that Android

either bans implicit intents for intra-application communication or

issues a warning to developers when unique action strings are

used during intra-application communication. One difficulty in

implementing this solution is differentiating between

communication that is meant to be intra-application and

communication that is meant to be inter-application. A solution

could then be to infer the type of communication from the

‘export’ flag. If the ‘export’ flag is not set to true, only intra-

application communication should be allowed.

5.1.3 Update Cycle of Android An obvious suggestion to deal with the issue of fragmentation

would be to reduce the length of the update cycle. This is

particularly crucial for an open-source platform like Android

where vulnerabilities in the source code are transparent to

cybercriminals [19]. However, given the involvement of multiple

parties such as the OEMs and carriers, this is not an issue that can

be solved with a simplistic solution. A possible suggestion would

be to restrict OEMs from making radical modifications to the core

elements of the base open source operating system when

performing their customisations [33]. This will ensure that, the

time required to port an update will be significantly reduced given

that, this is one of the main causes of delay in the deployment of

updates.

5.2 Android Application Developers As Steve Mansfield-Devine, editor of Network Security, aptly puts

it, “while Android theoretically has a strong permissions model, it

is frequently undermined by how developers produce their apps”

[24]. Indeed, developers play an important role in writing good

software that is not vulnerable to attacks by malware. Firstly, we

believe that developers should comply with Salzer’s design

principle of least privilege [29]. Such a principle would entail

developers ensuring that their applications have ‘permissions’ set

to the minimum and ‘uses-permissions’ set to the maximum.

Secondly, developers need to understand the security concerns

when using intents and intent-filters. They should limit the usage

of implicit intents through unique action strings and specify

export flags as false, as much as possible.

5.3 Android Users While Android platform developers and Android application

developers play an important role in reducing the probability of

malware penetration, Android users also play a vital part in

ensuring that their phones remain secure.

One of our suggestions for users would be to exercise their

discretion when downloading applications. Users can look for

indicators such as spelling errors or unnecessary permission

requests to discern a malicious application. While this might not

deter sophisticated malware writers, it will certainly prove

effective against less professional ones. An example is shown in

Figure 9 where a malicious application that masqueraded as a

legitimate Adobe Flash Player application successfully infected 50

Android devices last year [22].

Figure 9. Example of a malicious application

Spelling errors in the name of the application and unreasonable

permission requests such as access to SMS or MMS services

clearly suggested that this was an illegitimate application. This

example shows that users can help to protect their phones against

malicious applications by exercising vigilance and discretion.

In addition, we also recommend Android users to install anti-

malware on their phones given that Android is the most heavily

targeted platform by malware writers [32]. As mentioned earlier,

user discretion is likely to prove ineffective against more

sophisticated malware writers. An example of such a scenario are

applications that appear legitimate and harmless during

installation time but subsequently receive their malicious payload

through updates [14]. As such, having an anti-malware would

provide an additional layer of security for users.

Lastly, we believe that users should avoid downloading

applications from third-party application stores. As mentioned in

the earlier section on Application Distribution, these stores offer

minimal resistance against malicious applications, thereby leaving

their users highly vulnerable.

31

6. CONCLUSION Given that Android is the most popular smartphone OS today, it is

highly crucial that the relevant stakeholders play their part in

making the Android platform more secure. With an open-source

platform, the risk of malware infection is even more significant

since vulnerabilities are readily exposed to cybercriminals for

exploitation. Furthermore, as more Android applications get

released in the application markets, the prevalence of application-

layer attacks on Android smartphones will also increase. This

paper analyses the application-layer vulnerabilities associated

with the Android ecosystem and derives lessons learned for the

Android platform developers, the Android application developers

and the Android users.

We hope that our recommendations will be able to inspire more

focus on the vulnerabilities that exist in the Android ecosystem

and pave way for their elimination.

7. ACKNOWLEDGMENTS We would like to express our gratitude to Prof. Hugh Anderson

for his valuable assistance during the course of this project.

8. REFERENCES [1] Android Mobile Security Threats. Retrieved on July 20, 2016,

from Kaspersky Lab: https://usa.kaspersky.com/internet-security-

center/threats/mobile#.V4jAa8skq3A.

[2] Android Security White Paper 2015. Retrieved on July 18,

2016, from Google User Content:

https://static.googleusercontent.com/media/1.9.24.55/en/US/work/

android/files/android-for-work-security-white-paper.pdf.

[3] App Manifest, Android Developers. Retrieved on July 19,

2016, from Android Developers:

https://developer.android.com/guide/topics/manifest/manifest-

intro.html.

[4] Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.

R. and Shastry, B. 2012. Towards Taming Privilege-Escalation

Attacks on Android. NDSS, 17, 19-37.

[5] Bubinas, C. 2013. How does Apple vet software security in

the App Store. Retrieved on July 20, 2016, from RogueWave

Software: http://blog.klocwork.com/code-review/how-does-apple-

vet-software-security-in-the-app-store/.

[6] Chin, E., Felt, A.P., Greenwood, K., Wagner, D. and

Berkeley, U.C. Analyzing Inter-Application Communication in

Android. Retrieved on July 20, 2016, from University of North

Carolina, Berkeley:

http://webpages.uncc.edu/wwang22/Teaching/2011Fall-

6010/Android-2.pdf.

[7] Cozzette, A., Lingel, K., Matsumoto, S., Ortlieb, O.,

Alexander, J., Betser, J., Florer, L., Kuenning, G., Nilles, J. and

Reiher, P. 2013. Improving the Security of Android Inter-

Component Communication. In 2013 IFIP/IEEE International

Symposium on Integrated Network Management, IEEE, 808-811.

[8] Cuadrado, F. and Dueñas, J.C. 2012. Mobile application

stores: success factors, existing approaches, and future

developments. IEEE Communications Magazine, 50(11), 160-

167. DOI =

http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/MCOM.2012.635

3696.

[9] Davi, L., Dmitrienko, A., Sadeghi, A.R. and Winandy, M.

Privilege Escalation Attacks on Android. 2010. In International

Conference on Information Security, Springer Berlin Heidelberg,

346-360. DOI = http://link.springer.com/chapter/10.1007/978-3-

642-18178-8_30.

[10] Delac, G., Silic, M. and Krolo, J. 2011. Emerging security

threats for mobile platforms. In MIPRO, 2011 Proceedings of the

34th International Convention, IEEE, 1468-1473.

[11] Ehringer, D. 2010. The Dalvik Virtual Machine Architecture.

Techn. report, 4, 8.

[12] Faruki, P., Bharmal, A., Laxmi, V., Ganmoor, V., Gaur,

M.S., Conti, M. and Rajarajan, M. Android Security: A Survey of

Issues, Malware Penetration, and Defenses. IEEE

COMMUNICATION SURVEYS & TUTORIALS, 17(2), 998-1022.

DOI =

http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/COMST.2014.238

6139.

[13] Frumusanu, A. 2014. A Closer Look at Android Runtime

(ART) in Android L. Retrieved July 17, 2016, from AnandTech

online magazine: http://www.anandtech.com/show/8231/a-closer-

look-at-android-runtime-art-in-android-l/.

[14] Hill, S. 2015. Do You Need Anti-Virus On Android? We

Asked An Expert. Retrieved on July 21, 2016, from Digital

Trends: http://www.digitaltrends.com/mobile/do-you-need-

antivirus-on-android/.

[15] Intents and Intent Filer. Retrieved on July 17, 2016, from

Android Developers:

https://developer.android.com/guide/components/intents-

filters.html.

[16] IOS Security. 2016. Retrieved on July 15, 2016, from IOS

Security White Paper:

https://www.apple.com/business/docs/iOS_Security_Guide.pdf.

[17] Isohara, T., Takemori, K. and Kubota, A. 2011. Kernel-based

behaviour analysis for android malware detection. In

Computational Intelligence and Security (CIS), 2011 Seventh

International Conference on, IEEE, 1011-1015. DOI =

http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/CIS.2011.226.

[18] Kelly, G. 2014. Report: 97% Of Mobile Malware Is On

Android. This Is The Easy Way You Stay Safe. Retrieved on July

21, 2016, from Forbes:

http://www.forbes.com/sites/gordonkelly/2014/03/24/report-97-

of-mobile-malware-is-on-android-this-is-the-easy-way-you-stay-

safe/#204194ae7d53.

[19] Liebergeld, S. and Lange, M. 2013. Android security, pitfalls

and lessons learned. In Information Sciences and Systems 2013,

Springer International Publishing, 409-417.

[20] Llamas, R., Reith, R. and Nagamine, K. 2016. Smartphone

OS Market Share, 2015 Q2. Retrieved on July 17, 2016, from

IDC: http://www.idc.com/prodserv/smartphone-os-market-

share.jsp.

[21] Lockheimer, H. 2012. Android and Security. Retrieved on

July 20, 2016, from Google Mobile Blog:

http://googlemobile.blogspot.sg/2012/02/android-and-

security.html.

[22] Cyber Security Agency and Infocomm Development

Authority of Singapore. Malware Targeting Mobile Banking.

2015. Retrieved on July 21, 2016, from Singapore Computer

Emergency Response Team:

https://www.csa.gov.sg/singcert/news/advisories-alerts/malware-

targeting-mobile-banking.

[23] Marforio, C., Francillon, A. and Capkun, S. Application

Collusion Attack on the Permission-Based Security Model and its

Implications for Modern Smartphone Systems. Department of

Computer Science, ETH Zurich, Zurich, 2011.

[24] Mansfield, D.S. 2012. Android architecture: attacking the

weak points. Network Security, 2012(10), 5-12.

32

[25] Millman, R. 2015. Updated: 97% of malicious mobile

malware targets Android. Retrieved on July 19, 2016, from SC

magazine: http://www.scmagazineuk.com/updated-97-of-

malicious-mobile-malware-targets-android/article/422783/.

[26] Oberheide, J. and Miller, C. 2012. Dissecting the Android

Bouncer. Retrieved on July 19, 2016, from Summercon:

https://jon.oberheide.org/files/summercon12-bouncer.pdf.

[27] Perez, S. 2015. App Submissions On Google Play Now

Reviewed By Staff, Will Include Age-Based Ratings. Retrieved

on July 20, 2016, from Tech Crunch:

https://techcrunch.com/2015/03/17/app-submissions-on-google-

play-now-reviewed-by-staff-will-include-age-based-

ratings/?ncid=rss.

[28] Rashidi, B. and Fung, C. A Survey of Android Security

Threats and Defenses. Journal of Wireless Mobile Networks,

Ubiquitous Computing, and Dependable Applications, 6(3), 3-35.

[29] Saltzer, J.H. and Schroeder, M.D. 1975. The Protection of

Information in Computer Systems. Proceedings of the IEEE,

63(9), 1278-1308. DOI =

http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/PROC.1975.9939.

[30] Security Tips. Retrieved on July 17, 2016, from Android

Developers:

https://developer.android.com/training/articles/security-tips.html.

[31] Stallings and Brown. 2008. Wireless and Mobile Security.

Retrieved on July 19, 2016, from Georgia Tech University:

https://s3.amazonaws.com/content.udacity-data.com/courses/gt-

cs6035/transciptsWScreenShots/P2_L11++-

+Wireless+%26+Mobile+Security.pdf.

[32] Svajcer, V. 2012. When Malware Goes Mobile: Causes,

Outcomes and Cures. Retrieved on July 20, 2016, from Sophos

Whitepaper 2012:

https://www.sophos.com/enus/medialibrary/Gated%20Assets/whit

e%20papers/Sophos_Malware_Goes_Mobile.pdf.

[33] Vidas, T., Votipka, D. and Christin, N. 2011. All Your Droid

Are Belong To Us: A Survey of Current Android Attacks. In

WOOT, 81-90.

[34] Webb, A. 2016. Apple Shortens App Review Times in Push

to Boost Service Sales. Retrieved on July 21, 2016, from

Bloomberg Technology:

http://www.bloomberg.com/news/articles/2016-05-12/apple-

shortens-app-review-times-in-push-to-boost-service-sales.

[35] Zhou, W., Zhou, Y., Jiang, Z. and Ning, P. 2012. Detecting

Repackaged Smartphone Applications in Third-Party Android

Marketplaces. In Proceedings of the second ACM conference on

Data and Application Security and Privacy, ACM, 317-326.

DOI =

http://dl.acm.org.libproxy1.nus.edu.sg/citation.cfm?doid=213360

1.2133640.

[36] Zwahlen, A. and Edell, H. 2011. McAfee Q2 2011 Threats

Report Shows Significant Growth for Malware on Mobile

Platforms. Retrieved on July 18, 2016, from Intel Security:

http://www.mcafee.com/sg/about/news/2011/q3/20110823-

01.aspx.

33

34

Overview of Security Issues of Public Utilities

Chan Lup Seng School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

Ng Yong Khuang School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected]

Low Pei Hua

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected]

Tan Jia Liang School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected] This paper provides an assessment of ways in which the cybersecurity of public utilities have been compromised in recent years. We will identify several prevailing perspectives within the industry that contribute to poor security, and draw examples from prominent case studies to illustrate the different forms of attacks that have already occurred, as well as propose possible countermeasures. The goal is to accentuate the weaknesses in the current security system and give impetus for adopting a more serious stance on protecting public utility services.

Categories and Subject Descriptors C.3 [SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMS]: Process control systems; J.7 [COMPUTERS IN OTHER SYSTEMS]: Industrial Control General Terms Reliability, Security, Human Factors Keywords Supervisory Control and Data Acquisition (SCADA), Policy, Incentives, Mechanism, Assurance 1. INTRODUCTION Public utilities are organizations that provide services such as power, water, gas or sewage. As cities are dependent on public utilities to function, access to these systems may grant an attacker control to the lives of millions of people. Thus, it is in a nation’s best interest to protect their public utilities, as they are obvious targets for any aggressor who wishes to interfere with the nation’s regular functionalities, or to even wage war.

There are various incentives for hackers to infiltrate, collect intelligence on, disrupt and damage the process control systems

that public utilities use.

Attackers acting on political incentives could cause permanent damage to systems and infrastructure, and sustained, successive attacks could even trigger large-scale public unrest, with citizens voicing their dissatisfaction with the lack of provision of daily necessities like water and electricity. It becomes even more alarming when one realises that growing reliance on nuclear energy might allow a skilled attacker with enough knowledge about nuclear facilities to put millions of lives at risk by causing a reactor meltdown [11], without having to develop nuclear weapons of his own.

Staging cyber-attacks to steal information regarding the operations and also intellectual property of utility companies can be very rewarding in monetary terms. Confidential information is capable of deciding multibillion dollar deals in the highly competitive industry [22]. Since 2009, targeted attacks collectively known as the Night Dragon attack, have been made on global oil, energy and petrochemicals companies, posing a threat to the profits of these businesses.

Another way of obtaining money apart from data theft is to take control of public utilities, in other words ‘hold it hostage’, and use it as leverage to demand for ransom. In April 2016, Michigan’s third largest water and electric utility, Lansing Board of Water and Light (Lansing BWL) was hit by a ransomware when attackers encrypted files in the corporate server [15] and demanded payment before decrypting them.

Looking at the problem in Singapore’s context, proper management of the security of public utilities is even more pertinent to the country aiming to be a smart nation [17] and global innovation hub. Harnessing of technology begins with the proper protection of public utilities like power plants which these technology rely on.

2. BACKGROUND INFORMATION This section introduces some of the current underlying technology in public utilities, as well as identifies associated mind-sets within the industry that affect security.

35

2.1 Supervisory Control and Data Acquisition

Figure 1: Diagram depicting an ICS environment [40]

Industrial Control Systems (ICS) form the backbone of operations across many modern industries. While it encompasses a few types such as the Supervisory Control and Data Acquisition (SCADA) systems and Distributed Control Systems (DCS), this report mainly refers to case studies in which cyber-attacks have affected plants operating on SCADA, as it is quite widely used within the utilities sector and known to be lacking in security.

Supervisory Control and Data Acquisition, as its name suggests, refers to a kind of software application in which real time data is collected from a system for the purposes of tracking and controlling it through a centralized computer. The use of SCADA first originated in the power industry; it provides the ease of monitoring equipment over vast distances without having to be present on-site. It was first introduced in the 1960s when information security measures and protocols were not of main concern [14]. As the system was not built with security in mind [6], users have to retrofit security features into the system which may leave vulnerable spots for others to exploit. 2.2 Existing Industrial Approaches Affecting the Security Outlook 2.2.1 “Security by Obscurity” Security by obscurity is the policy where designs and technical details are kept secret as a form of defence against attackers. For a long time, ICS vendors harboured the belief that they were well defended against attacks as long as their designs and protocols remained unknown to outsiders. The reason was that without any details on the implementation, it should pose significant difficulties for adversaries to uncover the flaws in the design, as well as to manipulate the system to their advantage [29].

However, using obscurity as a means of security is generally ill-advised, especially if it is used as the main defence mechanism. It contradicts one of Saltzer and Schroeder’s design principles: “The security of a system should not be dependent on a secret design”. In other words, a system ought to be considered secure because of a good design, not because the design was a secret. Secrets don't remain secret for long [18], as enough information can be discovered by antagonists with skill and persistence. With the increased use of industry standard protocols, software and hardware, it is even more difficult to implement security by obscurity. There are open-source resources available on the

Internet--some ICS vendors even post the types of infrastructure such as Remote Terminal Unit (RTU) and versions used online.

This policy has to be used in combination with other security policies, to ensure that even if technical details are exposed, the vulnerabilities in the system are shielded from exploitation.

2.2.2 Prioritising Performance over Security Another policy that appears to govern organisations running the SCADA system is to maximize performance and reliability. As SCADA systems allow for mechanization of supervision and control over far-off equipment, as well as digitizing data records instead of manual logging, they are said to lower operational costs and increase efficiency by allowing complex processes to be managed without requiring large manpower. They were designed with efficiency in mind, not security [10].

Measures to protect confidentiality, and thus ensure security, may be viewed unfavourably -- for example, anti-virus scans may result in slower performance, and maintenance checks could result in significant downtime that is undesirable for public utility providers [21].

If we analyse this from the point of view of security goals such as Confidentiality, Integrity, Availability (CIA), it seems that SCADA users may be sacrificing Confidentiality and Integrity for the sake of Availability.

2.2.3 Reactive Rather than Proactive Approach SCADA protocols have been referred to a number of times as legacy systems, which in computing terms can describe some outdated software or hardware that ought to be replaced or upgraded but remains in use. There are a variety of possible reasons to account for this: its ubiquity could make it rather inconvenient and costly to completely replace, and ensuring that newer, more robust security measures are compatible with the old system is an issue that requires delicate handling. A 2015 paper published by Tenable Network Security, Inc. [37] hints at a similar sentiment – network vulnerability scanners which can be used to detect hosts connected to a network and highlight vulnerabilities, unfortunately incorporate techniques that may adversely affect SCADA networks.

If these reasons hold true, it exemplifies a situation in which the addition of security measures is seen as a hindrance towards instead of an indispensable aspect of constructing good systems. In these cases, approaches which have gained credibility over the years from fulfilling their intended purpose would normally be left alone, until events arise that draw greater attention to the faults within the system. Since the beginning of the 21st century, some notable viruses capable of damaging SCADA systems have indeed been brought to the public eye, including Flame, Stuxnet, and the Slammer worm [28]. Though the reported cases were accompanied by varying degrees of damage, it may have been sufficient to trigger concern from relevant security analysts or managers. Symantec’s annual Internet Security Threat Report documented a decreasing trend between 2011 and 2014 in disclosed ICS vulnerabilities [35]. This shows efforts have likely been made to reduce public weaknesses that attackers can take advantage of. Nevertheless, the 2015 statistic was a steep increase from the previous year’s, indicating that SCADA systems remain relatively insecure.

2.2.4 Insufficient Knowledge of Underlying Systems and Networks Operators lack knowledge of the systems and their dependencies, and hence they might not know what they should protect and how to go about protecting them. In 2008, a mere software update and subsequent reboot to one crucial computer on the Hatch nuclear power plant’s corporate network caused an automatic shutdown, as diagnostic data was reset on the

36

network. The data on water reservoir levels were affected and reset to low levels, and the system misinterpreted the suddenly low water level as an emergency [20]. Even though this might have been a trivial mistake and proved that the safety systems were functioning normally, an attacker could have repeated something equally simple and ‘trivial’, and yet succeeded in disrupting activities at the plant. The lack of understanding by staff of the systems used and how each of them affect one another not only poses a threat to day-to-day running of plants, it also prevents companies from analysing flaws and improving the setup of the systems and networks to make them more impenetrable to cyber-attacks.

3. ATTACK MECHANISM AND SUGGESTED PREVENTED MEASURES Since most SCADA systems are not built with security in mind [6], there are rarely any specific mechanisms developed to protect them from cyber-attacks. The ICS Cyber kill chain lists out the steps in which a perpetrator can carry out cyber-attacks. In this section we aim to explain and analyse different attack forms from different sections of the kill chain to give a holistic view of the attack on industrial control systems. We will also give possible suggestions to prevent such incidents from happening again, and assess the added assurances that these suggestions could provide.

Figure 2: Flow chart based on Lockheed Martin’s cyber kill

chain [23]

3.1 Reconnaissance 3.1.1 Gathering Intelligence 3.1.1.1 How it Works Data exfiltration is the unauthorized transmission of information out of a system. The transmission could be done by someone with physical access to the system or it could be automated through malicious programming remotely. The data being stolen could be credentials, trade secrets or network information.

In a well-known attack on several Ukraine power companies, the adversaries exfiltrated important information of the target network during the planning stage [9]. They discovered crucial hosts and devices that enabled them to hijack the SCADA Distribution Management Systems to open breakers, causing power outages. They subsequently attacked the computers, servers and even embedded devices that provided communications in their distribution substations.

3.1.1.2 Solution: Network Security Monitoring The attackers were allegedly able to spend months gathering intelligence due to lack of proper network monitoring. Companies should be watching out for new communications

leaving the network and previously unseen encrypted connections suddenly appearing. Minimizing where information exists and controlling access is vital to any ICS-dependent company. Network Security Monitoring is a good strategy for analysing the network and detecting indications of intrusion or malicious activities. It incorporates an Intrusion Detection System (IDS) but does more than intrusion detection and gathers all kinds of data types [5].

However, since data transmissions go in and out of networks all the time, data exfiltration can be hard to distinguish from normal network traffic. In order to differentiate the two, it is essential to cultivate a deeper understanding and recognize the types of information that belong inside the business network and ICS.

3.2 Delivery 3.2.1 Social Engineering - Phishing 3.2.1.1 How it Works Phishing is an example of social engineering, in which the sender masquerades as an organisation or individual known by the recipient. The attacker could simply try to ask for passwords or personal information and victims might give it away, mistakenly accepting that the attacker is who he says he is. Victims could also be tricked into downloading certain attachments that contain malware. [36] It is one of the simplest ways to infiltrate a network, with low cost and a relatively high success rate. If the attacker is good and does adequate research, a well-crafted email could look completely legitimate.

3.2.1.2 Solutions: Educating Employees, Sandboxing and Whitelisting The defence against social engineering is a tough one. Ultimately all organizations are made up of its employees, and as humans we are susceptible to attacks on our emotions. End-user awareness training and phishing simulation for the employees could be carried out. Workers should also be trained to understand the dependencies within the system and the effects their actions could have on other parts of the system. However, extended knowledge may increase the risk of an insider attack--the solution to which will be covered in a later section. Emails and workstations that connect to the Internet are the initial avenues of attack; the networks they exist on are untrusted territories. The connections to these territories have to be segmented, monitored and controlled. Public utility companies should operate under the worst-case scenario - assume that the network can be accessed by attackers - and ensure there are strong defences set up to control communications from any untrusted network. Sandboxing is a good tactic to use when accessing files and emails from the Internet. Sandboxing isolates the untrusted system or documents from network access and restricts its resources, protecting users by containing the damage caused from unintentional opening of malicious files. Whitelisting applications, a strategy whereby only a pre-approved list of applications are allowed to execute [31], is another effective way to fight phishing. This can be done on applications or email addresses themselves. However, it might not be sufficient [7]. Attackers could still use remote rogue clients and approved OS-level remote admin features to conduct malicious acts. In the case of whitelisting email addresses, this approach is flawed as well since attackers can easily spoof their email address by modifying the mail headers. Rather than using domain names in the whitelist, it is more effective to keep

37

specific addresses [4]. An even better tactic is to check the IP address of the mail sender rather than the email address. If the IP address is coming from somewhere suspicious, the mail should not be trusted.

38

3.3 Exploitation 3.3.1 Exploiting Flaws in Air Gaps - Usage of Personal Devices

Figure 3: Sources from which malicious codes penetrate air

gapped networks [19]

3.3.1.1 How it Works Air gapping a network involves isolating a network from other unsecure networks, usually the Internet, and is frequently used by public utilities to restrict network access to internal users only [19]. It’s a defensive mechanism that implements the policy of isolation. However, this is not an infallible way of protecting one’s network from intruders. Isolated systems are still vulnerable to hacks through external pathways which breach the physical gap [13]. In some cases, reliance on an air gap might give users in these networks a false sense of security, increasing potential for human error and giving hackers opportunities to access these networks, which was probably what happened in the Natanz nuclear facility, Iran in 2010.

The attack on the facility resulted in it having to decommission and replace about 1000 centrifuges over an unusually short period of time. It was later found that this was caused by the computer worm Stuxnet. Even though the facility was air gapped, Stuxnet managed to find its way into the system, as it did not require the Internet to spread. It was mainly circulated through USB flash drives, where it made use of a harmful autorun.inf file to copy itself onto a host computer and other connected flash drives on the host [25]. It most likely found its way into the Natanz facility through the use of infected personal computers and flash drives by plant personnel [3]. Once inside the network, Stuxnet was able to do everything it was programmed to do. The Natanz nuclear facility is not the only one that has been reported to be infected by Stuxnet; several have, showing that air gaps are generally not foolproof mechanisms to protect public utilities.

3.3.1.2 Solution: Restricting Usage of Personal Devices To stop air gaps from being exploited, companies running public utilities should place importance on educating and training employees on cyber security, followed by restricting the usage of personal devices in facilities. Enforcing rules and imposing restrictions to ensure air gap policies are followed through, will help to ensure the closed network is impenetrable from others, with a rather high level of assurance. Still, this does not prevent an insider from having access to the isolated network, and executing an attack on it. A single lapse in

judgement of any member of staff could also jeopardise the cyber security of the facility. However, another critical issue with this solution is that the complete isolation promised by air gaps is impractical [24]. SCADA systems have become increasingly connected to business networks in order for the large amounts of data and information generated to be transmitted more efficiently and cost-effectively. Although unidirectional diodes could be used to transfer data, a system which requires bidirectional communication between the two systems would still be vulnerable to attacks through this connection. There has also been a shift towards using IP networks in recent years [1]. The danger is here is that transmitting information over an IP network entails that the system now inherits all the risks associated with the Internet Protocol. According to William T. Shaw, a cybersecurity consultant, the internet connectivity allows users (in this scenario, prospective hackers) to obtain access to any other system linked to the same network [33]. In light of these issues, it is evident that more must be done to restrict hackers from manipulating systems instead of simply relying on air gaps.

3.3.2 Zero-day Vulnerabilities/Attacks 3.3.2.1 How it Works The Stuxnet worm also made use of a total of four zero-day exploits to infect computers and connected devices, while camouflaging its activity. One of the said exploits was a vulnerability in the Windows .lnk files. When an infected removable drive was accessed with an application with icon display capabilities, the vulnerability would allow the first of the malicious .dll files on the drive to be loaded into memory. The main purpose of this .dll was to hook other .dll files and alter the code in their Application Programming Interfaces (APIs), making it such that it would supply a negative result when asked if certain malicious files were present. This effectively hid the other malicious files on the disk, which could then be loaded into memory, and provide access to other executable code [26]. This granted Stuxnet access to perform its desired functions on the infected computer, undetected.

3.3.2.2 Solution: Penetration Testing A possible solution would be to perform penetration testing on the computers and networks used in public facilities more often, so that loopholes can be discovered in time, and subsequent software updates launched across facilities to address those vulnerabilities. However, such solutions are not foolproof and do not guarantee that hackers will not discover new zero-day vulnerabilities. Public utility facilities also have a tendency to refrain from updating their software [12], as it might cause more problems for them should the new software versions be incompatible with the systems they use [38]. Furthermore, patching will take time, a plausible deterrent if it interrupts the facility’s normal functioning. This makes facilities vulnerable to exploits that have already been uncovered by manufacturers, yet remain unresolved because utilities are reluctant to update their systems.

3.4 Command and Control 3.4.1 VPN Access 3.4.1.1 How it Works A virtual private network (VPN) allows a user to remotely connect to a server or private network through the Internet. It ensures the channel being used for the transmission is secured, using encryption to protect data confidentiality and allow only authorized personnel to access the private network.

39

As public utilities infrastructure tend to involve monitoring and controlling various devices and systems remotely, the existence of VPN can actually be advantageous for attackers. If they are able to hack into it, they obtain remote access through a safe channel. In the Ukraine case study briefly mentioned before, the remote operation of the breakers was partially enabled through a VPN connection [16]. Security measures need to be in place to prevent attackers from using stolen credentials and gaining access.

3.4.1.2 Solutions: 2FA, Monitoring Usage, and Constructing a Demilitarized Zone A two-factor authentication system (2FA) is one of the ways to prevent hijacking. It is a mechanism whereby users are required to provide two separate verifications. The first factor is usually a password or PIN, while the other could be a physical token or a one-time SMS. It abides by the design principle of separation of privilege. Even if a password or PIN is stolen, the necessitation of a physical token provides an added layer of security [32].

To protect against illegal VPN access in a network, every communication path should be scrutinised, the risks and incentives assessed, and non-crucial paths removed. A path should only be kept if its importance outweighs the risk of potentially serving as an attack route.

Network Security Monitoring can be coordinated to find abnormalities regarding the number of connections, time during which the connection was made, as well as its duration. A possible strategy is imposing time of use access on employees. These paths would be disconnected automatically after a predefined amount of time has lapsed since access was granted. Choke points could be inserted into the network by making sure that remote VPNs enter the network with a dedicated remote access demilitarized zone (DMZ). All external sources that are connected to the Internet should be located in the DMZ, an unsecured segment of a network that is separated from the rest of the trusted network by either single or dual firewalls [30].

3.5 Actions on Objectives 3.5.1 Destroying the Integrity of Information 3.5.1.1 How it Works It is also possible for an attacker to falsify data provided to operators through the Human Machine Interface (HMI) within a plant. Stuxnet was able to provide false data to the HMI, reflecting that all operations were normal, while it instructed Programmable Logic Controllers (PLCs) to spin the centrifuges to failure [3].

3.5.1.2 Solution: End-to-end Encryption Companies managing public utilities could place higher emphasis on protecting the data being transmitted within the facility, especially between sensors and the HMI, as a precaution in the event that an outsider is able to access their networks. This could be done using end-to-end encryption. Even so, using encryption techniques would inevitably slow down processes by a lot, and is generally not very feasible as these systems rely on real-time data to make decisions. Furthermore, this does not prevent a hacker with access to the network from performing a replay or Denial of Service (DoS) attack as they will still be able to relay information to the components in the system. Therefore it is paramount to protect networks from being accessed by others.

3.5.2 Causing Permanent Damage to Data 3.5.2.1 How it Works Once hackers have secured access to a system, one of the most destructive things they can do is to start deleting files.

Information crucial to normal operation or logs that could contain evidence that trace back to the hackers are prime targets for removal. In the attack mentioned on the Ukrainian power grid, the attackers used KillDisk to remove master boot records of target organizations [34].

3.5.2.2 Solutions: Backup, and Lookout for Unlicensed Updates A strategy against this, other than stopping intrusion in the first place, is to simply back up system files. A backup of important files could be stored in an external hard drive, or a server at another secured location. It is important that the servers are separated to avoid losing all the data if one server is compromised, whether due to an attack or an accident. The least privilege principle should be applied here, so that even if hackers gain access to a system, they do not have the privilege to do deletion using an account with low privileges. Unfortunately, if they get access to an admin account for example, they would still have free reign. In some cases, the conventional backup may fail to work. The perpetrators of the Ukrainian attack developed malicious firmware updates to replace actual firmware for serial-to-ethernet devices at over a dozen substations that they discovered during their reconnaissance stage. These devices were used to process commands issued from the SCADA network to the substation control systems. The malicious firmware eventually rendered the devices unusable and unrecoverable. When the attackers later opened the breakers to trigger the power outage, remote commands could not be given to the devices to reclose the breakers and bring the substations back online. To prevent unsanctioned firmware updates, administrators must be alert to abnormal behaviour on the field device. Even without knowledge of normal activity traffic, it is fairly easy to spot a firmware update given the network data, as there will be spikes in network traffic caused by modifications of firmware over the network (as shown in Figure 4 below). The administrators should be on the lookout for these spikes--a sign of firmware being uploaded secretly outside a scheduled downtime.

Figure 4: Sample Network I/O Data from a Malicious Firmware Update to an Industrial Ethernet Switch [9]

4. INSIDER ATTACKS 4.1 How it Works Insider attacks are conducted by trusted people, usually employees within an organisation who have authorised access, privileges or knowledge of the system being used. They may well have the authority to bypass security measures intended to prevent external attacks. This is pertinent to many utilities using legacy systems like SCADA with retrofitted security measures, that may focus more on external security rather than internal. The “security by obscurity” argument carries little weight here as well, since attackers equipped with first-hand knowledge of internal operations could be familiar with the flaws in the system and how to break it. In 2000, a computerised waste management system in Maroochydore, Australia was hacked by a man named Vitek Boden, who had previously worked for the company responsible for installing the city council’s SCADA radio-

40

controlled sewage equipment. It was considered an act of vengeance for being denied employment at the city council after the attacker lost his job. His selfish act caused great environmental damage, as 800,000 litres of raw sewage was spilled into various locations including local parks and rivers, affecting marine life and residents in the area [2]. Boden was able to cause such damage as he possessed the technical knowledge to hack into the SCADA system. He drove around the sewage control centre with a laptop and a handmade cable which sent signals to the control system, ordering the sewage to be released [8].

4.2 Solutions: Principle of Least Privilege, and Principle of Separate Privilege One way to guard against insider attacks is to observe the design principle of least privilege, by ensuring employees are only given knowledge of processes that are required for their jobs. However, implementation of such measures must be done in a sensitive manner, otherwise it may breed mistrust between employees and their company, making it hard for the staff to pledge allegiance to a company that seems to doubt their loyalty [39]. Separation of privilege may be useful here as well. Just as double-entry bookkeeping in banks serves to reduce instances of insider attacks (by requiring collusion between two or more personnel), similar methods can be adopted for public utilities.

5. CONCLUSION The various attacks mentioned in this report may not be specific to utilities--that is, business organizations that don’t keep themselves well secured could be vulnerable to similar threats. An important difference is that for public utilities, the consequences of a cyber-attack are potentially much higher, as physical impacts are tangible and directly affect many people.

Higher importance should be accorded to the security of public utilities. Countries that rely on systems with outdated, aging infrastructures are particularly at risk. As technology advances, hackers become more adept in their role. A variety of online resources have been developed that could serve as valuable aids to hackers. A project initiated using SHODAN, a unique search engine that allows one to search for devices that are connected to the Internet, unveiled more than a million SCADA and ICS systems connected to the Internet. Paired with other tools such as Metasploit (specially designed to locate security deficiencies in a machine) and TOR (a free-to-use software that permits users to surf the Internet while keeping their location concealed), it could in fact allow not just hackers with specialised software to attack public utilities, but just about anyone who has Internet access and the resourcefulness to apply themselves to the task [27]. It would be prudent for all management of public utilities to be aware of and take precautions against new avenues of attacks, in order to be assured that their security measures remain effective in the long term. We ought not to perpetuate ignorance to threats, nor sacrifice safety for the sake of convenience or avoiding costs, simply because we have not been attacked yet. 6. ACKNOWLEDGMENTS We would like to thank Prof. Hugh Anderson for all the advice given in consultations and for the opportunity to work on this project. 7. REFERENCES

[1] ABB. n.d. SCADA over IP-based LAN-WAN connections Application. Retrieved July 23, 2016 from

https://library.e.abb.com/public/09e2909e92d2ce8ac1257863004e7da0/SCADA%20application%20flyer_small.pdf

[2] Abrams, M. and Weiss, J. 2008 Malicious Control System Cyber Security Attack Case Study– Maroochy Water Services, Australia National Institute of Standards and Technology Computer Security Resource Center, Retrieved July 23, 2016 from http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-Study_report.pdf

[3] Albright, D., Brannan, P. and Walrond, C. 2010. Did Stuxnet Take Out 1,000 Centrifuges at the Natanz Enrichment Plant? Institute for Science and International Security. Retrieved July 23, 2016 from http://isis-online.org/uploads/isis-reports/documents/stuxnet_FEP_22Dec2010.pdf

[4] Bebeau, B. 2014. Spammers Are Taking Advantage of Your Whitelists by Spoofing Legitimate Brands. (February 2014). Retrieved July 23, 2016 from https://www.trustwave.com/resources/spiderlabs-blog/spammers-are-taking-advantage-of-your-whitelists-by-spoofing-legitimate-brands/

[5] Bedell, C and Bejtlich, R. 2003. Network security monitoring -- Going beyond intrusion detection. (September 2003). Retrieved July 23, 2016 from http://searchsecurity.techtarget.com/tip/network-security-monitoring-going-beyond-intrusion-detection

[6] Chileshe, G. and van Heerden, R. 2012. Proceedings of the 7th International Conference on Information Warfare and Security: Centre for Information Assurance and Cybersecurity, University of Washington, Seattle, USA, 22-23 March 2012, Academic Pub. 95

[7] Cobb, W. n.d. Will using whitelists and blacklists effectively stop spam? Retrieved July 23, 2016 from http://searchsecurity.techtarget.com/answer/will-using-whitelists-and-blacklists-effectively-stop-spam

[8] Crawford, M. 2006. Utility hack led to security overhaul. (February 2006). Retrieved July 23, 2016 from http://www.computerworld.com/article/2561484/security0/utility-hack-led-to-security-overhaul.html

[9] Electricity Information Sharing and Analysis Center. 2016. Analysis of the Cyber Attack on the Ukrainian Power Grid. Retrieved July 23, 2016 from https://ics.sans.org/media/E-ISAC_SANS_Ukraine_DUC_5.pdf

[10] Gligor, A. and Turc, T. 2012. Development of a Service Oriented SCADA System. Procedia Economics and Finance 3 (2012), 256–261. DOI: http://dx.doi.org/10.1016/s2212-5671(12)00149-9

[11] Greenpeace International. No more Chernobyls. Retrieved July 23, 2016 from http://www.greenpeace.org/international/en/campaigns/nuclear/nomorechernobyls/

[12] Higgins, K. J. 2013. The SCADA Patch Problem. (January 2013). Retrieved July 23, 2016 from http://www.darkreading.com/vulnerabilities---threats/the-scada-patch-problem/d/d-id/1138979

[13] Hussain, F. 2015. 8 Technologies That Can Hack Into Your Offline Computer and Phone. (July 2015). Retrieved July 23, 2016 from https://www.hackread.com/hacking-offline-computer-and-phone/

[14] Hyungjun, K. 2012. Security and Vulnerability of SCADA Systems over IP-Based Wireless Sensor Networks. International Journal of Distributed Sensor Networks 2012 (2012), 1–10. DOI: http://dx.doi.org/10.1155/2012/268478

[15] Ilitch, A. 2016. BWL network infected by “ransomware” phishing virus. (April 2016). Retrieved July 23, 2016 from http://wlns.com/2016/04/25/bwl-network-infected-by-ransomware-phishing-virus/

[16] Industrial Control Systems Cyber Emergency Response Team. 2016. Cyber-Attack Against Ukrainian Critical

41

Infrastructure. Retrieved July 23, 2016 from https://ics-cert.us-cert.gov/alerts/IR-ALERT-H-16-056-01

[17] Infocomm Development Authority of Singapore. Smart Nation Vision - Tech Scene & News. Retrieved July 23, 2016 from https://www.ida.gov.sg/tech-scene-news/smart-nation-vision

[18] Johansson, J. M. and Grimes, R. 2008. The Great Debate: Security by Obscurity. (June 2008). Retrieved July 23, 2016 from https://technet.microsoft.com/en-us/magazine/2008.06.obscurity.aspx

[19] Kaspersky Lab ZAO. 2014. Five Myths of Industrial Control Systems Security. Retrieved July 23, 2016 from http://media.kaspersky.com/pdf/DataSheet_KESB_5Myths-ICSS_Eng_WEB.pdf

[20] Kesler, B. 2015. The Vulnerability of Nuclear Facilities to Cyber Attack. Strategic Insights, Spring 2011 Volume 10 Issue 1. Retrieved July 23, 2016 from http://large.stanford.edu/courses/2015/ph241/holloway1/docs/SI-v10-I1_Kesler.pdf

[21] Kilman, D and Stamp, J. 2005. Framework for SCADA Security Policy. (2005). Retrieved July 23, 2016 from http://cms.doe.gov/sites/prod/files/framework for scada security policy.pdf

[22] Kurtz, G. 2011. Global Energy Industry Hit In "Night Dragon" Attacks by George Kurtz - McAfee. (February 2011). Retrieved July 23, 2016 from https://blogs.mcafee.com/business/global-energy-industry-hit-in-night-dragon-attacks/

[23] Lockheed Martin Corporation. 2015. Seven Ways to Apply the Cyber Kill Chain with a Threat Intelligence Platform. Retrieved July 23, 2016 from http://cyber.lockheedmartin.com/hubfs/docs/Technical_Papers/wp-seven-ways-to-apply-the-cyber-kill-chain-with-a-threat-intelligence-platform.pdf?t=1469101456617

[24] MacKenzie, H. 2016. Goodbye Air Gaps, Hello Improved ICS Security. (January 2016). Retrieved July 23, 2016 from http://www.belden.com/blog/industrialsecurity/goodbye-air-gaps-hello-improved-ics-security.cfm

[25] Murchu, L. O. 2010. Stuxnet Before the .lnk File Vulnerability. Retrieved July 23, 2016 from http://www.symantec.com/connect/blogs/stuxnet-lnk-file-vulnerability

[26] Murchu. L. O. 2010. W32.Stuxnet Installation Details. Retrieved July 23, 2016 from http://www.symantec.com/connect/blogs/w32stuxnet-installation-details

[27] Narayanan G. 2014. Cyber Security for SCADA/ICS Networks. Thales Group. Retrieved July 23, 2016 from http://icsd.i2r.a-star.edu.sg/asiaccs15/CPSS15-keynote3-GaneshNarayanan.pdf

[28] Nigam, R. 2015. (Known) SCADA Attacks Over The Years. (February 2015). Retrieved July 23, 2016 from https://blog.fortinet.com/2015/02/12/known-scada-attacks-over-the-years

[29] RAD. 2015. Cyber Security Solutions for Power Utilities. Retrieved July 23, 2016 from http://www.rad.com/21/Cyber-Security-for-Power-Utilities-White-Paper/30757/?utm_source=google&utm_medium=cpc&utm_content=SCADA-Security&utm_campaign=Utilities-SCADA

[30] Rouse, M and Cobb, M. n.d. What is DMZ (demilitarized zone)?. Retrieved July 23, 2016 from http://searchsecurity.techtarget.com/definition/dmz

[31] Rouse, M. n.d. What is application whitelisting? Retrieved July 23, 2016 from http://searchsecurity.techtarget.com/definition/application-whitelisting

[32] Rouse, M. n.d. What is two-factor authentication (2FA)?. Retrieved July 23, 2016 from http://searchsecurity.techtarget.com/definition/two-factor-authentication

[33] Shaw, W. T. 2004. SCADA System Vulnerabilities to Cyber Attack. Retrieved July 23, 2016 from http://www.electricenergyonline.com/show_article.php?mag=&article=181

[34] Symantec Security Response. 2016. Destructive Disakil malware linked to Ukraine power outages also used against media organizations. (January 2016). Retrieved July 23, 2016 from http://www.symantec.com/connect/blogs/destructive-disakil-malware-linked-ukraine-power-outages-also-used-against-media-organizations

[35] Symantec. 2016. ISTR. Internet Security Threat Report Volume 21, April 2016. Retrieved July 23, 2016 from https://www.symantec.com/content/dam/symantec/docs/reports/istr-21-2016-en.pdf

[36] Symantec. Attackers Target Both Large and Small Businesses. Retrieved July 23, 2016 from https://www.symantec.com/content/dam/symantec/docs/infographics/istr-attackers-strike-large-business-en.pdf

[37] Tenable Network Security. 2015. Protecting Critical Infrastructure: SCADA Network Security Monitoring. Retrieved July 23, 2016 from https://www.tenable.com/sites/drupal.dmz.tenablesecurity.com/files/uploads/documents/whitepapers/tenable-scada-solutions_0.pdf

[38] U. S. Department of Homeland Security. 2008. Recommended Practice for Patch Management of Control Systems. Retrieved July 23, 2016 from https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/RP_Patch_Management_S508C.pdf

[39] Vogel, D. 2013. How to successfully implement the principle of least privilege - TechRepublic. (May 2013). Retrieved July 23, 2016 from http://www.techrepublic.com/blog/it-security/how-to-successfully-implement-the-principle-of-least-privilege/

[40] Wilhoit, K. 2013. The SCADA That Didn’t Cry Wolf: Who’s Really Attacking Your ICS Equipment? (Part 2). Retrieved July 23, 2016 from http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-the-scada-that-didnt-cry-wolf.pdf

42

Cross-Site Request Forgery (CSRF) and Other Techniquesfor Attacking Web Applications ∗

Jiarui HanSchool of Computing

National University of Singapore13 Computing DriveSingapore 117417

[email protected]

Xuan SuSchool of Computing

National University of Singapore13 Computing DriveSingapore 117417

[email protected]

ABSTRACTAs the number of web applications grows rapidly in the pastdecade, attacks targeting these applications have also be-come increasingly common, and have caused considerablelosses in many cases. This paper surveys various techniquesutilized by hackers to attack web applications such as Face-book, Twitter and so forth. Techniques examined includeDistributed Denial of Service, Cross-Site Scripting, SQL in-jection, and Cross-Site Request Forgery. Moreover, in orderto concretely illustrate the negative impacts of web attacks,this paper selects the CSRF attack as a case study, andperforms a simple simulation to showcase its major conse-quences and possible protection mechanisms.

Categories and Subject DescriptorsK.6.5 [Management of Computing and InformationSystems]: Security and Protection—web application at-tacks, defense mechanisms

1. INTRODUCTIONOver the past decade or so, we have seen a dramatic increasein the number of web-based applications. Such applicationsare well embraced by businesses and individuals alike, dueto the convenience and low expense of Internet access inmany regions of the world. However, with the advancementof web-based technologies, we have also witnessed a growthin the sophistication and scale of web application attacks.

Notably, in the year of 2013 alone, SQL injection attackshave risen in number by 10%, and remote file inclusion at-tacks by 24% [3]. It was also reported that in the latterhalf of 2015, Distributed Denial of Service (DDoS) attackshave witnessed an increase of 50% in number, lasting an av-erage of close to 15 hours and targeting a diverse array ofindustries [23]. Such risen intensity of web attacks has givenrise to increased operational costs on the part of the com-panies. For example, it was estimated that DDoS attacksalone have incurred an average cost of $3.5 billions annu-ally on the companies [13]. Such financial losses could havebeen diminished should the companies be more vigilant andstringent in their security practices.

Web application attacks are launched with a variety of pur-∗This paper is written in partial fulfillment of the courseCS2107: Introduction to Information and Systems Securityat the School of Computing, National University of Singa-pore.

poses [8]. Politically motivated attackers include extremistgroups and government-sponsored hacker groups, who usu-ally launch attacks on web applications in order to inducefear, spread propaganda or attain other political gains. Fi-nancially motivated attackers launch attacks to steal intel-lectual properties or other economically valuable resources.And socio-culturally motivated attacks are for cultural, philo-sophical, theological, or even humanitarian goals.

It is paramount for application developers to understandthe mechanisms of these attacks as well as possible ways ofdefending against them, so as to minimize potential lossesthat users and the applications themselves may need to bear.This paper attempts to fill the gap in the understanding ofweb attacks among IT practitioners by introducing severalwell-known attacking techniques and their defense mecha-nisms.

2. TECHNIQUES FOR ATTACKING WEBAPPLICATIONS

In the following, four techniques for attacking web appli-cations will be discussed: Distributed Denial of Service,Cross-Site Scripting, SQL injection, and Cross-Site RequestForgery. Each section will firstly give an overview of theattack and then introduce examples of real attack on webapplications. For Distributed Denial of Service and Cross-Site Request Forgery, possible defense mechanisms will alsobe covered as a conclusion.

2.1 Distributed Denial of Service2.1.1 Overview

Distributed Denial of Service (DDoS) is a type of web attackwhere an attacker makes use of a large number of compro-mised computers to flood a targeted computer, in order toprevent legitimate users from accessing it [1][15]. DDoS at-tacks are said to be among the top three most used types ofattacks [14], and are posing severe security threats to webapplications.

The general architecture of computers that together performa DDoS attack is shown in Figure 1 [15]. The architectureconsists of five components. Attacker refers to the singlemachine that initiates the DDoS attack. Zombies are vul-nerable computers from the public network that have beenbrought under control by the attacker to perform the at-tack. They are usually hundreds or thousands in number,and together constitute what we call a botnet. Handlers are

43

Figure 1: Architecture diagram of DDoS attacks

computers chosen from the botnet to pass the instructionsfrom the attacker to the zombies. They also serve to com-municate the information obtained by the zombies about thevictim back to the attacker. Reflectors are other infectedmachines used to amplify the effect of the attack, and arean optional component of the architecture. Finally, victimrefers to the computer under attack. It is to be noted thatin this architecture, if only the attacker and the victim arepresent, the attack is considered a Denial of Service attack.The middle three layers of handlers, zombies, and reflectorsare where the distributed nature of DDoS attacks lies.

There are many schemes for the taxonomy of DDoS attacks,each using a different set of classification criteria [1]. Ingeneral, DDoS attacks could be categorized into network-layer attacks and application-layer attacks [19].

Network-layer attacks usually attempt to overwhelm andexhaust the network resources available to the victim. At-tacks under this category include SYN flood, UDP flood,ICMP flood and so forth. Let us explore SYN flood at-tacks further. Recall that in the establishment of a TCPconnection between two computers, a three-way handshakeprocess is required: 1) The connection initiator sends a SYNpacket to the destination to request for synchronization; 2)The destination computer sends back a SYN-ACK packetto acknowledge that it has received the request; 3) The ini-tiator sends an ACK packet to formally establish the con-nection. In this process, if the destination computer doesnot receive an ACK packet after it sends SYN-ACK, it willkeep waiting for tens of seconds, before it drops the connec-tion. This is where the vulnerability of three-way handshakelies. Attackers exploiting this vulnerability could instruct abotnet to send SYN requests to the victim at roughly thesame time, without ever replying the ACK packet. Theserequests for TCP connections from the zombies will quicklyclog the victim’s network bandwidth, making TCP connec-tions from normal users impossible. The situation only getsameliorated when the period of waiting ends, if no otherfaked requests for connection come in during this period.

On the other hand, application-layer attacks exploit thelimitations of a specific application, such as a web server.These attacks typically involve sending specially designedHTTP requests, or simply getting the botnet to bombardthe application with more requests than its maximum ca-pacity. A simple example of such attacks would be to directthe botnet to all download a particular image file from a

web application at the same time. If the application is de-signed to support simultaneous downloads from 20 differentsources, it would probably fail if, say, 200 computers areperforming the download concurrently.

2.1.2 DDoS Attacks on Facebook, Google and GitHubThere are many documented instances of DDoS attacks onweb applications. Even tech giants such as Facebook andGoogle have experienced large scale DDoS attacks that broughtthe sites down for an extended period of time. For example,in 2015, Facebook was hit by a massive DDoS attack by thehacking group Lizard Squad [4]. The attack resulted in asevere outage of Facebook and sites that have major depen-dence on it, such as Instagram and Tinder. Google was alsoonce the target of DDoS attacks. In 2014, a DDoS attackbrought down the tech giant’s services including the vitallyimportant search engine for around one hour [9].

A massive DDoS attack hit GitHub in March 2015 whichwas claimed to be the site’s “largest DDoS attack” in itshistory [5] [18]. A malicious JavaScript code snippet wasinjected into advertisements and web tracking services pro-vided by the Chinese net giant Baidu. Every two seconds,the JavaScript code sends GET requests to two reposito-ries on GitHub: GreatFire and cn-nytimes, both of whichare projects designed to combat censorship in China. Dueto the popularity of Baidu services, countless computersaround the globe were turned into zombies attacking thetwo GitHub pages, precluding other users’ access to them.To partially mitigate the attack, GitHub set the two pagesto serve another JavaScript snippet that shows an alert boxsaying “malicious JavaScript detected on this domain”. Thisalert box temporarily deterred the repeated sending of GETrequests to GitHub. Due to this defense from GitHub, manyInternet users at the time encountered the alert dialog whenthey visited certain web sites. It is believed that this attackwas a politically-motivated operation by the Chinese gov-ernment to suppress attempts to circumvent censorship [5].

2.1.3 Possible Defense MechanismsDDoS is a major threat to the Internet today. Despite vari-ous research efforts in developing new techniques for protect-ing web applications against DDoS, there is still no panaceafor it due to the inherent difficulty of identifying illegitimatenetwork packets from a mix of normal and attack traffic [1].Possible mechanisms for mitigating DDoS attacks include[15]:• Identification of statistical patterns of malicious packetsand employment of filtering systems to sieve out these pack-ets• Load balancing to increase the capacity and reliability ofservers so as to minimize the risk posed by DDoS• Rate limiting to control the maximum amount of trafficcoming into the server and to throttle additional traffic

2.2 Cross-Site Scripting2.2.1 Overview

Cross-Site Scripting (XSS) is often regarded as one of themost common web application vulnerabilities today [2]. Itis a type of code injection that allows malicious JavaScriptto be executed on a victim’s browser with the aim to com-promise users of a website [22].

44

Generally, there are three parties involved in an XSS at-tack: the website, the victims and the attacker. The web-site serves HTML pages to users when they request them,the victims are ordinary users of the website, while the at-tacker refers to a malicious user who carries out attacks onthe victims. During an attack, the attacker does not targethis victims directly. Instead, he exploits an existing XSSvulnerability in the website, making use of that weaknessand letting the website deliver the malicious JavaScript forhim. Vulnerabilities that make XSS attacks successful arevery broad and may occur whenever a web application usesinput from users to generate the output without sanitiza-tion. XSS attacks may result in various undesirable effects,such as credential stealing, hostile content insertion, and thedisclosure of personal data.

2.2.2 ClassificationThe aim of an XSS attack is to execute unauthorized scriptin the victim’s browser, and there are significantly differ-ent approaches of reaching this aim. XSS attacks can bebroadly classified into three categories: reflected XSS, per-sistent (stored) XSS and DOM-based XSS. To better explainthese three attacks, we set up a scenario [16] in which thegoal of the attack is to steal the victim’s “cookies” by ex-ploiting existing vulnerability in the website. The followingthree figures illustrate how different variants of XSS attacksare carried out.

Figure 2: Reflected XSS

Reflected XSS attacks: At first, the attacker creates aURL containing a malicious parameter and sends it to thevictim. If the victim goes on to request the page, the web-site will deliver a response including a malicious string tothe victim. The victim’s browser will execute whatever itreceives. In this case, the malicious script will be executedand send the victim’s cookies to the attacker.

Persistent (stored) XSS attacks: Firstly, a maliciousstring is specially crafted by the attacker and inserted intothe website’s database. Again, if his target victims click intothat modified page, the website will include the maliciousJavaScript from the database in the response and deliver itto the user. Together with the malicious string involved,the victim’s browser will execute all the script and send thevictim’s cookies to the attacker.

DOM-based XSS attacks: DOM-based XSS can be re-garded as a variant of reflected XSS and persistent XSS. Inthis attack, the victim’s browser will not execute the mali-

Figure 3: Persistent XSS

Figure 4: DOM-based XSS

ciously crafted script until the requested website’s legitimatescript is executed. The first two steps are the same as thosein reflected XSS. However, when the website receives the re-quest, it will not include the malicious script in the response.The malicious JavaScript is only inserted into the page afterthe victim’s browser executes the legitimate script containedin the response. Finally, the victim’s browser executes themalicious string and sends cookies to the attacker.

Comparing these three vulnerabilities, we find that in thefirst two attacks, the inserted string is executed immedi-ately when the page is loaded. Nevertheless, in DOM-basedXSS attack, the string is only executed after the victim’sbrowser has loaded the page [16]. The difference is subtlebut significant because unlike the previous examples wherethe vulnerabilities are present in the website’s server-side,attacks could also take place in client-side. As a result, evenif server-side code is completely secure, the code from client-side can still include user input in a DOM update after thepage has been loaded. If this is the case, the unsafe client-side code could enable an XSS attack as well.

2.2.3 XSS Attack on TwitterOn August 14, 2010, a Japanese developer named MasatoKinnugawa discovered a XSS vulnerability in Twitter’s siteand reported it to Twitter. Soon after, a “new” Twitterwas launched but the same problem still persisted. Havingrecognized the ignorance of Twitter, Masato decided to warnTwitter by launching a XSS attack. He set up a Twitteraccount named “Rainbow Twtr” and used it to illustratehow the XSS vulnerability could be exploited to turn tweets

45

into different colors.

Some time later, a Scandinavian developer called MagnusHolm spotted Kinnugawa’s idea and used it to play moretricks. He wrote a tweet containing a link that would trig-ger the Twitter users who moused over the link to retweethis tweet. This trick worked perfectly. Within a few min-utes, the retweets quickly numbered 3381. However, onlyusers of the Twitter site itself were affected during the at-tack; clients using third-party software were fine as thoseprograms correctly escaped the malicious URL. [6]

2.3 SQL Injection2.3.1 Overview

Structured Query Language (SQL) injection attacks are mostknown as the source of credit-card theft which consistentlyranks at the very top of web application attack vectors. Ithas evolved significantly over the last 10 years even thoughthe underlying vulnerability that results in SQL injectionremains the same[21]. Today, SQL injection attacks usu-ally execute arbitrary commands on the victim’s operatingsystem, stealing millions of credit cards and wreaking havocagainst web sites.

More precisely, SQL injection refers to a web applicationweakness in which the attacker could submit a query that isable to pass the verification test and be carried out by a webapplication, causing back-end database exposure. Such anattack can take place when a web application stores user-supplied data without proper input sanitization [10]. Anattacker could craft user-supplied data to trick web applica-tions into executing malicious queries, in some cases even al-tering data. Often, a SQL injection attack allows a hacker toview, modify, or delete data stored in the back-end database[22]. The consequences of a successful SQL injection can bevery serious. If we use the CIA triad to assess it, it harmsconfidentiality since sensitive data in a SQL database areusually exposed. It also posts threat to data integrity be-cause changes or even deletion of information can occur witha SQL injection attack.

2.3.2 A Simple ExampleAs explained above, if a web application does not validatethe user-supplied data properly, the attacker could make useof that data as part of the SQL command against a back-enddatabase. Below is a classical example.

First create a URL link where ID is a required input [10] :http://www.website.com/id/id.asp?id=data

The attacker exploiting SQL vulnerability could simply en-ter the following as the data:

1=1

If user-supplied data is not properly sanitized by the webapplication and is stored to the database directly, the replyto the query will expose all credentials stored because “1=1”is always true. We can use code to describe this example,as shown in Figure 5.

We shall notice that user log-in credentials are required inorder to run the command in Figure 5. The web application

Figure 5: SQL injection vulnerability

will execute the command according to the user-supplieddata.

Figure 6: SQL query Part i

If the attacker supplies ’ and “1=1” as the username andpassword, the query will be like this:

Figure 7: SQL query Part iiBecause under every situation, “1=1” is true, the databasewill return all user data stored to the attacker. In this way,the attacker will be able to obtain users’ sensitive informa-tion.

2.3.3 SQL Injection Attack on YahooIn July 2012, Yahoo! Contributors Network was hackedby a hacker group called “D33DS Company”. Reportedly,453,491 encrypted login credentials were stolen via a SQLinjection attack. The leaked data was soon verified to comefrom the Yahoo Voices service [12].

The hacker group found the vulnerability that allows themto inject their own SQL commands to database and thengain access to the users’ personal data.

According to security researchers, the most worrying part ofthis SQL injection attack was that users’ log-in credentialswere not encrypted when stored in the database. They wereall plain-text. It means that any hacker could just “scoop upthe emails and immediately start using them against otherservices, including Yahoo Mail” [7]. This may pose more riskon other Yahoo applications in the future if the problem isnot properly solved.

2.4 Cross-Site Request Forgery2.4.1 Overview

Cross-Site Request Forgery (CSRF) attacks are a lesser-known type of web attack that may nevertheless lead toserious consequences. CSRF attacks occur when a mali-cious third-party web site tricks a user’s web browser intoperforming undesired actions on a trusted site for which the

46

user is currently authenticated [24], as illustrated in Figure8. The consequences of a successful CSRF attack are lim-ited to the capabilities exposed by the vulnerable site, andcan range from leaking of private information, user accountsbeing compromised, to financial losses.

2.4.2 A Simple ExampleTo further elucidate the workings of CSRF attacks, let usconsider a simple, hypothetical example. Imagine we havea blog site hosted at http://example.com/, where anauthenticated user can create new blog posts. Further sup-pose that on this site, there is a form specifically dedicatedto posting blog entries, with its HTML code as follows.

<form action="http://example.com/post.php"method="GET">

Title: <input type="text" name="title">Post: <textarea name="content"></textarea><input type="submit" value="Submit">

</form>

With this form, a user is able to input the title and content ofthe blog post, and click the “Submit” button to submit hisnew entry to http://example.com/post.php for pro-cessing, as a GET request. The GET request will appendall the parameters to the URL, and therefore, a URL to cre-ate a blog entry with title “New Post” and content “Todayis a sunny day” will be constructed in the following way.

http://example.com/post.php?title=New+post&content=Today+is+a+sunny+day

The backend server will then parse this URL to get the titleand content, and create a new entry in the database.

The security loophole here lies mainly with the fact thatGET requests do not check the origin of the URLs. Anauthenticated user could access the above URL, say, tentimes from the blog site itself or from a third-party site,and the database will then create ten identical entries if noduplicate check of blog post or CSRF defense mechanismswere implemented. Attackers may exploit this vulnerabilityto flood the server database with nonsensical content.

This security vulnerability could be easily capitalized on us-ing simple HTML tricks. The key for attackers is to leadthe user’s browser into sending GET requests similar to theabove, and there are HTML techniques aplenty for achiev-ing such a task. For example, the attackers could make useof the src (source) attribute of a <img> (image) tag.

<img src="http://example.com/post.php?title=New+post&content=Today+is+a+sunny+day">

When a web page with this element loads, the browser willfirstly access the URL located at src before it can displaythe image. Such access will readily cause the server to createa new post if the user is concurrently in an authenticatedsession with the blog site, thereby resulting in a successfulCSRF attack. The naming of such attacks stems from thefact that a cross-site request is forged for malicious inten-tions.

In addition, it should be noted that this illustrative exampleuses the GET method to create new content in the database,which is not consistent with industry standards where GETrequests are usually used to retrieve content. However, the

attack techniques described here could be easily adapted forPOST requests using JavaScript request automation.

2.4.3 CSRF Vulnerabilities of FacebookEver since Facebook gained popularity in the 2000s, variousvulnerabilities that render Facebook susceptible to CSRFattacks have been discovered. A first CSRF vulnerabilitywas found in 2009 by the security researcher Ronen Zilber-man [17]. This vulnerability worked by a simple redirecton a third-party web site which tricks the authenticationsystem of Facebook into believing that the redirect requestcomes from Facebook. The system then disclosed users’ so-cial information to the redirect request, thereby threateningusers’ privacy. Fortunately, the vulnerability was reportedto Facebook before it caused severe privacy violation andwas quickly fixed.

A second example was reported in 2011, when researchers atSymantec proposed a tricky way to circumvent Facebook’santi-CSRF mechanisms [20]. The attack started with a linkinviting a Facebook user to watch a video. On the malicioussite playing the video, a dialog claiming to serve “securityverification” purposes was launched and prompted the userto click a link to “generate a security code”. This link wouldthen send a request to the URL https://www.facebook.com/ajax/dtsg.php, which would return the anti-CSRFtoken (see Section 2.4.4) for the current user session. Withthe anti-CSRF token at hand, the attacking site would beable to manipulate the user account easily, and could, forinstance, post another malicious link on the victim’s Face-book page to trick others into watching the video, therebypropagating the attack.

2.4.4 Possible Defense MechanismsNumerous defense mechanisms have been proposed to com-bat CSRF attacks, including, notably, regulations of GETrequests and use of anti-CSRF tokens [24], used to eliminateCSRF attacks via GET and POST requests respectively.

Regulations of GET requests: Such regulations specifythat GET requests be used only for data retrieval, and notfor data creation, modification, or deletion. These require-ments eliminate attacks such as the one described in Section2.4.2 where GET requests are used to create new blog en-tries. These requirements are in alignment with RFC 2616[11] and are widely adopted in the industry.

Use of anti-CSRF tokens: Attackers use JavaScript toautomate POST requests from a third site to perform CSRFattacks on an authenticated site. To defend against CSRFattacks via POST requests, pseudorandom values are in-cluded in the session cookie and also as a hidden value inthe forms. Server considers a submitted form valid, if andonly if the token value in the form matches the one in thecookie. As attackers have no means of knowing the tokenvalue in the cookie, it is difficult for them to submit a formwith the correct token and their attacks are effectively madeimpossible this way.

3. SIMULATION OF CSRF ATTACKSIn this section, we describe our efforts in simulating a CSRFattack targeting a money transfer site. We make use of two

47

Figure 8: Mechanisms of CSRF attacks. If the user is in an authenticated session with the target site andvisits a malicious web site in the meanwhile, the attacker may be able to send nefarious requests to thetrusted site on behalf of the user.

repositories: a minimal version of a banking application, anda single HTML page with JavaScript automation for postingcross-site form requests. The minimal banking site consistsof mainly two pages: one for user log-in, and the other forsending funds to other users, as shown in Figure 9.

Figure 9: Minimal banking application with userlog-in and fund transfer functionsThe banking application is implemented in PHP with aMySQL database and an Apache server as its back-end. Wehave created several user accounts for our simulation. Auser will start his visit from the log-in page, where he en-ters his account details to be checked against the database.After a successful authentication, the application maintainsa user session for his subsequent banking activities until helogs out. The process of sending funds is illustrated in thesecond part of Figure 9. In this scenario, the user withemail address [email protected] is sending a fund worth$30 to the user with email [email protected]. After theuser clicks “Go!”, the server will ensure that both users areexistent in the database and transfer the fund as requested.

While the user is in the authenticated session, he may surfother pages. Concurrent viewing of other sites togetherwith the banking application poses a security threat, sincethese sites may contain code that exploits vulnerabilities ofthe banking site to achieve malicious purposes. One suchscenario is shown also in Figure 9, where the other tab ti-tled “Hugh the Hacker” is in activity. This is our attack-ing script. In this script, we have an invisible form and aJavaScript snippet to automatically trigger the submissionof this form with preset values. In our case, the values are:email being [email protected], and fund amount being$30.

We compare the results of triggering the attack in the casewhere the money transfer site does not have protection mech-anisms and in the case where it does. When there is no anti-CSRF token in the fund transfer form, the attacking scriptsucceeds in posting a cross-site request to the banking site.This request causes an involuntary transfer of $30 to anarbitrary user. Clearly in this case, without adequate pro-tection of the site, monetary losses may be incurred to usersand correspondingly reputation of the bank damaged. Con-trarily, if we include a session-based anti-CSRF token in theform, the POST request sent from the malicious script fails.This is because the anti-CSRF token is a random string andthe attacking script has no way of correctly guessing and in-cluding this string in its request. Using such a mechanism,the site is protected against CSRF attacks.

It is evident from our simulation how the lack of CSRF pro-tection causes losses (especially for critical sites) and howthe presence of it could save the fortune of web applications.Through this simulation as a proof of concept of CSRF at-tacks, we wish that readers have a more concrete under-standing of them. Further technical details including theentire code bases for both the application and the attackingscript are included in the Appendix section of this paper forcompleteness’ sake.

4. CONCLUSIONSIn summary, this paper has taken a look at four types of webattacks: Distributed Denial of Service, Cross-Site Scripting,SQL injection, and Cross-Site Request Forgery. CSRF at-tacks are studied in greater depth by simulating one suchattack and presenting countermeasures against it. It is, how-ever, to be noted that this paper is only a brief overview onthe topic of web application security and is by no meanscomprehensive. The authors believe that awareness of andknowledge about web security are a must for IT practition-ers, and wish that this paper serves to raise such awareness.

5. ACKNOWLEDGMENTSThe authors of this paper would like to thank Prof HughAnderson of National University of Singapore for providingus with this opportunity to write our first technical paper.

6. REFERENCES[1] M. Aamir and M. A. Zaidi. A survey on ddos attack

and defense strategies: From traditional schemes tocurrent techniques. Interdisciplinary InformationSciences, 19(2):173–200, October 2013.

[2] Acunetix. Cross-site scripting (xss) attack.

48

[3] Acunetix. Analysing the latest trends in webapplication attacks, October 2014.

[4] D. Allan. Facebook: down and out again (along withinstagram) after ddos attack?, January 2015.

[5] S. Anthony. Github battles “largest ddos” in site’shistory, targeted at anti-censorship tools, March 2015.

[6] C. Arthur. The twitter hack: how it started and howit worked, September 2010.

[7] C. Arthur. Yahoo voice hack leaks 450,000 passwords,July 2012.

[8] H. Chen and D. Rituja. Q & a. what motivatescyber-attackers? Technology Innovation ManagementReview, 4(10):40–42, October 2014.

[9] G. D’Mello. Google reels under ddos attack, December2014.

[10] N. DuPaul. Sql injection cheat sheet & tutorial:Vulnerabilities & how to prevent sql injection attacks.

[11] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,L. Masinter, P. Leach, and T. Berners-Lee. Hypertexttransfer protocol–http/1.1. Technical report, 1999.

[12] A. Greenberg. Hackers spill more than 450,000 emailaddresses and passwords, blame a yahoo! databasevulnerability, July 2012.

[13] P. Institute. Cyber security on the offense: A study ofit security experts. Technical report, November 2012.

[14] P. Ionescu. The 10 most common application attacksin action, April 2015.

[15] R. K. An introduction to ddos - distributed denial ofservice attack, March 2011.

[16] J. Kallin and I. L. Valbuena. Excess xss, 2013.[17] S. M. Kerner. Facebook hit by cross-site request

forgery attack, August 2009.[18] M. Kumar. Github hit by massive ddos attack from

china, March 2015.[19] S. Mansfield-Devine. Ddos: threats and mitigation.

Network Security, 2011(12):5–12, December 2011.[20] B. Prince. Scheme defeats facebook’s defense against

cross-site request forgery attacks (csrf), October 2011.[21] M. Shema and A. Ely. Seven deadliest web application

attacks. Syngress, Burlington, Massachusetts, 2010.[22] D. Stuttard and M. Pinto. The web application

hacker’s handbook: finding and exploiting securityflaws. Wiley, Indianapolis, 2011.

[23] A. Technologies. Ddos and web application attacks,December 2015.

[24] W. Zeller and E. W. Felten. Cross-site requestforgeries: Exploitation and prevention. The New YorkTimes, pages 1–13, 2008.

APPENDIXA. SIMULATION: THE BANKING SITEThis section describes the structure of the banking applica-tion and includes its complete code with some explanations.Do note that due to time constraints, some of the code writ-ten may not follow best practices although the project itselfis sufficient for the simulation.

A.1 Project Directory StructureThe directory of the fund transfer application could be visu-alized as the following tree. There are two directories in the

project. Details about these directories and files are givenin the subsections.

bank_transfer_app

sql

database.sql

includes

db_connect.php

errors.php

functions.php

index.php

transfer.php

logout.php

A.2 SQL Codesql: The sql directory includes SQL code for initializing andseeding the database. For simplicity, the database consistsof only one table: the users table which contains log-inand bank balance information of the users. Since we do notsupport user registration in the application, we have relevantcode for creating dummy users as well. Below is the code indatabase.sql. An apparent security practice used here isto hash user passwords using the MD5 hash function.

CREATE DATABASE `cs2107`;

CREATE USER 'simulation'@'localhost'IDENTIFIED BY 'm5Z9STYSSsNA';

GRANT SELECT, INSERT, UPDATE ON `cs2107`.* TO 'simulation'@'localhost';

-- Table for storing user log-incredentials and bank balance

CREATE TABLE IF NOT EXISTS `cs2107`.`users` (

`id` int(10) unsigned NOT NULL,`email` varchar(64) NOT NULL,`password` varchar(64) NOT NULL,`balance` decimal(10,0) NOT NULL DEFAULT

'0') ENGINE=InnoDB;

ALTER TABLE `users` ADD PRIMARY KEY (`email`), ADD KEY `id` (`id`);

-- Add usersINSERT INTO `cs2107`.`users` VALUES(1, '

[email protected]', MD5('test_password'), 2000);

INSERT INTO `cs2107`.`users` VALUES(2, '[email protected]', MD5('CS2107ProjectSimulation'), 100);

INSERT INTO `cs2107`.`users` VALUES(3, '[email protected]', MD5('HughIsTheMostHandsomeProfAtSoC'), 100);

49

A.3 Back-end Codeincludes: This directory contains mainly back-end logic.There are three files in the directory.

db_connect.php: This file is in charge of establishingdatabase connections. The parameters in this file are iden-tical to those used to initialize the database in the .sql file.In a production environment, we may need to hide this fileusing some special techniques since it contains secrets (i.e.database credentials).

<?phpdefine('HOST', 'localhost');define('USER', 'simulation');define('PASSWORD', 'm5Z9STYSSsNA');define('DATABASE', 'cs2107');

// All PHP pages that require access to thedatabase need to include this file

$mysqli = new mysqli(HOST, USER, PASSWORD,DATABASE);

if ($mysqli->connect_errno > 0) {die('Unable to connect to database [' . $db->

connect_error . ']');}

errors.php: This file contains a list of possible exceptionsthat may be thrown in the back-end procedures.

<?phpdefine('ERR_NOT_ENOUGH_BALANCE', "You don't

have enough balance to perform the moneytransfer request.");

define('ERR_EMAIL_NOT_EXIST', "The given emaildoes not exist.");

define('ERR_AMOUNT_NOT_NUMERIC', "The amountyou entered is not a decimal number.");

functions.php: This file includes implementations of back-end processing logic such as user log-in, transferring of funds,and generation of anti-CSRF tokens. Readers may be inter-ested in noting how we make use of mysqli prepared state-ments in PHP to escape possible SQL injection attacks.

<?phpinclude_once 'includes/errors.php';

function email_exists($email, $mysqli) {// Return true if a user with the given

email exists, false otherwise$query = "SELECT id FROM users WHERE email =

? LIMIT 1";if ($stmt = $mysqli->prepare($query)) {$stmt->bind_param('s', $email);$stmt->execute();$stmt->store_result();

$stmt->bind_result($balance);$stmt->fetch();

if ($stmt->num_rows >= 1) {return true;

}}return false;

}

function login($email, $password, $mysqli) {// Return true if the given email and

password match our database record,false otherwise

$query = "SELECT id, email, password FROM

users WHERE email = ? AND password = ?LIMIT 1";

if ($stmt = $mysqli->prepare($query)) {$stmt->bind_param('ss', $email, MD5($

password));$stmt->execute();$stmt->store_result();

$stmt->bind_result($db_id, $db_email, $db_password);

$stmt->fetch();

if ($stmt->num_rows == 1) {return true;

}}return false;

}

function get_balance($email, $mysqli) {// Return the balance of a particular user$query = "SELECT balance FROM users WHERE

email = ? LIMIT 1";if ($stmt = $mysqli->prepare($query)) {$stmt->bind_param('s', $email);$stmt->execute();$stmt->store_result();

$stmt->bind_result($balance);$stmt->fetch();

if ($stmt->num_rows == 1) {return $balance;

}}throw new Exception(ERR_EMAIL_NOT_EXIST, 1);

}

function update_balance($email, $new_balance,$mysqli) {

// Update the balance of the user identifiedby $email to the new balance

if (!email_exists($email, $mysqli)) {throw new Exception(ERR_EMAIL_NOT_EXIST, 1

);} else if (!is_numeric($new_balance)) {throw new Exception(ERR_AMOUNT_NOT_NUMERIC

, 1);}

$query = "UPDATE users SET balance = ? WHEREemail = ?";

if ($stmt = $mysqli->prepare($query)) {$stmt->bind_param('ss', $new_balance, $

email);$stmt->execute();$stmt->close();

}}

function send_money($email, $amount, $mysqli){

// Send the given amount of money from theuser in the current session to thetarget email

$own_balance = get_balance($_SESSION['email'], $mysqli);

if (!email_exists($email, $mysqli)) {throw new Exception(ERR_EMAIL_NOT_EXIST, 1

);} else if (!is_numeric($amount)) {throw new Exception(ERR_AMOUNT_NOT_NUMERIC

, 1);

50

} else if ($own_balance < $amount) {throw new Exception(ERR_NOT_ENOUGH_BALANCE

, 1);}

$target_balance = get_balance($email, $mysqli);

// A database transaction could be addedhere

update_balance($_SESSION['email'], $own_balance - $amount, $mysqli);

update_balance($email, $target_balance + $amount, $mysqli);

}

function csrf_token() {if (isset($_SESSION['csrf'])) {return $_SESSION['csrf'];

} else {// Generate a random string as the CSRF

token$characters = '0123456789' . '

abcdefghijklmnopqrstuvwxyz' . 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';

$length = strlen($characters);$string = '';for ($i = 0; $i < 40; $i++) {$string .= $characters[rand(0, $length -

1)];}return $string;

}}

A.4 index.phpThis file serves the landing page of the application, i.e. thepage where the user is directed to enter his log-in creden-tials. It includes both HTML code for page layout and PHPcode for processing log-in POST requests. Do note that thisversion implements anti-CSRF mechanisms.

<?phpinclude_once 'includes/functions.php';include_once 'includes/db_connect.php';session_start();session_regenerate_id(true);

if (isset($_SESSION['email'])) {// User already logged in: direct to the

transfer pageheader('Location: transfer.php');exit();

}

$msg = '';// Handling login POST requestif (isset($_POST['login']) && !empty($_POST['

email']) && !empty($_POST['password'])) {$email = $_POST['email'];$password = $_POST['password'];

if (login($email, $password, $mysqli)) {$_SESSION['email'] = $email;$_SESSION['csrf'] = csrf_token();header('Location: transfer.php');exit();

} else {$msg = 'Your email and password do not

match.';}

}?><html lang="en">

<head><link href="https://maxcdn.bootstrapcdn.com/

bootstrap/3.3.6/css/bootstrap.min.css"rel="stylesheet">

<title>Simulation of CSRF Attack</title></head><body><div class="container form-signin"><h2>Bank Account Login</h2><form class="form-signin" role="form"

action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="post">

<h4 class="form-signin-heading"><?php echo$msg; ?></h4><!-- Error message -->

<input type="text" class="form-control"name="email" placeholder="Email"required autofocus></br>

<input type="password" class="form-control" name="password" placeholder="Password" required></br>

<button class="btn btn-lg btn-primary btn-block" type="submit" name="login">Login</button>

</form></div><br><br><br><p align="center">CSRF Attack Simulation for

CS2107</p></body></html>

A.5 transfer.phpThis file is for the money transfer interface. There areHTML code for page rendering as well as PHP code forhandling fund transfers.

<?phpinclude_once 'includes/functions.php';include_once 'includes/db_connect.php';session_start();session_regenerate_id(true);

if (!isset($_SESSION['email'])) {// User not logged in yet: direct to the

login pageheader('Location: index.php');exit();

}

$msg = '';if (isset($_POST['transfer']) && !empty($_POST

['to']) && !empty($_POST['amount']) && !empty($_POST['csrf']) && $_POST['csrf'] ==$_SESSION['csrf']) { // Predicate includeschecks for anti-CSRF tokens

$target_email = $_POST['to'];$amount = $_POST['amount'];

try {send_money($target_email, $amount, $mysqli

);} catch (Exception $e) {$msg = $e->getMessage();

}}

?><html lang="en"><head><link href="https://maxcdn.bootstrapcdn.com/

bootstrap/3.3.6/css/bootstrap.min.css"rel="stylesheet">

<title>Simulation of CSRF Attack</title></head><body>

51

<div class="container form-signin"><h3><?php echo "Welcome, " . $_SESSION['

email'] . "!"; ?></h3><h2>Money Transfer</h2><h3>Your current balance: <?php echo

get_balance($_SESSION['email'], $mysqli); ?></h3>

<form class="form-signin" role="form"action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="post">

<h4 class="form-signin-heading"><?php echo$msg; ?></h4><!-- Error message -->

<input type="text" class="form-control"name="to" placeholder="Recipient email" required autofocus></br>

<input type="text" class="form-control"name="amount" placeholder="Amount"required></br>

<input type="hidden" name="csrf" value="<?php echo csrf_token(); ?>"><!--Preventing CSRF attacks -->

<button class="btn btn-lg btn-primary btn-block" type="submit" name="transfer">Go!</button>

</form>

<p align="right">Click <a href="logout.php">here</a> to log out.</p>

</div><br><br><br><p align="center">CSRF Attack Simulation for

CS2107</p></body></html>

A.6 logout.phpAs the name suggests, this file handles users’ log-out re-quests. It simply deletes the current user session and directsthe user back to the main page.

<?phpsession_start();session_unset();header("Location: index.php");

B. SIMULATION: THE MALICIOUS SCRIPTThe script used for launching the CSRF attack is nothingother than a simple HTML file consisting of mainly twocomponents: a form for sending POST requests to the fundtransfer site, and a JavaScript piece for triggering form sub-missions. Note that the power of the CSRF attack could beamplified by using JavaScript loops to send multiple formsubmissions consecutively.

<!DOCTYPE html><html lang="en"><head><script src="http://code.jquery.com/jquery-

latest.min.js" type="text/javascript"></script>

<title>Hugh the Hacker in action</title></head><body><div class="container"><p>Welcome to my website!</p>

<iframe style="display:none" name="csrf-frame"></iframe>

<form method="POST" action="http://cs2107.local:8081/transfer.php" target="csrf-frame" id="csrf-form">

<input type="hidden" name="to" value="[email protected]">

<input type="hidden" name="amount" value="30">

<input type="hidden" name="transfer"value="">

<button type="submit"></button></form>

<script>document.getElementById("csrf-form").submit();</script>

</div></body>

</html>

52

Comparison between Tamper-Resisting Techniques for Software Applications

Li Zhikai A0093857M

National University of Singapore 92317028

[email protected]

Damian Goh Jun Yi A0131966Y

National University of Singapore 91089673

[email protected]

Lim Han Yang A0099182U

National University of Singapore 97213782

[email protected]

Lee Chun Hung A0125948U

National University of Singapore 91155031

[email protected]

ABSTRACT

In this paper, we will introduce the need for tamper-resistant

software, as well as providing common methods of software

tampering and techniques to counter them. Subsequently, a

comparison across techniques will be made to conclude on which

techniques are more suitable for the different applications of anti-

tampering software.

Categories and Subject Descriptors

D.2.0 [Software Engineering]: General – Protection Mechanisms.

D.2.4 [Software Engineering]: Software/Program Verification –

Correctness Proofs, Reliability

General Terms

Reliability, Security, Theory, Verification.

Keywords

Tampering, Rootkits, Backdoors, Reverse Engineering, Cyclic

Redundancy Checksums, Obfuscation, White-Box, Side-Channel

Attacks.

1. INTRODUCTION Information security is commonly introduced as an attacker

intruding into a victim’s terminal. Although this situation is still

true at times for software protection, software developers often find

themselves in a different playing field where the attacker himself

intrudes into the developer’s software within the attackers own

terminal. As the attacker has complete control of his own terminal,

software developers must device means of resistance within their

applications to prevent attackers from tampering with them,

whereby the attacker can freely obtain information from the

software or alter the functions of it.

In this paper, the importance of software anti-tampering will be

introduced, along with common tampering attacks, their

corresponding anti-tampering techniques and their applications.

Subsequently, we will compare and analyze each technique and

determine their suitability for their different uses.

2. A CASE OF SOFTWARE TAMPERING –

WORLD OF WARCRAFT: MASS

MYSTERIOUS DEATH INCIDENT On 7 October 2012, players of the famous online multiplayer role

playing game, World of Warcraft, found their in game characters

mysteriously dying for no apparent reason. This caused panic and

chaos while the in game towns were filled with corpses of

characters who died in this mysterious way [2].

The game disruption lasted four hours before game developer,

Blizzard, released a patch to fix this problem. Subsequently, the

culprit claimed responsibility for the incident over an online forum,

with his intention to express discontent for his wrongfully banned

friend [2].

In the incident, the culprit had managed to find a software

vulnerability in the game client files and managed to tamper with it

in order to run unauthorized actions such as killing other players.

As Blizzard mentioned in their forums, the culprit managed to

abuse an “in-game exploit” [2]. This brings up the issue of tamper

resistance which needs to be in-built within such game clients or

other software applications in order to prevent similar incidents

from occurring again.

3. USES OF TAMPER-RESISTING

SOFTWARE Inclusive of its function in computer gaming, anti-tampering

techniques are used in the following applications:

1. Computer games – Used to prevent exploits and cheating

in the game.

2. Military protection – Protect military computers,

communication software and other related technology

from leaking sensitive information or being altered [15].

3. Digital Rights Management (DRM) – Copyright

protection of digital data. This prevents unauthorized

distribution of data [13].

In each of the above applications, different techniques can have

varying levels of effectiveness, which will be discussed in a later

section.

4. TAMPERING ATTACKS Obtaining secret information and data or memory altering are what

attacks would aim to do with through software tampering. In the

context of software tampering, attacks could be the software user

himself, or another malicious user attacking a victim over the

internet. This section introduces several means and methods which

attackers can use to attack a software.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior

specific permission and/or a fee.

NUS CS2107’16, July 25, 2016, Singapore. Copyright 2016 ACM 1-58113-000-0/00/0010 …$15.00.

53

4.1 Attaining Root Access Some software attacks require root access on the target system in

order to directly carry out tampering, such as memory tracing using

a debugger. Attackers with root access can perform a white-box

attack, where he has full control over the software’s binary build,

execution and even its memory [22]. Rootkits and Backdoors, as

explained in the following subsections, are two means for attackers

to attain root authority.

4.1.1 Rootkits A rootkit is a program which allows an attacker to have his presence

hidden in a computer system, allowing subsequent access to the

system. To function, rootkits attach themselves and operate in a

system’s kernel which allows it unrestricted access to the system’s

hardware. Rootkits then tap on this wide access from the kernel,

and uses it to obtain its stealth [9]. For example, rootkits can use

this access to alter processes fetched by the task manager in order

to stay hidden. By manipulating and altering the execution flow and

records within the host operating system [21]. Rootkits can conceal

itself and other malicious files or programs from the owner of the

system to spy on them or do other malicious activities [10].

When used maliciously, rootkits can be installed on a system

intentionally by the user or unintentionally when a victim is

attacked over the internet, in order to manipulate or extract

information from a target software application without detection.

This allows direct tampering with data and memory of a particular

software application installed within the host computer, causing a

leakage of secret information from the software or illegally altering

the software memory during its run.

4.1.2 Backdoors Backdoors are legitimate point of access coded into a system or

software program for remote administration. It is usually reserved

for maintenance of the system and administrative backdoors are

protected with a username and password [23].

However, backdoors can also be installed or discovered by an

attacker, granting them equal authority to the system and bypassing

normal authentication protocols [9]. Unlike rootkits, backdoors are

usually exploited in a one-off attack on software or system

vulnerabilities, while a rootkit is designed for sustained operation

which stays hidden [9].

In the context of software tampering, attackers can use malware to

install a backdoor on a target system. This allows the attacker to

steal secret information, modify the software or carry out malicious

activities such as keylogging or weakening encryption algorithms

within a software [23].

4.2 Methods of Tampering Attacks This following subsections will explain some mechanisms and

methods which attackers can use to implement their attacks on a

software application.

4.2.1 Reverse Engineering and Side-Channel Attacks Reverse Engineering is the process of breaking down a software

application back to its elementary pieces or source code, whereby

one can extract information on the methodology of the final

software application being studied [16].

Reverse engineering of applications are done through various tools

such as decompilers. On larger and more ambitious software, side-

channel attacks are often used, which rely on unintentional

information leakage about application works. There are three

common types of side-channel attacks as follows:

1. Timing Attacks – A precise timer is used to time a target

software in completing a programmed task.

2. Power Consumption Attacks – Analyzing the power

consumption of a circuitry while it performs a

programmed task.

3. Differential Fault Analysis – Intentionally introducing a

fault to the application to observe how it reacts to it.

The above three techniques could be used to gather information

regarding the methodology of a software application [12] (See

Appendix A for examples). This could possibly allow one to

reverse engineer and replicate a portion, or even the entire source

code of an application from scratch.

The process to reverse engineer a software application usually

yields constructive results where one would study a software in

order to improve upon it or streamline it within a system of

networks. However, such efforts can also be used to tamper with a

software. By maliciously reverse engineering a software, editing

the source code and recompiling the application, attackers using

such methods can intentionally remove restrictive features of the

application, such as copy protection [18].

4.2.2 Software Memory Attacks Memory attacks involve alter a system’s temporary memory used

while running a software. Two types of such attacks are possible.

The first type of memory attack requires root access. It involves the

use of a debugger or a memory hex editor. This include the famous

Cheat Engine, which can be used to observe, track and change

variables within a software or a game, forcing variables in the

software to take on new values, essentially performing illegal

actions within the software [3].

The second type of memory attack are overflow attacks which do

not rely on root access, but software vulnerabilities instead.

Attackers can carry out a buffer or heap overflow, both occurring

if developers do not properly check their input parameters.

A buffer overflow can occur if a program does not check its input

parameters. On calling vulnerable functions, memory can be stored

outside of what is allocated to it [7]. Attackers can then embed

entire assembly codes within a memory stack. By changing the

return address at the end of the memory buffer, a buffer overflow

attack can hijack the software and make it do any action prescribed

in the payload embedded in the buffer during the attack [7]. An

example of a stack overflow is shown in Figure 1 below.

Figure 1. Illustration of buffer overflow.

Program Code

Data

Heap (Stores

Variables)

Procedure

Call Frame

(The Buffer)

Return

Address

Alloc.Mem.

Program Code

Data

Heap (Stores

Variables)

Procedure

Call Frame

(The Buffer)

Return

Address

Call vulnerable

input function

without

checking for

overflow

Overwritten

Return address

Function now returns to start

of malicious code input

Malicious

Code

54

A heap overflow happens due the way systems manages its free

memory in the heap. Memory in the heap forms a double linked list,

where each chunk of used or free memory keeps track of the

location of the next and previous chunk [19]. When a memory

instance is freed, it can be combined with adjacent instances of free

memory to form a larger chunk. When so, the system have to

remove an element from the linked list [19]. This can be illustrated

in Figure 2.1.

Figure 2.1. Removing the middle element from a linked list.

An attacker can now cause an overflow before the memory in the

middle chunk is freed. He can trick the new combined memory into

thinking that it has the address of the malicious code and is linked

to the function return call. When the system tries to free the middle

instance from the linked list, the system now relays the function

return to the malicious code, which is later performed when the

function terminates and returns [19]. This is shown in Figure 2.2.

Figure 2.2. Illustration of Heap overflow

5. ANTI-TAMPERING TECHNIQUES This section introduces some common techniques used to prevent

or deter the tampering attacks mentioned in the previous chapter.

Some methods prevent, while others detect occurrences of

tampering. In the event of a detection, the software can respond by

ending the program, restoring itself to the pre-tamper state,

reporting the attempt over the internet or in a more serious case,

punish the attacker by destroying systems files [4].

5.1 Cyclic Redundancy Checksums Cyclic Redundancy Checksums (CRC) is a method used to detect

errors in transmission or storage of data [20]. In the context of

software anti-tampering, it is used as an integrity check on the

binary source file, flagging out instances where the program has

been tampered with.

CRCs work by appending a number of bits, known as the

checksum, to the end of a block of data to form a code word. The

checksum is calculated using polynomial arithmetic, where the bits

of the data block is treated as the coefficients of an nth degree

polynomial, with n being 1 less than the size of the block of data

encoded. Another polynomial, called the generator polynomial, of

a smaller order (usually 16 or 32 bit) is chosen and used as a divisor

of the polynomial division for all blocks of data using the CRC

mechanism. After polynomial division is performed on each block,

the remainder of the polynomial division becomes the checksum.

When a software which adopts CRC runs, the data blocks are

divided again by the generator polynomial, and its checksum is

compared with the one appended to the end of the block [20]. This

verifies the checksum and hence the binary source code integrity.

If the data block and checksum do not tally, the program suspects

that it has been tampered with. This scheme is illustrated in Figure

3 below.

Figure 3. Illustration of the CRC scheme.

Similar to hashes of a file, encoding a larger block of data to a

smaller checksum can result in collisions. As such, there is a small

probability that a tampered data block can produce the same

checksum as the original data. To significantly lower the frequency

of such collisions, a larger order generator polynomial can be used,

resulting in a larger pool of checksums which a block of data can

have, hence reducing the probability of collisions. However, this

can cause an increase in the size of the binary source code of the

software.

5.2 Obfuscation Obfuscation deliberately make a source code obscure and

unintelligible, with the aim of making a code as unreadable as

possible without impacting the functionality of the code. This

deters attacks from reverse engineering the source code though a

layer of additional difficulty.

There are four main methods to carry out obfuscation [1] as follows

(See Appendix B for examples):

1. Layout obfuscation – mess up the physical look of the

code, through messing up the code formatting or naming

variables as random strings.

2. Data obfuscation - obscures the data structures in the

program, concealing important information about them

3. Control obfuscation – Jumble up the control flow of a

program, possibly through reordering code fragments.

4. Preventive transformations – Perform unnecessary

changes to data to make it harder for an automatic de-

obfuscation tools to work.

Obfuscation comes at a cost, as it will require more system memory

and increases the runtime of the program through performing

unnecessary tasks. Furthermore, some programs can automatically

de-obfuscate an obfuscated code [1], allowing a decompiler to

easily generate the source code. As such, the effectiveness of

obfuscation depends how well the source code is able to fool both

a human programmer and a de-obfuscation tool.

Memory in

use

New Freed

Memory

Free

Memory

New links

Malicious

Code

Function

Return call

Memory in

use

New Freed

Memory

Free

Memory Heap Overflow

New

link

Fake

links

55

5.3 Client-Server Mirroring Software can be protected by adopting a client-server infrastructure

allows for memory changes on the client side to be mirrored and

kept as a backup on the server side as well [8]. This adds difficulty

to a memory attack as attack would have to alter both the client and

server sided memory. Although altering server memory is possible,

users normally do not have authority to change them, deterring foul

play [6].

5.4 White-Box Cryptography White-box cryptography in software protection aims to retain the

secrecy of information when under a white-box attack [22]. Using

a symmetric encryption, assuming its attacker to be under a chosen

text attack model, and also able to observe and trace the software

memory through the white-box. Under such situation, a successful

implementation of white-box cryptography should ensure that the

attacker is unable to obtain the key to the encryption, thereby

preventing attackers from obtaining critical information through

analyzing other portions of the binary software [14].

In an encryption which involves multiple rounds of sub-encryptions

such as the 3DES or AES, White-box cryptography stops attackers

from obtaining sub-keys through analysis of one specific round in

the encryption, preventing them from reforming the overall

encryption key. Take DES encryption as an example, which uses a

56bit encryption key to generate 16 sub-keys of 16 bits to use

through 16 rounds of symmetric encryption (Each round denoted

as A, B, C… in Figure 4.1).

Figure 4.1. White-Box Attack on DES

In a white-box context, attackers can observe the intermediate

stages of transformation between rounds, as shown in Figure 4.1.

Doing so, he can easily do a brute force attack on each individual

round, which only has a 16bit key and a key-space of 216 = 65536,

thereby reforming the original 56bit key using the 16 sub-keys.

A possible implementation of white-box cryptography into such a

system is through protection via randomization [22]. As such, the

system above can be modified to that in Figure 4.2.

Figure 4.2. Implementation of White-Box Cryptography

The encryption in Figure 4.1 is modified to such in Figure 4.2.

Functions f, g and h are all randomly chosen at the start of the

encryption, with f-1 being the inverse of f and so on. Before

encrypting, lookup tables are generated by the system for each

round (Such as for B’). These lookup tables are used so that f-1, B

and g are performed as a one-step operation. Attackers intercepting

intermediate messages can no longer deduce the sub-key for B. As

such, attackers have to analyse adjacent rounds together in order to

eliminate the the random functions [22]. Doing so adds difficulty

to a brute force attack, making it less feasible, reducing the

vulnerability of a software under a white-box context.

5.5 Anti-Viruses An anti-virus software generally works through a constantly

updated blacklist of malwares [5]. To ensure security of the user,

an anti-virus adopts “On-Access Scanning” which checks the file

the user is about to run or download against its blacklist. Once a

match is found, the user is prompted to quarantine or delete the

infected file.

An anti-virus also has some capability to detect malware not in its

blacklist through heuristics detection where a slightly modified

malware or a program that runs suspiciously (Such as trying to open

many other files or copying itself into another file) will also return

a positive detection [11].

Such anti-viruses aid in software anti-tampering as this prevents

attackers from sending malicious patches or programs to try and

alter existing software files on the victim’s terminal. Thus

preventing possible leakage of sensitive information stored within

the software, such as passwords saved on Google Chrome.

6. TECHNIQUES ANALYSIS AND

COMPARISON In this section, we would analyze the trade-offs for applying each

anti-tampering techniques described and how they fare under

possible attacks previously raised. Comparing this with the

possibility of each type of application under different attacks, we

would conclude which anti-tampering techniques are best suited for

the different applications.

6.1 Effectiveness of Techniques Each technique will be analyzed based on their runtime

performance and memory usage in terms of both required file size

and temporary memory use. Their effectiveness in countering

reverse engineering and memory attack attempts will also be

carefully considered. In each case, an effectiveness score ranging

from 0 (Not effective) to 3 (Very effective) will be assigned.

In tables 1.1 to 1.5 below, our analysis is shown for CRCs,

Obfuscation, Client-Server Mirroring, White-Box Cryptography

and Anti-Viruses respectively.

Table 1.1. Analysis of Cyclic Redundancy Checksum.

Effectiveness Score Justification

Runtime 1

Repeatedly verifying checksums of

data blocks adds a lot of extra

runtime to a program.

Memory

Usage 0

Having to store checksums on top of

the original binary code uses up more

data than necessary. Furthermore,

checksums that are too small results

in many collisions. This result in the

source code increasing in size by a

significant factor.

Preventing

Side Channel

Attacks

3

Having extra functions and checks

complicates the software and makes

it harder for decompilers to work.

Directly prevents reverse engineering

through fault introduction as faults

will be detected through checksums.

Preventing

Memory

Attacks

3

Injected memory can be detected

easily as they do not have a proper

checksum.

Plain-

text

Cipher-

text …

Attacker can retrieve information in intermediate stage

C B A

Plain-

text

Cipher-

text …

Intermediate message gives no information

f-1 g-1

B’

A f g B C h

56

Table 1.2. Analysis of Obfuscation.

Table 1.3. Analysis of Client-Server Mirroring.

Table 1.4. Analysis of White-Box Cryptography.

Table 1.5. Analysis of Anti-Viruses.

6.2 Suitability of Techniques in Contextual

Applications In contextual applications, some softwares need to defend against

specific attacks more than others, and difference allowance for

performance compromise. With this, an applicative index from

1(Low importance) to 3(High importance) will be assigned to

preventing each attack or optimizing performance in each context.

Using the applicative index as a weightage for the effectiveness

score of each anti-tamper technique, a final weighted score will be

to quantitatively determine the most suitable technique for each

context. The results are summarized in Table 2 below.

Table 2. Summary of Applicative Index and Weighted Score.

For gaming, high indexes were given to runtime and system

memory as they are essential to ensure smooth gaming experience.

Memory attacks are also noted with high importance as these

involve cheating attempts within a game. Preventing side-channel

attacks are ranked lower as games are generally open with their

game mechanics and do not keep secrets within their software.

Military software are susceptible to Class 3 attacks, where attackers

have high motivation and large amounts of resources to perform an

attack. To maintain secrecy and information integrity in a military

software, preventing side-channel and memory attacks takes

priority over achieving runtime and optimizing memory use, giving

the former two high indexes and the latter two lower indexes.

Under DRM, security implementations must not drastically impact

the performance of the software, hence an index of 2 for both as

they are not the main priority. Preventing side channel attacks to

Effectiveness Score Justification

Runtime 2

By doing more actions to perform the

same task incurs a higher runtime and

memory use. However, depending on

the level of obfuscation carried out,

the runtime and memory usage can

vary. Good obfuscation schemes

minimizes runtime & memory usage.

Memory

Usage 2

Preventing

Side Channel

Attacks

3

Obfuscation aims to prevent leakage

of information by preventing

decompiliers from working.

Preventing

Memory

Attacks

0 Obfuscation cannot stop or detect

altered memories in the system.

Effectiveness Score Justification

Runtime 2

Runtime is somewhat impacted

through having to verify data with the

server.

Memory

Usage 2

Although this does not incur much

extra memory on the software client

terminal, it does use up memory on

the server. A huge amount of server

users can overload the server.

Preventing

Side Channel

Attacks

0 Server Mirroring does not prevent

reverse engineering.

Preventing

Memory

Attacks

2

With backup copies of its data on the

server, memory attacks can easily be

rectified. However, this method is

easily defeated by changing both the

client and server memory.

Effectiveness Score Justification

Runtime 0

Incredibly tedious to generate large

lookup tables for each stage of the

encryption. Large amounts of

calculations need to be done.

Memory

Usage 1

Creating large look-up tables hogs up

temporary system memory. However,

the memory usage is recoverable after

use and the scheme does not add

much more file size into the software.

Preventing

Side Channel

Attacks

3

Directly prevents side channel attacks

through using debuggers. Timing for

encryption is also constant, hence it

effectively stops one from reverse

engineering an application.

Preventing

Memory

Attacks

3

Memory attack will fail unless the

attacker knows the key and injects an

encrypted code.

Effectiveness Score Justification

Runtime 1

Constant on-access scanning slows

down runtime as file requests are all

checked before they can be executed.

Memory

Usage 3

Third party programs do not add onto

the software’s file size and can be

used across multiple softwares. Good

anti viruses do not hog up too much

memory to run.

Preventing

Side Channel

Attacks

0 Anti-viruses do not deter side channel

attacks.

Preventing

Memory

Attacks

2

Anti-viruses can detect most but not

all malwares or file that attempts

memory attacks on softwares.

Context

Applicative

Index Weighted Score of Techniques

Run

tim

e

Mem

ory

Usa

ge

Sid

e C

hn

l. A

tk.

Mem

ory

Atk

.

CR

C

Ob

fusc

atio

n

Cli

ent-

Ser

ver

Mir

rori

ng

Wh

ite-

Box

Cry

pto

gra

ph

y

An

ti-V

iru

s

Comp.

Games 3 2 1 3 1.25 1.08 1.33 1.17 1.25

Military

Use 1 1 3 3 1.58 1.08 0.83 1.58 0.83

DRM 2 2 3 1 1.17 1.42 0.83 1.17 0.83

57

obtain information is needed to stop attackers from reverse

engineering and removing the DRM restrictive feature. On the

other hand, memory attacks on the software usually target the

content of the software rather than removing DRM feature. Users

can do so, as long as they cannot perform unauthorized distribution.

From Table 2, we can see that Client-Server Mirroring would

benefit Games most, followed by CRCs and Anti-Viruses.

However, cheating gamers can always turn off their Anti-Virus,

rendering them ineffective, however, game platforms can introduce

similar mandatory third party software, such as the Valve Anti-

Cheating Platform on Steam [17], in place of Anti-Virus.

For military uses, unsurprisingly the high secrecy and secure

White-Box Cryptography and CRC should be adopted to prevent

serious class 3 software tampering attacks.

Lastly, obfuscation is the technique of choice when dealing with

DRMs as they effectively prevent reverse engineering without

compromising too much on performance.

7. CONCLUSION To summarize, this paper has provided some common software

tampering attacks as well as anti-tampering techniques. Through

considering requirements of some contextual applications, we have

concluded on techniques which are more suitable for such software.

Still, we acknowledge that our paper groups contextual applications

broadly in overly generic groups. Specific software within such

genres may vary in terms of susceptibility to different attacks,

making a different technique, possibly not mentioned in this report,

to be more suitable. However, our paper provide a decent overview

and general guide which would help a new software developer

decide how to implement anti-tampering on his or her software.

8. ACKNOWLEDGMENTS Our thanks to Prof. Hugh Anderson for his guidance and support

throughout the CS2107 module.

9. REFERENCES [1] Atallah, M. et al. (2004). A Survery of Anti-Tamper

Technologies. Arxan Technologies Inc. Retrieved 17 July

2016, from http://citeseerx.ist.psu.edu/viewdoc/download?

doi=10.1.1.642.1542&rep=rep1&type=pdf

[2] Benedetti, W. (2012). Hackers Slauter Thousands in ‘World

of Warcraft’. NBC News. Retrieved 19 July 2016, from

http://www.nbcnews.com/technology/ingame/hackers-

slaughter-thousands-world-warcraft-1C6337604

[3] Cheat Engine. (n.d.). About Cheat Engine. Retrieved 21 July

2016, from http://www.cheatengine.org/aboutce.php

[4] Collberg, Christian and Jasvir Nagra. Surreptitious Software.

Upper Saddle River, NJ: Addison-Wesley, 2010. Print.

[5] Comodo. 2016. How Antivirus Works. Retrieved 16 July

2016, from https://antivirus.comodo.com/how-antivirus-

software-works.php

[6] Cronin, E. et al. (2003). An Efficient Synchronization

Mechanism for Mirrored Game Architectures. University of

Michigan. Retrieved 21 July 2016, from https://www.comp.

nus.edu.sg/~bleong/hydra/related/cronin03efficient.pdf

[7] Cybersecurity Module for Computer Science Courses. (n.d.).

Buffer Overflow – “Don’t go out of Bounds” – CS2.

Retrieved 17 July 2016, from http://cis1.towson.edu/

~cssecinj/modules/cs2/buffer-overflow-cs2-c/

[8] Davis, S. (2009). Davis, Steven B. Protecting Games.

Boston: Charles River Media/Course Technology, 2008.

Print.

[9] Engebretson, P. (2013). Post Exploitation and Maintaining

Access with Backdoors, Rootkits, and Meterpreter. The

Basics Of Hacking And Penetration Testing, 167-185.

http://dx.doi.org/10.1016/b978-0-12-411644-3.00007-8

[10] Heasman, J. (2006). Rootkit threats. Network Security,

2006(1), 18-19. http://dx.doi.org/10.1016/s1353-

4858(06)70326-9

[11] How-To Geek. 2012. HTG Explains: How Antivirus

Software Works. Retrieved 16 July 2016, from

http://www.howtogeek.com/125650/htg-explains-how-

antivirus-software-works/

[12] Hugai, B. (n.d.). Introduction to Side Channel Attacks.

Retrieved 19 July 2016, from http://gauss.ececs.uc.edu/

Courses/c653/lectures/SideC/intro.pdf

[13] Jakubowski, M. et al. (2009). Tamper-Tolerant Software:

Modelling and Implementation. Microsoft Research.

Retrieved 19 July 2016, from https://www.microsoft.com/en-

us/research/wp-content/uploads/2016/02/jakubowski09tts.pdf

[14] Joye, M. 2008. On White-Box Cryptography. Retrieved 16

July 2016, from http://citeseerx.ist.psu.edu/viewdoc/

download?doi=10.1.1.700.7995&rep=rep1&type=pdf

[15] Keller, J. (2010). Anti-Tamper technologies seek to kepp

Critical Military Systems Data in the Right Hands. Retrieved

19 July 2016, from

http://www.militaryaerospace.com/articles/2010/04/anti-

tamper-technologies-seek-to-keep-critical-military-systems-

data-in-the-right-hands.html

[16] Schwartz, M. (2001). Reverse-Engineering. Computer

World. Retrieved 19 July 2016, from

http://www.computerworld.com/article/2585652/app-

development/reverse-engineering.html

[17] Steam. (n.d.). Valve Anti-Cheat System. Retrieved 22 July

2016, from https://support.steampowered.com/kb_

article.php?ref=7849-Radz-6869

[18] Treude, C. et al. (2011). An Exploratory Study of Software

Reverse Engineering in a Security Context. Retrieved 17

July 2016, from https://ctreude.files.wordpress.com/2011/08/

an-exploratory-study-of-software-reverse-engineering-in-a-

security-context.pdf

[19] Vanhoef, M. (2013). Understanding the Heap & Exploiting

Heap Overflows. Retrieved 21 July 2016, from

http://www.mathyvanhoef.com/2013/02/understanding-heap-

exploiting-heap.html

[20] Warren, Henry S. Hacker's Delight. Upper Saddle River, NJ:

Addison-Wesley, 2013. Print.

[21] Windows rootkits of 2005, p. (2016). Windows rootkits of

2005, part one | Symantec Connect. Securityfocus.com.

Retrieved 17 July 2016, from

http://www.securityfocus.com/infocus/1850, 2005

[22] Wyseur, B. 2012. Hiding Keys in Software. MISC magazine.

Retrieved 16 July 2016, from

http://www.whiteboxcrypto.com/files/2012_misc.pdf

[23] Zetter, K. (2016). Hacker Lexicon: What Is a Backdoor?.

WIRED. Retrieved 17 July 2016, from

https://www.wired.com/2014/12/hacker-lexicon-backdoor

58

10. Appendix A – Examples of Side-Channel

Attacks

10.1 Timing Attack An example a vulnerable code susceptible to timing attack is as

shown [14]:

To find out the password, an attacker can find out the password

character by character as the program will take longer to run if there

are more consecutive characters which are correct in the input.

10.2 Power Analysis Power analysis can reveal information about the intensity of actions

performed by the program. For example, Figure 5 shows the power

consumption of a DES encryption [14]. Clearly, the 16 spikes

observed correspond with the 16 rounds of encryption.

Figure 5. Power Analysis of DES encryption.

10.3 Differential Fault Analysis Differential Fault Analysis can be carried out in a variety of

methods. On encryption schemes, it is done by encrypting the same

information twice, but once with a fault that changes a 1-bit value

on the input [12]. This method can be applied onto the last round of

the DES encryption to obtain the 16th sub-key to allow once to

easily brute force the entire DES encryption key [12].

11. Appendix B – Examples of Code

Obfuscation

11.1 Layout Obfuscation Under layout obfuscation, one can replace variables with

meaningless names or mess up the formatting. An example is

shown in Table 3.1.

Table 3.1. Example of Layout Obfuscation.

Before Layout Obfuscation After Layout Obfuscation

double computeInterest

(double principal, double rate,

long time){

double interest;

interest=(principal*rate

*time)/100;

return interest;

}

do

uble cc(dou

ble a,double b, long

c){double

d;d

= (a*b*c)

/100;re

turn d;}

11.2 Data Obfuscation A way to carry out Data Obfuscation is to have split variables,

which in turn refer to the same thing. An example is shown in Table

3.2.

Table 3.2. Example of Data Obfuscation.

Before Data Obfuscation After Data Obfuscation

bool a,b,c;

a = true;

b = false;

c = a && b;

short a1,a2,a3,b1,b2,b3,c;

a1=true; b1=false;

a2=true; b2=false;

a3=true; b3=fales;

c=a1^(a2^a3) &&

b1^(b2^b3);

11.3 Control Obfuscation Under this, the program flow is intentionally broken up into sub-

branches with many cases, commonly using the “switch”

command. An example is shown in Table 3.3.

Table 3.3. Example of Control Obfuscation.

Before Control Obfuscation After Control Obfuscation

int multOfThree=3;

while(multOfThree <= 100){

printf(“%d”, multOfThree);

multOfThree += 3;

}

int direct = 1, multOfThree;

while(direct != 0){

switch(direct){

case 1:

multOfThree = 3;

direct = 2;

break;

case 2:

if(multOfThree

<=100){

printf(“%d”,

multOfThree);

direct = 3;

}else{

direct = 0;

}

break;

case 3:

multOfThree +=3;

direct = 2;

break;

}

}

11.4 Preventive Transformation Preventive transformation injects bad, redundant instructions to

prevent de-obfuscator tools from working. An examples is shown

in Table 3.4.

Table 3.4. Example of Preventive Transformation.

Before Preventive Transform After Preventive Transform

int list[100], I;

for(i=0;i<=99;i++){

list[i] = 0;

}

int extra[500], list[100],i;

for(i=99;i>=0;i--){

list[i] = 0;

extra[i] = extra[i+i/2];

}

59

60

Double-Spending & Related Attacks on BitcoinNg Ching Ann James

National University of Singapore 21 Lower Kent Ridge Road

Singapore 119077 +65 6516 6666

[email protected]

Joel Tan Xingyu National University of Singapore

21 Lower Kent Ridge Road Singapore 119077

+65 6516 6666

[email protected]

Xie Peiyi National University of Singapore

21 Lower Kent Ridge Road Singapore 119077

+65 6516 6666

[email protected]

ABSTRACT

Bitcoin, the most popular cryptocurrency globally, is the first

form of digital money that is maintained personally by users.

Despite Bitcoin’s worldwide popularity, its inherent design issues

and the absence of a central governing body have brought about

security vulnerabilities. In this paper, we present the double-

spending attack concerning Bitcoins, as well as related attacks.

Thereafter, we propose suggestions to mitigate these attacks,

considering feasibility and tradeoffs..

Categories and Subject Descriptors

K.4.4 [Electronic Commerce]: Security, Bitcoin network

General Terms

Security, Human factors

Keywords

Bitcoin, Security, Cryptocurrency, Blockchain, Double-Spending

Attacks

1. INTRODUCTION Bitcoin is a digital currency not issued nor regulated by a central

entity, was created in 2009 by Satoshi Nakamoto. Bitcoins can be

obtained from various avenues, including Bitcoin payments

received from buyers, purchasing bitcoins through Bitcoin

exchanges and taking part in Bitcoin mining [2]. Mining refers to

the use of computational power to verify Bitcoin transactions,

with new Bitcoins being generated in the process [2].

Figure 1: Verification of a Bitcoin transaction from a buyer to

seller [6]

In a Bitcoin transaction, the buyer first signs the transaction with

his private key as shown in Figure 1 above. To be sure that the

buyer owns the Bitcoins that he sent out, the seller signs the

transaction with the buyer’s public key to verify the transaction

prior to accepting it [6].

As Bitcoin and other cryptocurrencies gain popularity, there are

concerns over fast payment transactions where rogue users can

spend the same coins twice, thereby evading payment for services

acquired. In this paper, we present a typical double-spending race

attack together with several related attacks. We further include

countermeasures to resist double-spending race attacks for

vendors and Bitcoin developers.

2. BACKGROUND In a bitcoin transaction, a message is created with the new owner's

public key attached, and then signed with the private key of the

sender, which verifies that the message is authentic, and it comes

from someone who already has the bitcoins. The transaction is

then broadcast to the bitcoin network, allowing all Bitcoin users to

know that the new owner of the coins is the owner of the key in

the message.

The complete record of Bitcoin transactions is retained in the

block chain, which is a sequence of blocks or records. All

computers in the bitcoin network have a copy of the chain, which

is kept updated by passing blocks from one another. Each block

contains a record of all transactions sent before the latest block,

and through a hash function (SHA-256); each block verifies the

integrity of the preceding block. This block chain acts as ledger of

transactions for Bitcoin.

In order for a new block to be accepted by Bitcoin users, miners

produce a proof-of-work (PoW) to verify the transactions in the

block. Such a PoW is produced by the mining process in which a

nonce is produced such that when it is hashed with other fields

such as timestamps, the hash of previous block, the result is below

a target value. The difficulty of this process is adjusted such that

each block is generated approximately every 10 minutes.

What if more than one block has the same transactions? As blocks

are being created all the time, it is possible for multiple blocks to

point to the same parent block, and contain some but not exactly

the same transactions. In this case, the rule is to accept the

"longest" branch, or the branch that required the most time or

work to create.

As such, Bitcoin prevents users from performing a double-

spending attack by changing the block chain itself, since this

means that attackers not only have to change the transaction with

his own Bitcoins, he also have to change all subsequent blocks.

Given the difficulty in generating just one block, it is nearly

impossible for a single attacker to have sufficient computing

power to change the block chain.

61

3. DOUBLE-SPENDING ATTACKS

3.1 Motivation - Fast Bitcoin Payments Bitcoins are increasingly used for payments where fast service

time is needed, for example on vending machines and in

convenience stores. As of 26th July, 7995 venues are registered on

coinmap.org that accept Bitcoin payments, with many providing

fast payment services [3].

Fast payment by Bitcoins creates issues because the average time

needed to confirm a transaction, or the average block generation

time, is 10.38 minutes [5], with a large standard deviation of about

20 minutes [8]. It is impractical, however, for fast-payment

businesses to wait for Bitcoin confirmation before providing

customer services. Hence, businesses prefer to accept fast Bitcoin

payments without any confirmations provided transactions of

correct value are received from the Bitcoin network.

As such, it is possible for attackers to perform a double-spending

race attack by spending the same Bitcoins twice, exploiting

vendors who have insufficient time to check for confirmations of

Bitcoins received.

Figure 2: An illustration of double spending (adapted from [6])

Referring to Figure 2, the attacker initiates two transactions

involving identical Bitcoins, one with the vendor account and the

other with a helper account, which may belong to the attacker.

The vendor receives a Bitcoin transaction from the network and

believes it to be valid. However, the vendor’s transaction cannot

be redeemed afterward if the same Bitcoins that transacted with

the attacker’s helper account receive confirmation first.

Therefore, unlike traditional transactions using credit cards for

example, Bitcoin which has no centralized system to authorize

payments is vulnerable to uncertainty and security threats.

3.2 Requirements for Successful Race Attacks For double-spending race attacks to succeed, three requirements

must be met:

I. The transaction with the vendor must be added to

the vendor’s wallet. This means the vendor has to receive his transaction from the

Bitcoin network before the transaction that is sent to the attacker’s

account. If the attacker receives the transaction first, the

transaction to the vendor will be rejected, leading to failure of the

attack.

II. The transaction received by the attacker, not that

received by the vendor, gains confirmation. If the transaction

received by the vendor is confirmed first, the subsequent

transaction received by the attacker will be excluded from the

block chain. In this case, the attacker will have paid the vendor,

and the attack fails.

III. The vendor does not detect the attacker’s

misbehavior and identity within the service time. If the vendor

does not detect misbehavior from the attacker while together in

store, identifying the attacker afterward will be difficult since

Bitcoin accounts are anonymous and users can hold any number

of accounts.

Figure 3: Sequence of events for a successful double spending

race attack

3.3 Race Attack Evaluation

As all three requirements have to be satisfied for a successful

double-spending attack, it is thus important to evaluate the

probability of fulfilling each requirement and the factors affecting

them.

The factors affecting the success rate of double-spending attacks,

Ps, are:

1) The time interval ΔT between sending the transaction to

vendor TRv and sending the transaction to the helper TRh. A

time delay ΔT of positive value is needed to ensure that the vendor

receives his own transaction TRv first instead of TRh, satisfying

Requirement I. However, a larger ΔT leads to a lower Ps as

Requirement II will not be satisfied if ΔT is large enough to allow

TRv to be confirmed before TRh.

2) The number of helpers the attacker uses, Nh, to relay the

transaction TRh in the Bitcoin network. In general, a larger Nh

will lead to a higher Ps since the more the helpers; the higher the

chance of TRh being confirmed first as more peers in the network

receives TRh, not TRv, first.

3) The number of connections that the vendor has, C. A lower

C leads to a higher Ps because the lower the vendor’s

connectivity, the slower TRv spreads in the Bitcoin network than

TRh, thus satisfying Requirements I and II.

62

In order to satisfy Requirements I and II, an attacker can use a

relatively large number of helpers, Nh >= 2 and an intermediate

time interval, ΔT ~= 1, to increase the success rate Ps near to

100% provided that the number of the vendor’s connections C is

relatively smaller than the number of the helpers’ connections,

according to experiments conducted by Karame et al. If C is

approximately equal to the number of helpers’ connections, the

success rate decreases to about 60%. As a result, Requirements I

and II will be satisfied.

Satisfying Requirement III depends also on the service times of

business transactions. The service time has to be smaller than the

time it takes for the vendor to receive both TRv and TRh. For

typical vendors such as vending machines and take-away shops,

the average service time is 10 to 15 seconds. Subsequently, the

probability that the vendor detects misbehavior Pd equals the

probability that he receives both TRv and TRh after waiting 15

seconds. Pd is mainly affected by ΔT. The larger ΔT is, the lower

Pd will be. As such, to satisfy all three requirements, sets of (ΔT,

C, Nh) need to be identified such that Ps > Pd, where Pd refers to

the probability that he is discovered. Hence, there is substantial

incentive for attackers to perform a double-spending attack using

these sets of conditions. In fact, this allows the attacker to

simultaneously spend the same Bitcoins to multiple vendors at the

same time provided Nh is sufficiently large. However, this leads

to a higher Pd, as more recipients can receive both transactions

within their service time.

From the above analysis, there are indeed incentives for attackers

to perform double spending attacks involving fast payments since

the reward generally outweighs the cost. Even if misbehavior is

detected by the vendor, the attacker can strike at a different time

or choose to pay in full value.

For fast payment services involving a small amount of Bitcoins,

the incentives can be small for a single transaction. However,

since an attacker can double-spend multiple times or even target

multiple vendors at the same time with significant chance of

success, there remains a sizable threat for fast payment businesses

as the collective loss is significant.

For fast payment businesses, the simplest way to mitigate double-

spending is to obtain at least one confirmation before providing

services. However, given the nature of fast payment businesses, it

is not always feasible for fast payment vendors to await

confirmation as discussed before. In section 4, we discuss and

evaluate several possible solutions.

4. MITIGATING SUGGESTIONS In this section, we evaluate three possible solutions that fast

payment businesses can adopt to counter double-spending race

attacks: having a large number of connections and inserting

observers in the network. Furthermore, we present a

countermeasure by adopting double-spending alert messages.

4.1 Ensuring a large number of connections

to vendor As pointed out in section 3.3, a larger C, the number of

connections to vendor, will result in a reduced Ps, the success rate

of double-spending attacks, and a larger Pd, the probability that

the vendor receives both TRv and TRh after 15 seconds of waiting

time. As such, it can be argued that C can be used as a security

parameter that measures the resistance of a vendor to double

spending attacks. As such, one possible solution would be to

ensure a large number of peers are connected to the vendor to

resist double spending race attacks. If the number of connections

of the vendor is significantly large, the attacker would have to

invest in more helpers (increase in Nh) and increase the time

delay ΔT to increase his chances of success.

However, as the connections to any one node in the Bitcoin

network varies significantly, a vendor has to check constantly to

ensure that the number of connections does not fall below a

certain threshold.

Figure 4: Number of connections for 2 Bitcoin nodes over 6 days

4.2 Observers in the network In similar logic to the previous solution, the vendor can employ

helpful observers in the network which help transmit all received

transactions to the vendor. As a result, the vendor would have a

greater chance in receiving TRh within their service time, thereby

successfully detecting misbehavior before the attacker leaves.

However, as the attacker can increase time delay to lower the

chances that the observers receive TRh in time, the vendor would

have to employ about at least 3 observers to ensure at least one

observer can receive TRh in time, thus increasing the cost and

efforts required by the vendor.

4.3 Communicating Double Spending Alerts This countermeasure, devised by Karame et al., urges peers in the

network to relay an alert message to other peers when two

transactions using the same Bitcoins are received. This makes it

easier and faster for vendors to detect transaction misbehavior.

Furthermore, the vendor incurs no extra cost and attackers also

cannot evade the alert messages. However, an increase in the

number of transactions occurs in the Bitcoin network. This

decreases the performance of the network, making it prone to

other attacks such as Denial-of-Service attack.

To prevent transactions from increasing too much, as well as

nodes sending too many or false alerts, criteria for sending alerts

can be crafted:

1) Peers can forward only the first double-spending transaction.

2) Peers can send alerts only if there is proof of TRv and TRh

being correctly formed with legitimate signatures using the same

coins.

63

5. OTHER RELATED ATTACKS In section 3 we explored how a race attack is carried out. In this

section, we explore other attacks that resemble double-spending

attacks.

5.1 Timestamping Attack In a timestamping attack, or timejacking, the attacker causes the

target vendor’s network time to deviate from system time. As

mentioned above, each newly generated block contains a

timestamp that approximates the time of block creation. The

Bitcoin system uses the network time to validate newly received

blocks. If the timestamp of an incoming block is more than 2

hours after the current network time or earlier than the median of

the previous 11 blocks, the node automatically rejects the

incoming block.

Having rejected incoming new blocks, the target node becomes

isolated from the network next. The period when the isolated

target rejects all legitimate transaction confirmations is termed the

attack window. During this window, if the vendor relies on 0-

confirmation transactions, an attacker can filter out confirmations

of transactions of his helpers, TRh, from the target to perform a

successful double-spending attack for as long as the window

allows. The attack window will last until some honest nodes or

system operators intervene or the target node itself generates a

new block, thus providing the attacker greater incentives for

executing the attack.

Nevertheless, given the large amount of resources and computing

power needed for executing a timestamping attack, the rewards of

a double-spending attack can be small in comparison. As such, it

may be more worthwhile for the attacker just to use its computer

resources at hand to generate blocks legitimately.

5.2 Finney Attack Unlike a race attack, a Finney attack requires the attacker to have

access to a newly created block that has yet to be broadcasted. To

double spend, the attacker includes in this block a transaction sent

to himself, or a helper, TRh. The attacker then sends the vendor a

transaction using the same Bitcoins. The moment the attacker

receives his purchase, he broadcasts the double spending block,

thereby confirming his own transaction and overriding the

transaction with the vendor.

Executing a Finney attack successfully calls for patience and

careful timing on the part of the attacker. Firstly, a lengthy period

may pass before a block is found [1]. Additionally, the longer the

attacker waits for his goods to be delivered, the greater the

possibility that another miner locates and broadcasts an accurate

block, thus thwarting the attack [1]. Vulnerability to Finney

attacks follows three factors. Firstly, goods of value are sold

irretrievably while awaiting transaction confirmation. Secondly,

the attacker has a large timeframe to conduct attacks. Thirdly, the

purchase process is completed quickly in minutes [1].

A vulnerable entity to Finney attacks is an online store that sells

software for downloading over the internet. The store is interested

to provide software downloads instantly without accommodating

confirmation delays [1]. Being an online store, attackers can

choose any time of day to strike. Automated purchases are also

fast by nature, and coupled with software downloads being

unrecallable, this makes the online store an easy target for Finney

attacks [1].

On the other hand, a physical store such as a supermarket is more

resistant to Finney attacks. Purchased goods may leave the

supermarket permanently, but the time window for attackers to

purchase goods is constrained. Even if an attacker has significant

network mining power to find block, possible queues building up

at payment counters will disadvantage the attacker. This is owing

to the need to purchase as soon as possible after block discovery,

and longer queues increase the chance of attack failures [1].

5.3 Key guessing & collision attacks Having considered this, how about the simple theft of bitcoins

through accessing another’s account or generating the key for the

bitcoin account?

A Bitcoin address consists of a public key and private key. To

create a new address, a private key of RSA-256 bit is made, from

which the address, a 160-bit hash function, is computed and

derived. [10]

There are no limitations on the value of Bitcoin keys and

addresses that can be created. Thus, it is possible for 2 persons to

generate the same bitcoin address, allowing both accesses to funds

in that address. [11] Similarly, if someone can guess the private

key, they can gain access to that bitcoin account and all the

bitcoins that it contains.

However, the odds of generating an identical address are very

small. [6] Consider finding a collision in a low denominator

function of 160-bits, where there can be 2^160 = 1.4615016 x

10^48 permutations. 10^48! equals 1.46 quindecillion, or 1.46

trillion trillion trillion trillion. Assuming a computer processes at a

remarkably fast rate of 1000 addresses per nanosecond, this

translates to 10^12 addresses being processed per second, 3.1536

x 10^19 addresses being processed per year and 4.36 x 10^29

addresses being processed over the lifetime of the universe. This

figure remains 3.35 x 10^18 or 3 quintillion times less than the

number needed for a Bitcoin address collision to occur. With 160

bits, the probability of a Bitcoin collision has been shown to be

incredibly small. With RSA-256 bits, the probability of collision

is practically non-existent. Therefore, Bitcoin has a sound

cryptographic implementation.

With the large number of possible hashes for Bitcoin, a brute-

force attack is virtually impossible. However, attackers can resort

to less tedious dictionary attacks, capitalizing on the tendency of

people to use common phrases or words as passwords, or their

Bitcoin key. [7] Bitcoins have been stolen through this method,

which involves running words from a dictionary through various

hash functions to generate the private (key) and public (address)

key for that password. Once these keys are generated, they are

used by attackers online to check for matching Bitcoin addresses.

With both private and public keys present, the Bitcoin exchange

deems the activity to come from the user. Hence, the attacker who

generated the passphrase gains control of that particular bitcoin

address.

64

6. CONCLUSION All forms of currency face security issues, including

cryptocurrency such as Bitcoins. While Bitcoin faces poor

security implementation for digital wallets and human malpractice

issues just like any other normal currency, Bitcoin, as we have

seen, also contains inherent design limitations which make it

susceptible to double-spending attacks.

As discussed in this paper, the double spending attack can be

achieved in ways such as race attacks, Finney attacks and

timestamp attacks. Such issues are mainly due to design of the

Bitcoin system and should be considered by Bitcoin users and

developers to maintain security when engaging in Bitcoin

transactions.

Through assessing each attack mechanism, we came to the

conclusion that compared to a typical race attack, the cost for

attackers attempting Finney attacks and timestamping attacks is

significantly higher given their requirements for higher computing

power and resources.

As for countermeasures to prevent a typical double spending

attack from happening, simple solutions taken by the vendor can

be implemented, such as ensuring a large number of connections

or employing observers in the Bitcoin network for detecting any

misbehavior. Furthermore, as suggested by Karame et al, a

lightweight countermeasure making use of alert messages for

duplicate transactions can also be effective in preventing a typical

double spending race attack.

7. REFERENCES [1] Bitcoinj. (n.d.). Understanding the bitcoinj security model.

Retrieved July 23, 2016, from

https://bitcoinj.github.io/security-model

[2] Bitcoinwiki. (n.d.). Help:FAQ. Retrieved July 24, 2016, from

https://en.bitcoin.it/wiki/Help:FAQ

[3] Coinmap. (n.d.). Retrieved July 24, 2016, from

https://coinmap.org/welcome/

[4] Culubas. (2011, May 25). Retrieved July 24, 2016, from

http://culubas.blogspot.sg/2011/05/timejacking-

bitcoin_802.html

[5] Currency Stats Bitcoin currency statistics. (n.d.). Retrieved

July 24, 2016, from https://blockchain.info/stats

[6] How long would we have to wait to see a bitcoin address

collision? a LONG time. (n.d.). Retrieved July 24, 2016,

from https://bitcointalk.org/index.php?topic=1140945.0

[7] Is it possible to brute force bitcoin address creation in order

to steal money? (n.d.). Retrieved July 24, 2016, from

http://bitcoin.stackexchange.com/questions/22/is-it-possible-

to-brute-force-bitcoin-address-creation-in-order-to-steal-

money

[8] Karame, G. O., Androulaki, E., & Capkun, S. (2012).

Double-spending fast payments in bitcoin. Proceedings of the

2012 ACM Conference on Computer and Communications

Security - CCS '12. doi:10.1145/2382196.2382292

[9] Leavey, S. (2014, March 27). Part 2: The Crafty Design of

Bitcoin. Retrieved July 23, 2016, from https://the-

gist.org/2014/03/part-2-the-crafty-design-of-bitcoin/

[10] Moreno, M. (2013, May 6th). Bitcoin address collision.

Retrieved July 24, 2016, from

http://www.miguelmoreno.net/bitcoin-address-collision/

[11] What happens if your bitcoin client generates an address

identical to another person's? (n.d.). Retrieved July 24, 2016,

from http://bitcoin.stackexchange.com/questions/7724/what-

happens-if-your-bitcoin-client-generates-an-address-

identical-to-another-p

65

66

Case Study on NFC Technology of NUS Student Card

Adam Chin National University of

Singapore [email protected]

Daniel Low National University of

Singapore [email protected]

Lim Yi Hong National University of

Singapore [email protected]

Shee Zhi Xiang National University of

Singapore [email protected]

ABSTRACT This paper will discuss the background of Near Field Communication(NFC), and explain its usage and protocols. It will further examine the specifications of the NUS matric card, as well as highlight our findings in the investigation of the technology used, along with the data structure of the card.

General Terms Security, encryption, NFC, hardware, cryptography, authentication.

Keywords Nonce, LFSR, nested attack, darkside attack, MIFARE, PRNG, PROXMARK3, Crypto-1, tokenization.

1. INTRODUCTION NFC, or Near Field Communication, allows for wireless communication between two devices in close proximity. NFC tags and readers have a frequencies range of about 13.56MHz, with a reading range of 10cm or less. Due to the ease in transferring information, it is rapidly gaining momentum in the smartphone market. Two mobile devices can make use of NFC to exchange data and information by being next to each other (less than 10 cm apart), with one device being the transmitter(initiator) and one being the receiver(target), as seen by Figure 1. This is not limited to mobile devices either, as there are programmable NFC tags which can be placed in public places. These tags can be scanned by mobile devices to pass on information as well.

[21] Figure 1. Illustration of NFC communication There are multiple different tags for various NFC products, each with its own protocols and standards. The various tags are further elaborated in Appendix A. We will be discussing about the protocols associated with the MIFARE Classic 1k card, as it is used in the NUS Matriculation cards.

The MIFARE Classic 1k card is an 85.60 x 53.98 mm card that comes with 1kB of reprogrammable data (EEPROM) and an embedded antenna which uses the ISO14443A protocol for communicating with other NFC devices. The following sections will elaborate on the protocol and vulnerabilities of this card.

2. Applications of NFC 2.1 Modes of NFC There are three different modes of operation supported NFC devices: 2.1.1 Reader/Writer mode This mode allows NFC-enabled devices to read information that are written in NFC tags embedded in smart posters or displays. Furthermore, some NFC-enabled devices would be able to program or ‘write’ to a tag as well. [14] 2.1.2 Peer-to-peer mode In this mode, two NFC-enabled devices are able to communicate with each other to share data and information, such as files or photos [14]. 2.1.3 Card emulation mode NFC-enabled devices are able to act like smart cards, which would allow users to perform transactions with their devices via wireless connections [14].

2.2 Protocol, Standard and Encryption of MIFARE Classic 1k All NFC cards adhere to various standards and protocol. For example, each NFC card adheres to a communication protocol, either NFC-A, NFC-B, NFC-F. These protocols are further elaborated in Appendix B. Furthermore, there is an international standard for the manufacturing of NFC cards. For the MIFARE Classic 1k card, the international standard would be ISO/IEC 14443. Information on other international standards for NFC cards such as ISO/IEC 18092 is elaborated in Appendix C.

2.2.1. ISO/IEC 14443

67

The ISO/IEC 14443 standard defines four parts of international standards for contactless smart cards operating at a frequency of 13.56 MHz in close proximity within the range of 10 cm. This standard describes the modulation and transmission protocols used for communication between the card and the reader. There are two types of communication protocols supported by this standard: ISO/IEC 14443-A and ISO/IEC 14443-B [8]. 2.2.2. CRYPTO-1 The MIFARE Classic card employs a Crypto-1 cipher as a form of proprietary encryption. Crypto-1 consists of one 48-bit feedback shift register to maintain the state of the cipher, a linear function, a two-layer 20-to-1 nonlinear function and a 16-bit LFSR which is used as a pseudo random number generator during the authentication phase [11]. This encryption scheme was reverse engineered and cracked in 2008. 2.2.3. Authentication Protocol Before the reader and the tags transfer data or information, an authentication is carried out between the Tag and the Reader. This process is shown in Figure 2. First, the tag will be selected by the reader and sends its UID(u). Next, the reader will ask for the authentication of a specific memory block b. The tag will then send a challenge, {nT}, to the reader. The reader will send an encrypted response containing its own challenge, {nR}, and the answer, {aR}, to the tag’s challenge. Finally, the tag sends an encrypted message containing the reply to the reader’s challenge. {aT} [9]. This sequence of authentication is illustrated below in Figure 2.

[9] Figure 2. Authentication Protocol between Reader and Tag

2.3 Vulnerabilities of MIFARE Classic This section discusses the vulnerabilities for the MIFARE Classic card.

2.3.1. Key length

The key size used in MIFARE Classic 1K cards is 48-bits. Before Crypto-1 was cracked, brute force attacks had to be done with the reader connected to the online system. This introduced delays due to communication and authentication between the card and the reader, which caused brute force attacks to require an unfeasible amount of time. Hence, such a key size would be sufficient and considered secure. However, after Crypto-1 was cracked, an offline brute force attack could be executed with a local reader, which removed the delays [9]. This greatly reduced the time necessary for a brute force attack, which compromised the card’s security. 2.3.2. Predictable Nonces MIFARE uses a pseudo-random number generator(PRNG) to generate nonces for its authentication procedure. The nonces are 32-bits in length, however, it uses a 16-bit Linear Feedback Shift Register(LSFR) to generate the nonces. This means that the entropy of the any nonce would only 16-bits, and the nonces will be repeated every 2^16 - 1 times. Furthermore, the nonces can be predicted, as it was discovered that the LFSR is reset to a known state after it is powered down. All these factors caused the nonces required for authentication to be predictable [9]. 2.3.3. Nested Authentication Once the first sector is authenticated, an authentication request for a different sector can easily be sent. Although the communication is encrypted, the MIFARE card uses a weak PRNG, and hence predictable nonces as mentioned previously. This results in the nested authentication being vulnerable to a nested attack, as authentications for other sectors can easily be obtained, allowing hackers to recover the 32 bit keystream of the card.’ [9]. 2.3.4. Key stream leakage through parity bit During authentication, nonces are sent between the tag/card and the reader. If at least one of the eight parity bits is wrong, the tag/card does not respond. However, in the case when all eight parity bits are correct, but the answer to the challenge is wrong, the card replies with a 4-bit error code, indicating a failed authentication. The error code is encrypted, assuming that the tag/card would not be able to decrypt its value. However, 4-bits of keystream can be obtained by XOR-ing the encrypted error code with its plaintext value [9]. This vulnerability is exploited in the ‘Darkside attack’.

2.4 Types of MIFARE Attacks With the abovementioned vulnerabilities in the MIFARE Classic 1K card, there are various methods which people can use to crack your card and obtain your personal information. Some of the ways are: 2.4.1. Nested attacks A Nested attack on the MIFARE Classic cards is possible when one key of the card is already known. It can be carried out offline through a MIFARE offline cracker(MFOC) tool. The MFOC tool would use the known key to authenticate with the other card sectors and read the tag nonces. It does so in an encrypted session and then computes the number of LFSR shifts (output bit). It then guesses the next nonce value and calculates keystream 1, 2 and 3, before moving on to the next block [2]. 2.4.2. Darkside attacks

68

A Darkside attack on the MIFARE Classic card is used when no prior information about the card is known; ie. no keys are known. It can be done using the MIFARE classic universal kit(MFCUK). During authentication, when the reader sends {Nr} and {Ar}, the tag checks the parity bits before checking the correctness of Ar. If one of the eight parity bits is incorrect, the tag does not respond. • However, if all eight parity bits are correct, but the response Ar is incorrect, the tag will respond with a 4-bit error code 0x5 (NACK) indicating a transmission error. Moreover, this 4-bit error code is sent encrypted. • If the attacker combined (XOR) the error code 0x5 value (known plaintext) with its encrypted version, he can recover four keystream bits [4]. 2.5.3 Hardnested attacks Similar to the nested attack, the Hardnested attack is possible when one of the keys is already known. This attack is applicable to the newer Hardened MIFARE Classic 1K cards, which will be elaborated further in Section 3.4. As the PRNG in the newer cards are less predictable, this method is more similar to a brute force method, using the known key to reduce the number of possible keys for the targeted sector.

3. Cloning of NFC Cards In this section, we will describe how we used our knowledge of NFC to attempt to crack and clone a NUS Matriculation Card.

3.1 Old NUS Matriculation Card (2014) The NUS Matriculation card uses MIFARE Classic 1K, which is one of the most commonly used contactless card. MIFARE 1K card has 16 sectors, each contains four blocks and each block contains 16 bytes. The total memory size can be derived by doing a simple calculation, 16 x 4 x 16 bytes = 1024 bytes, which gives the card the name 1K. With reference to Figure 3, we can see that MIFARE 1K consist of 4 main categories:

• Card Serial Number (CSN) • Card Index Block (CIS) • Data • Site Key (Keys for each sector)

[22] Figure 3. Structure of MIFARE Classic 1K Card

The Proxmark3 was used to crack the NUS matriculation card issued in 2014, as it is able to execute both the ‘Darkside attack’ and the ‘Nested attack’. The Proxmark3 acts as a NFC reader or writer, and has various forms of attacks programmed in it. As we had no prior knowledge of any keys or information about the matriculation cards, we first tried the ‘Darkside attack’, as mentioned in Chapter 2.5.4. The image below, Figure 4, shows the result of the attack.

Figure 4. Valid Key Found

The ‘Darkside attack’ was able to retrieve one valid key, “a0a1a2a3a4a5”, which is a commonly used default key for all MIFARE 1K cards. Once we were able to retrieve the first key, we could execute the ‘Nested Attack’, as mentioned in chapter 2.5.3, to collect the remaining keys of each sector. Figure 5 below shows the result of the attack.

Figure 5. All the keys for A and B of MIFARE Card

With all the keys to each sector, we were able to read each sector’s information, and extract the data from the card. By analyzing this data, we noticed that the matric card number is stored in Sector 2 Block 4, which is the CIS sector, as seen in Figure 6 below.

69

Figure 6. The content in the NFC card, address 0x40 contains the student ID

3.2 Cloning of NFC Cards With the data extracted from the NUS matriculation card, we are able to attempt to clone the card by dumping the data into a Chinese Magic NFC card. 3.2.1 Chinese Magic NFC Card Chinese Magic NFC cards are unique cards compared to normal NFC cards. For NFC cards, sector 0 block 0, which contains the card’s UID and manufacturer information, is typically read only. To clone a NFC card, the UID would have to be copied over as well. However, with a normal NFC card, data cannot be written onto sector 0 block 0. Chinese Magic NFC cards allow users to both read and write to sector 0 block 0. This allows us to change the UID for the Chinese Magic Card [20]. 3.2.2 Cloning Result We were able to successfully clone the 2014 NUS Matriculation cards after dumping its data into a Chinese Magic Card. We tested it on entry and exits to the NUS school library and it was successful. 3.3 New NUS Matriculation Card (2016) During the course of our research, we have discovered that the newer matriculation cards (ie. cards issued to students in 2016) were harder to crack. These matriculation cards actually make use of hardened MIFARE Classic Cards, which have certain vulnerabilities fixed. From our research, we found out that these hardened cards implements a new PRNG, which made its nonces less predictable. Furthermore, these card no longer send out error codes regardless of the value of {Ar} [9]. For the hardened cards, both the ‘Darkside attack’ and the ‘nested attack’ are ineffective. With no information to start with, we tested commonly used default keys on the card to hopefully find a valid key, as manufacturers require cards to have 1 default key so everyone can read the MIFARE application directory, sector 0 block 0. We found out that nearly every sector was using a very common default key (a0a1a2a3a4a5), except sectors 1 and 2 (blocks 4-11). This is seen in Figures 8 and 9. However, to crack and clone the new matric card, we needed the keys to sectors 1 and 2, as these sectors hold all the details about the cardholder.

Figure 8. Sector 1 and 2 keys are not found for key A

Figure 9. Sector 1 and 2 keys are not found for key B

3.3.1 Hardnested attack In order to find the keys of hardened MIFARE cards, the Proxmark3 supports a feature called the Hardnested attack, which brute forces a number of keys based on the key of another block.The inputs this attack requires are: the key of another block, and the target block that we wish to crack. Using the previously found default key, we are able to use the Hardnested attack to retrieve the keys of block 4 and 8. By retrieving the keys for block 4 and 8, we would have access to sector 1 (blocks 4-7) and sector 2 (blocks 8-11). Figure 10 below shows the input required to execute the hardnested attack.

Figure 10. Command for hardnested attack After the command was entered, a brute force attack will be executed on block 8 of the MIFARE card. The time taken to crack the key is between 1 minute to 10 minutes. This is shown in Figure 11 and 12 below.

Figure 11. Valid key found A similar command is used for block 4, by changing the target block value to 4.

Figure 12. Valid key found The figure below, Figure 13, shows that the retrieved key is able to access the content of the block. This allows us to collect the information stored in the card to clone a new card.

70

Figure 13. Gain access with new key found

3.4 Summary - Comparison of New and Old NUS card The old NUS card uses MIFARE Classic 1K, which as mentioned above, is a common NFC-enabled tag, using a CRYPTO1 encryption. It contains 16 sectors, with each sector holding 4 blocks, with a memory of 16 bytes. The new NUS card uses the same model as the old NUS card, with both of them storing the student ID information in sector 2 of block 4 and the access privileges at sector 3 block 8. However the new NUS card uses the newer Hardened MIFARE Classic 1K which offers proper pseudo-random number generator, and does not send encrypted error codes after failed authentication. These two fixes to the vulnerability of the MIFARE Classic card resulted in the Hardened MIFARE Classic 1K to be much harder to be cracked.

4. Suggested improvements to NUS Matric card After reviewing the findings of the NUS Matric card, these are some suggested methods to prevent attackers from cracking the card. 4.1 Protocols to prevent attacks Firstly, we will look at other standards that are currently being used to enhance the security levels of card transactions. 4.1.1 Tokenization Tokenization is where data is replaced with a token, a piece of information that has no exploitable meaning or value. The token is an identifier that maps back to the original data through a tokenization system. The mapping is created such that the tokens are difficult to reverse without the tokenization system.[1] Similar to how e-commerce uses tokenisation, a system generated value could be stored into the student card which has no meaning without context. When read by the NUS card reader, the server would then map this value to the student identity stored in the system.[15] This way, attackers cracking the card would be unable to make sense of the data inside. However, keys are still easily obtainable and data in card can be cloned. 4.1.2 Increased Key Size and stronger encryption By increasing the key size for the encryption, it would be more difficult to obtain the key needed to decrypt the data. For example, MIFARE Plus supports 128-bit keys compared to MIFARE Classic’s 48-bit CRYPTO-1 keys.[17] This gives about 10^24 times more keys to choose from, requiring a lot more resources for brute force attacks.[5] This deters attackers from decrypting the card to obtain the data inside.

4.1.3 Use stronger encryption Furthermore, with the larger key size of 128-bit keys, stronger encryption methods such as AES encryption can be implemented. By making the encryption more complex, attackers will find it more difficult to derive the key and will have to resort to more inefficient attacks such as brute force attack.[16] On top of the large key size, attackers will require large amounts of computing power and time to obtain the key. [19] 4.1.4 Use a proper random number generator Any time the card is powered up, the LFSR resets to a known state. By keeping time constant between powering up and requesting a nonce Nr from the card, the nonce Nr sent will be constant. Using a proper random number generator will ensure Nr sent will be random, preventing attackers from exploiting this vulnerability [10]. 4.2 Recommendation for new student card Despite having proper random number generation and disabling authentication error codes, attacks on MIFARE 1K classic cards have been successful where secret keys were recovered in minutes.[9] Furthermore, tokenisation and tamper-proofing the card does not prevent it from being read and cloned.[18] As such, the best way to improve the security of the data stored in student cards is to increase the key size and use stronger encryption such as AES encryption. 5. CONCLUSIONS In conclusion, we have given a explained basic information about NFC by explaining its protocols and other background knowledge. We elaborated on the vulnerabilities a MIFARE Classic type card may possess, as well as the different type of attacks carried out on such cards. We also succeeded in cracking our NUS Matriculation cards, and discovered there were changes to the newest issues of cards. However, due to the the cards suffering the same weakness of its crypto-1 cipher, we were still able to hack into our group members new card. 6. ACKNOWLEDGMENTS We would like to thank Professor Hugh Anderson for this opportunity explore the technology behind NFC cards, and providing us various readers and chinese cards so that we could carry out our research on the NUS Matriculation cards.

7. REFERENCES 1. A. Craft, C. (2013). Credit Card Tokenization 101 — And Why it’s Better than Encryption. 3dsi.com. Retrieved from http://www.3dsi.com/blog/credit-card-tokenization-101 2. Almeida, M. (2014). Hacking Mifare Classic Cards. Retrieved from https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Almeida-Hacking-MIFARE-Classic-Cards-Slides.pdf

71

3. Alshehri, A. & Schneider, S. (2014). Addressing NFC Mobile Relay Attacks: NFC User Key Confirmation Protocols. Retrieved from http://infonomics-society.org/wp-content/uploads/ijrfidsc/published-papers/volume-3-2014/Addressing-NFC-Mobile-Relay-Attacks-NFC-User-Key-Confirmation-Protocols.pdf 4. Cloning a MiFare tag: about the attacks. (2014). Retrieved from https://pmo.io/blog/cloning-mifare-about-the-attacks.html 5. Ducklin, P. (2013). Anatomy of a change – Google announces it will double its SSL key sizes. Naked Security. Retrieved from https://nakedsecurity.sophos.com/2013/05/27/anatomy-of-a-change-google-announces-it-will-double-its-ssl-key-sizes/ 6. Foreman, C. (2011). Near Field Communications: a technology primer. Ars Technica. Retrieved from http://arstechnica.com/gadgets/2011/02/near-field-communications-a-technology-primer/2/

7. Host Card Emulation. (2014). Retrieved from http://www.smartcardalliance.org/wp-content/uploads/HCE-101-WP-FINAL-081114-clean.pdf 8. ISO14443 - NFC Tools. (2015). Nfc-tools.org. Retrieved from http://nfc-tools.org/index.php?title=ISO14443 9. Meijer, C. & Verdult, R. (2015). Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards. Retrieved from http://www.cs.ru.nl/~rverdult/Ciphertext-only_Cryptanalysis_on_Hardened_Mifare_Classic_Cards-CCS_2015.pdf 10. Merhi, M., Cesar Hernandez-Castro, J., & Peris-Lopez, P. (2011). Studying the Pseudo Random Number Generator of a low-cost RFID tag. Retrieved from http://lightweightcryptography.com/wp-content/papercite-data/pdf/c22mhp2011.pdf 11. Nohl, K. (2008). Cryptanalysis of Crypto-1. Cs.virginia.edu. Retrieved 24 July 2016, from https://www.cs.virginia.edu/~kn5f/Mifare.Cryptanalysis.htm 12. What are the operating modes of NFC devices? - NFC Forum. (2013). NFC Forum. Retrieved from http://nfc-forum.org/resources/what-are-the-operating-modes-of-nfc-devices/

13. :: PGP GROUP ::. Pgpgroupltd.com. Retrieved from http://www.pgpgroupltd.com/rfid1k.php(Zhixiangs source)(for the part after intro) 14. Thrasher, J. (2013). RFID versus NFC: What's the difference between NFC and RFID?. RFID insider. Retrieved from http://blog.atlasrfidstore.com/rfid-vs-nfc 15. Paper, White. "Voltage Secure Stateless Tokenization". N.p., 2016. Web. 25 July 2016. Retrieved from https://www.voltage.com/wp-content/uploads/Voltage_White_Paper_SecureData_SST_Data_Protection_and_PCI_Scope_Reduction_for_Todays_Businesses.pdf 16. Rouse, Margaret. "What Is Rijndael? - Definition From Whatis.Com". SearchSecurity. N.p., 2016. Web. 25 July 2016. Retrieved from http://searchsecurity.techtarget.com/definition/Rijndael 17. "MIFARE Plus S 4K|NXP". Nxp.com. N.p., 2016. Web. 25 July 2016. Retrieved from http://www.nxp.com/products/identification-and-security/smart-card-ics/mifare-ics/mifare-plus/mainstream-contactless-smart-card-ic-for-fast-and-easy-solution-development:MIFARE_PLUS_S_4K 18. Mast, Trevor. "Tokenization, EMV, NFC, HCE, MST – What Does It All Mean To Me? | Payments Leader". Paymentsleader.com. N.p., 2016. Web. 25 July 2016. Retrieved from http://www.paymentsleader.com/what-does-it-all-mean-to-me 19. "Learn Cryptography - Brute Force Attack". Learncryptography.com. N.p., 2016. Web. 25 July 2016. Retrieved from https://learncryptography.com/cryptanalysis/brute-force-attack 20. FuzzySecurity | RFID Kit. Fuzzysecurity.com. Retrieved from http://www.fuzzysecurity.com/tutorials/rfid/1.html 21. NFC Verification IP. Smart-dv.com. Retrieved from http://www.smart-dv.com/vip/nfc.html 22. How to configure MIFARE card memory layout | Suprema. Supremainc.com. Retrieved from https://www.supremainc.com/en/node/477

23. Hubers, E. (2015). Retrieved from https://commons.wikimedia.org/wiki/File:NFC_Protocol_Stack.p

8. APPENDIX 8.1 Appendix A – NFC Tag Type

72

Figure 14. ISO and Protocol for NFC [23]

73

8.2 Appendix B – Signal Technologies of NFC

Most NFC devices follow a similar protocol to communicate, NFC-A, NFC-B and NFC-F. 8.2.1. NFC-A NFC-A uses a ISO/IEC 14443A standard and delay encoding with amplitude modulation at 100%. Delay encoding is a 2 level signal where change in levels during a period is “1” and no change in levels is “0” [6]. 8.2.2. NFC-B NFC-B uses a ISO/IEC 14443B standard and Manchester coding with amplitude modulation at 10%. Manchester coding is a 2 level signal where signal changing from 90% to 100% depicts “0” and 100% to 90% depicts “1” [6]. 8.2.3. NFC-F NFC-F uses Sony FeliCA JIS X 6319-4 and uses Manchester coding similar to NFC-B, but communicates faster and is used more widely [6].

74

8.3 Appendix C – International Standards 8.3.1. ISO/IEC 18092

The ISO/IEC 18092 standard specify the modulation schemes, transfer speeds, coding and frame format of the RF interface of NFC-enabled devices. During the initialization for both passive and active NFC modes, this standard plays a role in defining the initialization schemes and the conditions required for data collision-control.

8.3.2. ISO/IEC 7816 ISO/IEC 7816 is a multi-part international standard divided into fourteen parts. ISO/IEC 7816-4 Part 1, 2 and 3 deal only with contact smart cards. They define the various aspects of the card and its interfaces. ISO/IEC 7816-4 Part 4 to 9, 11, 13 and 15 are relevant to all types of smart cards. They define the card’s logical structure, various commands used by the application programming interface for basic use, application management, biometric verification, cryptographic services and application naming. ISO/IEC 7816 Part 10 is used by memory cards for applications such as pre-paid telephone cards or vending machines. ISO/IEC 7816 Part 7 defines a 2 secure relational database approach for smart cards based on the SQL interfaces. (SCQL).[7]

8.3.3. FeliCa / JIS X6319-4 The JIS X6319-4 specifies the physical characteristics, transmission protocols, file structure and commands of high-speed contactless proximity integrated circuit cards. This standard is used in Japan, produced by Sony. FeliCa is a contactless card that is used mainly in Japan, for public transport and micro Payments.

75

76

Electronic Voting Protocols Guo Jiaqi

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected] Li Yinan

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected]

Han Xue School of Computing

National University of Singapore 13 Computing Drive Singapore 117417

[email protected] Yan Hongwei

School of Computing National University of Singapore

13 Computing Drive Singapore 117417

[email protected]

ABSTRACT

In this paper, we describe and compare different classes of

electronic voting protocols.

1. INTRODUCTION Electronic voting is the process in which electronic devices are

involved. In this paper, we focus on the voting where direct

recording electronic (DRE) voting machines are used. In this type

of electronic voting, the voting machine is responsible for both vote

casting and tallying, and votes are not recorded in any physical

media. The integrity of voting entirely depends on the voting

machines, hence careful design of voting protocol is required to

achieve a successful voting. Depending on the security and privacy

requirement of the voting, voting protocols used in electronic

voting can be classified to three types: hidden voter, hidden vote

and hidden voter with hidden vote. This method of classification is

suggested by Sampigethaya, K. and Poovendran, R. Each class of

voting protocols has various ways of implementation. In the next

few sections, we will introduce purpose behind each class of

protocols, show one way of implementation and evaluate its

properties.

2. PRELIMINARIES Before we start introducing different classes of voting schemes,

some background of voting and cryptography is explained here.

2.1 Voting process Voting usually includes the following stages:

Announcement stage: Authority announces protocols used in the

voting, eligibility of voters and other necessary information.

Registration stage: Eligible voters register with the authority.

Voting stage: Voters submit their votes.

Tallying stage: Authority computes the voting result and publish

the result.

2.2 Requirement of voting protocol In general, there following properties are desired to achieve in a

voting protocol:

Eligibility: There must be a system to verify who the voters eligible

to vote are.

Privacy: In some voting, the choice of a voter should be only visible

to himself/herself.

Verifiability: There should be a way to verify the vote recording

and tallying process.

Dispute-freeness: The protocol should be able to resolve disputes

in any stage of voting.

Accuracy: The protocol should be able to ensure that all valid votes

are correctly recorded and counted.

Fairness: There should be mechanism to prevent voter or authority

computing partial tally before the voting is over.

Robustness: The protocol should be able to prevent attack from

voters, authorities or third party.

Receipt-freeness: The voters should not be given any evidence to

prove to another party that he has made certain vote. This is to

prevent partial tally and vote buying.

In addition to the features listed above, it is desirable for the voting

protocol to be suitable for large scale elections. Factors such as

computation complexity may make a voting protocol unsuitable to

implement in large scale.

A careful survey of the requirements above will find that some of

these requirements are conflicting. For example, privacy of the

voter might be sacrificed for verifiability. Therefore, it is up to the

voting authority to decide which requirement to be prioritised.

2.3 Cryptographic concepts Finally, there are some cryptographic terms and techniques that are

commonly used for electronic voting protocols

Bulletin board: It is a publically accessible board where

information such as list of candidates and voting record are stored.

Interactive proof: It is the process used to proof identity of the voter

by interacting with the authority.

Secret sharing: In a voting where secret sharing is used no single

authority is holding complete information. For example, the vote

casted by the voter is divided to parts, and held separately by

multiple authorities. The vote can be recovered only if these

authorities combine their information.

Homomorphic encryption: It is the encryption technique where

given two ciphertext 𝑐1 and 𝑐2, which are obtained from plaintext

𝑚1 and 𝑚2 , we can get ciphertext 𝑐1 + 𝑐2 directly without

decrypting them individually.

Public key cryptosystem: It is the type of cryptographic technique

which uses different keys in encryption and decryption process.

The receiver of the message generates a pair of keys 𝑘𝑝𝑢𝑏 and𝑘𝑝𝑟𝑖,

then he announces 𝑘𝑝𝑢𝑏 publicly and keep 𝑘𝑝𝑟𝑖 secretly. Anyone

can use 𝑘𝑝𝑢𝑏 to encrypt a message but it can only be decrypted

with 𝑘𝑝𝑟𝑖 . Common public key cryptosystems are RSA and

ElGamal cryptosystems

77

Mixnet: Mixnet in the technique that provides anonymous channel

of communication. It allows voter to communicate with authority

without relieving his identity. In order to perform anonymous

communication, two types of mixnets are required.

Decryption mixnet: This should be used when voter send message

to authority (or bulletin board). The voter attach a random string R

to his message M and encrypt it with the public key of the mix K.

Then the mix uses its private key to decrypt𝐸𝐾(𝑅, 𝑀), removes the

random string, and send the message to the authority. In order to

hide the identity of sender, the decryption is only performed for a

series of messages, hence no link between 𝐸𝐾(𝑅, 𝑀) and M can be

found. Essentially, the mix permute the order of the messages when

it performs decryption. Using a series of mixes, which forms a

mixnet, will provide better anonymity for voters.

Re-encryption mixnet: This is used mainly for the authority to

communicate back to the sender without being able to identify the

identity of voter. The voter encrypts his address M with 𝐸𝐾(𝑅, 𝑀)

like previously and send it with his message. When the authority

replies the message, it replies to the encrypted address via the re-

encryption mixnet. The mixnet will work in the same manner as in

the previous paragraph, and deliver the message to the voter.

Blind signature: This is the technique used to prove eligibility of

voter to the authority without revealing it. It has various ways of

implementation, but the general idea is to separate identification of

voter and actual balloting to two steps. The voter first proves his

identity to the authority or trusted third party to obtain a signature,

then anonymously submit his vote with the signature. The voter

should not be able to be traced from the signature.

3. HIDDEN VOTER PROTOCOLS In this class of voting schemes, the voters send their votes

anonymously to tallying authorities through an anonymous channel

such as mixnet. The content of the vote need not be encrypted in

this process. The tallying authority will receive a set of votes at the

output of the anonymous channel. As a result, at the tallying stage,

anyone is able to compute the tally, but the votes cannot be traced

back to the voter.

3.1 Example Scheme

Below is one of implementation of hidden voter protocol proposed

by Sako and Killian. It is a bulletin board based scheme. In a

bulletin board based scheme, votes and tallying results are

published on a publically accessible bulletin board. General steps

of this protocol is shown in Figure 1.

Announcement stage: The public key (using ElGamal cryptosystem)

of the anonymous channel, 𝐾 = 𝑔𝑠 = 𝑔∑ 𝑠𝑖𝑙𝑖−1 is announced, where

parameters are set up as required in E1Gamal cryptosystem. Then

every mix, 𝑚𝑖𝑥𝑖 generates a public key, private key pair (𝑔𝑆𝑖 , 𝑆𝑖).

Registration stage: in the order of re-encryption mixnet, each mix,

𝑚𝑖𝑥𝑖 performs the following for each voter: It takes input

𝐸𝐾(𝑣𝑓, 0) = (𝑔0, 𝐾0𝑣𝑓) for all choices of candidates, which is

represented by 𝑣𝑓 , f spans across all the candidates. Then it

commits a random permutation 𝜋𝑖,𝑗 to voter 𝑉𝑗 using 𝑉𝑗 ’s public

key. Then it uses a random string 𝑟𝑖,𝑓 to re-encrypt the votes as

𝐸𝐾(𝑣𝑓, ∑ 𝑟𝑎,𝑓 + 𝑟𝑖,𝑓𝑖−1𝑎=1 ). Then 𝜋𝑖,𝑗 is applied to these re-encrypted

votes to get a random permutation. After this, it posts a proof of

correctness of the process on a bulletin board. Finally, it uses

untappable channel to send the permutation to voter 𝑉𝑗 .

Now the voter 𝑉𝑗 can use his personal 𝜋𝑖,𝑗 to trace back actual votes,

but this can only be done by himself because the permutation is

need in tracing.

Voting stage: all voters choose their encrypted votes and submit it

to the first mix. The decrypted mixnet will process all the votes.

Each mix posts non-interactive proofs of correct mixing

(decryption and permutation) on the bulletin board. The last mix

will output the decrypted vj’s on the bulletin board.

Figure 1. Hidden Voter Protocol

78

This scheme mainly achieves eligibility, privacy, a certain degree

of fairness, universal verifiability and accuracy properties. Only

voter himself can establish the link between his vote and encrypted

vote at output of mixnet, hence his privacy is well protected. Since

people can check their votes through the verifiable mixnet and the

publicly accessible bulletin board, it achieves accuracy. However

the massive communication and computation to achieving

universal verification makes it unscalable and inefficient.

Meanwhile the using of untappable channel realized receipt-free

property. And robustness and fairness properties can be achieved

until the last mixes, because the votes are published after all votes

voted which are decrypted by mixnet instead of tallying authority.

But if anyone complains the fairness of the election, a re-election is

also inevitable. Receipt-freeness property is satisfied assuming

one-way untappable channels, since the voter cannot prove its vote

to adversary. However the bulletin scheme in Sako and Killian

(1995) has a critical weakness, any single non-participating mix in

the decryption mixnet can cause failure of election, so this theme is

lack of robustness to a certain extent.

4. HIDDEN VOTE PROTOCOLS In hidden voter electronic voting schemes, voters anonymously cast

their votes without encryption on the vote. In secret balloting

elections, votes are supposed to be kept secret, hence we need

another class of voting protocols -- hidden vote protocols. In hidden

vote protocols, voters can openly submit their votes, but the votes

are encrypted, and can only be decrypted during tallying stage. A

simplified overview of this genre of voting scheme can be

described as the following. An eligible voter submits his/her

encrypted vote as well as the proof for validity to a specific section

on the bulletin board. Then the voting authority(ies) collects all the

valid votes and computes the tally result. Finally the result as well

as its proof is posted on the bulletin board for public view. Usually

some common techniques, such as homomorphic encryption and

secret sharing, are also integrated into this kind of schemes in order

to achieve some desirable properties like privacy, verifiability,

accuracy, fairness and robustness.

Now we introduce a hidden vote scheme proposed by Benaloh. The

main idea of it is also illustrated in Figure 2.

The cryptosystem used in this scheme is based on the rth residuosity

assumption and it possesses additive homomorphism. In the

announcement phase, each authority randomly chooses two large

prime numbers p, q and a prime r such that r | (p-1). It also calculates

the product n = pq. Then a number K satisfying both (i) gcd(K, n)

= 1 and (ii) there does not exist an integer x such that 𝐾 ≠ 𝑥𝑟 ∀𝑥 ∈𝑍𝑛

∗ is selected as the public key for that authority. Then the triple

(K, r, n) is released to voters with other parameters kept secret

within the authority.

In the registration phase, a voter 𝑉𝑗 constructs his/her vote ballot by

encrypting both a yes vote and a no vote and put them in a capsule

in random order. The encryption process is as the following:

𝐸𝐾(𝑣𝑗 , 𝑢𝑗) = (𝐾𝑣𝑗 𝑢𝑗𝑟)(𝑚𝑜𝑑 𝑛) , where 𝑣𝑗 ∈ {0, 1} representing

the content of the vote and 𝑢𝑗 is randomly chosen by the voter from

the set Z𝑛∗ = {integers x: 0<x<n and gcd(x, n) = 1}. An interactive

proof is required to demonstrate the validity of the ballot a voter

generates before he/she can cast a vote. This is done by sending the

encryption of both 0 and 1 votes in a random order to the authority.

The authority will check the validity of the encryption by sending

a challenge to voter, at the end of proof, authority returns

encryption of both his vote choices. The interactive proof adopted

here makes it possible to probabilistically prove the validity of a

vote ballot without leaking the information of its content. This Figure 2. Hidden Vote Protocol

79

technique thus helps to achieve both verifiability and accuracy

without sacrificing privacy.

In the voting phase, a voter designates one of the two votes in the

ballot as the casting vote. Every valid vote is then segmented into

shares and distributed among the voting authorities. This

mechanism can help to improve the robustness and fairness of the

voting scheme, because a single authority does not have complete

information of any particular vote hence it is unable to decrypt the

vote on itself.

Finally in the tally phase, each voting authority first calculates a

partial sum using the vote shares it receives, and then authorities

collaborate together to calculate the final voting result which is later

released on the Bulletin Board. Note that since a homomorphic

cryptosystem is used for encrypting votes, the authorities can

compute tally directly from encrypted votes without decrypting

each votes, hence the content of each vote is not compromised in

this tally phase. An interactive proof for the result is also publicly

posted for verification purposes.

However given all the advantageous properties this voting scheme

has achieved, it also suffers from some specific limitations. Firstly,

the starting of voting phase depends on the termination of

registration phase, which means that a voter has to wait until every

other voter completes his/her interactive proof of vote ballot

validity before he/she can really cast a vote. Another disadvantage

of this scheme is the intensive computation and communication

involved in the interactive proof processes. This kind of

inefficiency will possibly reduce its real world scalability due to

realistic time and resource constraints.

5. HIDDEN VOTER HIDDEN VOTE

PROTOCOLS From the name of this class, is obvious that it is the combination of

Hidden voter and Hidden vote. This class of voting protocols

protect the identity of voter and keeps the votes secret.

Here we introduce a token based HVHV scheme proposed by

Fujioka, which is a token based scheme. Figure 3 shows the flow

of this scheme.

At the initialization stage, voter produces a key k, which is only

known by himself, encrypts his votes as𝐸𝐾(𝑣, 𝑘), and sent it to the

registration authority to get the signature of the authority. By doing

this, the authority is unable to know the vote v since it is encrypted

by the voter.

During the registration stage, the voter obtains a blind signature on

an encrypted vote 𝐸𝐾(𝑣, 𝑘) from a registration authority

as𝑠𝑖𝑔𝑛𝐴(𝐸𝐾(𝑣, 𝑘), 𝐾𝐴−1). At this stage, the identity of the voter is

verified by the authority, and thus the voter is proved that he/she

have right to vote. However, the authority is unable to view the vote

v, as it is encrypted by the voter;

The voter then post his/her signed encrypted vote anonymously on

the bulletin board as 𝐸𝐾𝑚(𝑠𝑖𝑔𝑛𝐴(𝐸𝐾(𝑣, 𝑘), 𝐾𝐴−1));

After all votes have been submitted, the decryption mixnet will

decrypt all votes using the public key 𝐾𝑚, and passes all decrypted

votes to tally authority as 𝑠𝑖𝑔𝑛𝐴(𝐸𝐾(𝑣, 𝑘), 𝐾𝐴−1);

Tally authority then verifies its signature with the private key 𝐾𝐴−1

and then unbinds the encrypted votes as 𝐸𝐾(𝑣, 𝑟);

Voters send their key K that they produced at the initialization stage

to the tally authority anonymously; Figure 3. Hidden Voter Hidden Vote Protocol

80

After that tally authority obtains the private key 𝐾−1 from all voters

to decrypts the votes as 𝐷𝐾(𝐸𝐾(𝑣, 𝑘)) = 𝑣, it is able to computes

the tally sum(v);

As a combination of hidden voter and hidden vote schemes, HVHV

inherits their properties. Privacy problem is the biggest

disadvantage in hidden vote scheme as voters do not vote

anonymously. In hidden voter scheme, the serious drawback lack

of fairness, as partial tally is leaked before the counting stage.

HVHV combined both two schemes to solve these problems.

The privacy of the voters is preserved through the whole voting

event, since blind signature technique is used. The encrypted vote

will be opened by the voters just before the tally stage, nobody even

authorities are impossible to know the partial tally before the end

of the election procedure. Thus, maximum fairness is achieved.

However, addition of hidden voter and hidden vote also increased

the complexity of the scheme. This perfect-fairness property also

leads to impractical problem. If we take a look at the step 5 in fig.1,

we notice that this step requires all voters to participate in the

tallying stage to decrypt their votes. It is extremely time-consuming

if we held a large scale of election. In addition, lacking of accuracy

and robustness is the main leak of this scheme. Even though

registration authority is incapable to know who the voter is, it

whereas can detect abstainee (valid voter but does not register).

This allows any authorities to forge the vote and add them to

themselves, which is undesirable. Lastly, collusion between the

voter and the registration authority can cause eligibility problem, as

the registration authority can sign for anyone even he/she is not a

valid voter.

To address the problem of inaccuracy and un-robustness problem,

another token based scheme is proposed in Juang et al. (2002). In

this scheme, the token is enforced by adding electrical tag, ID and

the voter’s signature. By doing that, the problem of accuracy and

robustness is been addressed, as no one can forge the abstainee’s

vote since it requires the abstainee’s ID and signature. Moreover,

this scheme also solve the eligibility problem. Instead of just

employing one registration authority to verify voters’ identity, this

scheme now sets a group of registration authority. Each Voter has

to gain a required number of the registration authorities’ signatures

to verify his/her identity. By doing this, the collusion problem

between voter and registration authority is avoid. However, the

inherent impractical property of HVHV still cannot be addressed

by this scheme, as at the tally stage, all voter still has to participate

to decrypt their votes.

6. EVALUATION

6.1 Comparison between Voting Protocol

Classes In the previous three sections, we introduced three different classes

of electronic voting protocols and gave an example to each class.

The property of the protocol can be affected by the implementation

of the scheme, hence a good scheme is able to achieve more

desirable properties. It is worthy to note that in general, when a

protocol aims to achieve more properties, it become more complex,

hence it becomes less practical to be used in large scale election.

However, those complex protocols may still be used in small scale

voting, where both privacy of voters and content of the vote should

be protected.

6.2 Link to Real World In many countries, election law explicitly requires secret balloting,

hence hidden voter is a required property. At the same time, leaking

of partial tally before end of voting stage can cause unfairness of

election, hence hidden vote is also desirable. Although proposed

HVHV protocols suits the need of most of elections, it is not

practical to implement because it requires cooperation of all parties

in tallying stage. There are a few countries such as France, Canada

and Norway trying to use DRE for their elections, however, the

security of the systems used remains questionable.

7. CONCLUSION These three classes of voting protocols satisfy different groups of

requirement of a voting process. We should note that even if we

get a perfect protocol, there can still be human errors during its

actual implementation and execution, which will cause unfairness

of voting. Furthermore, promoting these protocols to the public will

also be a challenge, because they are more complicated than

conventional voting methods. Therefore, electronic voting

protocols are still at developing phase, and improvements are

needed before it can be widely applicable.

8. REFERENCES [1] Bellovin, R. Cryptography: Authentication, Blind Signatures,

and Digital Cash. Retrieved July 20, 2016, from:

http://wwwf.imperial.ac.uk/~rbellovi/writings/chaum.pdf

[2] Benaloh, J. D. C. (1987). Verifiable secret-ballot elections

(Order No. 8809191). Available from ProQuest Dissertations

& Theses Global. (303644517). Retrieved from:

http://libproxy1.nus.edu.sg/login?url=http://search.proquest.c

om.libproxy1.nus.edu.sg/docview/303644517?accountid=13

876

[3] Chaum, D.L. Untraceable Electronic Mail, Return Addresses,

and Digital Pseudonyms. in Rivest, R. ed. Communications

of the ACM, 24(2). 84-88.

[4] Fujioka, A. Okamoto, T. and Ohta.K. A Practical Secret

Voting Scheme for Large Scale Elections. Advances in

Cryptology - AUSCRYPT ’92, LNCS 718, pp. 244-251,

1992.

[5] Internet Voting Outside the United States. Verified Voting.

Retrieved July 24, 2016 from

https://www.verifiedvoting.org/internet-voting-outside-the-

united-states/

[6] Sako, K. and Kilian J. Receipt-Free Mix-Type Voting

Scheme - A practical solution to the implementation of a

voting booth. In Guillou, L.C. and Quisquater, J.J. ed.

Advances in Cryptology - EUROCRYPT ’95, LNCS 921, pp.

393-403, 1995.

[7] Sampigethaya, K. and Poovendran, R. A framework and

taxonomy for comparison of electronic voting schemes.

Computers & Security, 25(2). 137-153.

81

82

Social Engineering Penetration Testing Reshmi Sinhahajari

A0127244L School of Computing

National University of Singapore

13 Computing Drive

Singapore 117417

[email protected]

Evangeline Ong Yiling

A0131793A School of Computing

National University of Singapore

13 Computing Drive

Singapore 117417

[email protected]

Kor Chin Yew Kenwick

A0096515Y School of Computing

National University of Singapore

13 Computing Drive

Singapore 117417

[email protected]

ABSTRACT

This paper provides an overview of the social engineering aspect of

penetration testing, ranging from the intelligence gathering phase to

the actual attack phase. Starting off with a background of

penetration testing and the rise of social engineering in cyber-

attacks, the various different styles and tools employed by social

engineers to compromise the security of target organizations and

computer systems will be discussed in detail aiming to provide a

broader perspective regarding manipulation of human behavior in

extracting confidential information.

General Terms

Management, Documentation, Reliability, Experimentation, Security,

Human Factors and Verification.

Keywords

Social Engineering, Reconnaissance, Threat Modelling, Metadata,

Phishing, Attack vectors, Pretext, SET

1.INTRODUCTION

1.1 Background

Penetration testing involves the probing of a security system through

a series of self-initiated attacks to identify potential vulnerabilities in

the system that might expose victims to unwanted threats. This form

of security measures dates back to the 1960s when computer

systems became increasingly inter-connected over communication

lines and the risk of security impeachment became apparent. [1] As

such, in 1967, the first computer conference was held to discuss

ways to combat vulnerabilities or security loopholes in computer

security. There are numerous ways of conducting penetration tests

and attacks, for example networks, web applications, wireless

communications, etc. Social engineering, as defined by the SANS

Institute’s, refers to “the art of utilizing human behavior to breach

security without the participant (or victim) [2] even realizing that

they have been manipulated” which in the context of information

and security system refers to the use of manipulative behaviors to

exploit vulnerabilities in human nature in order to gain access to their

personal information. This form of deceptive actions relies

fundamentally on the manipulation of the natural human tendency to

trust is through clever and well-crafted communication techniques.

[3] The highly sophisticated and multi-faceted structure of Social

Engineering has the ability to bypass even the most advanced IT

security defenses as it capitalizes on the weakest link in any

security, which are human beings, leading to its increasing popularity

in cyber-attacks in today’s world [4].

1.2 Overview of Social Engineering

Even though human behaviors are unpredictable, there exist a

systematic framework in the approach of performing social

engineering penetration test This can be surmised into three main

phases: reconnaissance, threat modelling, and the actual execution

of attacks [5]. Firstly, reconnaissance work is carried out via

gathering of information of the businesses available in public. After

gathering the necessary intel, threat modelling is conducted to

identify the form of attacks that a company is most vulnerable to

and thus prone to encounter, and finally, exploitation attacks are

executed using the intelligence gathered in the initial stages and the

strategies planned and simulated in the threat modelling phase.

1.3 Data Collection [5]

In the assessment for the outcome of a social engineering

penetration testing, a good report will provide a bird-eye’s view of

the security of a system by surfacing the vulnerabilities in the

system so that these loopholes can then be investigated thoroughly

and rectified by the company accordingly. One way to obtain a

comprehensive assessment report is through the use of appropriate

data collection tools. In this section, we will talk about three

different approaches used in the collection of data: (1) Simple text

Editor + Folder structure, (2) Mind Mapping and (3) Document

manager.

1.3.1 Folder Structure

One form of data collection tools involved creation a folder structure

with the use of a text editor (that is in-build in all OS) and having an

organized folder structure. At each folder structure, there exists a

text file that states specifically the types of penetration testing being

performed, detailing how the penetration tests (e.g. phishing email

attack, remote phone attack, etc.) are being implemented, the result

of the penetration test. Documentary notes such as screenshots or

file attachment of the outcome are also included to substantiate the

information collected.

1.3.2 Mind-mapping

The use of mind-map is beneficial as it aids in information retention

which is crucial during data collecting in the event whereby the

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee.

Conference’10, Month 1–2, 2010, City, State, Country.

Copyright 2010 ACM 1-58113-000-0/00/0010 …$15.00.

83

assessment and report writing period are days apart. In the mind-

map, there exist an initial core with several main branches,

stemming from the center, representing the different assessments

performed. Subsequently, sub-branches from the core brand

represents further investigation for each assessment performed. It is

also pertinent that text notes are written down during the

assessment process at each branches to concretize the activities at

that stage. In the market, there exist mind-mapping editors (such as

MindJet [6] or XMind [7]) that allow users to hyperlink images and

document directly onto the mind-map; these tools allow large

amounts of information to be stored in a single mind-map.

1.3.3 Document Management Tools

For efficient collection of data, document management tools allow

efficient collection and collation of data. Some of such tools include

Dradis Pro [8]. The Dradis Pro is able to directly import data

collected from security tools and simultaneously organize this

information by removing duplicates copy of a security report, saving

both time and effort. Likewise, Scrivener, another document

management tools, aids in compartmentalizing the data collected and

arrange it in a systematically. For instance, should an attack of

similar nature (e.g. phishing email) occur at different location, the

software will organize them under one heading with the different

locations as sub-category.

2.RECONNAISSANCE PHASE

Reconnaissance is the process of information gathering [9] and is

arguably the most important stage in any form of penetration tests.

Successful strategies of this phase include both an active approach,

where there is direct interaction with the target as well as a passive

approach, where the target has no knowledge of the presence of the

attacker. Much of an organization’s information is made easily –

even unknowingly – available in the public domain. The information

could be released via, for instance, document metadata or

registration details for their public IP addresses [10]. Techniques in

which reconnaissance can be conducted will be covered in this

section.

2.1 Corporate website

One way to begin gathering intelligence on a business is to start

from its corporate web presence. The types of information that can

be retrieved include a company’s business purpose; partners, clients

and vendors; email addresses; employee names; staff hierarchy;

and photos of employees or business locations [10].

Such information can be retrieved directly from a website through

spidering. Spiders, or Crawlers, are designed to index websites and

their contents. The Spider starts with a seed URL, identifies all

hyperlinks on these sites, then visits each of these links, building a

full map of the website [10]. It uncovers initial information for the

social engineer that can be further investigated, such as business

partners, clients, vendors, and contact pages, as well as identify

documents and key words across large sites. This process assists

penetration testers by allowing the complete mapping of a corporate

web presence in an automated, time-effective manner [10].

2.2 Document Metadata

Document metadata refers to attribute information stored within

office documents. Some of the metadata are easy to find. In the

case of a Microsoft Office document, accessing the document

properties yields pre-populated information such as the user’s, or

corporate organizations, name. Additionally, other pieces of

metadata that are usually unknown to and not easily editable by the

user can be dug up, including the version of the word document,

some potential authors, and document creation and revision dates

[11].

2.3 Photographic Metadata

Digital files contain information ranging from the type of system that

created it to the more sensitive exact geolocation at which the

photograph was taken [10]. This is possible especially when taking

pictures with devices such as smartphones built in with GPS

functionality – every picture uploaded directly to social media sites

also has its location data, or Exif (exchangeable image file format)

data contained within. Tools for Exif data extraction include

Exiftool, Image Picker, Wget, and GeoSetter [10].

2.4 Email Addresses

Many businesses do not keep track of what their employees do with

corporate email addresses, and email addresses are given away

without much thought, be it to sign up for forums, online shopping

accounts or social networks. Yet, what may seem as a harmless

piece of information is particularly useful to social engineers. A

good 91% of data breaches come from phishing [12]; a penetration

test could very well exploit this form of social engineering using the

employee emails they have obtained. Password attacks can also

occur via Outlook Web Access (OWA): the email address can be

broken down into different permutations to guess internal naming

conventions for users, and to use this information to attack Virtual

Private Network (VPN) portals [10]. Finding out where the

collected email address is used on the Internet provides information

a social engineer could use to create plausibility for a successful

attack [num1]. Furthermore, email address conventions help a social

engineer determine a list of suitable emails to target in their attack

[10]. It would, for instance, be more effective to send a phishing

email to a single user’s address rather than a generic mailbox such

as [email protected]).

2.5 Social Media

Social networking sites have become very much a part of everyday

life, and contain a vast wealth of personal information (which also

means social engineers can gain access to vast amounts of

intelligence).

LinkedIn, an online network application that allows people to

connect with others throughout various industries, contains profiles

where employment history, skills and specializations, photographs

and references are made available. An organization often manages

its own group on LinkedIn, providing a list of employees along with

their entire history [10]. A social engineer can use this to his

advantage, particularly when seeking to impersonate an employee.

Compared with LinkedIn, Facebook, is used in a personal manner,

and corporate presences are limited in scope. Yet, useful

information can be uncovered by looking for photographs which

identify locations, the interior of offices, or employees, or from a

user profile that may contain job titles and work history [10]. Graph

Search, a Facebook function, allows one to craft search terms

relating to anything that has been touched by a Facebook user [10].

A social engineer could use this tool to search, for instance, a list of

84

potential former employees with the search term “people who

worked at Company X in 2012”, or other information such as a

general layout of the premises, employee hangouts, and photos of

employees that may contain identification passes [10].

3. THREAT MODELLING

Information gathered from the reconnaissance stage can now be

used to plan and simulate attacks. The threat modelling stage of the

social engineering assessment identifies the most significant security

threats and helps to focus the assessment on the right areas in the

later execution phase much like a vulnerability assessment [13]. To

assess the client’s susceptibility to these threats, certain threat

modelling strategies are discussed in this section.

3.1 Scenarios

Each scenario comprises multiple components [13]. Firstly, threats

are identified: An example could be that a call center comprising

mostly undertrained students are susceptible to basic social

engineering attacks. Gaining access to a highly privileged

employee’s email account could result in serious damage to the

company reputation. The main objective to be set follows directly

from the threat, in this case: gain access to a highly privileged

employee’s email. A formal approach to identify a target is

conducted, and an attack vector or the means by which the attack

will be carried out is defined (e.g. conducted over telephone). A

plausible situation and character, known as pretext, is generated.

Primary techniques of attack (e.g. impersonation) are used,

supplemented by secondary techniques (e.g. pressure the target and

demand a solution) used to identify additional vulnerabilities or

enhance the chances of a successful attack.

3.2 Target Identification

Figure 1. Generic target identification triangle [13]

Formal target identification is a structured process of elimination

resulting in just a few targets that are deemed as the most suitable

for the objective [13]. When attacking a business, every single

employee and those directly or indirectly linked with the business is

potentially a target. The number of targets reduce as they are

“promoted” to a higher layer based on certain criteria, using

information garnered from the reconnaissance phase.

The criteria at the first layer are based on open-source

reconnaissance [13], or initial reconnaissance. This involves

eliminating a large number of potential targets based solely on

information remotely gathered and based on the overall objective of

the attack. One fundamental criterion is seniority in a company; it is

often advantageous to pick a target with higher privileges than the

rest, unless the objective requires picking new and vulnerable staff.

Good digital footprint is another typical criteria as limited information

on a target could hinder the decisions that can be made. In some

cases, however, attacks are designed specifically to obtain

information that remains obscure even after research has been

done. Another common criterion is to promote targets in the right

department. The reception, for example, is responsible for providing

valid access to areas of the building.

The next layer involves target profiling [13], whereby decisions are

made based on the individual characteristics of the target, with the

hope of increasing the chances of success based on generalizations

about individuals with these characteristics. These include age,

gender, and interests. Some attacks may be more successful based

on a target’s age: depending on context, it could be easier to

manipulate a younger, inexperienced staff into revealing information,

or it could be easier to target an older person who is less likely to be

computer literate. Some scenarios could be gender specific: a call

center filled with male staff may be less likely to follow proper

procedures should a young female call in, perhaps to ask for a reset

of her password. Likewise, information regarding the various

interests of a target could be used against them.

Moving away from remote reconnaissance, the third layer, physical

reconnaissance [13] focuses on the targets and how they relate to

the objective. Patterns of behavior, such as a person’s working

hours, time he goes out on a lunch or cigarette break, or even if the

target will be not available during the entire testing window, can

assist in decisions regarding when to call or engage a target and

elicit information. Physical covert engagement includes taking

photographs or recording the target for information gathering. Using

this criteria, targets are promoted/eliminated based on whether they

can actually be engaged with. This step also reveals information

about who is associated with the target, such as close friends and

work colleagues. Associate engagement uses these avenues to the

attack the target.

The final layer, target engagement [13], reveals the best possible

targets for an attack. Targets are prioritized based on overall

suitability and the most promising ones are focused on first. A

suitable social engineering scenario is designed, and the actual

section of the scenario involves overtly engaging the target.

3.3 Pretext design mapping

Once a clear objective and target has been identified, the process

can move on to the pretext design mapping stage. The pretext

design map [13] begins with the objective and the chosen target,

branching off at the “Who” stage (who is associated with target and

objective). The “How/Why” stage follows, listing possible reasons

for engaging the associates and forming the basis for the pretext.

From this section, information gathered from reconnaissance work

is added to create the pretext. Following which, techniques to be

used and their corresponding attack vectors are clarified, and

classified according to their level of risk (a purely qualitative

assessment at the discretion of the consultant). Organizing the risk

levels and vulnerabilities in this manner enables the consultant to

start making good decisions on what pretexts to use in assessment.

85

Figure 2. Example of a pretext design map [13]

3.4 Planning for the unknown

Scenarios do not always go to plan, and it is important to consider

various possible events that could happen. Probable outcomes and

appropriate responses can be planned. To provide answers to

suspicious employees or avoid raising suspicion when common or

innocuous questions are asked, a cover story should be established,

filling in the finer details of the pretext and providing a clear idea of

why the consultant is there/calling/sending an email [13]. Exit

strategies provide damage control should certain outcomes become

unexpectedly difficult to recover from. The tactics include

temporarily diverting a conversation to another topic; pretending to

have been interrupted by a colleague and putting the target on hold;

playing the fool by pretending to have forgotten or not to have been

told; answering a question with another question; or ignoring the

question and continuing on [13].

4. EXECUTION PHASE

This is the actual attack phase of the penetration test whereby the

system vulnerabilities will be exploited based on the intel gathered

during the reconnaissance phase and threat modelling stage. This is

the actual “hacking process” in terms of cyber lingo. This process

should be done with prior legal and authorized permission. We will

now explore the attack phase by examining planned and targeted

email, telephone and physical vector attacks.

4.1 Email Attack Vectors

Phishing is a fraudulent activity conducted with the intention of

extracting sensitive information regarding the target such as their

usernames, passwords, credit card details (and sometimes even

money) by feigning the identity of a legitimate organization through

means of electronic communication. [14] The concept of Phishing

has gained its popularity for many reasons. How many people do

we know of that do not possess an email address or telephone

number? The answer is probably none! As of February 2016, google

has about 1 billion monthly active users worldwide and that’s just

one mail service provider. [15] Thus, targeting a service which

millions of people utilize would achieve incredibly effective results

even if a very small percentage fall for the scam. A study by the

Anti-Fraud Command Centre of RSA reported that an estimated 27

billion pounds was lost to cybercrime in the United Kingdom

revealing that most users do not examine their emails carefully

enough. Moreover, conventional defense approaches restrict and

monitor inbound traffic but outbound connections are not dealt with

the same level of scrutiny whether it’s a home setting or a corporate

one. A malicious attacker just needs to find 1-2% of vulnerable

target systems which can grant full access through outgoing

channels via payloads embedded in pdfs or a corrupt file, etc. In

conclusion, phishing is so successful due to the extensive number of

targets, weak client-side defenses and users’ disposition to click on

almost anything they receive. [16]

4.1.2 Types of Phishing

Phishing attacks can both be done on a generic database of email

addresses (trawling) or on more personalized level (spear phishing).

[16] Though trawling is common and is usually sent to all the

corporate email addresses obtained in the reconnaissance phase,

they can be quite easily identified as suspicious emails and have the

potential of attracting attention throughout the business as they are

essentially mass scam campaigns. Spear Phishing, however, results

in much more effective outcomes as it employs a rather detailed and

personal tone of attack on specific departments or individuals within

the organization. It is the most pervasive form of advanced

persistent threat (APT) attacks among cyber criminals today. [17]

A skillfully designed spear-phishing email depends on the extent of

homework and research invested in the reconnaissance phase and

open source intelligence as discussed earlier. By scanning social

networking sites such as Facebook or even LinkedIn, one can easily

come up with an accurate and persuasive spoof email leveraging on

the particular individual’s or department’s interests for example an

employee involved in a hockey league which utilizes his corporate

email address or the HR department of an organization actively

seeking prospective candidates and resumes. Choosing to send

emails at office hours is especially effective as chances of gaining

access into a corporate machine at that time would be relatively

higher.

4.1.3 Phishing Methodologies

4.1.3.1 Malware-Based

Studies have shown that 94% of targeted emails attack by malicious

file attachments misleading users to download seemingly harmless

corporate documents which contain corrupt file extensions. The

malware is automatically installed without the knowledge of target

and can be used to access the C&C (command and control server)

by the hacker. Moreover, the document appears to be genuine (Ex:

Resume.pdf) to remove suspicion of any malicious activity [18]

Concealing corrupt file extensions is relatively simple (Ex:

file.pdf.exe would appear as pdf.exe.) Nowadays, executable(.exe)

files can be usually blocked which is why other file types such as

.rtf,.xls and .zip files have emerged to account for 70% for all

corrupt file types. Techniques such as RTLO (Right to left Override

Unicode), which reverses the direction of reading file names, [19]

and password protected compressed files are implemented to avoid

further detection by security software. Upon gaining access to a

single target machine, hackers may obtain access to the entire

computer system and all the confidential information regarding the

corporation ready to be exploited at will. [20]

Figure 3: Malicious attachment

file types [19] Figure 4: Spoof Email

86

4.1.3.2 Credential Harvesting

This process (also known as clone phishing) involves attempting to

gain network access credentials of victims by tricking them into

clicking on embedded malicious links. Most of these scam emails

involve requesting users to resolve inconsistencies regarding

account transactions (Ex: PayPal) or by asking them to update their

company log-in passwords by providing them with various

hyperlinks attempting to direct them to a legitimate looking cloned

website which is in reality the attacker’s website. After obtaining

the credentials, the user will be redirected to the original website of

the bank or company (after a “failed” first attempt) thereby

removing suspicion and rendering the attack impossible to detect

and report. [21] The process through SET (Social Engineering

Toolkit) is shown in the figures below:

Launch SET->Website Attack Vectors->Credential Harvester

Attack Method->Key in IP address-> Enter site to clone (Ex:

www.gmail.com)->credentials reflected in console. The underlying

process is that the attacker launches a webserver in the same

network as the victim, develops the same hierarchy (through tools

such as Httrack,etc).and design of the Outlook Web Application

(OWA) server, writes a PHP code which saves the credentials

entered by the victim in a text file and then sends the scam email to

persuade the target to access the duplicate OWA server [22]. The

cloning process can also be executed through Java Applets (Refer

the Appendix for more details)

4.1.3.3 NDR’s and Out of Office Responses

When an email is sent to a non-existent target organization address,

a non-delivery report is generated. From here, X-received and X-

originating IP values within the SMTP (Simple Mail Transfer

Protocol) header are obtained which may include the internal IP

address space. Though this may not seem that useful, if a physical

breach of the target organization ever occurs, this would be very

effective in a plug-in and hack attack and valuable time can be

saved.

The real treats are however when the attacker receives an Out-of-

Office response via a legitimate email address obtained from earlier

information gathering phases. Most business organizations have the

habit of using them and though they may seem to disclose relatively

harmless information, this is a crucial piece of information that

hackers can exploit, even though it may not be directly through

email attack vectors. Typical responses will have “who to contact in

my absence” information provided which may help establish

credibility of the attacker within the target organization as they will

be familiar with the chain of command. Moreover, a hacker could

impersonate the particular victim’s supervisor attempting to gain

access to confidential information. The second critical piece of

information is usually the signature of the employee which provided

the job title, designation, hand phone number, fax number and

sometimes even personal email addresses as an alternate form of

communication. This could lead to an even wider scale phishing

attack of the target as they are now definitely a confirmed hit on the

attacker’s spam list. An example of such an attack could be:“Hey

Sue! I was speaking to Sally last week and she said had to

attend a business conference in Beijing but mentioned that I

could contact you if I needed any information regarding his

files. Would you direct me to the necessary information?” An

assuming employee wouldn’t think twice about handing over the

relevant small details especially as there would be no point double

checking since the person is not contactable either way. [23] Out-

of-Office replies should thus be as limited as possible and never

stating any personal contact information as this exposes the target to

physical attacks as well.

4.2 Phone Attack Vectors

Phone scams (also known as Voice Phishing or Vishing) are very

much an effective tool in testing the security strengths of an

organization during penetration testing as the amount of information

that can be obtained through tools of persuasion and the right

amount of effects is unimaginable. This includes and is not limited

to employee numbers, addresses, credit card numbers and

passwords. According to statistics vishing scams cost users up to

about 24million pounds annually. [24] We will now cover aspects of

some types of telephone attacks as well as the tools used to gather

key information through a variety of examples.

4.2.1 Card Cancellation Scams

This phone scam relies on triggering the target’s panic attack mode,

causing them to react in impulse. In a real-life example, the scam

was from an Apple retail store where the scammer impersonated a

concerned staff member calling to report a suspicious individual

attempting to spend a large amount of money using the target’s

credit card. The victim is then asked to check all her cards and upon

finding them all intact, the scammer suggests that’s it’s a possible

case of fraudulent cloning and encourages the victim to get all the

credit cards cancelled. At this juncture, the flustered target cuts the

call and dials the bank. However, the scammer is still holding the

line keeping the call active and in a hurry the victim doesn’t realize

that the dial tone is missing and believes that their conversation is

now occurring with the bank when in actual fact it is still the

attacker on the same line. The attacker confirms the money

transactions validating the previous complaint and is now stressing

on the victim’s pressure points suggesting a new scheme developed

to cancel all credit cards at once to minimize damage. The victim is

then told that the cards will be collected personally by the banks

trusted courier and is asked to key in the pin numbers to

authenticate the victim for new cards that have to be issued. The

attacker now has both the cards and the necessary pin number

simply by creating a pressure situation and using the effective tool

of money to manipulate the victim to act without thinking. Numerous

cases have been reported pertaining to such attacks with

perpetrators making up to 50 000 pounds in a day. [25]

4.2.2 Caller ID Verification

Many people seem to be under the illusion that Caller Id can be fail-

proof way to warn and protect against malicious vishing attempts

but is that really the case? The answer is not since a decade ago

when Voice Over Internet Protocol(VoIP) service, which

transforms an analog phone signal to a digital one over the internet,

Figure 6: Captured

Credentials [16]

Figure 5: Credential Harvester

Attack Method [16]

87

and Private Branch Exchange (PBX) communications systems,

which allowed modification of internal phone lines allowing access

to the display of outgoing calls, among other features became

affordable and accessible. [26] Caller Id spoofing is definitely

prevalent even today. More than often, an employee contact

database cannot be kept up to date accurately and this raises issues

like the case of a new employee or a current employee claiming to

have lost or replaced their phone. Another interesting thing is that

not all caller ID’s appear when a call goes through transfers.

However, the original person who transferred the call might still

show up on the Caller ID console which is why it is always

effective to try to get routed to the target’s phone line via the main

reception in an organization to remove suspicion of a malicious

caller ID.

4.2.3 The Help Desk

Impersonating a member of the IT staff in the target’s company and

offering help of non-existent technological issues is another common

form extracting useful information from the victim. Employees with

no technical knowledge of IT systems whatsoever are especially

vulnerable to this type of risks as they are unaware of the

confidential information they are disclosing in a seemingly jargon

language. For example, an attacker may request the target to launch

certain commands such as ipconfig/all and then “net

accounts/domain” which will provide the attacker with not only the

network IP addresses but also the DNS server addresses and the

domain password policy which can be exploited in conducting

network penetration tests to extract highly confidential information.

4.2.4 Sales Calls

Almost all organizations and businesses deal with sales calls on a

daily basis which provided the perfect cover for an attacker to

fabricate a product selling scheme with the intention of extracting

crucial information. Having done prior research in the intelligence

gathering phase, contact the IT department of the organization

directly or through the help desk. Most effective are offers

regarding anti-virus software where the attacker attempts to gather

information regarding the firewall and security systems in place of

the particular organization. Some staff members may directly

disclose this information (Ex: Norton Anti-virus expiring in 6

months) whereas others might simply respond by stating they

already have their own software in place and aren’t interested in

purchasing anymore. In the latter case, upon pushing for more

information regarding their current facilities, the staff usually reveal

that information since it’s not uncommon for salespeople to be

persistent about pitching their business model no matter what. This

provides as a very effective disguise in extracting information since

sales people are natural social engineers and it seems appropriate

that attackers leverage on this from of attack. [27]

4.2.5 Environmental Sounds

Before attempting a phone call to attack the target, prior

consideration should be catered to the kind of atmosphere one is

calling from. For example, sales people would be calling while

commuting hence traffic noises are appropriate whereas a help desk

operator is likely to be situated in a busy call Centre with plenty of

noises in the background. It these small details which add an extra

layer of credibility to the scammer establishing a trust relationship as

well as removing doubts of any possible foul play at force. Sounds

can also be used to create pressure situations and evoke sympathy,

for example a harassed mother with the sound of a baby crying in

the background provides an authentic cover of a stressed individual

thereby facilitating faster compliance from the target to help the

“victim” in need. This is a very important tool in Vishing scams as it

enhances the target’s sensory connection with the attacker.

4.3 Physical Attack Vectors

Physical Attacks are the most “active” from of information

gathering possible. This approach of attack builds on the intel

gathering after the email and phone attacks. This an important

element in conducting a social engineering assessment of an

organization and should be takes as the final step of attack after all

other forms of possible vulnerabilities have been exploited. A simple

phone call has the ability of securing a pass to a conference room

inside the building without having to ever physically see it! However,

for organizations which conduct due diligence on its security

systems and controls, such access might be potentially difficult, in

which case the focus of the attacks should be redirected to the main

building itself. An onsite inspection can provide crucial opportunities

for discovering new vulnerabilities of the organizations or the

potential targets. Some of these questions are: Which floor is the

target area on? Are there any businesses or places employees

frequently visit or have electronic access to? Are there magnetic

strips control inside the building? We will explore two methods of

physical attacks which we may employ during on-site investigation

of target organizations.

4.3.1 Dumpster Diving

In simple words it is the process of searching for treasure in

somebody’ else’s’ garbage [28] The first issue is obviously locating

the trash which can achieved through innocent vishing calls to the

cleaning staff to gain information about the location and timings of

the disposal. The attacker can then simply pose as a security guard

or disposal personnel with the proper attire to avoid suspicion. It

isn’t always necessary that one might come across a passcode or

high fi legal scam. Even simple documents such as an email

conversation, or employee list or an organizational chard can prove

extremely effective in proving confidential information and possible

avenues of social engineering attacks.

4.3.2 Shoulder Surfing

This process is essentially an observation technique, like looking

over an employee’s shoulder to obtain information. This proves

especially helpful in busy or crowded settings to provide for cover.

Often confidential information such as passwords being typed or

composition of email the target can give away crucial information

4.3.3 Rogue Access Points

One of the most effective ways to leave backdoors is to utilize

“rouge” wireless access points into which an attacker could plugin

and create outbound connections. When physical access to the

building is possible through previous efforts of vishing, then the

attacker say simply plus in a malicious USB device into any access

point to gain access to the organization’s private networks through

means of port scanning and network exploitation tools such as

MetaSploit and Hydra. Nevertheless, if that is not possible, an

88

attacker may still attempt to install rogue access points via means of

wireless networks from a nearby location. For example, if the target

organization does not provide wireless access its employees, they

may seek another source of free wireless connection which the

attacker will so benevolently provide by setting up an open wireless

network broadcasting any SSID like “Free Internet”. Once the

employees are connected to the network, their traffic can be

intercepted easily and the attacker can gain access to critical

information such as passwords, company credentials, email

addresses and many more which would create a much wider

phishing attack arena. [29]

5. CONCLUSION

The amount of information that people are willing to disclose once

psychological barriers have been eliminated is alarming. In some

cases, attackers don’t even require to step foot into the organization

as they achieve access to the internal networks through phishing

and vishing attacks alone. Millions of people and companies around

the world have been targets of social engineering attacks and

therefore, this is one of the crucial aspects of penetration tests that

must be conducted to assess the security system of an organization

or IT system. Preventing such attacks include proper education,

strict policies, and regular security awareness trainings of individuals

within the organization to ensure the awareness of the types and

possible modes of attacks of social engineers.

REFERENCES

[1] ckirsch. 2013. What is Penetration Testing? (April 2013).

Retrieved July 24, 2016 from

https://community.rapid7.com/docs/DOC-2248

[2] Watson, G. 2014. An Introduction to Social Engineering. Social

Engineering Penetration Testing. Elsevier Inc. 2-4.

[3] Mason, A. 2014. Writing the Report. Social Engineering

Penetration Testing. Elsevier Inc. 311-326

[4] Shackleford, D. 2012. Social engineering penetration testing:

Four effective techniques. (July 2012). Retrieved July 24, 2016 from

http://searchsecurity.techtarget.com/tip/Social-engineering-

penetration-testing-Four-effective-techniques

[5] Pavković, N and Perkov, L. 2011. Social Engineering Toolkit —

A systematic approach to social engineering. (January 2011).

MIPRO, 2011 Proceedings of the 34th International

Convention. 1485-1489

[6] Retrieved July 24, 2016 https://www.mindjet.com/home/

[7] Retrieved July 24, 2016 from http://www.xmind.net/features/

[8] Retrieved July 24, 2016 from

http://securityroots.com/dradispro/features.html

[9] Anonymous. 2016. Understanding Social Engineering Attacks.

(January 2016). Retrieved July 23, 2016 from

https://www.wordfence.com/learn/understanding-social-

engineering-attacks/

[10] Ackroyd, R. 2014. Leveraging Open-Source Intelligence.

Social Engineering Penetration Testing. Elsevier Inc. 154-204.

[11] Pesces, L. 2008. Document Metadata, the Silent Killer…

SANS Institute InfoSec Reading Room.

[12] Lord, N. 2016. Social Engineering Attacks: Common

Techniques & How to Prevent an Attack. (June 2016). Retrieved

July 23, 2016 from

https://digitalguardian.com/blog/social-engineering-attacks-common-

techniques-how-prevent-attack

[13] Watson, G. 2014. Creating Targeted Scenarios. Social

Engineering Penetration Testing. Elsevier Inc. 135-151.

[14] Margaret Rouse and Mike Cobb. What is phishing? - Definition

from WhatIs.com. Retrieved July 23, 2016 from

http://searchsecurity.techtarget.com/definition/phishing

[15] Frederic Lardinois. 2016. Gmail Now Has More Than 1B

Monthly Active Users. (January 2016). Retrieved July 23, 2016

from https://techcrunch.com/2016/02/01/gmail-now-has-more-than-

1b-monthly-active-users/

[16] Watson, G. 2014. Email Attack Vector. Social Engineering

Penetration Testing. Elsevier Inc. 2-4.

[17] FireEye. 2016. Spear-Phishing Attacks, Why they are

successful and how to stop them. (2016). Retrieved July 23,2016

from https://www2.fireeye.com/rs/fireye/images/fireeye-how-stop-

spearphishing.pdf

[18] Nart Villeneuve. 2011. Targeted Attacks on Popular Webmail

Services Signal Future Attacks - TrendLabs Security Intelligence

Blog. (June 2011). Retrieved July 23, 2016 from

http://blog.trendmicro.com/trendlabs-security-intelligence/targeted-

attacks-on-popular-web-mail-services-signal-future-attacks

[19] Amir Lev. 2011. Krebs on Security. (September 2011).

Retrieved July 23, 2016 from

http://krebsonsecurity.com/2011/09/right-to-left-override-aids-email-

attacks/

[20] Ivan Dimov. 2013. Phishing Techniques: Similarities,

Differences and Trends - Part II: Targeted Phishing - InfoSec

Resources. (2013). Retrieved July 23, 2016 from

http://resources.infosecinstitute.com/phishing-techniques-similarities-

differences-and-trends-part-ii-targeted-phishing/

[21] David Bisson. 2016. 6 Common Phishing Attacks and How to

Protect Against Them. (June 2016). Retrieved July 23, 2016 from

http://www.tripwire.com/state-of-security/security-awareness/6-

common-phishing-attacks-and-how-to-protect-against-them/

[22] Ahmed Mohamed. 2013. Phishing and Social Engineering

Techniques - InfoSec Resources. (2013). Retrieved July 23, 2016

from http://resources.infosecinstitute.com/phishing-and-social-

engineering-techniques/

[23] Andy O. Donnel. 2016. Remove These 4 Things From Your

Auto-replies RIGHT NOW!! (April 2016). Retrieved July 23, 2016

from http://netsecurity.about.com/od/secureyouremail/fl/remove-

these-4-things-from-your-auto-replies-right-now.htm

[24] Darren Boyle. 2014. 'Vishing scams' costing phone users

£24million annually: Almost 60% report receiving 'suspect' cold

calls. (February 2014). Retrieved July 23, 2016 from

http://www.dailymail.co.uk/news/article-2857100/vishing-scams-

costing-phone-users-24million-annually-60-report-receiving-suspect-

cold-calls.html

89

[25] Brian Milligan. 2013. Fraudsters trick people into handing over

cards on doorstep. (May 2013). Retrieved July 23, 2016 from

http://www.bbc.com/news/business-22513041

[26] Caller Smart Inc. Caller ID Spoofing: How Scammers Use

Local and Trusted Numbers to Trick You. Retrieved July 23, 2016

from https://www.callersmart.com/articles/18/caller-id-spoofing-

how-scammers-use-local-and-trusted-numbers-to-trick-you

[27] Changing Minds. Social Engineering. Retrieved July 23, 2016

from

http://changingminds.org/techniques/general/social_engineering.htm

[28] Margaret Rouse. 2005. What is dumpster diving? - Definition

from WhatIs.com. (2005). Retrieved July 23, 2016 from

http://searchsecurity.techtarget.com/definition/dumpster-diving

[29] Tech Library. 2015. Understanding Rogue Access Points.

(September 2015). Retrieved July 23, 2016 from

http://www.juniper.net/techpubs/en_us/junos-space-apps/network-

director2.0/topics/concept/wireless-rogue-ap.html

[30] TustedSec. Social-Engineer Toolkit - TrustedSec - Information

Security. Retrieved July 25, 2016 from

https://www.trustedsec.com/social-engineer-toolkit/

[31] Karthik R. Social Engineer Toolkit (SET) tutorial for

penetration testers. Retrieved July 25, 2016 from

http://www.computerweekly.com/tutorial/social-engineer-toolkit-set-

tutorial-for-penetration-testers

[32] netbiosX. 2012. Java Applet Attack Method. (March 2012).

Retrieved July 25, 2016 from

https://pentestlab.wordpress.com/2012/03/03/java-applet-attack-

method/

APPENDIX

The Social Engineering Toolkit (SET) is a python-driven tool which

aids in conducting various types of exploitation attempts during the

execution phase of the penetration test. [30] Developed by

TrustedSec, it has a number of custom attack vectors embedded

inside with features of backdooring executables and evasion of IT

security defenses such as antivirus, firewalls, etc. SET can be

accessed from Kali Linux (or Backtrack for earlier operating

systems) and is an incredible asset to any social engineering

penetration tester.

Figure 7: Opening Screen of SET Framework [31]

In the figure above, there are a variety of attack strategies to

choose from especially useful during spear phishing, applications.

For example, selecting option in the figure above brings up another

screen:

Figure 8: Available Attacks and Payloads [31]

After choosing let’s say to perform email attack vectors and the

type of file to be included (default being PDF embedded .exe), the

type of payload is now chosen. Payload essentially refers to the

malware part of any intended data or message which performs the

attacks on the computer system.

Website cloning during the credential harvester method of phishing

has been also discussed in the paper. Another way of achieving the

same results is the Java Applet Attack Method as demonstrated

below:

Figures 9 &10: Java Applet Attack Method [32]

90

Public Key Infrastructure - Attacks and Precautions

Thenaesh Elango, Ivan Koh, Patrick Koh, Claurence LeeNational University of Singapore

ABSTRACTSecure communications between two entities over an inse-cure network such as the Internet requires some form ofcryptography. The large and decentralised nature of theInternet makes it practical to use asymmetric-key cryptog-raphy to secure communications, as a key does not need tobe securely shared beforehand. Asymmetric-key cryptogra-phy, however, is extremely vulnerable to an attack known asthe man-in-the-middle attack. Attempts to protect againstthis attack lead to the development of public key infrastruc-ture, which is ubiquitous and widely-used today. However,public key infrastructure is not perfect. This paper discussesattacks against modern public-key infrastructure and waysto protect against such attacks.

1. INTRODUCTION

1.1 NotationWe first define some notation for use throughout this paper,to avoid cumbersome inline definitions in the main body ofthe text. We make several forward references to conceptsand terms discussed later in the paper, so the reader mayfind it helpful to treat this subsection as a reference. Weattempt to make the notations as simple as possible withoutsacrificing key (pun not intended) information.

Asymmetric Key Pairs. We denote an encryption key byke and a decryption key by kd. Whenever we refer to aparticular agent’s key, we use the first letter of the agent’sname as a lowercase subscript. For example, the encryp-tion key of an agent named Alice is denoted kea. We de-note the encryption operation by a function named E andthe decryption operation by a function named D, whereE : (encryptionKey, plainText) → cipherText and D :(decryptionKey, cipherText) → plainText.

Public and Private Keys. We will only make referencesto public and private keys of a particular agent once wehave made it explicit which key (encryption or decryption)is public and which is private.

Certificates. When a certificate authority (CA) signs a key,it is necessary for it to sign the key together with the identityof the owner of the key. We denote the identity of an agentby id. When we refer to a particular agent, we use the firstletter of the agent’s name as a lowercase subscript. Much likethe case with keys, the identity of Alice is denoted ida. A CAtypically signs a hash of the identity and encryption key ofan agent with its own encryption key. More precisely, for anagent called X, a CA called Z computes E(kez, h(idx, kex)),which we call the certificate of X granted by Z and denotecert(x, z). We refer to the (idx, kex) pair as the credentialsof X.

1.2 MotivationsAsymmetric-key cryptography enables communications be-tween two parties without requiring them to first exchangea shared key over a secure channel.

The proverbial Alice and Bob generate a key pair each,where one of the keys is used to encrypt a message and theother is used to decrypt it. Alice generates (kea, kda) andBob generates (keb, kdb). They each make their encryptionkeys public and keep their decryption keys private. WhenAlice wishes to send a message, M , to Bob, Alice computesand sends E(keb,M) to Bob. Assuming kdb has not beencompromised or leaked, only Bob can perform the requisitedecryption operation, D(kdb, E(keb,M)) which yields theplaintext message M .

While this is certainly a step up from unencrypted commu-nications and more practical than symmetric-key cryptog-raphy which requires prior secure exchange of a shared key,there remains a major weakness: man-in-the-middle attacks.

1.3 Man-in-the-Middle AttacksWe consider, without loss of generality, the case in whichAlice wishes to send a message to Bob, over an insecurechannel which may be intercepted by Harry, a malicious ac-tor. We note that Bob shares keb publicly over an unsecuredchannel. If Harry is able to intercept and modify all com-munications between Alice and Bob, Harry may be able togenerate his own key pair (keh, kdh) and send keh, passing

91

it off as Bob’s public key. Alice then ends up encrypting hermessage, M , with keh instead of keb and sending E(keh,M)over the network. Naturally, Harry is able to recover theplaintext message by performing M = D(kdh, E(keh,M)).Harry can then inspect the message or even maliciously mod-ify it (into a new message M ′) before computing and sendingE(keb,M

′) over to Bob, who is none the wiser.

1.4 The SolutionWhat Alice needs, in this case, is the assurance that the keyshe is using to encrypt the message is indeed keb and notany other person’s key. This assurance may come from athird party, Carol, that both Alice and Bob trust.

Suppose Carol has a key pair (kec, kdc) and makes her de-cryption key kdc public while keeping her encryption key kecprivate. In order to make use of this trust relationship, Bobsends a hash of his identity and his public key, h(idb, keb),to Carol, who then signs it (generating cert(b, c)) after veri-fying Bob’s identity and ensuring that it was indeed he whomade the request. Bob then distributes keb as usual, butthis time together with the newly-signed cert(b, c). Alicecan then computeα = D(kdc, cert(b, c)), compute β = h(idb, keb) separatelyand check if α = β. If so, she can be sure that the key shereceived is indeed keb and she can proceed to securely sendBob messages.

We note the assumption that Alice has securely receivedkdc correctly prior to the communication with Bob and thatCarol signed the correct key keb and not some other key fromsome malicious actor. This requires a pre-existing securechannel to transfer Carol’s public key to Alice and properverification by Carol that it was indeed Bob who requestedthe signing of his credentials.

1.5 The Real WorldThe preceding analogy is the foundation of modern publickey infrastructure (PKI). In place of the proverbial Carol,there are global certificate authorities (CAs) such as Verisignand several governmental agencies, which are widely trusted.The public keys of these CAs are pre-installed on most com-puters and are known as root certificates. The distributionmedia of the OS serve as the requisite secure channels forthe transmission of the root certificates. A standard knownas X.509 [Hou+02] governs the content of certificates, whichare significantly more elaborate than the simple model wehave presented in this section. The simple model, however,will be sufficient for our discussion.

Each CA (or, more specifically, its associated registrationauthority (RA)) verifies the identity of anyone requesting acertificate. Upon being convinced of the authenticity of thecredentials of the agent requesting a certificate, the CA signsthe key. As the CA is widely trusted, an agent holding acertificate from the CA is then able to conduct business withmany entities that demand secure communication and havea root certificate from that CA installed on their systems.

However, PKI, at present, is far from watertight, and thereare several attacks that reduce its effectiveness. We shallexplore these in the next section.

2. ATTACKS ON PKI2.1 Compromise of CAThe ultimate attack on PKI, of course, is an outright com-promise of a CA. If a CA is compromised by an attacker,the attacker may issue fraudulent certificates that are thenimmediately trusted by anyone trusting the CA, allowing aman-in-the-middle attack.

We go back to the proverbial example of Alice, Bob, Carol(the CA) and Harry (the malicious agent) to illustrate thisattack. Alice wishes to send a message securely to Bob. Sheneeds to encrypt the message with Bob’s public (encryption)key, keb, and is assured that she is indeed using keb insteadof Harry’s public key keh for this purpose because Carol hasprovided a signed hash E(kec, h(keb)) that she can checkagainst. However, if Harry manages to force Carol to signkeh and release E(kec, h(keh)) in place of E(kec, h(keb)),Harry will be able to pass off his public key as Bob’s. Aman-in-the-middle attack is then naturally possible.

A Dutch CA, DigiNotar, was compromised in this mannerin 2011 [PC11]. An attacker with the necessary credentialsto use DigiNotar’s systems issued a malicious certificate forGoogle (with the public key indicated being the attacker’spublic key rather than Google’s). Any agent trusting Dig-iNotar immediately began trusting the malicious certificate,enabling several man-in-the-middle attacks in Iran.

Another case of CA compromise was the breach of Bit9 in2013, a computer security company that acted as a CA forsome of its customers [Sec13]. Bit9 produced whitelist soft-ware that, when installed, prevented any programs exceptthose listed in a whitelist from executing. Bit9, in a securitylapse, failed to install its own whitelist software on some ofits local computers, allowing malicious actors to perform anattack and gain access to the CA certificates. These mali-cious actors then used the compromised CA certificates tosign fake certificates and perform man-in-the-middle attackson undisclosed major customers of Bit9.

The attacks described in this section are the ultimate com-promise of PKI, removing the very foundation of trust in thesystem. There is another kind of attack, which targets indi-vidual users’ instead of entire CAs, which will be exploredin the following section.

2.2 Compromise of Client SystemCompromising a CA requires finding a loophole or lapse intheir security systems and exploiting it. One would reason-ably expect a CA to be well-defended and employ competentstaff to maintain their security, making such attacks out ofreach of all but the most well-funded and disciplined adver-saries. However, the systems of individual Internet users arelikely to be much less well-defended. That, combined withthe fact that many Internet users are laypeople with poorunderstanding of computer security, makes attacks with asocial-engineering component likely to succeed. This sectionexplores some of them.

One attack involves mass-sending emails to targets that ex-ploit the ability to send attachments (and the tendency ofnaive users to open them).

92

In 2015, French users were spammed with an email purport-ing to come from the French Ministry of Justice [Ced15],claiming that their property was due to be seized as a resultof bankruptcy proceedings, and that a copy of the proceed-ings was attached in the email. When unsuspecting usersopened the attached Microsoft Word document, a decoy im-age was displayed while a macro downloaded and installeda malicious payload known as the GootKit backdoor on theuser’s machine.

The GootKit backdoor installs a new root certificate on theuser’s system, making the user unwittingly trust any agentwhose credentials have been signed by the malicious certifi-cate. This, once again, allows man-in-the-middle attacks tooccur.

Another similar attack involves malicious software masquerad-ing as legitimate software on rogue sites. Such software,when run, downloads and installs a new root certificate, withthe same nefarious results as before.

Troj/BHO-QP was an example of such malicious software,which masqueraded as a Flash Player extension [Sop10].Troj/BHO-QP was a browser helper object (BHO) that in-stalled a malicious DLL and a fake Verisign root certificateon the victim’s system. The fake certificate was then used tosign the DLL to prevent it from appearing as unverified. TheDLL could then run without raising suspicion and carry outits nefarious goals (as a backdoor into the victim’s system).

2.3 Insufficient Verification by CAThe effectiveness of PKI is partly predicated upon sufficientverification of the party applying for a certificate. Shouldthe registration authority (RA) associated with the CA failto perform its verification duties appropriately, it is possiblefor an attacker to submit false credentials and have themsigned, allowing man-in-the-middle attacks.

Unfortunately, many low-cost CAs tend to do just that [Woo10].A common verification technique by many low-cost CAs isknown as domain validation. Domain validation typicallytakes place by sending an email to an administrative contactlisted in the WHOIS listing for the domain. The rationalefor this is that only someone in the organisation will haveaccess to such emails and that a malicious adversary outsidethe organisation will not be able to access those emails.

The problem with this is that a malicious adversary can reg-ister a similar domain (e.g. gooogle.com instead of google.com)with his own administrative contact details. Should this ad-versary submit a certificate request for this malicious domainto a CA that performs domain validation, he will succeed ashe has access to his own administrative email as listed in theWHOIS directory. This adversary may then launch phishingattacks by sending emails with links to this slightly differ-ent malicious domain. When users click on this domain,they will see a lock icon in their browser’s address bar (asthe certificate is signed), lulling them into a false sense ofsecurity.

With the advent of Let’s Encrypt, a CA that validates cer-tificate requests and provides certificates in an automatedfashion, Mozilla has updated Firefox to display a green lock

instead of a grey one when domain validation is used [Moz15].This, unfortunately, has the side effect of making domain-validated certificates seem extremely secure (which is typi-cally the status associated with the green lock).

Fortunately, there are ways to defend against these attacks.

3. DEFENCE FROM ATTACKS ON PKI3.1 Certificate Revocation ListsMany attacks on PKI seen in the previous section involvecertificates mistakenly issued to malicious parties. One wayto resolve this is to maintain a certificate revocation list(CRL) that is regularly updated with newly-discovered ma-licious certificates [Hou+02]. Whenever a secure connectionis to be made, the CRL can be looked up to see if the certifi-cate has been revoked. If so, the connection can be flaggedas untrusted or even dropped.

A potential issue with this approach, however, is that theCRLs need to be maintained and updated. As discover-ing a malicious certificate and blacklisting it takes sometime, unsafe connections may still be made in the mean-time. There may also be human error in this process, whichmay cause the accidental blacklisting of non-malicious cer-tificates (and potentially serious service disruptions). Fi-nally, if the CRLs are not properly distributed with suffi-cient redundancy, there may also be a single point of failure,allowing a denial-of-service attack to easily take down theCRLs.

3.2 DNS Certification Authority AuthorisationAnother class of attacks on PKI seen in the previous sectioninvolve exploiting user ignorance to install malicious rootcertificates on end-user systems. DNS Certification Author-ity Authorisation (CAA) [HS13] significantly reduces thechance of such attacks succeeding, by allowing DNS serversto also specify which CAs are allowed to sign certificates fora particular domain. A malicious root certificate installedon an end-user’s system will then be rendered useless.

Naturally, DNS CAA is vulnerable to DNS cache poisoningattacks, but it is still preferable to having no DNS CAA atall. This is because attacking a DNS cache is yet anotherthing an attacker needs to do in order to make a success-ful attack against PKI using DNS CA, thus increasing thedifficulty of the attack.

3.3 Public Key Pinning Extension for HTTPOne way to prevent attacks from forged certificates on theWeb is to use the HTTP Public Key Pinning (HPKP) ex-tension [Moz16]. While a client is likely to trust multipleCAs, some of which may be compromised and all of whichcan sign keys from websites, HPKP ensures that only oneCA can sign keys from any given website. This significantlyreduces the attack surface.

The first time a user connects to a website with HPKP en-abled, the website sends its public keys via a HTTP header,which the client stores locally. Whenever the client connectsto the same website again, the client checks the certificateused to ensure that the keys match. If they do not, it means

93

that a different (and potentially fake) CA is signing the keyand the connection should be flagged or prevented.

4. CONCLUSIONAs long as asymmetric-key cryptography is used, PKI willremain a necessary component of the network infrastruc-ture that enables end-to-end secure communications acrossan untrusted network. Without PKI, man-in-the-middle at-tacks are nearly trivial to conduct for any attacker that inter-cepts a network link and is able to read and modify packetssent across.

We have, however, seen that PKI is not a complete solu-tion to the problem of man-in-the-middle attacks. Attacksof PKI itself may come via compromise of CAs, compro-mise of the root certificate store on client systems or poorverification on the part of the RAs.

Fortunately, there are ways to defend against these attackson PKI, such that PKI remains a good solution to the ever-present threat of man-in-the-middle attacks. However, as wehave seen, these defences are still not perfect, though theyreduce the attack surface significantly.

Throughout this paper, we have concerned ourselves onlywith CA-based PKI (using the X.509 standard), as this is themost common sort of PKI used all over the Internet, makingattacks on CA-based PKI particularly severe. However, CA-based PKI is not the only form of PKI in existence. A goodalternative is the web of trust, where trust is not vested ina single point of failure (the CA), but is instead distributedacross many different nodes. Such PKI is already used inOpenPGP-based systems, and may well point towards thefuture of PKI.

References[Hou+02] Russell Housley et al. Internet X. 509 public key

infrastructure certificate and certificate revoca-tion list (CRL) profile. Tech. rep. 2002.

[Sop10] SophosLabs.“Who’s your Verisign?” — Malwarefaking digital signatures. 2010. url: https://

nakedsecurity.sophos.com/2010/06/23/trojbhoqp-

verisign/.

[Woo10] Mike Wood. “Want my autograph? The use andabuse of digital signatures by malware”. In: VirusBulletin Conference. 2010.

[PC11] JR Prins and Business Unit Cybercrime. Dig-iNotar Certificate Authority breach’Operation BlackTulip’. 2011.

[HS13] Phillip Hallam-Baker and Rob Stradling. DNScertification authority authorization (CAA) re-source record. Tech. rep. 2013.

[Sec13] Krebs on Security. Security Firm Bit9 Hacked,Used to Spread Malware. 2013. url: http://

krebsonsecurity.com/2013/02/security-firm-

bit9-hacked-used-to-spread-malware/.

[Ced15] Kenney Lu Cedric Pernet. Fake Judicial SpamLeads to Backdoor with Fake Certificate Author-ity. 2015. url: http://krebsonsecurity.com/2013/02/security-firm-bit9-hacked-used-

to-spread-malware/.

[Moz15] Mozilla. Updated Firefox Security Indicators. 2015.url: https://blog.mozilla.org/security/

2015/11/03/updated-firefox-security-indicators-

2//.

[Moz16] Mozilla. Public Key Pinning. 2016. url: https:/ / developer . mozilla . org / en / docs / Web /

Security/Public_Key_Pinning.

94

Testing Program for Vulnerabilities  

Kwok Jun Kiat School of Computing 

National University of Singapore 13 Computing Drive Singapore 117417 

[email protected]  

ABSTRACT This paper seeks to investigate and explore various techniques and                   strategies used for analyzing and testing programs for               vulnerabilities. This will be done by discussing the benefits and                   pitfalls of the various vulnerability testing methods and to determine                   the scope and coverage of such techniques. Subsequently, this                 paper will then discuss methods to quantify the quality of these                     techniques. 

Categories   and   Subject   Descriptors K.6.5   [ Security   and   Protection ]:   Invasive   Software 

General   Terms Algorithms,   Reliability,   Security,   Verification. 

Keywords Security, Software Vulnerability, Vulnerability Testing, Fuzzer,           Disassembler,   Code   Coverage 

1. INTRODUCTION In recent years, technology have become an integral part in our                     everyday lives and simply cannot live without it. With this increase                     in reliance on technology, the number of threats to all electronic                     devices have been rapidly increasing. [1] In order to protect our                     way of life, it is inevitable that we must improve our own security                         mindset. There are two types of testing program for vulnerabilities.                   Firstly, would be to check that the software which we have obtained                       from any external sources, nowadays mainly from the internet, is                   safe to use. Safe to use meaning that it does not contain any                         malicious intent that would damage the computer system or open up                     a “backdoor” for attackers to access and take control over the                     system. Secondly, we need to ensure that the software written by a                       trusted source does not contain any bugs or result in any crashes.                       Issues within the code could lead to attackers exploiting them which                     could lead to all users of the software being targeted. Hence,                     vulnerability testing is extremely important to ensure the protection                 and   integrity   of   our   computer   systems. 

 

2. Vulnerability   Testing Vulnerability testing is the act of defining and classifying                 vulnerabilities in a targeted program. This involves running a                 scanning program on the target program to search for any possible                     security holes or contain any malware. When a program is                   developed, it could possibly contain millions of lines of code which                     gives instructions for the computer to execute. Even though each                   individual   component   within   the   program   should   have   already   been 

tested and proven to be working, it is not uncommon for errors to                         slip through the regression testing process. When the program is                   released for commercial use, the userbase will use the program in                     many unexpected ways and there may even be hackers who are                     intentionally looking for ways to exploit the program. The main aim                     of hackers would be to exploit a vulnerability in the program and                       use it to gain control or steal information from other users or the                         server hosting the program itself. Hence, the need for suitable                   means   to   ensure   the   credibility   and   integrity   of   the   program.  

 

2.1 Active   Testing Active testing is a testing technique where the tester, either a human                       tester or a vulnerability testing software, submits an input or a test                       case into the target software and analysis the result. The tester                     would then modify its input based on the result returned by the                       software   and   come   up   with   new   test   cases   to   submit.[6]  

After every single action performed by on the software while under                     testing, the output would be checked to verify if it is correct. If it is                             not correct, there is a problem with the software and would require                       fixing. The tester would continuously repeat the testing process and                   come up with more test cases to perform testing. The tester would                       need to build a mental model of the target software which will                       continue to grow as the software is being tested, and also to note                         down things which requires a follow­up to find and detect problems                     in   the   software. 

 

2.2 Passive   Testing In contrast to active testing, passive testing monitors the program                   and checks that the behaviour is correct without any interaction with                     the system. The testers follows a script to get information about the                       software. Passive testing generally involve creating a fixed test case                   that have been proven to work before which would be administered                     into the target software. This method is much more efficient as                     compared to active testing as it does not require a tester to adapt its                           interaction with the software. This would also reduce the risk of                     human error as the amount of human interaction with the testing                     process is minimal. However, passive testing alone is not effective                   enough for most software and would require a mixture of both                     active and passive testing to ensure the minimal quality of the                     software   product. 

 

3. Vulnerability   Scanning A vulnerability scanner allows early detection and handling of                 known   security   problems.   Through   the   implementation   of   current  

 95

 

standards into a vulnerability scanner, it will be possible to locate                     any potential security vulnerabilities.[3] Vulnerability scanning is a               form of passive testing that involves a database of terms which the                       scanner   will   go   through   to   detect   for   vulnerabilities. 

 

3.1 Drawbacks There   are   two   main   drawbacks   to   vulnerability   scanning.[7]  

 

3.1.1 Instance   only A vulnerability scanner is only able to scan for and detect as                       vulnerabilities in the program at the current instance in time. Any                     future updates or change in the environment of the program could                     lead to new problems emerging causing security holes to occur.                   This would require a scan to take place on a regular basis to ensure                           the   integrity   of   the   program. 

 

3.1.2 False   Positive,   False   Negative As a vulnerability scanner works based on a database containing                   information required to check a program for vulnerabilities, the                 scanner is unable to determine if the generated result is a false                       positive or false negative. Human judgement would then be                 required to step in and analyse the feedback to determine the actual                       state   of   the   program.  

Another issue concerning the use of a database is that the scanner is                         only able to detect known exploits present in the database. Any                     undiscovered vulnerabilities would unable to be detected by the                 scanner until the database itself is updated. Thus this requires a                     constant updating of the database and regular scan to take place to                       ensure the reliability of this method. This leads to vulnerability                   scanning being relatively unreliable as compared to other techniques                 in   determining   the   integrity   of   the   program.  

 

4.  Fuzzing Fuzzing is a method to test for vulnerabilities within a software                     through the administration of random inputs produced a fuzzing                 program, or else known as a fuzzer, which will result in the target                         software crashing. The use of a fuzzer can effectively provide an                     overview of the robustness of a software and seek out any critical                       issues within it. As it requires no access to the actual source code,                         fuzzing is considered a black box technique, although it can also be                       used during white box testing due to its potential to detect bugs                       efficiently without a review of the actual source code. After                   detecting the crash, the source code will become much easier to fix.                       [2]  

The main advantage of fuzzing is that it does not require a human                         tester to constantly interact with it for it to continue functioning. The                       tester only has to set up fuzzer and it would do the rest of the job by                                 itself. The fuzzer can be left untouched for as long as required until                         a crash has occurred. The result of a successful fuzzing can also                       conclude on the robustness of the targeted software. Due to its                     automated   nature,   fuzzing   is   considered   as   a   type   of   passive   testing. 

However, fuzzing also comes with its own set of drawbacks. For                     example, bugs that do not result in the program crashing will be                       undetected.   Crashes   that   only   trigger   under   specific   scenarios   will  

also slip through. At times, it could actually be very difficult to                       design a fuzzer capable of achieving high code coverage during its                     testing. More details about code coverage will be mentioned in the                     next   section.  

 

4.1 Types   of   fuzzers To produce a good fuzzer, many factors must be taken into                     consideration. The fuzzer must be able to determine the type of                     input required by the software at each individual instance. For                   example, when the program requires an input of the age of a person                         in the form of an integer value. The fuzzer must first recognise that                         the data type required is an integer, the fuzzer will then need to                         randomise the input value from the domain of a possible humans                     age instead of any random integer. Having a “smarter” fuzzer will                     significantly increase the efficiency of the fuzzer in seeking                 vulnerabilities   within   the   program. 

 

4.1.1 Mutation   Fuzzer Mutation fuzzer involves first generating a sample valid input that is                     acceptable by the target software. The fuzzer will then randomly                   mutate the valid input to produce new mutated input which will then                       be used as test cases. Due it being mutated from an original source,                         the code coverage of the mutation fuzzer could be lesser as                     compared to other types as only codes which makes use of this set                         of inputs will be executed. An example usage of a mutation fuzzer                       would be through an intercepting proxy, such as burp suite [9], that                       can intercept and modify network traffic between applications. The                 fuzzer can intercept the packet, randomly modify it, and send it back                       out to try and produce a crash or abnormal response from the                       application. 

 

4.1.2 Generation   Fuzzer As compared to mutation fuzzers which require an initial test case,                     generation fuzzers does not require any inputs as prerequisites.                 However, the fuzzer would require a database of possible input to                     randomly select through in order to generate the test cases. Even                     though it will be more time consuming to produce a generation                     fuzzer, generation fuzzers can achieve a higher code coverage as it                     can produce more valid inputs that are targeted towards a single                     portion of the program. An example of the generation fuzzer would                     be web browser fuzzing, such as Nduja fuzzer[15] which runs on                     the Grinder Framework[16]. The test cases can be generated                 through scraping the target web browser, such as firefox’s web API                     [17], and randomly producing input based on the types of function                     calls   available   to   that   particular   browser. 

 

5. Coverage Coverage measures the amount of blocks of codes which are                   executed while test are being conducted. [9] Code coverage is                   attained by attaching specific tools for binary instrumentation to run                   tests on the targeted software. The tool will then provide the                     percentage of the code that is executed during the test. The main aim                         of   coverage   would   be   to   measure   the   quality   of   a   set   of   test. 

Code coverage is not a measurement of the the integrity of the                       software,   in   fact,   it   is   more   of   a   measurement   of   the   performance   of  

 96

 

the testing program. Attaining 100% code coverage does not                 guarantee a software to be completely tested, it only means that                     every single block of code have been tested under a given set of                         conditions. Having a high code coverage on a single program as                     compared to another would imply that the formal program have                   been through more blocks of code that the other, the actual                     efficiency or accuracy in determining which program is better                 cannot be guaranteed. Code coverage also does not assure that the                     portions of code that have been covered will be completely free of                       vulnerabilities, it only guarantees that the inputs contained within                 the current test case will not produce any error that differs from the                         expected   output. 

Using code coverage measurement will help create additional test                 cases to increase coverage. [5] The results of obtained from code                     coverage will clarify exactly which portions of the program have                   been tested by each individual test cases. This would provide a                     quantitative   measure   of   the   quality   of   the   testing   tool   or   test   cases.  

 

5.1 Types   of   Code   Coverage There are multiple criteria to determine code coverage, each criteria                   would differ from another with no single criteria being absolutely                   greater than another when determining which criteria to use. It                   would be best to use a multitude of different criteria to determine the                         actual   coverage   of   the   program.[8] 

 

5.1.1 Statement   Coverage Statement coverage, also commonly known as line coverage,               measures if every statement within the software have been executed.                   Control codes such as if, for and switch will be covered including                       the statements within them. [18] As the most basic type of                     coverage, statement coverage would be inaccurate under certain               conditions. For example, in Figure 1, an if statement without an                     else, should the condition in the if statement is fulfilled, the test                       would achieve complete coverage. However, the case where the                 condition is false, i != 1, need not be included to achieve complete                         code   coverage. 

int    i; if ( i ){              //Code   to   be   tested } 

Figure   1:   Sample   code   for   code   coverage   testing 

 

5.1.1 Branch   Coverage Branch coverage is a coverage method that seeks to ensure that                     every single possible branch at each point of decision have been                     executed to ensure that every block of code have been executed.                     [10] This means that every true or false statement in the program                       would have to be taken both ways to ensure a complete coverage of                         the program. This would take into account the case which does not                       work in statement coverage, however, branch coverage would fail at                   short­circuit operators. For example, in Figure 2, only one of the                     condition, i=1 or j=1, needs to be fulfilled for it to be completely                         covered   by   branch   coverage. 

 

 

int    i ,    j; if (    i    ||    j    ){             //Code   to   be   tested } 

Figure   2:   Sample   code   for   code   coverage   testing 

 5.2.2 Function   Coverage In comparison to branch coverage which focuses more on the actual                     source code of the program, functional coverage focuses more on                   the various functions or subroutines present within the program. An                   example of a way to calculate function coverage would be to get a                         percentage of the number of functions that have been measured over                     the   total   number   of   functions   within   a   software.  

 

5.2 Binary   Instrumentation One major difficulty in determining code coverage for large                 programs that during black box testing is that it is hard to keep track                           of which functions or blocks of code have been tested before and                       which have not. A solution to overcome this issue is to use binary                         instrumentation tool, for example Intel’s Pin.[5] Pin is commonly                 known as a Just­In­Time compiler that performs instrumentation at                 the run time on the compiled binary files. This process does not                       require recompiling the source code and can even support                 instrumentation   of   programs   that   dynamically   generates   code. 

Pin intercepts the execution of the first instruction of the executable                     and “recompiles” into a new code starting from the same                   instruction. The new code will then work similarly to the original                     one except that whenever a block of code has been exited, pin will                         regain control and generate the next set of code for the branch target                         to continue execution. Pin keeps all of the code that have been                       generated in memory for reusing and directly branching from one                   sequence   to   another   to   improve   efficiency.   [5] 

To configure how pin works and what is to be executed when a pin                           intercepts a code execution, a pintool have to be made. A pintool is                         a C++ program that includes a “pin.H” header file which contains                     functions to register instructions to be called at different points of                     the programs execution. These functions include PIN_INIT() which               initialises pin, INS_AddInstrumentFunction(Instruction) which       register instructions to be called, and PIN_AddFiniFunction(Fini)             that   registers   a   Fini   function   to   be   called   when   the   program   exits. 

 

5.2.1  Determining   Code   Coverage Using pin to determine code coverage is possible through tracking                   exactly which block of code have been executed during the                   execution of the program. From the output, the quality of each test                       case or testing software can be quantified and used to compare and                       determine if one is greater than another. However, to determine the                     actual   percentage   code   coverage   is   a   much   more   difficult   task.  

The main issue with using pin as a code coverage tool is that it is                             extremely difficult to attain the actual total number of blocks present                     within the target software. Pin is only capable of keeping track of                       the   blocks   of   code   that   have   been   executed   at   least   once   over   the  

 97

   

 

course of all the test case being administered into the software. Any                       blocks that have not been executed before, would be left out when                       calculating the overall percentage code coverage. As a result, the                   percentage code coverage attained by pin is an overestimate of the                     actual code coverage done by the test case. Even though this is                       situationally inaccurate if used to determine if a set of test cases is                         capable of achieving a high code coverage, this problem might be                     insignificant if it is only used to compare between various test                     cases. 

For example, over a course of all the runs on a program, 10 blocks                           of code have been identified by pin. Let there be three test cases                         where the first test case have executed blocks 1­8, the second test                       case 2­7, and the third test case 3­10. It is obvious that the first test                             case is better than the second as the set of blocks visited by the                           second test case is a subset of the the first test case. On the other                             hand, the first and third test case have covered the same number of                         blocks with six of them being the same and 2 of them being unique                           to each test case. Even though, it is inaccurate to say that the test                           cases have both 80% coverage, it can be determined that both these                       test   cases   have   the   same   percentage   code   coverage.  

 

5.2.2 Detecting   Vulnerabilities Being able to insert instrumentation code to keep track of the                     workings of a program is not limited to just code coverage                     purposes. At every predetermined instance of the program, pin is                   able to attain other information such as the state of the heap or                         memory at given instance to check for abnormalities and seek out                     any   potential   vulnerabilities.[13]  

For example, as seen from Figure 2, the code would result in a heap                           overflow due to exceeding the size of the buffer allocated by the                       memory. 

char     * buf    =    malloc ( 8 ); int    i    =     0; for ( i = 0 ;    i <= 8 ;    i ++){             buf [ i ]     =     'A'; } 

Figure   2:   C   source   code   producing   a   heap   overflow 

To check for any overflow, the pin tool will have to first store the                           base address and size of the buffer. Whenever any instruction                   which affects memory, such as lw(load word) or sw(store word),                   occurs during execution, pin will check if the destination address is                     within the memory allocated to determine if an overflow has                   occurred.   [12] 

 

5.3 Disassembler A disassembler converts an executable in machine language into                 assembly code as much as possible. However, a disassembler is                   unable to retrieve the assembly code entirely. For example, it is                     impossible to disassemble an exe file and reassemble the output into                     another executable that does the exact same thing. [14] Good                   disassemblers, such as IDA Pro, can be easily purchased through                   the   internet   at   a   hefty   price.[4]   The   disassembler   can   be   used   during  

black box testing to check for any explicit malicious code present                     within   the   software. 

However, using a disassembler can be a good tool for assisting in                       calculating code coverage. As mentioned above that it is extremely                   difficult above to attain the total number of blocks within a                     software. Using a disassembler, determining the exact number of                 blocks becomes a trivial task as it would provide the entirety of the                         assembly code. The drawback to using this technique to determine                   the actual number of blocks would be that disassembling large                   programs and going through all the blocks would take a large                     amount   of   time. 

 

6. Conclusion There are many tools readily available for users to download and                     use to ensure the protection of their system. Even though most of                       the programs such as fuzzers or disassemblers are only useful                   towards heavily security geared users, there are other programs that                   would suit the generic user better. An example of this would be                       virustotal [11], a free online service that analyzes suspicious files                   and URLS, which have a much higher detection rate due to its                       pooled malware definition database. By simply taking a simple step                   to scan any untrusted files, the users can ensure the safety of their                         computer systems. This security mindset should be taken seriously                 and integrated into everyone's lifestyle to ensure the wellbeing and                   protection   of   our   way   of   life. 

 

7. REFERENCES [1] A   New   Zero­Day   Vulnerability   Discovered   Each   Week. 

(2016).   Symantec.   Retrieved   24   July   2016,   from https://www.symantec.com/content/dam/symantec/docs/infographics/istr­zero­day­en.pdf 

[2] Hillman,   M.   (2013).   MWR   InfoSecurity.   Retrieved   24   July 2016,   from https://www.mwrinfosecurity.com/our­thinking/15­minute­guide­to­fuzzing/ 

[3] Houghton,   K.   (2003).   Sans.org.   Retrieved   24   July   2016,   from https://www.sans.org/reading­room/whitepapers/threats/vulnerabilities­vulnerability­scanning­1195 

[4] IDA:   Ordering.   Hex­rays.com.   Retrieved   24   July   2016,   from https://www.hex­rays.com/products/ida/order.shtml 

[5] Pin   ­   A   Dynamic   Binary   Instrumentation   Tool   |   Intel® Software.   (2012).Software.intel.com.   Retrieved   24   July   2016, from https://software.intel.com/en­us/articles/pin­a­dynamic­binary­instrumentation­tool 

[6] Active   Testing.   www.tutorialspoint.com.   Retrieved   24   July 2016,   from http://www.tutorialspoint.com/software_testing_dictionary/active_testing.htm 

 98

 

[7] An   Overview   of   Vulnerability   Scanners.   (2008).   Retrieved   24 July   2016,   from http://www.infosec.gov.hk/english/technical/files/vulnerability.pdf 

[8] What   is   test   coverage   in   software   testing?   It’s   advantages   and disadvantages.   (2016).Istqbexamcertification.com.   Retrieved 24   July   2016,   from http://istqbexamcertification.com/what­is­test­coverage­in­software­testing­its­advantages­and­disadvantages/ 

[9] Burp   Suite.   Portswigger.net.   Retrieved   24   July   2016,   from https://portswigger.net/burp/ 

[10] Branch   Testing.   www.tutorialspoint.com.   Retrieved   24   July 2016,   from http://www.tutorialspoint.com/software_testing_dictionary/branch_testing.htm 

[11] VirusTotal   ­   Free   Online   Virus,   Malware   and   URL   Scanner. (2016).   Virustotal.com.   Retrieved   24   July   2016,   from https://www.virustotal.com/ 

[12] Salwan,   J.   (2013).   shell­storm   |   Stack   and   heap   overflow detection   at   runtime   via   behavior   analysis   and   Pin. Shell­storm.org.   Retrieved   24   July   2016,   from http://shell­storm.org/blog/Stack­and­heap­overflow­detection­at­runtime­via­behavior­analysis­and­PIN/ 

[13] Salwan,   J.   (2013).   shell­storm   |   Taint   analysis   and   pattern matching   with   Pin.Shell­storm.org.   Retrieved   24   July   2016, from http://shell­storm.org/blog/Taint­analysis­and­pattern­matching­with­Pin/ 

[14] Stamp,   M.   (2006).   Information   security.   Hoboken,   N.J.: Wiley­Interscience. 

[15] Valotta,   R.   (2013).   Fuzzing   with   DOM   Level   2   and   3   ­ Tentacolo   Viola.   Sites.google.com.   Retrieved   24   July   2016, from https://sites.google.com/site/tentacoloviola/fuzzing­with­dom­level­2­and­3 

[16] Fewer,   S.   (2011).   stephenfewer/grinder.   GitHub.   Retrieved   24 July   2016,   from   https://github.com/stephenfewer/grinder 

[17] Web   APIs.   Mozilla   Developer   Network.   Retrieved   24   July 2016,   from   https://developer.mozilla.org/en/docs/Web/API 

[18] Woodward,   M.,   Hedley,   D.,   &   Hennell,   M.   (1980). Experience   with   Path   Analysis   and   Testing   of   Programs.   IEEE Transactions   On   Software   Engineering,   SE­6(3),   278­286. http://dx.doi.org/10.1109/tse.1980.230473 

 

 

 99