SPAM over Internet Telephony and how to deal with it

SP AM O VER INT ERNET TELEPHONY A ND HO W TO DEAL WITH IT Dr. Andreas U. Sc hmidt 1 , Nicolai Kun tze 1 , Rac hid El Khay ari 2 1 F raunhofer-Insitute for Secure Information T echnology SIT Rheinstrasse 75, German y 2 T echnica l Univ ersit y Darmstadt German y 1 { andreas.sc hmidt | nicolai.kun tze } @sit.fraunh ofer.de, 2 rac hid.el.kha y ari@go oglemail.com ABSTRACT In our mo dern so ciet y te lephony has dev elop ed to an omnipresen t servic e. P eople are a v ailable at an ytime and an ywhere. F urthermore the In ternet has emerged to an important comm unication medium. These facts and the raising a v ailabilit y of broadband in ternet access has led to the fus ion of these t w o services . V oice o v er IP or short V o IP is the k ey- w ord, that describes this combination. The adv antages of V oIP in c ompar ison to classic telephon y are location in- dep endence, simplific atio n of tra nsp o r t net w orks, abilit y to establish m ulti- media comm unications and the lo w costs. Nev ertheless one can easily see, that com bining t w o tec hnologies, alw ay s brings up ne w ch allenges a nd problems that hav e to be solv ed. It is undeni- able that one o f the most annoying facet of the In ternet now ada ys is email spam. According to different sources email spam is considered to b e 80 to 90 p ercen t of the email traffic pro duced. Securit y experts susp ect that this w ill spread out on V oIP to o. The threat of so called v oice spam or Spam ov er Internet T elephon y (SPIT) is ev en mor e fatal than t he threat that arose with email spam, fo r the anno y ance and dis- turbance factor is m uc h higher. As instance an email that hit s the in b o x at 4 p.m. is useless but will not disturb the user muc h. In contrast a ringing phone at 4 p.m. will le ad to a m uc h higher disturbance. F rom the provid ers p oint of view b oth email spam and v oice spam pro duce un w anted traffic and loss of trust of customers into the service. In order to mitig ate this threat differen t approac hes from different parties ha v e b een dev elop ed. This pap er fo cuses on state of the art an ti v oice spam solutions, analyses them and rev eals their w eak p o ints. In the end a SPIT pro ducing b enc hmark to o l w ill b e introduced, that attac ks the prese nted an ti v oice spam solutions. With this to ol it is p o ssible for a n administrator o f a V oIP net w ork to test ho w vulnerable his system is. KEY WORDS SP AM, In ternet T elephon y , V oIP , SPIT, atta c k scenarios 2 SP AM O VER INT ERNET TELEPHONY A ND HO W TO DEAL WITH IT 1 INTRODUCTION In the following sections w e will discuss t he problematic of SP AM ov er Inter- net T elephon y . The first section will deal with a general SPIT explanation and classifi catio n, fo llo w ed b y a scien tific SPIT threat analysis. In the second section the state of the art in SPIT prev ention mec hanisms will b e presen ted and their w eaknesses ana lysed. In the last se ction w e will tak e a lo ok at our SPIT benc hmark to ol (SXSM - SIP XML Sc enario Mak er) and ho w this to ol can exploit the w eakness es of an ti SPIT mec hanisms. 2 SPIT VERSUS SP AM The fo cus o f t his pap er is set on the topic of so called SP AM ov er Interne t T elephon y (SPIT). The first asp ect to men tion is, that a lt hough SPIT con- tains the phrase ”SP AM” and has some parallels with email spam, it also has ma jor differences. The similarit y is that in b oth cases senders (or callers) use the Interne t to tar g et recipien ts (or callees) or a g r oup of users, in order to place bulk unsolicited calls [3]. The main difference is that an email arriv es at the s erve r b efore it is accesse d b y the user. This means that structure and con ten t of an email can be a na lysed a t the serv er befo r e it arriv es at the recipien t and so SP AM can b e detected b efore it disturbs the recipien t. As in V oIP scenarios dela ys of call establishmen t are not wished, session estab- lishmen t messages are forwarded immediately to the recipien ts. Besides this fact the con tent of a V oIP call is exc hanged not un til the session is already established. In other w ords if the phone rings it is to o late for SPIT prev en- tion and the phone rings immediately after session initiation, while an email can b e dela y ed and eve n, if it is no t delay ed, the recipien t can decide if he w an ts to read the email imme diately o r not. In addition to these asp ects another main difference b et w een spam a nd SPIT is the fact, that the single email itself con ta ins information, tha t can b e used for spam detection. The header fields con tain info rmation ab o ut sender, sub ject and con tent of the message. A single SPIT call in contradiction is tec hnically indistinguishable from a call in general. A SPIT call is initiated and answ ered with the same set of SIP messages a s any other c all. 1 3 INTUITIVE SPIT DEFINITION SPIT is described ve ry similar in differen t publications and the descriptions can be summarise d as ”un w an ted” , ”bulk” or ”unsolicited” calls. In [2] e.g. SPIT is defined as ”unsolicited a dv ertising calls”, whic h is already a sp ecial form of SPIT. In [3 ] SPIT is defined as ”tra nsmission of bulk unsolicited messages and calls” wh ich is a more general definition than the first o ne, as it do esn’t c haracterise the con ten t and includes also messages. Note that with this definition it is not clear, if the term ”messages ” is used in order to generalise the type of messages t hat are sen t (e.g. ”SIP INVITE” or ”SIP OPTIONS” me ssages) or, if it is used in order to include SP AM that is sen t o v er Ins ta nt Messages (SPIM = SP AM ov er Instan t M essages). T he mos t precise definition is found in [1] where ”Call SP AM” (as the authors call it) is defined as ”a bu lk unsolicited set of s ession initia tion attempts (e.g., INVITE requests), attempting to establish a voice, video, ins ta nt messaging, or other t yp e of communic at io ns session”. The authors of [1] go ev en o ne step further and classify that ”if the user should answ er, t he spammer pro ceeds to rela y their message ov er the real- time media.” and stat e that this ” is the classic telemark eter spam, a pplied to SIP”. W e can easily see, that the presen ted definitions so far are v ery similar, but differ in the ir deepness. 4 SPIT ANAL YSIS The pr o blem with the definitions ab ov e, is that they are either to sp ecific or to g eneral. In order to find a more precise definition, w e ha v e t o ana lyse how SPIT is put in to exec ution and what the goal of the initiator of SPIT is. In practice the initiat o r of SPIT has the goal to establish a comm unication session with as m uc h victims as p ossible in o rder to tra nsfer a message to an y a v ailable endp oint. The attac k er can fulfil this via three steps. First the systematic gathering of the con tact addresses of victims. Second is t he establishmen t of comm unication sess io ns with these victims a nd the third step is the s ending of the mess age. In the follo wing w e will not only discuss, why the pro cess of informa- tion gathering is part of the SPIT pro cess, but w e will also see that it is the basis of any SPIT attac k. In order to con tact a victim, the at- tac k er m ust kno w the SIP URI of the victim. W e can differ p ermanen t SIP URIs (e.g. s ip:someone@example.com) and temp orary SIP URIs ( e.g. sip:someone@192.0.2.5). 2 4.1 Information gathering A t first w e will take a lo ok at information gat hering of p ermanent SIP URIs. If an attack er w an ts to reac h as man y victim s as p ossible he m ust catalogue v alid assigned SIP URIs. The premisses f o r the Scan attac k are the p os- session of at least one v alid accoun t and kno wledge ab out the sc heme of SIP URIs of the targeted platform (e.g. pro vider). Let us assume the atta ck er has a v alid SIP account at SIP provider ”exam- ple.com” and he w an ts to scan the provid er’s net work, in order to ac hiev e a list of v alid permanen t SIP URIs. Let us also assume that the provide r ” ex- ample.com” distributes SIP URIs that corresp ond to the f o llo wing sc heme: The user name of the SIP URI is a phone num b er that b egins with the digits ”555” f ollo w ed by 4 more random digits. All phone num b ers from ”5550000” to ”5559999” are v alid user names of this pro vider. As the attack er has no w kno wledge ab out all v alid user na mes, he m ust find out whic h of them are already assigned to customers and whic h of them are not. The attack er can no w step throug h the whole list of v alid SIP URIs and send adequate SIP messages to each URI and receiv e info rmation ab out the status o f the tested URI. The simple st w ay is sending an INV ITE message to eac h SIP URI and analyse the answ er of the SIP Pro xy . If the SIP URI is not assigned, the SIP Pro xy may answ er with a ”404 Not found” resp onse, if the SIP URI is assigned but the user is not registered at t he momen t, the SIP Pro xy may answ er with a ”480 T emp orarily unav ailable” resp onse and if the SIP URI is assigne d and the use r is registered, the call will b e established and an- sw ered with a ”200 OK” resp onse. When t he atta c k er has stepp ed t hrough the whole list and mark ed all p ossible SIP URIs, he has a lis t of a ssigned SIP URIs, that can b e used for future attac ks. Note that it is not necessary that the scan attac k m ust be fulfilled w ith an INVIT E message, w e just dis- cussed this wa y as the simplest w a y , b ecause it alr eady leads to the desired session establishmen t. The atta c k er could also use a n OPTIONS request or a REGISTER request and analyse the reaction of the Prox y . Mainly the im- plemen tation of the targeted Pro xy decides on whic h mes sage will gran t the desired information. Some Pro xies e.g. resp ond to all OPTIONS requests with a ”200 OK ” message, eve n in case of an inv alid or unassigned SIP URI. No w w e will tak e a lo ok at gathering o f temporary SIP URIs. T emp orary SIP URIs consist of the user name part and the ho st part. The user name part is us ually a string or a phone n um b er and the host part is the IP , where the endp oin t can b e reac hed directly . If an attac k er has already generated a list 3 of v alid assigned SIP URIs, he no w additio nally needs the correspo nding IP addresses o f the SIP URIs. In some Pro xy implemen tatio ns the temp orary SIP URIs are published in the ”Con tact” header of the res p o nse message to a request. In this case the desired informatio n is achiev ed in the same w ay as the p ermanen t SIP URIs. If the pro xy do es not pro vide the IP address in the SIP resp o nses, the attac ke r m ust use a more complex metho d to ac hieve the desired informatio n. Let us assume this t ime that ”example.com” is an In ternet Service and V o IP provider. The pro vider a ssigns IP addresses of the range 19 2 .0.2.5-192 .0 .2.155 to his customers and SIP URIs with t he same sc heme as describ ed ab ov e (555XXXX). Let us assu me The customers ha v e hardphones (e.g. analogue telephone attached to V oIP ready router or Analog telephon y adapter). With this kno wledge the attac ker can step through the list of IP addresses and tr y sending an adequate SIP request (INVITE,OPTIONS) directly t o the endp oin t (e.g. to UDP P ort 5060) and analyse the respo nses in the same w ay as described ab ov e. The a t t ac k er can p opulate a list of temp ora r y SIP URIs. Note that the temp orary SIP URIs are only v alid for a short time perio d (max. 24 hours), as customers are usually forced to dis connect their in ternet connection after a certain perio d. Although this pro cedure is harder to fulfil than t he first one, it has the ma jor adv antage, that the attac k er do esn’t need v alid accoun ts a s premiss . Because the Proxy is no t inv olve d and SIP messages a re sen t directly to the victim, the atta ck er can use any SIP iden tit y he wishes as source address. The clien t can not verify the iden tit y , as nearly all existing implemen tations of clien ts accept SIP messages from a n y source. No w that we hav e seen ho w lists of p ermanen t or temp orary SIP URIs can b e ac hiev ed, w e will discuss the usage of the m. 4.2 SPIT session establishmen t When the a t t ac k er has collected a large n um b er of con tact addresses , he can b egin session establishmen t to the victims. Whic h list he m ust use (temp o- rary or p ermanent URIs) dep ends on the comm unication infrastructure he w an ts to use. W e c an distinguish t wo p o ssible w ays of session establishmen t: The att a c k er can establish a se ssion with se nding a n INVITE message via Pro xy , whic h w e can call SPIT via P ro xy or he can establish a session with sending a n INVITE message directly to the endp oint without in volving the Pro xy , whic h we can call D ir ect IP Spitting. F or SPIT via proxy the attack er only needs a list of permanen t SIP URIs and for Direct IP Spitting he needs 4 the list of temp orary SIP URIs. Again for SPIT via Pro xy the attac k er needs at least o ne v alid user accoun t and for D irect IP Spitting he do esn’t need a v alid accoun t at all. 4.3 SPIT media sending The last step of the SPIT pro cess is the media se nding after the session has b een established. Whic h t yp e of media is sent, dep ends on the scenario in whic h the SPIT attack take s place. The b est scenario classification can b e found in [2] and defines three t yp es of SPIT scenarios: • Call Cen tres: In Call cen tres a computer establishes a call to an en try of the cata lo gue and then dispatc hes the call t o a call cen tre agen t who will then talk to the callee. • Calling Bo t s: A calling b o t steps thro ugh the list of gat hered informa- tion, establishe s a session and then sends a prerec or ded message. • Ring tone SPIT: Some V oIP telephones come pre-configured in a wa y that they a ccept a sp ecial SIP header informatio n called ”Alert-inf o ” whic h ma y contain an URL pointing to a prere corded audio file some- where on the Interne t. Ob viously , this can b e used to pla y adv ertising messages before the call has eve n b een accepted b y the user just a s the phone is ringing. An adaption of t his metho d could b e a SPIT attac k where the a ttac k er just w ants to let the victims phone ring, in order to dis turb the victim. In this special case no media is sen t at all and the session is terminated as so on as the phone rings (e.g. when a ”180 R inging” is receiv ed). Ob viously this is the most anno ying facet of SPIT. 4.4 SPIT summary As w e can see now the SPIT pro cess is v ery complex and has differen t as- p ects whic h ha v e to b e cons idered in order to deve lop coun termeasures. The general definitions that w e discusse d in the first section are insufficien t a s a basis of discuss ion and do not cov er a ll facets of the problem. In general w e can sa y , that Spitting describ es the systematic scanning o f a V oIP net w ork with the tar g et of gathering information ab out av ailable user accoun ts and the systematic session establishmen t attempts to as man y users as p ossible in order to transfer a n y kind of message. 5 5 SPIT COUNTERMEA SURE S AND THEIR WEAKN E SSES In the follo wing sections we will discuss state of the art SPIT prev en tion mec hanisms in order to p oint out their adv an tag es a nd disadv an ta g es. The coun termeasures are ordered by t yp e and not b y publication. As a matter of fact most publications define a set of counterme asures as a solution to mitigate SPIT . Nev ertheless w e will discus s eve ry metho d on it’s own and not the orches tra t ion of different mec hanisms. Note t ha t only those tec hniques are listed, that ha ve crys tallised in researc h. 5.1 Device Fingerprin ting The t echniq ue of activ e a nd passiv e device fingerprin ting is presen ted in [4] and is based on the follo wing assumption: Ha ving kno wledge ab out the type of User Agen t that initiates a call, helps finding o ut whether a session initiation a ttempt can b e classified a s SP IT or not. The assumption is based o n the analogy to e.g. HTTP based worms . As describ ed in [4] these types of w orms hav e differen t sets of HTTP headers and differen t resp onse b ehaviour, when compared to typ ical W eb brows ers. So if we can compare the header la yout and order or the resp onse b eha viour of a SIP User Agen t with a t ypical User Agent, w e can determine if the ini- tiated session establishme nt is an attac k or a normal call. The authors de scrib e tw o t yp es of tec hniques that can be used for t ha t pur- p ose ”P assiv e a nd Activ e Device Fingerprin ting”. 5.1.1 P assiv e Fingerprin t ing The e.g. INVITE message of a session initiation is compared with the IN- VITE message of a set of ”standard” SIP clien ts. If the order or app earance of t he header fields do es no t match an y of the standard clien ts, the call is classified as SPIT. The fingerprin t in this case is the appeara nce and the order of the SIP header fields. The a uthors of [4] presen t a list of collected fingerprin ts of standard hard and soft phones. 5.1.2 Activ e Fingerprin ting User Agen ts are prob ed with sp ecial SIP messages and the resp onses are analysed and compared with the resp onse b eha viour of standard clien ts. The fingerprin t in this c ase is the returned resp onse co de and the v alue of certain 6 header fields. If the fingerprin t do esn’t matc h an y of the standard clien ts, the call is classified as SPIT. The authors recommend the sending of sp ecially crafted standard compliant and non complian t OPTIONS requests, in order to analyse the response b ehaviour of a clien t. 5.1.3 W eakness of Device Fingerprin ting The w eakness of passiv e fingerprinting is described by the a utho rs of [4] themselv es. As passiv e fingerprinting only a nalyses the order and existence of the header fields of an INVITE message, an a ttac k er simply needs to o rder the header fields in the same w a y as one standard clien t. In that case t he passiv e fingerprin ting mec hanism can’t detect the attack. W e can state nearly the same fo r activ e fingerprinting, as a n att a c k er only needs to b eha ve lik e one standard clien t when receiving unexpected or non standard complian t SIP mes sages. It is v ery simple for an a ttac k er to dev elop an attac king SIP clien t that b eha v es ex actly lik e a standard clien t, as he can use the same SIP Stack or imitate the b eha viour of SIP Stac k of a standard clien t. W e can call this a t t ac k Device Spo ofing and an y att a c k er, who is able to spo of a dev ice can nott b e iden tified. As Device Fingerprin ting is dis cussed as a serv er side anti SPIT mec hanism, it is useless against Direct IP Spitting as the clien ts don’t hav e an y c hance to v erify the fingerprin t of the attack ing client. In the end w e will tak e a lo ok on practical issues of Device Fingerprin ting. When we take a lo o k at to day’s V oIP univ erse, w e will find out that there exist a v ast v a riet y of hard- a nd softphones. Eac h of this phones has it’s own SIP Stac k and ev en within a pro duct fa mily header lay outs and b ehav iour differ ev en b et w een tw o v ersions of the same device. The result is, that an administrator who uses Device Fingerprin ting in order to pro tect his system, m ust alwa ys k eep the list of fingerprints up to date. Comparing the INVITE message of a caller with an old o r incomplete fingerprin t list, can lead to blo c king the call although t he call is not a SPIT call. L et us e.g. a ssume that a caller uses a standard clien t and that the man ufacturer sends out a firm w are upgrade, that mak es ma jor changes to the SI P Stac k. Any calls of this user are blo c k ed or mark ed as SPIT, until the administrator of the V oIP net w ork up dates the fingerprin t list and this pro cedure will rep eat an y time a new firm ware v ersion is rolled out or ne w clien ts are released. T aking it ev en one step further, we can see, that as more a nd more clients and v ersions are released, the fingerprin t list will b ecome wider a nd wider 7 and in the end nearly an y com bination of e.g. header fields will b e presen t in the list. The main problem of device fingerprinting is that it is deriv ed from a HTTP securit y tec hnique. In that scenario only few clien ts (w eb browsers ) from few dev elop ers exist, in con tradiction to the V oIP w orld. 5.2 White Lists, Blac k Lists, Grey Lists The White List tec hnique is presen ted e.g. in [2] [1] and works as follow s: Eac h user has a list of users that he accepts calls f rom and an y caller who is not presen t in t he list will b e blo c ke d. In addition the priv ate White Lists can b e distributed to ot her users. If e.g. a caller is not presen t in the White List of the callee, White Lists of other trusted users can b e c onsulted and their trusted users (up to a certain lev el), ho we ve r this tec hnique needs additional mec hanisms. Black Lists are the con tradiction of White L ists and con tain only identities , that are already know n as spammers. An y call from a caller whose iden tity is presen t in the callee’s Blac k List is blo c ke d. Ev en Blac k Lists can b e impleme nted as distributed Blac k Lists, where a callee can consult the Blac k Lists of other users. Grey listing w o rks as follo ws: On initial request of an unkno wn user (not in White List) the call is rejected and the iden tit y is put on the Grey List. As stated in [2] in case the caller tries calling bac k within a short time p erio d, the call will b e accepted. An adaption of this tec hnique is describ ed in [1] a s Consen t Based Comm unication. In case of Consen t Bas ed Comm unication the call of an unkno wn caller is initially blo c k ed and put on the G rey L ist. The callee can consult the Grey List and decide, if he will accept future calls from this iden tity or blo c k it p ermanen tly . 5.2.1 W eaknesses of W hite Lists, B lack Lists, Grey Lists Blac k Lists can not really b e view ed as a SPIT coun termeasure, b ecause additional methods are needed to classify a caller a Spitter. A Blac k List on serv er side w ould require e.g. statistical metho ds for classifying a caller as Spitter. In case of a clien t side Black List, the user m ust mark a caller a s a Spitter, e.g. after receiving an initial SP IT call from this caller. Both serv er side a nd clien t side Blac k List a r e v ery useless a gainst D irect IP Spitting for differen t reasons. Serve r sided Blac k Lists are b ypassed b y Direct IP Spitting, b ecause the SIP messages a re sen t directly to the clien t. Clien t sided Blac k Lists are c ircumv en ted b y Direct IP Spitting, b ecause the caller can tak e on an y iden tity in order to place calls. So if o ne iden tity is blo c k ed he can simply switc h the Iden tit y . W e can call this att a c k SIP Iden tity Sp o ofing and 8 an y attack er who can sp o of SIP iden tities, can easily b ypass Black Lists . White Lists are at first sigh t harder to circum v ent t han Blac k Lists, b ecause the attac k er has no kno wledge ab out the en tries of the White List of the victim. So ev en if he w ants to sp o o f a n identit y , the attac k er do esn’t know whic h iden tity he mus t tak e on, in order to place a successful call. In case of Direct IP Spitting the a ttac k er could simply try out all existing accoun ts with a brute force attac k until he finds out whic h iden tities are no t blo c k ed. A less exhausting pro cedure can b e performed in case o f dis tributed or imp orted white lists [2]. In that scenario the attack er needs one v alid accoun t. After adding the victim to the attac k er’s white list, he can no w select that he wan ts to imp ort the white list o f the victim. So he can g et access to all en tries of the victim’s white list and can sp o of these identities e.g. in a Direct IP Spitting attack. The Gr ey Lis t mec hanism can b e b ypassed the same w ay as White List mec hanisms, as it just represen ts a mec hanism tha t allo ws first time contact. All in all w e can say , that any atta ck er who is able to p erform SIP Iden tity Sp o ofing, can b ypass Black Lists , White Lists and Grey Lists. In the end we will take again a lo ok at the practical side o f the presen ted mec hanisms. Th e concepts of Blac k, White and Grey Listing are deriv ed from the Instan t Messaging world, wh ere it is a matter of course, that use rs first ask for p ermission, b efore they are added to a nother user’s buddy list and only buddies can comm unicate with eac h other. When a user receiv es a comm unication r equest, he receiv es the profile of t he other user containing e.g. nic k name, email address, full name or ev en profile photo. On basis of this information, the user can decide a nd is able to decide, if he w an ts to accept messages in future from that party or no t . T ak en to the V oIP scenario this mec hanism seems v ery impractical as the intro duction problem has to b e solved. Le t us ass ume e.g. an emplo ye e of a bank w ants to call one of his customers. In case of white listing the call can no t b e successfully routed to its target, as customers usually don’t hav e the phone num b ers of emplo y ees of their home bank listed in the White Lis t. The decision basis for accepting or rejecting a call is simply the phone num b er tha t is sen t b y the caller. If the call is rejected at first (Grey listing) the callee mu st decide if he w an ts to accept future calls and he m ust base this decision o n the phone n umber. W e can easily s ee tha t this fact is v ery impractical. 9 5.3 Reputation Systems Reputation based mec hanisms are describ ed in [5] or in [1] and can b e sum- marised as follo ws: Aft er receiving a call, the callee can set a reputation v alue for the caller, that marks this caller as Spitter or not. This reputation v alue m ust be assigned to the identit y of the caller and can be use d for future ses- sion establishmen t requests. This tec hnique can b e used e.g. as attac hment to Grey listing [1] in order t o pro vide a b etter decision basis . The autho rs of [5] explain that the user feedback can b e used additionally for calls that w ere not detected by other SPIT prev enting comp onen ts. The w ay the reputation v alue is generated can differ. The SPIT v alue can b e e.g. an additional SIP header, or included in a sp ecial error resp onse co de o r distributed via SIP ev en t notification mec hanism. Reputation sy stems can b e either based on negativ e or po sitive re putat io n v alues. This means that in first case only Spitters are mark ed with negativ e v alues or in second case ”normal” callers are mark ed with p ositiv e v alues. An adaption of this metho d can b e found in [6] where use r feedback is com- bined with s tat istical v alues in order to calculate a reputation v alue. The reputation v alue is e.g. comp osed of a v alue r epresen ting the num b er of times a n identit y o ccurs in o ther users’ Black Lists, call densit y , call length or similar statistic v alues. The assumption b ehind t his approa ch is that the calculated v alue will differ m uc h b et w een ”norma l” users and spitters . 5.3.1 W eakness of Reputation Systems Reputation systems tha t ar e based on negative reputatio n can b e b ypassed in same wa y as Black Lists [1]. A user with a negativ e reputation can b e view ed as globally blacklis ted as his calls are blo c ke d e.g. for any user (this dep ends on the p olicy that is used). Nev ertheless an attack er that is black listed simply needs to gain access to a new ”clean” accoun t. In case of a SPIT v alue as SIP header, t he SPIT v alue can b e sp o ofed by the attac ke r (e.g. with Direct IP Spitting) and w e can call this attac k SIP Header Sp o ofing . The attac ke r can simply set or c hange v alues of header fields, when he uses Direct IP Spitting. In addition an a ttac k er can create sev eral accounts with the aim of pushing the SPIT v alue of o ne accoun t up or do wn (dep ending on implemen tation). This attac k can b e called Reputation P ushing or Pulling . Again we will also take a closer lo ok o f practical issues of the a n ti SPIT mec h- anism. At first w e must admit, that Reputation systems are more auxiliary 10 features than SPIT blo c king mec ha nisms. The reason fo r this argumen tatio n is, that the user mu st classify a call as SPIT via a butto n or b y en tering a v alue. This v alue is used for future decisions on t ha t SIP iden tit y . So ini- tially SPIT is not prev ented by t his tec hnique. Then the SPIT v a lue of an iden tit y ha s to be sho wn to callees, so that they c an decide ab out accepting or rejecting the call. Let us assume a Spitter has ac hiev ed a SPIT v alue or SPIT probabilit y of e.g. thirt y p ercen t and then calls a victim. What should happ en no w? When the call is forwarded to the user and the v alue is e.g. sho wn in the display of the callee’s phone, he can decide to accept or reject the call on a b etter de cision basis. The problem is that an yhow his phone rings and that is what should b e prev en ted. He could hav e just pic k ed up the call and listened the first 5 seconds to know that it is SPIT. So the SPIT v alue didn’t just add one p ercen t of b enefit. On top o f this fact a ttac k ers could misuse the scoring system and create enough accoun ts in order to threaten ”normal” users with collectiv ely giving them negative reputation [1] 5.4 T uring t est s, Computational P uzzles T uring test are tests w here the caller is given a c hallenge, that a human can solv e easily and that is ha rd to solve fo r a mac hine. Therefore T ur ing t ests or CAPTCHA (Completely Automated Public T uring test to tell Computers and Humans Apart) are tests, that counterme asure Calling Bo t attac ks in V oIP scenarios. T uring tests in V oIP scenario w o r k as follo ws: On initial call establishmen t attempt, the caller is transferred to a n interactiv e System where he is c hallenged with a task e.g. dia ling 5 dig its that he is hearing (so called Audio CAPTCHA). While the nu mbers are read out bac kgro und m usic or an y other kind of noise is pla ye d, s o that sp eec h recognitio n systems can’t b e used to solv e the ta sk. A h uman caller in con tra diction will solv e the task without difficulties and o nly if the task is solv ed, the c all will be forw arded to its destination. T uring tests can b e used in combination with white lists, solving the in tro duction problem as described in [8]. Computational Puzzles seem at first s ight v ery s imilar to the T uring tests concept. As describ ed in [7 ] a SIP Proxy o r User Ag ent Serv er can request from a User Agen t Clien t (caller) to compute the solution to a puzzle. The goal of this metho d is to raise CPU costs of a call and so reduc e the num b er of undesirable messages that can b e sent. T ur ing t est in con tra diction hav e the goal to blo c k non-human callers, as describ ed a b o ve . According to [7] the 11 puzzle, that has to b e solv ed, could b e finding a pre-image tha t will SHA1 hash to the correct image. This means that the UA C will b e c hallenged with a SHA1 hash of a v a lue a nd the UA C m ust find out ( by computing it) whic h v alue has b een hashed. 5.4.1 W eakness of T uring tests and Computational Puzzles T uring tests seem at first sight v ery effectiv e for SPIT preve ntion in combi- nation with white lists, but nonetheless hav e we ak p oints . The first approac h of b ypassing Audio CAPTCHA is rela ying the CAPTCHA t o h uman solv ers. An attack er could pa y c heap w orkers , who are only hired to solv e Audio CAPTCHA. In countries with c heap lab our this w ould raise the costs per call o nly marginally [1]. In order to r educe the costs, an attack er could eve n e.g. set up an adult hotline and could dispatc h Audio C APTCHA to the customers of this service. This tec hnique is kno wn from visual CAPTCHA where the images f r om CAPTCHA protected sites are copied and rela y ed to a high traffic site owne d b y the attac ke r. All in all w e can state, that an attac ke r who c an detect CAPT CHA and rela y it to h uman solv ers is able to b ypass T uring tests a nd we can call this attac k CAPTCHA R ela y Attac k . Computational Puzzles can not b e view ed a s SPIT prev en tio n mec hanisms, as attac k ers usually p ossess high computational p ow er. So Circum ve nting a system protected b y Computational Puzzles, do esn’t ev en demand a sp ecial attac k. The attac ke r just needs sufficien t CPU p o wer. In the end ag ain w e will tak e a lo o k at some pra ctical issues of t he des crib ed tec hniques. As far as T uring tests are concerned, w e can see, that t his method is ve ry in trusiv e. User Interaction is forced ev ery time a caller is not presen t in the White List of a callee. The difficult y with Computational Puzzles is, t ha t differen t V oIP endp oin ts ha v e differen t abilities in computational p o w er. So if t he task is to hard to solv e (consumes to o m uc h CPU p ow er), session establishm ent will b e dela y ed v ery m uc h for e.g. a lo w-end cell phone, while attac kers with high CP U p o wer PCs w on’t b e concerned m uch. With this fact Computational Puzzles are v ery ineffectiv e a nd con tra pro ductiv e, as they only b other ”normal” users. 5.5 P ay ments at risk P a ymen ts at risk mec ha nisms can b e used in order to demand pay ment from an unkno wn caller. In [1] this tec hnique is des crib ed as follows : If user A w an ts to call user B, he m ust first send a small amoun t of money to user B. 12 When User B accepts the call and confirms that the call is not a SPIT call, the amoun t will b e c harged bac k to user A. With this tec hnique it is p ossible to raise costs for SPIT callers while k eeping ”normal” calls che ap. In [1] it is describ ed as a n auxiliary techniq ue that solv es the introduction problem of White lists, tis means, that paymen t is only required f o r callers who a re not on the White list of callee. In general the payme nt could b e demanded for ev ery call, but this w ould mak e the telephon y service more expensiv e. An adaption of this metho d is described in [9], here the P ayme nt tec hnique is used in com bination with a SPIT prediction v alue tha t is computed a t serv er side. If the SPIT like liho o d is high the call is rejected, if the SPIT lik eliho o d is small the call is forw arded to the callee and if t he SPIT lik eliho o d v alue is in b et w een p aymen t is demanded auto matically . Only if the pa ymen t is fulfilled the call will b e fo rw arded t o its targ et. The difference b et w een the t w o approaches is, that in the first case the pay ed amount is only ch ar ged bac k for non SPIT calls and in the second case, callers who reject payme nt are treated as Spitters. 5.5.1 W eakness of Pa ymen t at r isk In whic h w ay P aymen t at risk can b e b ypassed dep ends ma inly on the wa y it is implemen ted. As described demanding pa ymen t for eac h call w on’t b e v ery realistic, b ecause this w ould req uire a high administrativ e ov erhead a nd more costs for service prov iders. Let us a ssume P aym ent at risk com bined with White listing as in the first example, so that pa ymen t is only required for callers that are not presen t in the callee’s White List. In this case a caller could simply spo of iden tit y a s describ ed in the se ction ab out White List. In the se cond scenario, where P a ymen t at risk is com bined with a Reputatio n system, the att a c k er just needs to ac hiev e an adequate reputation v alue, as described in the correspo nding section. Let us even assume, that P aymen t at Risk is used for ev ery call. Ev en In that case an attac k er could circum ven t it, by imp ersonating a s another us er, so that he can establish calls a nd shift the costs on to ” no r mal” customers. In whic h w ay this kind of SIP Identit y Hijackin g attack is fulfilled is an other ques tion and out of scop e for no w. Besides the tec hnical asp ects, practical issues of P aym ent at R isk are nu- merous. A t first the relativ e high costs, that are required for micropayme nt will m ust b e view ed, the inequities in the v alue of currency b et wee n sender and r ecipien t [1] and the additio nal interactions that a user must take (e.g. 13 confirming a call from an unk nown part y as non SPIT). 5.6 In trusion Detect ion Mech anisms, H oney phones In trusion Detection Systems are (generally described) systems , tha t can b e used for detection of a n y kind of abnormal b eha viour within a e.g. netw ork and so rev eal attack s. An implemen tat ion of this tec hnique is presen ted in [10] based on the Ba y es inference approac h com bined with net w or k monitor- ing of V oIP sp ecific tr affic. The In trusion Detection System is designed as a defence mec hanism against differen t V oIP sp ecific a ttac ks including scan attac ks and SPIT attac ks. F or ev ery attac k a conditional probability table (CPT) is defined f or v ariables suc h a s request inte nsity , error respo nse in ten- sit y , parsing error inte nsity , n um b er of differen t destinations, max num b er o f dialogues in w aiting state, n um b er of op ened R TP p orts, request distribution and resp onse distribution. Let us lo ok at e.g. the CPT f o r the n um b er of differen t des tinatio ns v a riable: F or a SPIT attac k the like liho o d of ha ving more tha n 7 differen t destinations is set to 1 and the lik eliho o d o f hav ing up to 7 differen t destinations is set to 0. The concept b ehind this techniq ue is, that the differen t atta c ks affect these v ar ia bles in differen t w a ys, e.g. a SPIT attac k us ually has a higher probabilit y of a higher n umber of destinations than nor ma l t r a ffic. So a b elief of a netw ork trace can b e calculated with the aid of lik eliho o d vec tor s that were defined in the CPT. In the end the trace can b e c atego rised as an attac k or normal trace (refer to [10] for detailed description). Honey phones can b e used as part o f an In trusion Detection Systems as de- scrib ed in [2] [11 ] and can b e view ed as V o IP sp ecific Honeyp ots. A Honeypot represen ts a part of a netw ork that is no t a ccess ible by ”normal” users and therefore an y access to the honey p o t can b e view ed as an attac k. V oIP spe- cific hone yp ot s can b e used in or der to detect Scan attack s or SPI T attac ks. As describ ed in [11] the Honeyp ot is implemen ted as a complete parallel V oIP infrastructure, that is logically and ph ysically separated from the normal net- w ork and so simulates a whole V oIP net w ork. Let us assume a Scan a t tac k as describ ed ear lier. When the attac k er sends e.g. OPTIONS or INV ITE requests to v alid assigned p ermanen t URIs they are forwarded thro ugh the normal SIP net work ( Proxy , UA C), but when the atta ck er tries to send an OPTIONS request to an unassigned o r in v alid SIP URI the request will b e forw arded to the Honeypot, where the r equests can b e monitored and tr eat ed adequately . The a ut ho r s of [11] prop ose call a nalysis in order to determine 14 attac k c haracteristics, interaction with the originat o r in order to determine the source of the attac k and blo ck ing of the calls, as adequate treatment. The mo nito ring system o f this approac h works a s follow s: A da y is divided in to sections of sp ecified time (e.g. one hour). F or eac h section a predefined metric is calculated (e.g. n um b er of calls, n umber of differen t recipien ts, av - erage duration of a call) matching predefined ev en ts (e.g.call). I n the learning phase (e.g. a mon th), daily statistics are built to extract a long term accoun t profile (e.g. daily av erage of the num b er of calls for each section). In the detecting stage (e.g. a day), a short term profile is compared to the long term one by using an appropr ia te distance function (e.g. Eu clidean dis tance, quadratic distance, M aha lanobis distance). A recen t profile which is q uite differen t from the long term one indicates po ssible misuse. Another metho d is to study non stationary features of an accoun t, for example the distribu- tion of calls o v er all callees or the shap e o f the callees’ list s ize ov er all dialed calls. By comparing c hanges of a distribution ov er the time by using of an appropriate distance function (e.g. Hellinger distance), sudden bursts may b e detected and treated as abnormalities [11]. 5.6.1 W eakness of In tr usion Detect ion Mecha nisms, H oney phones In trusion Detection Systems ba se on the assumption, that the characteristics of atta c ks differ m uch from c haracteristics of normal calls. At first s ight this assumption seems lo gic, as e.g. within a SPIT attack , the attack er calls hun- dreds or thousands of victims within a n hour, while a normal user w ouldn’t ev en send out one percen t of this amoun t of calls. Nev ertheless the attack er has tw o p ossibilities in order to b ypass detection by an In trusion Detection System. The first is to align his b eha viour with the b eha viour of normal users, e.g. adjust the call rate to 5 calls p er hour. Ob viously this tec hnique is hard to f ulfil, b ecause this w ould mak e an att a c k very inefficien t as it w ould consume to o m uc h t ime, but on the other hand t he goal of a spitter is not to reac h as m uc h users as p o ssible within the s hortest time perio d. Reac hing e.g. thousand users with a call rate of 5 calls per hour w ould tak e appro ximately 8 day s. W e can call this techn ique Call Rate Adaption , this means that an attack er is able to adjust his call rate (e.g. num b er of calls p er time slot, n umber of sim ultaneous calls). As the c all rate is not the only v ariable that is us ed in order to de tect abnormal behaviour an attac k er can use a second tec hnique in order to not b e detected by Intrusion Detec- tion Systems. T he a ttac k er can use differen t accoun ts for his attacks , so 15 that statistic v alues ar e spread ov er sev eral accoun ts. Let us assume that an attac ke r has one hu ndred v alid user accoun ts. With this amoun t o f acc ounts he can partitio n the targeted user accoun ts in t o one h undred groups and use only one accoun t p er group. The users from g roup one are only called with accoun t one and so on. It is harder for a monitoring system to detect attac ks that are originated from differen t sources, as there mus t b e a t ec hnique to correlate partial att a c ks to o ne complete attac k. This techniq ue can b e called Accoun t Switchin g , as the a t tac k er switc hes the used accoun t while he is p erforming an attac k. Honeyp ots are v ery effectiv e against scan attack s a s an y one who tries to reac h in v a lid o r unassigned iden tities, will b e trapp ed and so Honeypots are v ery effec tive against SPIT. Whe n the Spitter can’t scan the net w ork for as- signed a nd unassigned n um b ers, he is forced to view all n um b ers as assigned. When he views all n umbers as assigned, he will so oner or later step in to the trap, b ecause he will establish calls t o endp oints, that a re part of the Honeyp ot. Neve rtheless attac kers can trick the Honeyp ot mec hanism with SIP Iden tity Hijacking . When an attack er imp ersonates the accoun ts o f normal us ers and then p erforms SPI T attac ks with this normal accoun ts, he will access end p oin ts in the Honeyp ot system with normal accoun ts. So the assumption that accesses to the Honeyp ot ar e only established by attac ke rs is lapsed. In the end we will t a k e a g ain a lo ok at the practical issues of the pr esen ted solutions. The practical problem w ith in trusion de tection system s in general is, that they ba se o n statistical assumptions t ha t a r e not verifie d. The que s- tions that has to b e solv ed is: Where is the b or derline bet wee n normal usage and abnormal usage? The publishe rs state that statistical v alues a r e assumed or deriv ed fro m atta ck c haracteristics, but in order to reduce the rate of false negativ e and false p o sitiv e classifications, the know ledge basis m ust b e pre- cise. So we can sa y tha t what we lac k, is kno wledge of SPIT c har a cteristics as w e no wada ys can’t really distinguish SPIT from normal traffic unless the SPIT attac ks are excessiv e. Honeyp ots ha v e the disadv an ta g e, that they only detect access to in v alid or unassigned accoun ts, this means tha t a n attac k er who only access es v alid accounts w on’t b e handled b y a honeyp ot. 5.7 Summary W e can finally sa y , that we ha ve seen SPIT countermeas ures with differen t w eak points . All of the presen ted ideas hav e tec hnical and practical weak 16 p oin ts, that can b e exploited b y attac k ers in o rder to circum v ent these tec h- nique. An attack er who is able to p erform Device Spo o fing, SIP Iden tity Sp o ofing, SIP Header Sp o ofing, Reputation Pushing or Pulling, CAP TCHA Rela y Attac k, SIP Iden tit y Hijac king, Call Ra t e Adaption, a nd Accoun t Switc hing has a go o d rep ertoire, that enables him to b ypass an y of t he pre- sen ted tec hniques or combinations o f them. An attack er now needs a t o ol that aggregates the presen ted a t t ac ks. 6 SIP XML SCEN ARIO MAK ER In the follow ing sections w e will in tro duce our SPIT pro ducing b enc hmark to ol, that implemen ts the presen ted att a c king tec hniques. 6.1 T echnica l Basis SXSM is ba sed on SIPp dev elop ed by HP [12]. SIPp is a n Op en So ur ce test to ol and traffic generator for SIP . SXSM expands SIPp with the ability to quic kly create custom SIP scenarios via a graphical user interface (GUI), execute created scenarios and ev aluate the r esult of the execution. The func- tionalit y is fulfilled by tw o differen t editing mo des and one execution mo de. 6.2 Message Editor The message editor delive rs the basis functionalit y , the abilit y to create cus- tom SIP Me ssages. SIP mes sages are the sm allest elemen t s of SIP scenarios, as SIP sce nario s are seque nces of SIP messages. Within the mes sage editor, the user can configure the lay out of eac h a nd ev ery SIP message, that can b e used in the scenario editor (explained later). Additionally the messages can b e group ed in to sets, so that the user can create e.g. t w o differently comp osed INVITE messages a nd put one into set A and o ne in to set B. Later the user can dis tinguish the tw o INVITE messages, because the y are in differen t sets. In the message editing mo de the user c an ev en comp ose or mo dify existing SIPp con trol messages (e.g. pause c ommands) that can be used in order to control the b ehav iour during execution. SXSM comes preconfigured with a set of standard messages that can b e use d as orien tation in order to comp ose o wn messages. 17 6.3 Scenario E ditor The scenario editor is the core elemen t of SXSM. In this mo de the user can create SIP scenarios, based on the bric ks created in the message editor. Ev en the scenarios can be gro up ed in differen t sets. The user m ust c hose a name for a scenario and can then select f rom the list of messages, the messages he w an ts to add to the scenario and in whic h order they should app ear. Afterw ards the user can edit the scenario, that is presen ted as an XML file, in detail. Let us assume t he user wan ts to create a scenario where an INVITE message is sen t, then a ”1 00 T rying” is receiv ed, then a ”180 Ringing” is receiv ed then a ”200 OK” is receiv ed. In this case the user simply selects these messages and adds them to the scenario, sa v es the scenario file and w ork is done. 6.4 Sho ot Mo de The sho ot mo de r epresen ts the execution mo de. In this mo de the user can put previously created SIP s cenarios into a sequence, execute them one after the other and ev aluate the results presen ted. The user s elects scenarios from the scenario list and adds them to the sho ot list, then he configures the call rate ( calls p er time p erio d), t hen he en ters information ab out the target (remote IP , remote p ort) and ab o ut himse lf (lo cal IP , lo cal p o rt). After this information has b een prov ided, he m ust pro vide information ab out the SIP iden tities, that should be used for the execution. The user can ch o ose, if he w ants to use fixed v alues for b oth source and target SIP URI o r inject v alues f rom an ex ternal CSV file. In first case he mu st pro vide a us er name for the targeted SIP URI and this user name will b e used for eac h and ev ery call, that is executed through the sho ot list. If the user w ants to inject v alues from an external CSV, he mu st sp ecify t he lo cation of the file. After all par ameters hav e b een set, the user can execute the sho ot list. SXSM then feeds SIPp with the input data and w aits un til the scenarios are execu ted. When the execution is fulfilled, SXSM ev aluates the exit co des, that w ere gene rat ed by SIPp. The following exit co des are considered: • 0: All calls w ere successful • 1: A t least one call failed • 97: exit on in ternal command. Calls ma y hav e b een pro cessed. Also exit on global timeout 18 • 99: Normal exit without calls processed • -1: F ata l error Based on the exit co de a success rate is calculated and displa y ed. If e.g. all scenarios of the sho ot list completed with exit co de ”0” then the success rate is ”10 0”. Additionally log files will b e presen ted for each scenario, that can b e used for deb ugg ing purp ose in case of failed sc enarios. 6.5 Using SXSM as attac k to ol As SXSM is implemen ted within a v ery broa d and modula r con text, it can be used for all SIP testing purp oses and in sp ecial as a SPIT pro ducing attack to ol. In the f o llo wing w e will discuss h ow the differen t attac ks, that we re presen ted in the previous sections, can b e put in to pra ctice. 6.5.1 Device Sp o ofing The Device Sp o ofing attac k is an attac k, that has tw o facets. As w e discuss ed earlier device fingerprints can b e deriv ed from the lay out of the SIP messages or from the b ehav iour . The lay out of SIP messages can b e manipulated within the message editor o f SXSM. If a user w ants to imita te the message la y out (presence and order of SIP headers) of a device, he simply needs to create a new set of SIP messages, name the set after the device and create the desired SIP mes sages, according to the wished la y out. The b ehav iour of the clien t can b e manipulated within the scenario editor. The ability to create sce nario s that con tain branc h points eases this process. A scenario can then contain a section for ev ery message that can b e receiv ed. The user m ust only put tests in to the scenario with the sc heme ”if message x is receiv ed jump to sec tio n y”. 6.5.2 SIP Iden tity Sp o ofing Iden tit y Sp o o fing in its simple form is prov ided b y inserting the wished SIP URI in the ”F rom” and ”Con tact” header of the SIP messages. If the user w an ts to inject the SIP URI from an external CSV file he mus t sp ecify this in the scenario file. The user simply needs to put the expression ” [fieldn]” where n represen ts a n um b er (the column of the CSV file) at the p osition where the user name is usually placed in the ”F rom” or ”Con tact” he ader according to the follo wing sc heme: 19 F r om: [field0] < sip:[field1]@[lo c al ip]:[lo c al p ort] > ; Here the first column of the ”caller.csv” file con tains the name of the iden tity and the se cond column con tains the user name part of the SIP URI. 6.5.3 SIP Header Sp o ofing SIP Header Sp o ofing can b e fulfilled with tw o differen t appro ac hes. The first one is to create custom SIP messages with the message editor and set headers and header v alues as wished. The second is using standard SIP messages and c hange v alues of headers with the detail view of the scenario editor. The first one should b e preferred, if the user wan ts to create a lot of scenarios with the same header v alue and the second v aria n t should b e used, if the user w an ts to t w eak v a lues o nly once in a while. 6.5.4 Call Rate A daption The Call Rate Adaption attac k can b e fulfilled within the sho ot mo de. The user just needs to add a scenario to the sho ot list and adjust the v alues for call ra t e. He can put e.g. ”Scenario X” into the sho o t list and set the call rate to 10 times per se cond and s to p as so o n as 100 calls hav e b een finis hed. With this me tho d it is p o ssible to control in detail ho w man y times in wh at time p erio d a scenario is executed. As one and t he same s cenario can b e presen t sev eral times in the sho ot list, the user can define the b eha viour v ery precisely . So he can e.g. determine that ”Scenario X” s hould b e executed 100 times with a call rat e of 1 0 calls p er second and then 20 times with a call ra t e of 2 calls p er second. Note that the phrase ”call” means one pass of scenario fr o m b eginning to end and do es no t mean that a call is a ctually placed. A scenario could e.g. consist of sending an OPTIONS request and receiving the answ er. 6.5.5 Accoun t Switchin g The Accoun t Switc hing attac k is a sp ecial form of SIP Iden tit y Sp o ofing and can b e fulfilled by pro viding an external CSV file with appropriate data. Let us assume the user w a n ts to place 100 calls to h undred differen t targets with ten diff erent SIP iden tities. The CSV file for the callee should contain h undred ro ws and each row should con tain the user name of the targeted URI. The CSV file for the caller should contain 1 0 rows and each row should con tain one of the ten user names, that should b e used as source. Including 20 the SIP iden tities for the caller can b e fulfilled with the mec hanism describ ed in the section ab o ut SIP Iden tit y Sp o ofing. Including the SIP iden tities of the target can b e configured in the sho ot mo de b y selecting the external CSV file as target. 6.5.6 Reputation Pushing or Pulling Reputation Pushing or Pulling is v ery dep enden t of the implemen tation, but can b e fulfilled in a g eneric w a y . The user simply needs to create t wo scenar- ios. One, that sends out a call and one, tha t receiv es a call. The receiving sce- nario should include e.g. a p ositiv e reputation v alue in to the BYE message. Note, that this is t he p o in t where it is implemen ta tion sp ecific, as it dep ends on the implemen tat io n of the Reputation System where the reputation v alue m ust b e put. Then the user m ust launc h t w o instances of SXSM and sho ot out the calling sc enario with one instance and the rece iving scenario with the o t her instance. Combin ing this tec hnique with Accoun t Switc hing for the call receiving side can lead to the desired effect of Reputation Pushing or Pulling. 6.5.7 SIP Iden tity Hijac king SIP Iden tity Hijac king is again very implemen tat ion dep endan t. but w e can tak e a lo ok at a simple attack deriv ed from [13 ]. The registration hijac king attac k is presen ted as follows: 1. Disable the legitimate user’s registration. This can be done b y: • p erforming a DoS attac k against the user’s device • deregistering the user (another attac k whic h is not co ve red here) • G enerating a registration race-condition in whic h the att a c k er sends r ep eatedly REGISTER requests in a shorter timeframe (suc h as ev ery 15 seconds) in or der to ov erride the legitimate user’s r eg- istration request. 2. Send a REGISTER request with the attac ke r’s IP address instead of the legitimate user’s With SXSM this pro cess could b e put into practice, by creating scenarios for eac h of the pres ente d steps and execute them o ne after the other, but as the Session Hija cking atta c k has a v ariet y of aspects, that hav e to b e considered w e will not discuss this matter in detail for no w. 21 6.5.8 CAPTCHA Rela y Attac k The CAPTCHA Relay A tta ck can b e fulfilled with the Third Part y Call Con trol (3PCC) mech anism. With this mec hanism it is p o ssible for SIP p (and therefore for SXSM) to create a comm unication session with sev eral remote endp oin ts and so r elay e.g. calls. The pro cedure is f ulfilled as follows. The A ttack er calls the victim, who sends the Audio CAPTCHA. In resp onse the attac ke r calls human solv er and ”REFER”s t he victim to him. As the result the victim a ccepts and the human solv er solv es CAPTCHAs. As this attac k is a s go o d as the used CAPTCHA de tecting algorithm, t he tec hnique m ust b e a da pt ed to future implemen tatio ns o f b oth CAPTCHA generato r s and detecte rs. 7 CONCLUSION This pap er described the main asp ects, that should b e considered by dev el- op ers of anti SPIT solutions. W e sa w, that a precise problem definition is mandatory for SPIT researc h, as w e can only cov er all asp ects, if w e clearly kno w which pro blems ha ve to b e faced. Then w e saw, that state of the art an ti SPIT mec hanism still em b o dy b oth tec hnical and practical w eak p oin ts, that can b e view ed as vulnerabilities. In the last part of t his pa p er w e got an impression of ho w this vulnerabilities can b e abused by attack ers, with a simple attac k to ol, whose p ow er lays in full con trol ov er the SIP proto col. The next step of researc h should consider the presen ted attac ks and dev elop mec hanism that blank out these vulnerabilities. References [1] J. Rosen b erg, C. Jennings, R F C 5039 - The Sessio n In i tiation Pr oto c ol (SIP) an d Sp am , IETF, 2008. [2] M. Hansen, M. Hansen, J. M ¨ oller, T. Rohw er, C. T olkmit a nd H. W aack, Developing a L e gal ly Compliant R e achab i l i ty Management System as a Counterme asur e agai nst SPIT , 2007. [3] S. Dritsas, J. Mallios, M. Theoharidou, G.F. Marias and D. Gritzalis, Thr e at Analysis of the Sess ion Initiation Pr oto c ol R e gar ding Sp am , IEEE, 2007. 22 [4] H. Y an y , K. Sripa nidkulch aiz, H. Zhangy , Z. Shaez and D. Saha, In c or- p or ating A ctive Fingerprinting into SPI T Pr e v ention Systems , 200 7 . [5] M. Stiemerling S. Niccolini, S. T artarelli, R e quir ements and me tho ds fo r SPIT id e ntific ation using fe e db acks in SI P. Internet-dr aft , 2008. [6] F. W ang, Y. Mo, B. Huang, P2P- A VS: P2P Base d Co op e r ative V oI P Sp am Filtering , 2007. [7] C. Jennings, Computational Puzzles for SP AM R e duction in SIP. Internet-dr af t , 2008. [8] H. Tsc hofenig, E. Leppanen, S. Niccolini, M. Arumaithurai, Au tomate d Public T uring T est to T el l Computers and Humans Ap art (CAPTCHA) b ase d R ob o t Chal leng e s for S I P. Internet-dr aft , 2008. [9] S. Lisk e, K. Reb ensburg, B. Schnor, SPIT-Erken n ung, -B ekanntgab e und -A bw e hr in S I P-Netzwerken , 2007. [10] M. Nassar, R. State, O. F estor, Intrusion dete ction me chanism s for V oI P applic a tion s , 20 07. [11] M. Nassar, S. Niccolini, R. State, T. Ew ald, Holistic V oIP I ntrusion Dete ction and Pr evention System , 2008. [12] SIPp at Sourceforge, h ttp:/ / sipp.sourceforge.net/index.h tml . [13] Tw o attac ks against V oIP , h ttp://www.securit yfo cus.com/info cus/1862 . 23