impact of heartbleed bug in android and counter measures

International Journal on Computational Sciences & Applications (IJCSA) Vol.5, No.2,April 2015

DOI:10.5121/ijcsa.2015.5208 87

Impact of HeartBleed Bug in Android and Counter Measures

Santosh Naidu P and Kasamsettty KedarNath

Department of CSE,M.V.G.R College of Engineering,Vizianagaram, India

Abstract Now a days smart phones revolving around the globe. The no of Android users are also increasing day by

day, the main problem arises here. The Android operating system based devices are more advance and also

prone to bugs when compared to other OS devices. Mainly Android comes with lot of Apps so in order to

provide the services to the user. So the App developers was in a hurry to release the Apps as per market

strategy which causes vulnerabilities. Some of them intentionally creates the Apps in order to hack the

device. When compared to other operating system Android is a open source so everybody trys to perform

the reverse-engineering of Apks and perform some modifications, release the Apks into the market. We

believe that our study will awaken the developers and researches.

Keywords— OpenSSL; TLS; DTLS; gadgets

1.INTRODUCTION

Android and ios, and the provisions (applications) that run on these platforms have picked up

market share vastly . The vicinity of application development systems and rich libraries, and also

simple dispersion by means of online application stores, for example, Google Play furthermore

Apple App Store have significantly brought down the boundary to passage in application

improvement and organization. Not withstanding, the low boundary to enter the business sector

implies applications (or application upgrades) are liable to constrained investigation before

scattering, permitting slip inclined applications through and thusly influencing client experience.

A first step towards redressing this circumstance is to comprehend the way of bugs and the bug-

fixing methodology connected with cell phone stages and applications. In any case, exact bug

studies have so far centered generally on desktop and also server applications. The main cause

for the vulnerabilities occurring in the Android is open-source so that any App Developer can peek into Apks by following the procedure of Reverse- Engineering with the help of apk-tool and

we can acquire all the source code used by the App Developer, and the modified can be released

into the store. We are having three stages of balancing the study of Bugs.

International Journal on Computational Sciences & Applications (IJCSA) Vol.5, No.2, April 2015

88

At first we need to focus on the quality of bug reports , fix process, fix time, priority, categories

and engagement of the community during the fix process. The main problem occurs at stage of

reporting time and fixing of bugs will vary. There will be lot of gap between these two stages.

Secondly we need to maintain the life-cycle process of bug with the hlep of google code. Mainly

every App developer will maintain their bug repository therefore everybody can access the bug

reports and try to fix them.

Finally at third stage Android Apps which in turn access the information related to user which can

be harmful. Day-to-day these bugs increasing widely.

2.HEARTBLEED BUG

Heartbleed is a security bug in the OpenSSL cryptography library. OpenSSL is a broadly utilized

usage of the Transport Layer Security(tls) convention. Heartbleed may be misused whether the

gathering utilizing a helpless OpenSSL case for TLS is a server or a customer.

Heartbleed results from dishonorable info acceptance (because of a missing limits check) in the

execution of the TLS pulse augmentation, the heartbeat being the premise for the bug's name. The

powerlessness is delegated a cradle over-perused, a circumstance where programming permits

more information to be perused than ought to be permitted. An altered rendition of OpenSSL was

discharged on April 7, 2014, on that day Heartbleed was openly revealed. Around then,

practically 17 percent (around a large portion of a million) of the Internet's safe web servers

ensured by trusted powers were accepted to be powerless against the strike, permitting burglary

of the servers' private keys and clients' session treats and passwords. The Electronic Frontier Foundation, Ars Technica, and Bruce Schneier all regarded the Heartbleed bug "disastrous".

Forbes cyber security writer Joseph Steinberg composed, "Some may contend that [heartbleed] is

the most exceedingly bad helplessness found (in any event as far as its potential effect) since

business movement started to stream on the Internet."

As of May 20, 2014, 1.5% of the 800,000 most prevalent TLS-empowered sites were still

defenseless against Heartbleed. Heartbleed is enlisted in the Common Vulnerabilities and

Exposures framework as CVE-2014-0160. The elected Canadian Cyber Incident Response Center

issued a security release exhorting framework chairmen about the bug. Different TLS usage, for

example, Gnutls and Mozilla's Network Security Services, are not influenced, as the deformity

lies in OpenSSL's execution instead of in the Internet convention itself. Thus, none of Microsoft's

items or administrations are influenced by Heartbleed.

A.Appearance

The Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer

Security (DTLS) conventions was proposed as a standard in February 2012 by RFC 6520. It gives

an approach to test and keep alive secure correspondence joins without the need to renegotiate the

association each one time. The helpless code was received into across the board use with the

arrival of OpenSSL adaptation 1.0.1 on March 14, 2012. Pulse backing was empowered of

course, creating influenced renditions to be defenseless naturally.


89

B.Discovery

As per Mark J. Cox of OpenSSL, Neel Mehta of Google's security group reported Heartbleed on

April 1, 2014. The bug was named by a designer at Codenomicon, a Finnish cybersecurity

organization, which additionally made the draining heart logo, and dispatched the space

Heartbleed.comto clarify the bug to the general population. As per Codenomicon, Neel Mehta

initially reported the bug to OpenSSL, however both Google and Codenomicon ran across it

autonomously. Codenomicon reports April 3, 2014 as their date of disclosure of the bug and as

their date of warning of NCSC-FI (previously known as CERT-FI) for helplessness coordination.

C.Code patch

Bodo Moeller and Adam Langley of Google arranged the fix for Heartbleed. The ensuing patch,

which was added to Red Hat's issue tracker, is dated March 21, 2014. The following ordered date

accessible from general society confirmation is the case by Cloudflare that they altered the defect on their frameworks on March 31, 2014. Stephen N. Henson connected the fix to OpenSSL's

variant control framework on 7 April. The initially settled adaptation, 1.0.1g, was discharged on

that day.

3.BEHAVOIUR OF HEARTBLEED BUG

The RFC 6520 Heartbeat Extension tests TLS/DTLS secure correspondence interfaces by

permitting a workstation toward one side of an association with send a "Pulse Request" message,

comprising of a payload, normally a content string, alongside the payload's length as a 16-

bitinteger. The getting workstation then must send literally the same payload again to the sender.

The influenced adaptations of OpenSSL allot a memory support for the message to be returned

focused around the length field in the asking for message, without respect to the genuine size of

that message's payload. Due to this disappointment to do fitting limits checking, the message

returned comprises of the payload, potentially emulated by whatever else happened to be in the

distributed memory cushion.


90

Fig 1. A Depiction of Heartbleed

Heartbleed is accordingly misused by sending a distorted pulse demand with a little payload and

substantial length field to the powerless gathering (typically a server) so as to inspire the

exploited person's reaction, allowing agressors to peruse up to 64 kilobytes of the exploited

person's memory that was liable to have been utilized long ago by OpenSSL. Where a Heartbeat

Request may ask a gathering to "send back the four-letter word 'winged creature'", bringing about

a reaction of "fledgling", a "Heartbleed Request" (a noxious pulse solicitation) of "send back the 500-letter word 'fowl'" would result in the victimized person to return "feathered creature" took

after by whatever 496 characters the victimized person happened to have in dynamic memory.

Agressors along these lines could get delicate information, trading off the classifiedness of the

exploited person's interchanges. Despite the fact that an assaulter has some control over the

revealed memory piece's size, it has no influence over its area, and thusly can't pick what

substance is uncovered. OpenSSL normally reacts with the lumps of memory it has most as of

late tossed.

A.Affected OpenSSL installations

The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive). Later versions

(1.0.1g and ulterior) and previous versions (1.0.0 branch and older) are notvulnerable.

Installations of the affected versions are vulnerable unless OpenSSL was compiled with -

DOPENSSL_NO_HEARTBEATS.


91

B.Vulnerable program and function

Define abbreviations and acronyms the first time they are used in the text, even after they have

been defined in the abstract. Abbreviations such as IEEE, SI, MKS, CGS, sc, dc, and rms do not

have to be defined. Do not use abbreviations in the title or heads unless they are unavoidable. The

vulnerable program source files are t1_lib.c and d1_both.c and the vulnerable functions are

tls1_process_heartbeat() and dtls1_process_heartbeat().

4.IMPACT OF HEARTBLEED BUG

Any android gadgets running the 4.1.1 form of jam bean are vulnerable after the content alter has

been finished, the paper is prepared for the format. t's still vague what number of gadgets are

defenseless, yet the harm is prone to be substantially more held than Heartbleed. The most

helpless targets are EAP-based switches that require both an individual login and a secret key — an answer regularly found in remote Lans. In those cases, an assaulter could utilize Heartbleed to

draw a private key from the switch or confirmation server, successfully bypassing any efforts to

establish safety. All the more significantly, the strike could just target gadgets inside Wi-Fi range,

genuinely restricting the potential targets. This specific variant of the strike may be slower to

close, But it ought not be about as across the board as the first bug, since the universe of

defenseless gadgets is easier. An alternate concern is Android gadgets even now running the 4.1.1

rendition of Jelly Bean, which are known to be powerless against the bug. In a switch based ambush, the ambusher would offer an open Wi-Fi sign and after that perform the Heartbleed

assault to draw information from any associated gadgets. It's another line of assault, leaving

numerous Android gadgets recently defenseless. As now, a large number of gadgets were all the

while running 4.1.1, including a few varieties of the HTC One. Numerous were redesigned in the

wake of the strike, yet others may even now be defenseless.

All the more extensively, its an update that the security world is even now working through the

different impacts of Heartbleed. Significantly after the focal servers have been fixed, scientists

can find more darken strike that follow less evident targets. Helpless administrations like

OpenSSL and TLS were generally utilized, leaving an expansive reach of potential targets. "The

web and email are the greatest clients of [tls], however in no way, shape or form the main ones"

says Columbia teacher Steve Bellovin, "Any unpatched executions are at danger from

Heartbleed." Most current frameworks will have moved up to a Heartbleed-verification adaptation of OpenSSL at this point, yet there's dependably the worry that a few access focuses

will stay unpatched. With respect to the more extensive effect of Heartbleed, Errata Security

originator Robert David Graham assesses just a large portion of the harm is cleaned up, proposing

Cupid may be the minimum of the groups inconveniences. "We'll be seeing vital Heartbleed

hacks for a considerable length of time,".


92

Fig 2. A proof-of-concept exploitation of Android 4.1.1 mobile browser using the Heartbleed exploit

5.COUNTERMEASURES FOR HEARTBLEED BUG At present there are about 17 antivirus applications on Google Play marked as "Heartbleed finders". Six of them output the OpenSSL library having a place with the Android stage for

vulnerabilities. Lamentably, this technique isn't sufficient for identifying the Heartbleed weakness

on Android. But in restricted Android adaptations (principally 4.1.0-4.1.1), the lion's share of

Android stages are not powerless, as most forms utilization OpenSSL libraries that are not

helpless or essentially have the OpenSSL pulse usefulness debilitated. In any case, Android

applications much of the time use local libraries, which either specifically or by implication

power defenseless OpenSSL libraries. Hence, despite the fact that the Android stage itself is not

powerless, ambushers can even now ambush those helpless applications. They can commandeer

the system movement, redirect the application to a vindictive server and after that send made

heartbeats messages to the application to take delicate memory substance.

Applications with powerless OpenSSL libraries and affirmed this assault. The greater part of the

powerless applications are recreations, and some are office-based provisions. In spite of the fact

that there is very little profitable data in the diversion applications, ambushers can take Oauth

tokens (access tokens and revive tokens) to commandeer the amusement accounts; thusly, the

data may be valuable for commandeering those connected interpersonal organization accounts

with off base arrangements. Office applications helpless against Heartbleed are considerably

more hazardous because of further potential information spillage. Inside the 17 Heartbleed locator

applications on Google play, just 6 identifiers check introduced applications on the gadget for

Heartbleed powerlessness. Inside the 6, 2 report all applications introduced as "Protected",

including those we affirmed as defenseless. One locator doesn't indicate any application output

results and another doesn't check the OpenSSL form accurately. Just 2 of them did a better than

average scout Heartbleed weakness of applications. Despite the fact that they conservatively

marked some non-helpless applications as defenseless, we concur it is a suitable report which


93

highlights both the vulnerabilities and the linkage botches. We've likewise seen a few fake

Heartbleed indicators in the 17 applications, which don't perform genuine discoveries nor show

recognition results to clients and just serve as adware.android's security sandbox outline keeps a

noxious application from having the capacity to get to memory substance utilized by partitioned

applications. Additionally lucky is the way that the greater part of Android telephones aren't

powerless. Still, the danger shouldn't be released. To end Heartbleed's hang on the server,

merchants and administration suppliers must embrace the Fixed OpenSSL programming.

A.The right kind of wrong: Coding error protects some Android apps from

Heartbleed

From the start, some Android office benefit requisitions likewise had all the earmarks of being

helpless. Be that as it may the scientists discovered a typical coding oversight really implied the

Heartbleed bug wouldn't work. "A deeper look indicates that these applications either commit an

error in the local code linkage or simply hold dead code," "In this manner, when they attempt to conjure SSL capacities, they straightforwardly utilize the non-helpless OpenSSL library held

inside the Android OS, as opposed to utilizing the powerless library gave by the application."

REFERENCES

[1] Nielsen, "Smartphones Account for Half of all Mobile Phones, Dominate New Phone Purchases in the

US," March 29, 2012, http://blog.nielsen.com/nielsenwire/category/online-mobile/

[2] "Google play," April 2012, https://play.google.com/.

[3] E. Linstead and P. Baldi, "Mining the Coherence of GNOME Bug Reports with Statistical Topic

Models," in Proceedings of the 2009 6th IEEE International Working Conference on Mining Software

Repositories, ser. MSR '09. Washington, DC, USA: IEEE Computer Society, 2009, pp. 99-102.

[4] J. Śliwerski, T. Zimmermann, and A. Zeller, "When do changes induce fixes?", in Proc. MSR, 2005,

pp. 1-5.

[5] M. Fisher, M. Pinzger, and H. Gall, "Analyzing and relating bug report data for future tracking", in

Proc. WCRE, 2003, pp. 90-99.

[6] A. Pathak, A. Jindal, Y. C. Hu, and S. P. Midkiff, "What is keeping my phone awake?: characterizing

and detecting no-sleep energy bugs in smartphone apps", in Proceedings of the 10th international

conference on Mobile systems, applications, and services, ser. MobiSys'12. New York, NY, USA:

ACM, 2012, pp. 267-280. [Online]. Available: http://doi.acm.org/10.1145/2307636. 2307661

[7] OpenRadar, "Openradar bug repository", http://openradar. appspot.com/.