A Framework To Eliminate Backdoors From Response .

2y ago
23 Views
2 Downloads
585.17 KB
15 Pages
Last View : 18d ago
Last Download : 2m ago
Upload by : Kamden Hassan
Transcription

A Framework to Eliminate Backdoors from Response-ComputableAuthenticationShuaifu Dai1 , Tao Wei1,2 , Chao Zhang1 , Tielei Wang3 , Yu Ding1 , Zhenkai Liang4 , Wei Zou11Beijing Key Lab of Internet Security TechnologyInstitute of Computer Science and TechnologyPeking University, ChinaAbstract—Response-computable authentication (RCA)is a two-party authentication model widely adopted byauthentication systems, where an authentication systemindependently computes the expected user response andauthenticates a user if the actual user response matchesthe expected value. Such authentication systems havelong been threatened by malicious developers who canplant backdoors to bypass normal authentication, whichis often seen in insider-related incidents. A maliciousdeveloper can plant backdoors by hiding logic in sourcecode, by planting delicate vulnerabilities, or even by usingweak cryptographic algorithms. Because of the commonusage of cryptographic techniques and code protection inauthentication modules, it is very difficult to detect andeliminate backdoors from login systems. In this paper,we propose a framework for RCA systems to ensure thatthe authentication process is not affected by backdoors.Our approach decomposes the authentication module intocomponents. Components with simple logic are verifiedby code analysis for correctness; components with cryptographic/obfuscated logic are sandboxed and verifiedthrough testing. The key component of our approach isNaPu, a native sandbox to ensure pure functions, whichprotects the complex and backdoor-prone part of a loginmodule. We also use a testing-based process to either detectbackdoors in the sandboxed component or verify that thecomponent has no backdoors that can be used practically.We demonstrated the effectiveness of our approach inreal-world applications by porting and verifying severalpopular login modules into this framework.I. I NTRODUCTIONUser authentication is the basis of access control andauditing. Through the login process, the authenticationsystem verifies a user’s identity to grant the user properprivilege in the system. The important role of a loginmodule makes it an attractive target for attackers. Acommon type of login module attacks is through backdoors: malicious developers intentionally leave codein a login module to bypass normal authentication,allowing them to get unauthorized privilege. There havebeen many incidents where insiders left backdoors inlogin modules to gain unauthorized access to computersystems, e.g., the backdoor in Cart32 Shopping Cart [5].*Corresponding author. Email: wei tao@pku.edu.cn2University of California, BerkeleyCollege of Computing, Georgia Institute of Technology4School of Computing, National University of Singapore3Due to the complexity of large software systems, it isvery hard to completely detect this type of threats.Based on how the authentication system interacts withusers, it typically falls into two categories: after a userresponds to the authentication challenge, the authentication system either compares the user’s response with anexpected value computed from known credentials of theuser, or uses the user’s response as part of a complicatedauthentication computation. The authentication systemof the first type computes the expected response valueusing credentials on the server. The user is authenticatedif the computed value matches the user’s response.We refer to this type of authentication as responsecomputable authentication (RCA). In the other type ofauthentication systems, the user response is used as aninput to the authentication computation, which is basedon techniques such as public-key cryptography [26] andzero-knowledge proof [6]. In this paper, we focus onbackdoors in the first type of authentication system,response-computable authentication (RCA), which iswidely used in authentication systems.Malicious developers have various ways to plant andhide backdoors in RCA login modules. The simplestway is to add a hard-coded username/password pair.Alternatively, a backdoor condition can be an obfuscated relationship between the username and password.Besides user inputs, a backdoor may also be triggeredby system events or internal state of the authenticationprocess. Moreover, malicious developers can exploit avulnerability in the login module to circumvent thenormal authentication process. They can also embedcryptographic backdoors in RCA modules, e.g., usinga carefully constructed insecure hash function to maketwo responses collide at a controllable probability toallow the backdoor’s creator to login.Although it is straightforward to detect hard-codedusername/password pairs, it is very difficult to useprogram analysis to find backdoors in login modulesthat involve heavy cryptographic computations or codeprotection and obfuscation. Manual source code reviewis also difficult to detect cryptographic backdoors. Furthermore, a malicious developer can directly instrument

ServerUser0) login requestUsually, step 2-4are combined toa function L()1) ChallengeCompute Responsebased on(Password, Challenge)3) Response2) ResponseREJECT 4') N4) YACCEPTFigure 1.(RCA).Typical steps in Response-Computable Authenticationbackdoors at the binary level. For example, a trojanedcompiler can create a backdoor in the programs it generates, which is based on hard-coded passwords [32].Figure 1 illustrates the process of a typical two-partylogin protocol using RCA, based on techniques suchas plain text password, CRAM-MD5 [21], RSA SecureID [3], time-based one-time password (TOTP) [4],and HMAC-based one-time password (HOTP) [24]. Onreceiving the authentication request (step 0), the servergenerates a challenge to the user (step 1). After itreceives the response from the user (step 2), the servercomputes the expected response value using the credentials on the server (step 3). It authenticates the userif the user’s response matches the server’s computedresponse value (step 4). Step 3 and step 4 form theRCA authentication procedure. We use L() to denotethe RCA decision function. It maps user response toa boolean value, TRUE for “accept” and FALSE for“reject”.By studying several types of RCA backdoors, weobserve that all such systems treat the decision functionL() as a blackbox: they authenticate users only bythe return value of L(), no matter how this returnvalue is generated. As a result, they cannot distinguishauthentication decisions resulted from authentic userresponse and those resulted from backdoors. For example, when the L() contains a backdoor using a hardcoded username, it immediately returns true when theusername is provided.In this paper, we design a secure framework for RCAto ensure that the authentication result is not affected bybackdoors. Since backdoors in login modules are causedby the blackbox nature of the authentication process, thehigh-level idea is to decompose the RCA login moduleinto components: for components with simple logic,verify theirs correctness by code review and analysis;for components with cryptographic/obfuscated logic,sandbox them to prevent the logic from being affectedby attackers, and then verify the logic through testing.The decision function L() has two main components,response computation (denoted as f ()) and responsecomparison. The response comparison is a simple components that can be directly verified by code review,but we need to make sure it cannot be bypassed.The response-computation function depends on assistantcomponents, such as reading the password database.The assistant components are typically simple and canbe checked for backdoors by code review and analysis. The major challenge arises from the responsecomputation function, which often contains a lot ofcryptographic operations, making it very difficult todetect backdoors by code inspection. Our solution ensures that the response-computation function to be apure function, which returns the same result withoutside effects each time it is invoked on the same set ofarguments [14].Our approach ensures response-computation functionto be free of backdoors based on the following observation: for one login try, there is only one correctresponse which we can explicitly get from the responsecomputation function. Following this observation, weuse formal analysis to identify the upper bound ofbackdoor usability in a login module, which forms atheoretical basis of our testing methods. Through thetesting, either we can detect the possible backdoor or wecan ensure the backdoor cannot be used by its creator.To the best of our knowledge, this approach is the firstto give formal analysis of probability of authenticationbackdoor usability.To achieve this goal, we design NaPu, a nativesandbox to ensure pure functions, and use it to purifythe response-computation function. NaPu has severalfeatures: vulnerability isolation, global state isolation,and internal state reset. These features can prevent anattacker from triggering backdoors stealthily. We buildthe NaPu sandbox based on Native Client (NaCl) [37],and implement our framework to secure RCA modules.We ported several widely used login modules, such asCRAM-MD5, HOTP, TOTP, into this framework, andverified that these ported libraries are backdoor-free.Our results showed that our solution can be easily applied to real-world systems with acceptable performanceoverhead.In summary, we develop a solution to ensure thatresponse-computable authentication is free of impactsfrom backdoors. Our solution either detects hidden

backdoors or ensures the malicious developer cannotbypass authentication even with a backdoor plantedin the authentication process. Our solution makes thefollowing contributions: We propose a novel framework to guarantee thatthe decision of an RCA login module is not affected by backdoors. The key idea is to ensure eachsub-component of the authentication process freeof backdoor influence, either by analysis of simpleapplication logic, or by sandboxing and testingcryptographic/obfuscated logic. We give a systematic analysis of authenticationbackdoors, and formally prove the upper bound ofpossibility that a backdoor can be used by attackersin an RCA login module. We build NaPu, a NaCl-based pure-functionenforcing sandbox, to support the framework. We have prototyped our framework and portedmany widely-used login modules. Our evaluationverified that they are free of backdoors.The rest of this paper is organized as follows: Section II introduces RCA backdoors and the adversarymodel. Section III describes our intuition and approachdesign. Section IV analyzes the security of our solution.Section V explains our prototype implementation. Wepresent the evaluation results in Section VI. Section VIIdiscusses limitation of our solution. We discuss relatedwork in Section VIII. Section IX concludes this paper.II. BACKGROUNDIn this section, we describe the adversary model forour approach, i.e., what malicious developers can do andwhat they cannot to launch an RCA-backdoor attack.Furthermore, we discuss characteristics of backdoors inRCA login modules, and categorize these backdoors.We also introduce the concept of pure function, whichis the basis of our solution.A. Adversary ModelWe focus on RCA backdoors in login modules. Thebackdoors are implemented by malicious developerswho have the opportunity to access developing environments and modify code or binaries. These maliciousdevelopers include malicious insider developers andeven intruders. They can implement backdoors in software during the development process, but they cannotinterfere in the deployment environment.Methods to plant backdoors. Backdoors can be planted in different ways. The straightforward way is tomodify the source code directly. For example, in theProFTPD incident [2], the intruder concealed a backdoor in the source code package. The malicious developer can modify the development environment, suchas the compiler. Thompson’s compiler backdoor [32]is such an example. The malicious developer can alsodirectly modify the binary code to insert a backdoor.The latter two types of backdoor-planting methodscannot be detected by source code review.Methods to avoid detection. We assume maliciousdevelopers cannot use obfuscation or anti-debuggingtechniques to build backdoors, which are not permittedwhen code review is required. However, the attackerstill has a number of ways to prevent the backdoorfrom being detected. They may construct a subtlevulnerability that eludes source code inspections, andgain system privilege by a malformed input. They maydesign and use a weak cryptographic algorithm inthe login modules, for example, using insecure hashfunctions with a weak collision probability.Attacker’s Limitations. Similar to [18], we assumethat only few developers act maliciously, and theycannot compromise the source code review and softwaretesting process. Moreover, they cannot compromise thedeployed systems where the login module runs, so theoperating system modules are trusted, which providefile reads, network communication, and random numbergeneration. In other words, we do not consider theattacks in which the user-space login module withbackdoors can directly control the kernel of operatingsystem (e.g., a rootkit) or modify system libraries. Inaddition, we assume the backdoor creators cannot modify the password database in the deployed systems. Suchattacks can be simply identified by database auditing.B. Types of RCA BackdoorA general RCA decision function L(), shown inFigure 1, takes inputs from users U and global states G,maintains internal states I, and returns a boolean value,T RU E for accept and F ALSE for reject. Specifically,the response-computation component of L() generatesan expected response Response0 , and the responsecomparison component of L() compares Response0with the user’s response Response. Based on howResponse is used in the login module with a backdoor,we classify backdoors into two categories:Type T1: Bypassing response comparison(Response0 6 Response): In this category, the attacker can authenticate successfully regardless of the valueof Response and Response0 , because the responsecomparison step is bypassed. The attacker can logineven when the response-computation function f () doesnot compute any response at all. The bypassing isusually triggered when some special conditions are met:Based on L()’s input type, there are three basic typesof trigger conditions, listed as follows. U-triggered backdoors. Special user inputs U canbe used to trigger hidden logic or intended vulnerabilities in L() to bypass the comparison statement

static int i 0;.i //record the login attempt numberif (i%10 0){response str.revert(challenge);// transform based on the challenge}return response;.Figure 2.the hard-coded password to compute a response,which makes the response predictable by theattacker.Figure 2 shows another example. The responsecomputing function f generates a responsethat is the bit-wise inverse of the challengeevery ten login attempts (i.e. internal states).So the backdoor attacker can always send thebit-wise inverse of the challenge to the serverand authenticate successfully with a probability of1/10.An internal-state triggered backdoor example.and force L() to directly return T RU E.G-triggered backdoor. Global states G, such assystem times and MAC addresses, can also beused. For example, between 4:00am and 4:01am,L() directly returns T RU E regardless of user’sresponse. I-triggered backdoor. Internal states I can be a kindof trigger. For example, L() can record the loginfailure frequency and return T RU E if the failurefrequency falls into a specified range.Note that all these three kinds of trigger conditionsand their combinations can be used to implementbackdoors. We can eliminate this type of backdoorsif we ensure that the response comparison cannot bebypassed. Type T2: Controlling computation of expected response (Response0 Response): In this category, theresponse comparison is not bypassed, but the responsecomputation component is affected by attackers. Recallthat the response-computation function f () generates aresponse Response0 , which is compared to Responseto decide whether the user (or attacker) can login.However, as the developer who writes f (), the attackercan plant backdoors to make the response generated byf () predictable. Ideally, the expected response shouldonly depend on the challenge and the user’s password.Based on how the backdoor in the response-computationfunction affects the expected response, we further classify this type of RCA backdoors into two sub-categories. Type T2a: Response computation depends oninformation other than challenge and password.In this category, when given a specific pair ofpassword pw and challenge cha, the responsecomputation function can generates differentresponses, depending on the value of (U, G, I).The attacker can predicate the response if when aspecial condition is planted in the login module.For example, the attacker can plant a hard-codedpair of username and password in f (). When thehard-coded username is supplied in U, f () usesThis type of backdoor can be eliminated if thecomputation function f () is assured to depend onlyon cha and pw, i.e., for a given pw and cha, f ()always generates the same response. Therefore,the response-computation function f () should onlyperform pure computation, without side-effectand dependencies to external or persistent internalstates. This requirement can be satisfied if weensure that the response-computation function is apure function, which is introduced in Section II-C. Type T2b: Response computation has collisionbased backdoors.In this category, when given specific passwordpw and challenge cha, the response-computationfunction f () generates the same responseResponse0 . Response0 is determined by thepassword pw, which is set by the normal user andis unknown to the attacker. Therefore, the attackercannot predicate the exact response generated byf ().Given a challenge, if the output of f () is differentfor different passwords (i.e. f ()’s value spaceis uniform distributed), the attacker can onlylogin successfully with a probability equals tothat of guessing the right password. However, themalicious developer can implement a function witha high weak-collision probability. For example,given a challenge cha0 , f () may output res0for half of possible passwords, which allows theattacker to login successfully with a probability of1/2 using the response res0 .This kind of backdoor, called collision-based backdoor, can hardly be detected by traditional programanalysis methods, but it can be eliminated if wecan measure the computation function’s collisionprobability. Again, it requires that f () is assuredto depend only on cha and pw.

B(Server)A(User).idA.idA(login aPumemoryexceptionfMemoryWiperPure es(response)no OutputREJECTyesFigure 4.NaPu architecture.ACCEPTFigure 3.New RCA framework.From the above discussion, we can see that ensuring the response-computation function to perform purecomputation is the basic to prevent Type T2 backdoors.Next, we introduce the concept of pure function.C. Pure functionA function is called pure, if the following two properties hold [14]: It has no side effects, i.e., the evaluation doesnot have any visible effects other than generatingthe function results. Functions those modify arguments, global states or hard disk file are not freeof side effects. Its execution is deterministic, i.e., given the sameset of function arguments, it always generates thesame result.Pure functions introduce important features to simplify security analysis. For example, the password encryptfunction crypt() in POSIX should be a pure function.Given a plain password and a salt, cyrpt() should returna

authentication systems, the user response is used as an input to the authentication computation, which is based on techniques such as public-key cryptography [26] and zero-knowledge proof [6]. In this paper, we focus on backdoors in the first type of authentication system, response-c

Related Documents:

CanSecWest 2011 - Vancouver March 9-11th, 2011 E. Filiol (ESIEA - (C V )O lab) Dynamic Cryptographic Backdoors CanSecWest 2011 1 / 48. Introduction Bypassing IPSec Dynamic cryptographic trapdoorsConclusion Outline 1 Introduction 2 Malware-based Information Leakage over IPSEC-like Tunnels

Hardware backdoor protection is a relatively new area of research that protects against a serious threat. Recently, some attention has been given to protecting hardware designs from hardware backdoors implanted by malicious insiders, but there are currently only two known solutions that have been proposed. Hicks et al. designed a method for .

Intercoms Hacking: call the frontdoor to install your backdoors 1 Introduction 1.1 Context An intercom [1], door phone, or a house intercom, is generally a voice communication device

work/products (Beading, Candles, Carving, Food Products, Soap, Weaving, etc.) ⃝I understand that if my work contains Indigenous visual representation that it is a reflection of the Indigenous culture of my native region. ⃝To the best of my knowledge, my work/products fall within Craft Council standards and expectations with respect to

akuntansi musyarakah (sak no 106) Ayat tentang Musyarakah (Q.S. 39; 29) لًََّز ãَ åِاَ óِ îَخظَْ ó Þَْ ë Þٍجُزَِ ß ا äًَّ àَط لًَّجُرَ íَ åَ îظُِ Ûاَش

Collectively make tawbah to Allāh S so that you may acquire falāḥ [of this world and the Hereafter]. (24:31) The one who repents also becomes the beloved of Allāh S, Âَْ Èِﺑاﻮَّﺘﻟاَّﺐُّ ßُِ çﻪَّٰﻠﻟانَّاِ Verily, Allāh S loves those who are most repenting. (2:22

Pages 10 and 11 contain some suggestions from Dr. Elmer Towns [s book The Daniel Fast for Spiritual Breakthrough. (Used by permission) Fasting Suggestions Eliminate one meal a day and pray during that mealtime. Eliminate two meals a day, and pray during their times. Eliminate all desserts.

The API Specification and the EEMUA Specification differ slightly in some respects. The main differences in the specifications are in the requirements for the rheological properties and filtrate loss of the slurry. The rheological properties of the slurry at different rates of shear are determined using a direct reading viscometer. Filtrate loss is determined using a filter press. Test methods .