Model-Based Vulnerability Testing of Payment Protocol Implementations

Transcription

1 odel-based Vulnerablty Testng of ayment rotocol Implementatons Ghaz aatoug INRIA Nancy Grand Est 615, rue du Jardn Botanque Vllers les Nancy edex, France Frédérc Dadeau FETO-ST Insttute/ INRIA ASSIS 16 route de Gray, Besançon, France chael Rusnowtch INRIA Nancy Grand Est 615, rue du Jardn Botanque Vllers les Nancy edex, France ABSTRAT We nvestgate an approach to automate model-based vulnerablty testng of payment protocols used by e-commerce applcatons. We am to mprove the effcency and performance of logcal vulnerablty testng. The proposed approach s based on a formal specfcaton of the protocol mplementaton (SUT) and vulnerablty attack scenaro explotaton for drvng the test executon. Ths approach s llustrated wth a use case example bookshop applcaton and one of the most used payment protocols ayal Express. 1. INTRODUTION The tremendous ncrease n onlne transactons has been accompaned by an equal rse n the number and type of attacks aganst the securty of onlne payment systems. These attacks explot hdden vulnerabltes n payment protocol mplementatons wthn e-commerce applcatons. In fact, to guarantee secure onlne transactons, e-commerce applcatons ntegrate thrd-party servces. Ths s done by mplementng a specfc payment module wthn the applcaton core usng specfcaton of web AI provded by asher-asa-servce (aas) companes such as ayal. However, ths ntegraton ntroduces new securty challenges due to the complexty of coordnatng an applcaton nternal state wth those of the component servces and the web clent across the Internet. oreover, some web applcaton developers are not very well traned wth secure programmng technques. As a result, the securty of an applcaton s not necessarly a prorty of the desgn goals [3]. Indeed, whle valdaton focuses on absence of runtme errors, and conformance w.r.t. specfcatons, securty aspects are too often left-asde [14]. Ths s exacerbated by the rush to meet deadlnes n the fast-movng e-commerce world. Therefore, penetraton testng s mandatory to reveal eventual logcal flaws that mght be otherwse have been overlooked durng the development phase. Ths knd of tests can also be acheved by companes specalzed n securty testng, n pentestng (for penetraton 2nd Workshop on Hot Issues n Securty rncples and Trust (HotSpot 2014). Supported by DAST roject of Fonds natonal pour la socété numérque- Technologe de Sécurté & Réslence des Réseaux and F7 NESSoS project. testng) as nstance. These companes montor the constant dscovery of such vulnerabltes, as well as the constant evoluton of attack technques. However, t s worth to say that detectng vulnerabltes n a securty protocol, and, n our case, n the payment process, remans a most dffcult task to perform, as t requres a deep knowledge of the (payment) protocol and the way t s mplemented wthn the e-commerce applcaton. We need more effectve methods to mprove the effcency of mplementaton testng tools, as most of the exstng approaches resort to random or manual testng [5]. The work presented n ths paper nvestgates a sem-automatc tool that ams to mprove the effcency and accuracy of logc vulnerablty testng, by means of formal specfcaton and abstract attack scenaros (nferred or manually desgned). Smlar efforts have been reported n SaIoS project [13, 1] on dfferent classes of protocols. These approach dffer from the one presented here, as they rely on a dfferent language (ASLan) whch s more concrete, and thus easer to concretze for test executon. Besdes the consdered mutatons are very smlar to classcal code mutaton operators, whle the HLSL mutatons we consder more specfcally target the securty functons of a protocol. E-commerce payment protocols and attacks have also been extensvely addressed n [14], however ths work dd not attempt to automate the detecton of vulnerabltes of the executon of vulnerablty test cases. We am to mprove a recently proposed archtecture for automatcally complng abstract attack traces to concrete executable tests on protocol mplementatons [9]. We have mplemented a partly-automated penetraton testng platform to detect vulnerabltes on some mplementatons of ay- al Express payment protocol whch s complex and wdely used n busness transactons. We have succeeded to test an attack scenaro on a realstc mplementaton usng formal attack trace generated by the L-AtSe model-checker [12]. Although not reported here, a smlar expermentaton was conducted wth our technque, on an mplementaton of agento [10] contanng a logcal securty flaw that conssts n the absence of sgnature of the purchase amount. To explot ths flaw, a malcous attacker can modfy the amount to pay, and purchase expensve tems by payng a rdculous prce. Ths logcal flaw was dscovered ndependently by the

2 NBS Systems company 1. Notce that, although ths work addresses payment protocols, t can also be appled to other securty protocols such as authentcaton (see [6] for more detals). In the remander of ths paper, we frst present, n Secton 2, an overvew of the methodology. Then, we dscuss the specfcty of the addressed type of vulnerablty on a concrete example, ntroduced n Secton 3. Secton 4 descrbes n detals the prncple of the proposed approach. We provde the modellng materal and the platform archtecture n order to show how the test generaton tool chan produces abstract attack traces and how they are reproduced on real-word mplementaton of an e-commerce applcaton (E-Book Shop) mplemented wth a vulnerable payment module. Secton 5 descrbes studes on the formal analyss of payment protocols. The strengths of our proposed approach s dscussed n Secton 6. Fnally, Secton 7 presents a concluson and the future works. 2. ODEL-BASED VULNERABILITY TEST GENERATION We gve here an overvew of our odel-based Vulnerablty Testng (BVT) approach as a generc soluton for logc vulnerabltes testng. 2.1 rncples of the approach We frst descrbe the prncples of the approach before gvng nformaton on the dfferent artefacts that t nvolves, namely the protocol model, formal attack trace and formal attack scenaro. The proposed process to perform vulnerablty testng, depcted n Fgure 1, s composed of the followng actvtes Formal specfcaton Ths actvty s done by the securty test engneer before startng the test process. It conssts n formalzng the system under test (SUT) from the exstng specfcaton provded by nformal requrements. The formal model s expressed usng the HLSL language [2]. utaton process utaton [7] s a technque that conssts n ntroducng logcal faults, n our case nto the HLSL model n order to create vulnerabltes. These mutatons smulate mplementaton choces or actual mstakes that can be made by a programmer. Ths can be automated for HLSL usng an exstng mutant generator named juhlsl [6]. odel checkng After applyng the mutaton process, model checkng tools are used to verfy the protocol, and possbly generate abstract attack trace f the mutant s declared unsafe. The goal of the model checker s specfed usng LTL formula whle defnng specfc securty property. In ths approach, we consder the L-AtSe model-checker a back-end of the AVISA protocol analyss tool-set, as ths tool s able to produce counter-examples as attack traces f the protocol s declared unsafe. However, other back-ends of AVSIA 1 http// Advsory_agento_aypal.pdf could be used, such as On-the-Fly odel-hecker (OF) or SAT-based odel-hecker (SAT). Adaptaton Before startng an executon of the formal test scenaro, a step s requred. Indeed, durng the modellng actvty, all data used by the protocol are modelled at an abstract level. As a consequence, the attack scenaro s expressed at ths level, and can not be executed as s. Ths step thus conssts n brdgng the gap between abstract keywords, used n the abstract trace, and the real AI of the SUT. Durng ths step, the securty test engneer has to defne how modelled data are mplemented wthn the SUT. Test executon t ams to automatcally execute abstract scenaros on concrete mplementatons. Ths step relates modelled data exstng n the formal attack scenaro wth the real AI defned by the test engneer n the prevous step. ommuncaton wth the SUT happens n real tme and n a dynamc way. If no nformal specfcaton of the protocol exsts, the frst two steps (formal specfcaton and mutaton process) can be replaced by a model nference technque. Ths can be performed more or less automatcally usng other technques such as traffc analyss between agents nvolved n the executon of the protocol. In ths context, the conclusons that can be drawn from the test executon are dfferent. Instead of lookng for a vulnerablty (ntroduced at the mutaton step), ths actvty wll check that the vulnerablty actually exsts n the mplementaton. 2.2 Logcal flaws n payment methods Nowadays e-commerce web applcatons ncreasngly ntegrate a trusted thrd-party component presented as a asheras-a-servce (aas) n the payment process. The man purpose s to better guarantee secured payment transactons, as the aas can collect the payment of a purchase from the shopper and nform the merchant of the completon of the payment wthout revealng the shopper s senstve data such as a credt card number. In the consdered case study, the well-known ayal server s used as an example of aas server. Durng a checkout process, communcatons happen between the thrd entty and the merchant as well as between these two servces and the web clent controlled by the shopper. Ths trlateral nteracton s meant to coordnate the nternal states of the merchant and the aas, snce each party has only a partal vew of the entre transacton. Unfortunately, ths thrd-party ntegraton ntroduces a complexty n the payment protocol mplementaton wthn the e-commerce applcaton whch brngs new securty ssues. Indeed, an mproper dstrbuton of the protocol functonalty between the nvolved enttes leads to logcal flaws that can be exploted by a malcous shopper. Actually, an onlne purchase transacton s always ntated by the clent (web browser) and managed by some publc AI methods mplemented n the two sdes the merchant and the aas. A dshonest shopper can make web AI calls of methods exstng on the e-commerce applcaton wth well-chosen arguments and n an arbtrary order so that he can shop products

3 Fgure 1 odel-based vulnerablty test process for free or alter the way the payment s verfed [14]. Ths shows that to have communcatons over https do not prevent sever attacks aganst e-commerce applcatons. It s worth to menton that network man-n-the-mddle attacks are not consdered here, snce the checkout modules of all the merchants and aas webstes communcate exclusvely over https. 3. RUNNING EXALE E-BOOK WITH AY- AL 3.1 Descrpton of the applcaton E-Book shop s an e-commerce applcaton that contans a number of vulnerabltes related to logcal flaws n payment process. Its man goal s to test the effcency of proposed approach n a legal envronment, smplfy the complexty of the testng process and get more hands on the SUT. Hence, we consder ths applcaton as a honeypot. E-Book shop has been developed as a real e-commerce applcaton wth the followng features Authentcaton E-book shop provdes personalzed content to regstered users. 3.2 Example of a concrete attack scenaro The concrete attack scenaro we consder enables a dshonest user to purchase an expensve product and pay for a cheaper one. Ths attack explot data freshness vulnerablty ntegrated wthn the payment module mplemented n the E-Book Shop applcaton. Fgure 3 depcts all the exchanged messages between dfferent enttes nvolved n the payment process. The scenaro conssts n ntatng two parallel sessons wth the system under test (the E-book Shop applcaton) wth the same account and no matter f ts done wth the same browser or not. Durng the frst sesson, the attacker chooses an expensve product and starts the payment process. However, he stops at the logn step on the sandbox of ayal. On the other sesson, the attacker starts the payment steps for a cheap product. When he gets the confrmaton of payment from the ayal ste, he substtutes the token value wth the token of the frst sesson, before gettng redrected to the merchant ste. Ths way, the merchant (f ncorrectly mplemented) beleves that the attacker has pad for the expensve product and responds wth a successful payment. But, n realty, the attacker has only pad the cheaper product of the second sesson. We descrbe n detals the process of ths attack scenaro detecton and smulaton startng from formal modellng endng to the real smulaton on a concrete mplementaton. Search The search feature offers the possblty to flter books by names. urchase Books A regstered user on E-book shop can purchase books usng hs ayal account. E-book shop s an e-commerce applcaton that allows a user to search and select books through a shoppng cart system and then purchase the chosen products wth hs ayal account. ommands that have been pad successfully are saved n a local data base. Fgure 2 provdes some screenshots of the applcaton. We mplemented the payment module usng the ayal sandbox framework provded by ay- al ste, and the ntegrated vulnerabltes was a subject of a deep research on the last revealed securty flaws n the most used e-commerce applcatons. We now detal one of the attack scenaros we used durng the testng phase of the SUT. 4. DETAILS OF OUR BVT AROAH In ths secton, we detal each man actvty of the odel- Based testng process. For each actvty, we present ts objectves as well as ts process. The E-book shop runnng example s used to llustrate our approach. 4.1 odellng the SUT In order to conduct the securty analyss of the ayal payment protocol, the approach starts by specfyng the protocol relyng on Alce-Bob notaton. The checkout process begns when the button ay Now on the merchant web ste s clcked. Ths operaton drects the shopper s browser to the ayal webste where he s nvted to provde hs ayal buyer account credentals to contnue the purchase process. If the nformaton entered by the user s correct, the shopper s agan redrected to a payment success merchant Web page. Behnd the scene, there are http nteractons between the three partes, who communcate by callng Web-AIs

4 Fgure 3 Example of a concrete attack scenaro on ayal ayment mplementaton exposed by the merchant and the aas. Such AIs are essentally dynamc web pages and are nvoked through http requests. A clent sends an http request through an URL wth a lst of arguments and receves an http response, often a Web page dynamcally bult by the server, as the outcome of the call. The formal model of the protocol was desgned usng the ayal documentaton [11] and some traffc analyss. To examne the traffc, E-Book Shop applcaton was deployed on a local xampp server [15] and http traffc capturng tools were used, such as Fddler [8], retrevng all the http exchanged messages between the nvolved enttes durng a checkout process. Fgure 4 provdes the Alce-Bob notaton of the ayal Express protocol, whch s descrbed n an assocated HLSL specfcaton (not shown here). For the purpose of effcency and concseness, only the most sgnfcant steps and felds were modelled. In ths fgure, denotes the clent (web browser), s the erchant (E-book shop) and s the aas (ayal). Frst, the clent starts by logn to the applcaton, choosng the product and ntate the payment ths s modelled usng the message checkout. It contans also the order descrpton nformatons (product detals, shppng address, bllng address...). The merchant redrects the clent to the ayal ste usng a redrecturl whch corresponds to the paypalconnect abstract message n Alce-Bob notaton. Also, the latter denotes the logn process to ayal account and the payment confrmaton acton on the ayal ste. In addton, the merchant generate a token whch s a random value used to dentfy the payment n process. Once the the prevous step s valdated by the aypal server, the latter responds wth 302 HTT redrecton to the returnurl url specfed by the merchant, the Token receved from the clent and the ayerid whch dentfy the clent ayal account. Fnally, the merchant confrm the success of the payment process. Durng the executon of the protocol ay- al Express, communcaton happen also between the merchant and the ayal ste n two tmes. Frst, the Set- Expressheckout message, sent by the merchant, nforms the ayal server about an upcomng operaton. Then, the DoExpressheckoutayment message requests the payment executon. 4.2 odel checkng and test generaton The man purpose of the test generaton actvty s to produce test cases from the specfed model. After modellng the protocol, the model checkng tools are used to verfy the HLSL model, and possbly generate abstract attack traces f unsafe. The goal gven to the model-checker s specfed usng HLSL wtness and request features. These latter nform the L-AtSe model-checker to ensure that the Token value s generated n a fresh manner durng the protocol executon, L-AtSe fnds the attack trace that volates the test purpose related to the specfed HLSL model of the SUT. Fgure 5 depcts the attack scenaro at the formal level. It corresponds to a replay attack on the token value. Notce that, for ths example, the mutaton phase explaned n Secton 2.1 has not been appled. However, such a model could result from a correct model that would have been mutated. 4.3 Adaptaton Before startng an executon of the formal test scenaro, a prelmnary work step s requred. Durng the modellng actvty, all data used by the protocol are modelled at an abstract level. As a consequence, the attack scenaro can not be executed as s. The gap between abstract keywords used n the abstract trace and the real AI of the SUT must be brdged. Indeed, the securty test engneer have to defne how modelled data s mplemented n the SUT. Also, whle recevng responses from the SUT, our tool s n charge of retrevng relevant felds from the receved response. In case of sendng operaton, each abstract message needs to be translated nto real message format. Table 1 descrbes the semantcs of the abstract data nvolved n our example of attack scenaro, gven n Fgure 5. Some abstract messages correspond to operatons performed by the tool Attack Smulator, others correspond to felds contaned n the http messages. 4.4 Test executon platform archtecture

5 Table 1 appng modelled data to ts semantc use for testng odeled data Its mplementaton checkout start(); logntobookshop() ; chooseroduct() paypalconnect logntoaypal() returnurl http//localhost/bookshop/php/checkout.php?acton=return Token gettoken() ayerid getayerid() checkout SetExpressheckout Token paypalconnect, Token paypalconnect,token returnurl, Token, ayerid returnurl, Token, ayerid DoExpressheckoutayment, Token, ayerid Result confrmage Fgure 4 Alce-Bob notaton of ayal Express protocol checkout1 paypalconnect, Token1 checkout2 paypalconnect, Token2 paypalconnect,token1 returnurl, Token1, ayerid returnurl, Token2, ayerid confrmage Fgure 5 Formal attack trace As dscussed above, the attack trace produced by a modelchecker s rather abstract and, n order to be able to detect real attacks that affect protocol mplementatons, t s mandatory to provde a platform that performs both () messages format converson, from a formal level to the mplementaton level, and () real communcatons wth the SUT. Ths platform s archtecture s now descrbed, n terms of components, wth ther functonaltes and nteractons. It dsplays three man components, each wth a specfc role 1. Attack Trace ompler dentfes agents, messages types and elementary operatons. 2. Scenaro Executon Engne generates (resp. retreves) outgong (resp. ncomng) messages. 3. Attack Smulator smulates the scenaro on real communcaton channels. As shown n Fgure 6, the testng envronment takes as nputs the attack trace and the mutated model of the consdered protocol, and returns an ndcaton whether the consdered attack on the consdered mplementaton exsts or not. To better understand the functonaltes of each module, we wll rely on the prevous scenaro as a use case example n what follows. Attack trace compler Fgure 2 Regular payment process The Attack Trace ompler transforms an abstract attack trace gven n Fgure 8 nto an executable attack scenaro descrbed n Fgure 9. The component collects ntruder ntal knowledge, shown n Fgure 10, from the HLSL protocol and follows the attack trace nstructons to buld the

6 Fgure 6 latform Archtecture L1 7="receved at step1" 8=p1(7) 9=p2(7) Fgure 7 Addtonal nformaton for each attack scenaro step (m,4) (m,4) (m,4) (m,4) heckout_g1 par(paypalconnect,token_g7) heckout_g1 par(paypalconnect,token_n1) attack scenaro. The latter descrbes n detals the actons that should be performed by the ntruder when executng the attack. Hence, t s structured nto steps and elementary operatons, each step correspondng to an abstract attack trace nstructon. In order to explan the process of complng the attack trace, we gve here an example of attack trace treatment, based on the detected scenaro on ay- al Express payment protocol. Recall that ths scenaro volates the freshness of the exchanged value of token between the merchant and the ayal server. For nstance, we take the second lne n the abstract trace n Fgure 8 whch corresponds to paypalconnect, Token1. It s a recevng operaton (denoted by the symbol?) of the concatenaton of the paypalconnect and Token value. Thus, the output of the attack trace compler s as follows step 1?7 = par(paypalconnect, T oken g7). Also, the attack scenaro contans addtonal nformatons about how to get each part of the composed message descrbed n Fgure 7. We denote here p1(m) (resp. p2(m)) the projecton of a message m on the frst (resp. second) component. In addton, the attack scenaro contans a data structure, shown n Fgure 10, whch s ntalzed wth ntruder Intal Knowledge (keys or agent s denttes) and s updated each tme the system evolves to a new state. Scenaro executon engne Ths module s responsble of translatng the attack scenaro, from the formal level to the mplementaton level. Snce the (p,5) (p,5) (m,4) (m,4) par(paypalconnect,token_g7) par(returnurl,par(token_g7,ayerid_n7)) par(returnurl,par(token_n1,ayerid_g2)) onfrmage_n2 Fgure 8 Abstract attack trace as generated from the model checker executon envronment s desgned for an mplementaton level, the exchanged messages are real network messages. As seen prevously, messages n the formal model are specfed as frst-order terms. Therefore, t s necessary to map these terms to concrete messages and operatons. Ths s the man role of the Scenaro Executon Engne t ensures the assocaton between abstract messages and concrete ones, stored n the Data Store module. Operaton executon s held wth the functonalty provded by the rmtve Holder. Fgure 6 descrbes more ths module components. The attack scenaro nstructons can be classfed nto three categores (1) message constructon, (2) message sendng, and (3) message recevng. To do ths, cryptographc prmtves (crypt, par and unpar) and network prmtves (send and receve) are used.

7 step 0!6= heckout_g1 L1 6="generated nonce at step0" step 1?7= par(paypalconnect,token_g7) L1 7="receved at step1" 8=p1(7) 9=p2(7) step 2!6= heckout_g1 step 3?10= par(paypalconnect,token_n1) L1 10="receved at step3" 11=p2(10) step 4!7= par(paypalconnect,token_g7) step 5?12= par(returnurl,par(token_g7,ayerid_n7)) L1 12="receved at step5" 13=p1(12) 14=p2(12) 15=p2(14) step 6!16= par(returnurl,par(token_n1,ayerid_g2)) L1 18="generated nonce at step6" 17=par(11,18) 16=par(13,17) step 7?19= onfrmage_n2 Fgure 9 Abstract attack scenaro L0 0="ntally known" 1="ntally known" 2="ntally known" 3="ntally known" 4="ntally known" 5="ntally known" 6="generated nonce at step0" 7="receved at step1" 8=p1(7) 9=p2(7) 10="receved at step3" 11=p2(10) 12="receved at step5" 13=p1(12) 14=p2(12) 15=p2(14) 18="generated nonce at step6" 17=par(11,18) 16=par(13,17) Fgure 10 Intruder Knowledge rmtve holder The needed cryptographc operatons are defned n the rmtve Holder module. In relaton wth the specfcaton of the protocol, ths component provdes a lbrary of operatons such as encrypton, decrypton, nonce generaton, sgnng and concatenaton. It s necessary to make sure that the whole scenaro can be executed wthout any errors. To do that, the rmtve Holder provdes all the possble operatons needed by the protocol mplementaton. It s worth to say that n the used protocol example (ayal Express) as mplemented n the E-book Shop applcaton, we do not need cryptographc operaton mplementaton. However, ths can mandatory when dealng wth more complex e-commerce payment protocols. Data store essage creaton depends on the knowledge acqured n prevous step of the scenaro, snce the tested protocols are stateful. Hence, all the messages handled by the platform are saved n the Data Store n ther real format and n an ndexed way whch facltates data processng. The Data Store also contans all objects requred for ntermedate computaton lke encrypton keys, data nonces, agent denttes and sub-messages. Scenaro executon handler Ths s the platform core algorthm whch handles the nstantaton of abstract operatons by concrete executable one. It takes as nput the elementary steps of an attack scenaro, and processes each nstructon n order to dentfy the next operaton to perform as well as ts arguments. It nteracts wth the rmtve Holder module to execute cryptographc operatons and wth the Data Store module to save or retreve arguments dependng on the attacker behavour descrbed n the attack scenaro. Algorthm 1 descrbes all the nteractons wth dfferent modules. Input Instructon I Output Request to another component Let I gets nstructon value; ase {I s send(x)} then Get data from the Data Store at poston ; all A Smulator to send message ase {I s X=receve()} then all A-Smulator to get the receved message ; Store the message on the Data Store at poston ase{i s X=operaton(Xy,Xz)} then Get data from Data Store at postons y and z; all the rmtve Holder to execute the prmtve; Store the message on the Data Store at poston ase{i s fnsh()} then ext wth success Algorthm 1 Scenaro Executon Handler The frst (resp. second) case corresponds to a message sendng (resp. recevng) operaton over the network. The thrd case of Algorthm 1 corresponds to the message constructon or decomposton. In all cases, the Handler nvokes the Data Store and the rmtve Holder modules. onsder, for nstance, nstructon X1 = par(x2, X3). Frst, the Scenaro Executon Handler collects the arguments by

8 requestng them from the Data Store. Then, t calls the concatenate method n the rmtve holder to construct the message. Fnally, the latter s stored at the result poston X1 n the Data Store. Attack smulator After mappng a formal message to the real format, the Scenaro Executon Handler processes emsson and recepton operatons. In these cases, t sends a request to the Attack Smulator module, whch s the nterface of the platform wth the external envronment. At the formal level, the protocol model abstract some felds exstng n a real mplementaton, whch need to be restored at the concrete level. The Attack Smulator s n charge of the conformance of the exchanged data wth the protocol model, meanng that t has to dentfy the relevant felds and retreve data from the SUT response (case of recevng operaton) and to nstantate the relevant felds n the request message (case of sendng operaton). In general, the Attack Smulator tasks nclude () creatng the real communcaton channels, () sendng messages, and () recevng messages. Therefore, HtmlUnt was ntegrated n the Attacker Smulator module. HtmlUnt s a Java unt testng framework for testng Web based applcatons. Ths headless browser allows Java test code to examne returned pages ether as text, as XL DO, or as collectons of forms, tables, and lnks. It can also deal wth https securty, basc http authentcaton, automatc page redrecton and other http headers. Furthermore, ths testng framework was used to automate clcks on lnks and navgaton between pages of the onlne store. We gve here an example of HtmlUnt use wthn Attack Smulator lass. In our case study scenaro, step 0 of the abstract attack scenaro corresponds to the followng nformatons step 0!6= heckout_g1 L1 6="generated nonce at step0" After generatng the message nonce usng the nformaton provded by L1 and the operaton mplementaton wthn the rmtve Holder module, the Attack Smulator proceeds wth the sendng operaton. However, as we modelled the protocol usng alce-bob notaton heckout denotes the steps of logn to the applcaton, choosng product randomly and startng payment process. Therefore, we provde the sendng operaton manually mplemented n the Attack Smulator wth the correspondng HtmlUnt fragments of code n Fgure 11. The attack valdaton Attack valdaton s the most mportant step of the testng process, as t affects the effcency of the proposed tool n attack detecton. The smulator needs to assert whether the attack s smulated wth success or not. Ths must be done n a rgorous way to avod false postves and false negatves. anly, we propose to dentfy the fnal state of the SUT when the attack succeeds. Due to the complexty of ths process, we have studed two cases wth dfferent verdct assgnment methods 1. Frst case when the attack success s acheved by publc vod send(object object) { Strng name = ((NameValuear) object).getname(); Strng value = ((NameValuear) object).getvalue(); f (value.equals("heckout")) { Htmlage currentpage = weblent.getage(baseurl + "/ndex.php"); HtmlTextInput textnput = (HtmlTextInput) currentpage.getelementbyname("logn"); textnput.setvalueattrbute("test"); HtmlasswordInput passwordnput = currentpage.getelementbyname("password"); passwordnput.setvalueattrbute("test"); HtmlSubmtInput submt = (HtmlSubmtInput) currentpage.getelementbyname("btnonnexon"); currentpage = submt.clck(); Lst<DomElement> products = currentpage.getelementsbyidandorname("btnajouteraner"); nt max = products.sze(); Random randomgenerator = new Random(); nt = randomgenerator.nextint(max); HtmlSubmtInput submt = (HtmlSubmtInput) products.get(); currentpage = submt.clck(); HtmlSubmtInput submt = currentpage.getelementbyname("btnayer"); currentpage = submt.clck(); } Fgure 11 Java code mplementng the sendng operaton reachng a fnal state whch s known by the test engneer and can be dentfed wth a smple verfcaton usng a verdct keyword. In ths case, upon completon of the attack scenaro executon, the smulator asserts whether the fnal state of the system s the state correspondng to an attack success or not. Ths was done usng the JUnt testng framework that helps deployng the attack valdaton process as follows Strng verdct; assertt rue(currentpage.ast ext().contans(verdct)); 2. Second case the attack success valdaton s not trval and one needs to verfy all nformatons about payment operatons such as payment status, seller ayal account stuaton, etc. Therefore, we propose to provde the test engneer wth a log fle whch contans all the actvtes performed by the platform whle the test executon. Ths facltates the task of assertng whether the attack scenaro was smulated successfully or not. 5. FORAL ANALYSIS AN EXALE As specfed n the frst secton of ths paper, the testng process usng our approach starts wth formal specfcaton of the SUT. Then we proceed wth the model checkng verfcaton and valdaton step n order to generate abstract attack trace. The latter serves as n nput for our testng platform. In ths secton, we present the formal analyss work done on the most used payment methods (aypal ayment, Amazon ayment, Google heckout). anly we focus on how for-

9 mal verfcaton and valdaton technques can help fndng mplementaton logcal flaws. In our work, we rely on a lst of recently dscovered mplementaton logc flaws provded by [14]. Specfcally, we study an other example of attack scenaros on payment module Integraton of Amazon Smple ay payng to the attacker hmself to check out from the vctm Amazon Smple ay payment protocol s one of the leadng payment methods mplemented n merchant web stes. Fgure 12 shows the workflow whle executng the checkout process. After choosng a product the shopper starts payment process by clckng on the pay button. Then the merchant redrects the shopper s browser to the payment AI of the aas, passng orderid, gross and returnurl as the arguments. Ths message s sgned by the merchant, so the shopper cannot tamper wth the arguments when forwardng the message to Amazon ste. After the aas (.e., Amazon) verfes the merchant s sgnature, the shopper makes the payment, whch the aas records to ts database. The payee s the merchant who sgns the merchant redrecton message. Then, the aas redrects the shopper back to the merchant usng the returnurl that the merchant supples n the redrecton message. The entre aas redrecton message s sgned by the aas, whch s verfed by the merchant. Ths checkout procedure seems secure as no data can be contamnated by the attacker. Flaw and explot. In fact, ths protocol mplementaton can be vulnerable when the malcous shopper also plays the role of a dfferent merchant. Specfcally, anyone can open a seller account on Amazon. Suppose that the seller account s regstered under the name Alce. What the attacker wants to do s to pay Alce (actually, hmself) but check out an order from a store belongng to Bob (https//bob.com). The attack proceeds as follows. Frst, the attacker starts a payment process and blocks the redrecton message provded by Bob. Then, he decrypts the receved message, and actng as Alce, he sgns t wth hs prvate key. The trck here s that the message sgned by Alce actually carres a returnurl to Bob ( Bob.com/fnshOrder). As a result, even though Alce (the attacker) s the party that receves the payment, the aas wll redrect the shopper s browser to Bob wth a redrecton to call fnshorder. Although the message s ndeed sent to Bob, t s actually about the payment that the attacker made to Alce. The logcs n fnshorder, as sketched n Fgure 12, does not verfy that the payment was made to Bob, and therefore s convnced that the order has been pad. Fundamentally, the problem comes from the confuson between the merchant and the aas about what has been done by the other party. Goal specfcaton usng LTL formula n HLSL. After the modellng step n HLSL, we proceed wth the modelcheckng step. We use L-AtSe tool to detect the attack trace that explots the exposed vulnerablty. Ths s done usng a logc formula to nvaldate as a goal defnton. In fact, goals n HLSL language serves as test purposes for L-AtSe tool. The latter executes the specfed protocol and tres to fnd an attacker behavor that volates the property defned n the goal declaraton secton of HLSL specfcaton. In the studed example, we defne the securty property as follows goal [] ( (pay(a,km1,amazon_merchant,redrectlnk) /\ knows(nv(km1)) /\ delver(km,a,amazon_merchant,redrectlnk)) /\ ~ equal(km1, km) => pay(a,km,amazon_merchant,redrectlnk) ) end goal we denote by km (resp. km1) the publc key of a merchant m (resp. m1). Also, a represents the dentty of the agent playng the role of the payment servce provder (Amazon n our case). In addton, to defne the goal n HLSL model we use two meanngful keywords pay and delver. Typcally, pay( a, km1, protocol d, text) s the HLSL fact statng that the agent a has pad the agent whose publc key s Km1. In other words, agent a has pad the agent m1. Also, delver(km, a, protocol d, text) s the fact statng the purchase delvery by the agent whose publc key s Km to the agent a. In order to explan the specfed goal we gve the followng attack state secton the IF fle [4]. secton attack_states attack_state ltl_1_1 (Km1,RedrectLnk) = pay(a,km1,amazon_merchant,redrectlnk). knows(nv(km1)). delver(km,p,amazon_merchant,redrectlnk) & not(dequal(km1,km)) & not(pay(a,km,amazon_merchant,redrectlnk)) As a result, the attack state correspondng to the specfed securty s a state when an agent m1 controlled by the ntruder receves a purchase payment although he dd not delver any product. Besdes, a honest merchant m makes a purchase delvery and dd not receve any payment acton. 6. DISUSSION Whle the detecton of vulnerabltes can be dscharged by protocol analyss tools, such as AVISA, performng vulnerablty tests usng penetraton test tools remans the most dffcult task when tryng to ensure securty of protocols mplementatons. Such a process s usually tedous and tme-consumng, requrng advanced knowledge n software debuggng and reverse engneerng. There are many cases where no access to the source code/bnares s possble, and where a black box knd of testng s the only vable soluton. The best penetraton testers ntmately understand each and every attack used by ther automated testng tools; they ntutvely and explctly know what to look for when assessng the results of ther tests; they understand how complex software systems work. The proposed approach for vulnerablty testng protocol mplementatons s orented towards the followng objectves 1. Stateful testng our tool performs testng on real word mplementaton n a dynamc way. Also, t s able to

10 Fgure 12 Amazon ay workflow smulate multple sesson connexons wth the SUT unlke most of the state of the art automatc penetraton tools. 2. Accuracy and precson our approach s guded by a prelmnary formal analyss and model-checkng step. Explotaton of powerful formal verfcaton technques leads to pertnent testng process. The tool helps not only n detectng known mplementaton logc flaws but also n dscoverng new ones. 3. Tme effcency the automated tasks n the approach reduces test executon tme compared to alternatve penetraton testng tools. Approxmatvely two days of engneerng work were needed to specfy a protocol model and defne a securty goal. Then model chekng can be performed n a few seconds. Two days of software engneerng work were requred to develop an adaptaton layer. 4. Scalablty the tool archtecture can easly be extended to cover other protocol mplementatons. In fact, when dealng wth multple mplementatons of a specfed protocol, one need to adapt the modelled data wth ts semantcs wthn the SUT. In such way, the database of formal attack traces (nferred or manually generated) s reusable for all mplementatons correspondng to the specfed protocol. See Fgure Dscoverng mplementatons the constructon of a reusable database of attack scenaros helps to perform too some reverse-engneerng on protocol mplementatons. The traces n the database correspond to dfferent specfcatons (mutated models) and dfferent mplementatons. The black box testng process helps to derve nformaton about the SUT mplementaton dependng on the executablty of the replayed attack traces. For nstance we can dstngush between aypal Standard and aypal Standard wth IN by the ablty to execute or not some scenaro from the database. 7. ONLUSION AND FUTURE WORKS In ths paper, we proposed an approach that supports the bndng of specfcatons of payment protocols to actually deployed mplementatons through formal model complng Testng dfferent protocol mplementa- Fgure 13 tons and the automatc penetraton testng of real mplementaton aganst putatve attacks found by model checker. The approach conssts n model checkng a (possbly) mutated formal model, lookng for attack trace volatng securty property. If an attack s returned, the platform generates automatcally concrete attack scenaro nstructons, encodng how to verfy and generate protocol messages. The abstract attack trace s analysed and the nstructons are executed accordngly. In order to assess the effectveness of the proposed platform, we mplemented ts archtecture relyng on the RU Agle process. We used the Java languages and lbrares to mplement ts components. Especally, to provde the needed functonaltes and operatons we used the HtmlUnt lbrary. Our platform s able to successfully execute an attack on a ayal Express mplementaton wthn a realstc e-commerce applcaton E-Book Shop. In partcular, we appled a replay attack scenaro that was detected at a formal level usng model checkng. It s worth to say that our soluton s not specfc to a sngle scenaro, and t s able to smulate all the possble formal attack traces related to the modelled ayal Express protocol. Followng our work, we are plannng several mprovements. In order to smplfy the platform use, we wll develop a graphcal user nterface. Also, we wll perform further penetraton tests on other payment protocol mplementatons for revealng undscovered securty flaws. To do so, we frst need to generate further formal attack traces related to dfferent securty propertes. We can refer to the mutaton technques

11 descrbed n [6], appled to a formal specfcaton of the protocol. To acheve that, the model needs to be developed wthout any knowledge of a concrete mplementaton (only based on requrements documents). The mutatons wll nject concrete faults that could represent mplementaton errors, at the model level, that the test wll search for, at the mplementaton level. Second, we wll need to manually adapt the modelled data to ts semantc use n the protocol mplementaton. roceedngs of the 2011 IEEE Symposum on Securty and rvacy, S 11, pages , Washngton, D, USA, IEEE omputer Socety. [15] XA an easy to nstall Apache dstrbuton. http// 8. REFERENES [1] A. Armando, G. ellegrno, R. arbone, A. erlo, and D. Balzarott. From odel-heckng to Automated Testng of Securty rotocols Brdgng the Gap. In A. D. Brucker and Jacques Julland, edtors, Tests and roofs, volume 7305 of Lecture Notes n omputer Scence, pages Sprnger Berln Hedelberg, [2] AVISA project, Delvrable 2.1. The Hgh Level rotocol Specfcaton Language, http // [3] B. Bezer. Black-Box Testng Technques for Functonal Testng of Software and Systems. John Wley & Sons, New York, USA, [4]. Bozga, S. Graf, I. Ober, I. Ober, and J. Sfaks. The IF Toolset. In arco Bernardo and Flavo orradn, edtors, Formal ethods for the Desgn of Real-Tme Systems, volume 3185 of Lecture Notes n omputer Scence, pages Sprnger Berln / Hedelberg, [5]. Büchler, J. Oudnet, and A. retschner. Sem-Automatc Securty Testng of Web Applcatons from a Secure odel. In Sxth Internatonal onference on Software Securty and Relablty (SERE 2012), pages IEEE, [6] F. Dadeau,.-. Héam, and R. Kheddam. utaton-based test generaton from securty protocols n HLSL. In IST 11, pages IEEE omputer Socety, [7] Rchard A. Dello. Test adequacy and program mutaton. In ISE, pages , [8] Fddler The free web debuggng proxy for any browser, system or platform. http//fddler2.com/. [9] Hatem Ghabr, Ghaz aatoug, and chaël Rusnowtch. omplng symbolc attacks to protocol mplementaton tests. In SSS, pages 39 49, [10] agento communty edton. http// [11] aypal development & ntegraton gudes. https//developer.paypal.com/webapps/ developer/docs/classc/products/. [12] atheu Turuan. The L-Atse rotocol Analyser. In Term Rewrtng and Applcatons - roc. of RTA, volume 4098 of Lecture Notes n omputer Scence, pages , Seattle, WA, USA, [13] Luca Vganò. The SaIos project Secure provson and consumpton n the nternet of servces. In IEEE Sxth Internatonal onference on Software Testng, Verfcaton and Valdaton, Luxembourg, Luxembourg, arch 18-22, 2013, pages , [14] Ru Wang, Shuo hen, XaoFeng Wang, and Shaz Qadeer. How to Shop for Free Onlne Securty Analyss of asher-as-a-servce Based Web Stores. In