← All talks

QUESTIONING 42: Where is the "engineering" in the Social Engineering of Namespace Compromises?

BSides Las Vegas1:04:231.4K viewsPublished 2016-08Watch on YouTube ↗
About this talk
QUESTIONING 42: Where is the "engineering" in the Social Engineering of Namespace Compromises? - Vineetha Paruchuri Ground Truth BSidesLV 2016 - Tuscany Hotel - Aug 03, 2016
Show transcript [en]

uh so up next we have uh vanita parchuri from dartmouth college so give her a welcome hello

so hi um questioning 42 so why are we questioning the answer to the live universe and everything because when we talk about a few attacks that seem to happen uh off in the wild we attribute this term called social engineering to this um it's just something we say when people do things and people deceptively get into systems by conning or deceiving other people or just cutting the system basically that's kind of what social engineering seems to be right now so yes we have the answer we know what went on we know what people did we know how they got in but what's the question as deep thought gave out the answer and as people were

trying to ponder the question so what is it that we're trying to solve now so what are we trying where's the engineering in social engineering so we we just say this but what does it really mean and if it is engineering in fact then why are we just saying this is something that someone with some charm and tact can pass through a system but where's the engineering part that's not engineering so what is all of this so that's what this is going to be let's just dive in so um at a very macro level the talk is going to be about some case studies uh that happened in the wild uh basically some attacks that were

supposedly called social engineering attacks that happened that were widely publicized but nothing really seems to be done about those things yeah and then get the lowdown on the theory basically what that means engineer what aspects of aspects that could be engineered from the data basically whatever case studies that happen and then um what i propose um is a way of visualizing this so-called problem um and right now we don't even know what this problem is as i said yes social engineering exists but what is the problem that social engineering is being targeted at is it identity theft maybe is it uh theft for financial motivations yes in some cases but we also see that in a

lot of cases these are not the primary motivators at all so in which case how do we do the risk metrics um what is this problem called then so that's kind of interesting to look at so that's what we're going to talk about so yes these were the case studies that i'm talking about where um in 1995 uh the most expensive domain name tilldate ever sex.com which was sold for 13 million dollars in 2010 i believe um the domain ownership was transferred um by a malicious person just sending a fax to the domain registrar yes i see people giggling there uh all it took for the transfer of ownership for the most expensive domain name ever

was a fax which was in fact poorly written because yes because the person was a hacker he did not have formal education uh he did not go to school there were a lot of spelling and grammatical errors which should have been obvious but the registrar just didn't care uh which we will get into it uh the policies and uh the culpability of registrars um so yes that was 1995 and in 2013 metasploit.com uh apparently got hacked um the same way not hacked yes but the domain was hijacked for a brief time h.d moore i believe tweeted about it saying hacking like is the 60s so almost two decades later why did that work um it shouldn't have um why

so that's one thing so um in 2015 i believe at tesla.com also got hijacked because a person who we don't know yet called at t posed as a tesla employee redirected all calls to his att number uh used that as an authenticating attribute to tesla's domain registrar and redirected tesla's dns and because he did that he was also able to detect tesla's mx records uh using which he could redirect all the emails going to the twitter official twitter accounts of tesla and elon musk and posted for a while why for the lulls exactly so what's the risk metric here no financial gain kind of an identity theft but not really kind of social engineering again but not

really there are aspects of social engineering yes um cloudflare this is interesting and this is yes yes yes i know so i was in the speaker lounge and i actually met an employee of cloudflare who was very interested in what we're talking about so yes this was widely publicized um cloud florcia matthew prince's prior personal gmail account got hacked how um combination of social engineering and a vulnerability in google two-factor authentication workflow i will tell you what so um so yes his private email was compromised by answering random security questions through uh someone obtaining his docs on somewhere um through which was connected to his work uh google apps account for which for which he was the admin for the club

flare um and because um he was an admin and they did the password recovery for the private email the two-factor authentication for the google apps account was disabled so this was a flaw in google two-factor authentication which has since been rectified but more of these keep popping up uh because there was one more which had a cross-site scripting vulnerability um and there was um at least one more which had a authentication app authentication or session authentication vulnerability i believe i could give you the exact information after the talk in case anyone is curious about it but yes so there was a part of it for social engineering part of it was vulnerability in workflow and part of it was also

unsafe secure practices where cloudflare admins were busy seeing themselves to the password recovery email sent to cloudflare clients just to ensure that the client got the email but if a malicious attacker was the admin he will get the same email which will have the link to the password recovery for the client from which he could recover the password for chance uh dns was compromised that way and that was fun so yes the target was 4chan um but yes then matthew prince goddard cloudflare uh the entire cloudflare system. yes they realized that this happened they rectified that in a few hours they were very transparent about it they were great about it but this happened um more fun stuff

the cia director um got um his uh a teenage hacking collective got access to cedar director's personal email and home telephone number and also partial credit card information in 2015 how they called verizon post as a verizon employee gave a fake uh employee code which verizon apparently calls a v code um why that code passed checks nobody knows um the cynical me says they're not even tracking this stuff more optimistic giving the benefit of doubt me says maybe they have a log now audit later policy which also is not appropriate here they should have authenticated that in real time i was just talking to someone about these things and they said that apt now just means advanced persistent

teenagers because in 2016 exactly one year after this happened and when everyone was up in arms uh the same teenage hacking collective um hacked the white house um director of the office of science and technology policy the director of national security and uh i believe also the deputy director of the fbi and also the miami pd fun same way they didn't even like do anything magical and revolutionary and this was the cia director's case was publicized so widely and people were so outraged about it why are these things being rectified so what is going on here so you can see part of it is yes social engineering but part of it is also inherent vulnerabilities and systems and

inherent vulnerabilities in policies inherent vulnerabilities and workflows inherent vulnerabilities and protocols how do we define these things what is this even that is why this shit's not being solved that is why what worked in 1995 is apparently working in 2013. so yes it seems very easy to do as an attacker but it seems harder to defend once you actually get into the nitty-gritty of these things yes so i didn't even go into all of these things and you kind of see where i'm going with this but yes there's more i'd be happy to talk about any of these cases in more detail if anyone wants to talk to me later uh but in the interest of time let's

just move on so yes um this is another interesting case that i do want to go into detail uh just because i can use points from here to like make my uh explain things later um so this is just one of the cases i mentioned here matt honan um he was a wired reporter um whose entire digital life got compromised all for what his three-letter twitter handle all for what for the lows because an apt advanced persistent teenager wanted to basically should post just because so how did they go about it yes so he went to first hornet's twitter account which listed his webpage which listed his personal gmail address um but then yes uh you need to control that

gmail address how unfortunately honolulu did not enable two-factor authentication but what happens when you don't uh enable two-factor authentication is if you go to the uh password recovery page in gmail it shows you the secondary email um the partial secondary email and if you're a human and not a machine you can pretty much guess what that is any guesses his name is matt honan and that is m some dots and n

like his name's matt holland like yes that's as simple as it gets you can just get it in the first try if you know the person so okay so now um the the person knows what he needs to do he needs to compromise his apple account how does he go about it he starts with amazon yes this is where it gets interesting so you call amazon generate a random credit card number that you want um all you need to add a new credit card number to an amazon account is billing address and email the account email so it has to be one of these two emails right it's either the primary email or the secondary email

he'll try if he doesn't get through at the first glance he'll hang up he'll call back and he'll try the other email two tries finite doable so yes somehow he added the cred not somehow this is exactly how he added the credit card information so um then he hung up calls again and now what happens um you claim to have lost control of the email associated with your amazon account so now you want to add another email which is the email controlled by you the malicious person yes i'm a bad person um so how what do they ask you now they ask you for yes your billing address and another identifier which is the financial information which you just had

so give the whole credit card number for all day care so yeah you're basically in you now have control over matt holland's email poor thing so why do you want to do this because you log in and you now have um information of his real credit card uh last four digits of his real credit cards which you then use to call apple and authenticate yourself as matt honen and get a temporary password on phone and get access to his me.com email so and then what did the teenager do basically wiped all of his devices just so that he couldn't get back in and i was talking about this yesterday at a mixer to another person who was telling

me that um this didn't happen in honors case but he was telling me that there's a new kind of attacks where people are holding your apple devices for ransom because if not they will wipe them so yes exactly this is how fun so um yes now he has control of honan's secondary email he can log in whatever got a temporary password and now he'll use that to control his primary gmail address because yes goes to password recovery does recovery gets to the email that he now controls um and then he now has information to pretty much everything banks twitter facebook he is a reporter so all of his high profile contacts you name it but what did the person do

posted on twitter didn't touch his accounts didn't buy on amazon they didn't do nothing just she posted on twitter for a while for kicks and giggles for the lulls yes so how do you do risk analysis here what is what according to you now is a high value target verizon account comcast account the cia director was hacked that way so how do you associate risk what's your um probabilities now when you're trying to engineer this that's why it gets complicated so even if given that you even have a mechanism to like sort this out and engineer that we don't that's a different story we i'm trying to get there so yes and yes all of these things go on

but um i wanted to have some fun um so i tried some and work ship that shouldn't work work i tweet stormed ranted so many times told them every time things went wrong why they went wrong and how they shouldn't go wrong but i don't know they're not they don't seem to be doing anything about this why will yes we'll get into the whole motivations and that in the next slide but what did i do um so yes amazon claims that this thing that happened doesn't happen anymore and yes it doesn't happen i did check um but i called nordstrom which is almost like calling amazon uh what did i do i just called them with

the number um on file for the account a account i did it to myself but i could do it any of you so be nice to me i guess um so um i just call them with uh the phone number on file and they're like hi vanita what can we do for you today didn't ask my billing ads didn't ask me to verify myself like didn't care who i was just scared i mean i called a person called with a number which is easily spoofable even a teenager yes could do it um what did i do i redirected a package i sent to myself and what did they ask me zilch just the new address that i wanted

to redirect the package to so while we're at it can we also please uh update my address to this new address that we're redirecting the package yes they did it and while we're at it can we also change uh the phone number associated with this account kind of yes and while we're at it can we also um change the email address associated with this account so yeah i was just pushing to see how far i can get away with and that's when they started asking me questions so that's when i hung up but then i called back no no it's not over i call back so now what do i have i have my other phone number that i control

i have this new address um that again i know now the old address is relevant because address on file is now my new address and i just changed my email because i know my zip code i know the email the old email i know my new billing address so yeah i basically owned my own nordstrom account whereas i could own yours too so yes be nice to me so yeah that was fun um and then yes ebay so then when we like go back to this uh cases yes uh in the case of at n because that was single letter twitter handle he was offered as much as 50 grand for his twitter handle um yes and at jb it was offered almost

500 grand probably by justin bieber fans but let's not get there let's not judge we're nice people or not um so yes um these are worth money um so what happened at that end at n got compromised eventually obviously yes uh there's enough motivation there um someone impersonated like in the case of verizon where they impersonated with a take we code which somehow passed they called paypal impersonated themselves as a paypal employee got the last four digits of the customer basically just got all the customer information um and then used that to call godaddy and um yeah fun yeah uh asked for basically use that to authenticate but wait paypal uh takes the last four digits of your

credit card and go daddy does the last six digits so you don't know the next two digits so what did the attacker do he just guessed and they let him guess because why uh he claimed that he lost the card um which he used to register this so now he doesn't remember so a very empathetic customer service person let him guess the thing so i wanted to see whether this is really true because that for me sounded very insecure and common sense dictates that you shouldn't let people guess financial information because whatever that's funny uh i mean if it was a real person he would at least have this number even if he lost the

card he would at least have this number on some email statement or something or he could even get it from his bank whatever so clearly it's not the person you're you need to be talking to but uh because you want to sell crap um you value my privacy less than you value your profit great so yes i called a bunch of people and saw how much i could get away with guessing and what do you know and yes i did get away with guessing with a bunch of other things but that's not interesting what's more interesting is they let me guess my own birth here because i claimed i forgot apparently forgot the year i was born

fun yeah isn't that fun would you i mean before i tried this i didn't even think things were this bad no when i told her so this was a part of my thesis so when i was telling my advisor what i did that day he was like are you kidding me and then he goes and tells to like all these people he met like i did not know things were this well i'm like yes sergey i did not know things were this bad so yes it's scary and a tnt oh my god don't even get me started on that i can go on for the rest of the but no i compromised my own att account at least

four times in different ways not the same thing which is why i don't know what they're up to i don't know what their playbook is because apparently they have no playbook yeah and kevin mitnick's a tnt account also got hacked i believe he even filed a case on that yeah that was fun and this was a while back and then now very recently um not exactly a t but the ftc uh chief technologist lori krainer's phones were a phone account like mobile phone account was compromised because someone claiming to be her uh went with a fake id got a bunch of fancy iphones and just left and then the real lori trainer's phones just got

disabled same uh similar thing happened to dearie maxine uh the black lives matter activist yeah so um this is not a one-off thing um this has been happening over the years again as we discussed historically bad stuff um why i don't know i tried telling them but all the response i got was please don't worry we will never give your pii to anyone who cannot verify themselves but i just told you how a person who is not me it can verify themselves they didn't get it i spent 20 minutes on the call then i got frustrated and then i just tweet stormed yeah well so yeah so i don't even know what their playbook is so i

can't tell you the exact algorithm that i used or the exact steps i followed because i didn't even need to do stuff i just sweet talk them naughty i mean i always we re-talk look at me i'm a bad person i just told you i'm not even a charming person and then they even accepted like what i said so okay whatever so yes why do these things happen bunch of things i can talk in detail about not talk rant in detail about each of these things until whenever but um in the interest of time the power imbalance is what uh we briefly talked i briefly talked about i touched upon a little earlier as to

they value their profit um more than they value our privacy there is no tangible value on privacy and that's another problem even with the law proving harm then a person's privacy is compromised is much difficult and the bar is unfairly higher than proving harm but like in terms of financial harm or physical harm so um i think ryan kayla um wrote a couple of really good a lot of your papers on this topic um and yes using namespaces and personally identifying information as authentication attributes ever so the whole purpose of an email or a phone number is for people to give it to public to contact you so why are you using public information to authenticate individuals

which you're somehow assuming that it's like safe or secretive enough to authenticate individuals that's stupid why are we doing it nobody knows it's just how it's done and there's no better mechanism now so let's just go with what worked in the 60s or the 90s or whatever um so yes the validity and vulnerability of whose data yeah this is another interesting thing that i pick on quite occasionally a lot of times um yeah don't even bother going to my website and uh who is uh looking me up on who is like it's hidden i opted for the privacy thing but most people don't um so billing address one apparently primary authenticating attribute in a lot of these services i can just

get it through going to your who's account and accountability of domain registrars yes so this is something i previously said i would touch upon yes so who's liable you just get a fax and then you don't even verify and then you just transfer ownership or in at m's case godaddy let them guess didn't even check with at end and just transferred the ownership of his domain to an attacker who then held that up for ransom and wanted his twitter handle fun so these are legal aspects associated with i said uh proving harm for loss of privacy and legally the law hasn't quite caught up with um the technology we all know that and yes there are some game theory and

economics aspects here like power imbalances and the whole economic aspects of services versus actors and there's also some um risk metrics associated as in how do you um figure out what's a high value target anymore like you're comcast well you wouldn't think like people would have anything to do with your comcast but the cia director was hacked with this verizon account and i believe the director of national intelligence or ostp one of those was packed with comcast and what happened they just sent an email to his wife posing as him saying honey can you please give me their password to your comcast account and she did i am not kidding i cannot make this stuff up

um i have news articles that i can code um as i said if anyone wants more information or whatever citations for whatever i just talk feel free to meet me later i'll give you all of this so yes things are up this is why we didn't solve it so yes um some of the things we talked about are immediately doable like how do we define this problem uh making standards and some of them are fairly more difficult doable but still fairly more difficult so i don't say they're impossible so from left to right i ordered them in the degree of tractability or intractability so the ones in red are fairly doable yes we will now define

the problem i will tell you how i define this problem um i will tell you how we can visualize this problem as in what is it social engineering identity theft um financially motivated crimes what is this now and the whole database issue that i'm talking about where no database no reliable database no database exists even if it exists would that be reliable who will be covering it what privacy laws apply what information can be got that's a whole different kind of forms so but yes those are doable those are within our hands as engineers we can engineer the crap out of this but the ones in um yellow orange-ish yellow whatever that color is um they're fairly um

less tractable this again still doable but fairly harder uh where we have to account for um the whole economic motivation of it like the whole uh economic slash game theories like risk metrics that i've talked about and hard to detect and hard to detect because let's say this person got into matt honan's account and did nothing didn't wipe his uh apple devices didn't she post on twitter he is a reporter um let's say it's glenn greenwald and this happened to glenn greenwald and he was talking to snowden fun no so um they're hard to detect because technically no one is breaking anything the inherent insecurities that exist in protocols that are already in place which from the services service

providers and appear everything is fine like for 18 for example at t don't worry we will not give your pii to anyone who is not you but how do you know it's not me if they give you the information so that's why they're hard to detect so i mean i hope um this particular point i'm making it clear because as i said i had to stay on phone for 20 minutes with multiple people at atnt telling them precisely why they cannot say it's not me and they still didn't get it so yes so yes these are also fairly doable we can come up with standards uh we can um companies uh we can the economic motivation if

companies see that customers are losing trust and if we call them out like i am doing right now um and kevin mitnick did by filing a case in a court of law but apparently nothing was done um still yes doable but the ones in blue um yeah i don't even want to open those kind of forms right now i can't change the law right now yes technically we can um a lot of effort i'm lazy um cross platform yes all of these um service providers cross domain healthcare energy tech uh service industry consumer goods um and cross service yes apple amazon nordstrom neiman marcus um you can't ask all these people to follow one thing

you said which is why i'm not saying that that's not my solution which is also why this is intractable and no one's really um really really looked into it so yes that's why what worked in 1990 fireworks apparently works in 2013 and that's why hd moore says people are hacking like it's the 60s so yes this is the problem space and as you can see it's not a formatting issue it's just as chaotic there's law there's authentication and then there's icann policies where i can is pretty much the household dictatorship over the crappy policies that it makes and the validity of the who is data like firstly um yeah why are we um using billing address as a

private attribute when it's universally known that billing address technically can be made or is a public attribute in a whose domain for like a lot of people these days when everyone has services online i mean quick bull who here has a website yeah almost all of us uh quick pull who here has online presence right that's my point these are obvious things why aren't people doing anything about it i mean they're trying yes and i'm telling you exactly why this is hard so yes that's chaotic but so this is um this professor this adjunct professor called charles palmer who is also the cto of security and privacy at ibm research um teaches a course at dartmouth uh

security and privacy he has a famous line in one of his uh first classes there are enablers in security and then there are disablers figure out what you want to be and then do the assignments from take it from there basically so all of what i spoke right now is basically me being a disabler yes i broke into stuff i'm complaining about stuff i'm whining about stuff i'm ranting about stuff but yes what am i doing about it now as an engineer what can we what am i doing and what can we do so yes we see there are a couple of common threads again at a very high level and yes we will get into detail on this later

um there we see that these are a result of protocol failures in the case of amazon for example they literally followed a series of steps which just left open a wide gaping vulnerability which the attacker worked to his or her advantage and even in the case of cloudflare that was what happened even in the case of nordstrom that was what happened so when you think about it this way you don't need to care whether the vulnerability came up because of a flaw in the system or a fly in the workflow or because someone was charming enough to sweet talk your customer service you don't need to care you just need to make a protocol that doesn't leave these holes open for

example in very trivial example in verizon's case if they had an interface that checked for an employee's v code in real time that hack wouldn't have gone further and in nordstrom's case um if they had um if they had checked um another attribute other than just a phone number which could be easily spoofed i couldn't have gone much further if i were not me i i mean for each case i could tell you exactly where those fail as i said if you want me to get into more detail yes in the interest of time uh i'm going a little fast but yes please talk to me later so what are the common threads these are

protocol failures and in almost all the cases the attacker exploited secondary authentication mechanisms like they either forgot their passwords or they either forgot their security questions or they either wanted to do something secondary like change an ownership or like do something so secondary authentication mechanisms by default cannot be as strong as primary authentication mechanisms because we go to secondary authentication mechanisms only when we cannot fulfill the requirements of the primary authentication mechanisms very simply put let's say you're traveling abroad and you don't have access to your phone uh phone service and then you have a two-factor authentication and you will not get the code code enough because you're in paris so maybe temporarily you will use a

one-time uh token authentication token that gmail gives you or if you're not that savvy maybe you'll just disable two-factor authentication for a week because what's the words that could happen um yes so secondary authentication mechanisms by default have inherent insecurity in them so given this and given that there are also protocol failures and given that this is what it happens how do we go about these things so couple of ways until now we are focused um and yes matt blaze makes this argument very beautifully in this paper that he uh wrote toward a broader view of security protocols those who follow me on twitter probably know about it i keep ranting about this paper in so many contexts because yes

this is universally relevant i see this paper that could be applied in so many contexts because get this the dude made a protocol out of ordering wine yes yes i see your expression and that was the exact expression i had when i first read the papers like holy i was brainsporting because he says his argument in that paper is that over the years humans have perfected this request response interaction scenario where we figured out through evolution the most or at least an optimal or sub-optimal whatever scenario where one party doesn't lose or one party doesn't have an undue advantage over the others for example when you're ordering a wine you do not pay them unless you get your

wine but if someone's giving you the wine they will ensure that that you don't leave without paying so you have this whole dance that you do where you order someone brings it and then like you put your they get your check and then you put your credit card whatever and he details this as a client server interaction and shows one way of optimizing this protocol so what matt blaze um um envisions these protocols as as primarily defense protocols uh if that evolved over time but i didn't see a reason to not flip this on its head and look at it as human scale attack protocols which these attackers seem to be doing again going back to the

matt hernan case those series of steps irrespective of how charming or not charming you are if you call amazon and do those steps irrespective of who you are that will work and yes now they patched it i get it disclaimers and all that uh but yes i did the same for nordstrom so irrespective of who you are you do the same thing and apparently that will work so yes and there are compelling security problems across a wide spectrum areas that do not outwardly involve computers so yes these do not outwardly involve computers but when you think about your first call to amazon until you hang up i as an engineer would envision that as a session

and you hang the hang up and you call again that for me would be a start of another session but what's happening here or what was happening here and what still is these sessions are stateless in the sense that one session has no knowledge of the other session but let's say we made these sessions stateful we now have more information to connect links and we can figure out what the attackers figured out correct so yes there is some engineering that could be done here we just need to figure out how to do it and um how people figured out ways around this protocol because people who made these protocols are not stupid at least i hope not

um so but then why were teenagers able to get around these where someone in a company spent time and money and enough qa and testing i hope um to make these protocols so why were they so easy to break so that brings us to our last argument and i will also talk about these two um later if i have time um but you can read them in the meanwhile ver um sean smith makes this argument that such vulnerabilities happen due to differential perceptions like how you as a systems designer would envision the system to work would be very different from how i as an advanced persistent teenager would want to break the system right i

don't care whether that is at the network security level or the application security level or whatever level i just want to find a hole and i just want to get in i just want to break stuff why for the laws but whatever so how do you figure out these differential perceptions their paper again gives a model a formal model based on semiotic triads um proposed a long came back um to and yes over 200 cases to see why this happens and where these triad breaks and how we could avoid these things so

sure

thank you you're gonna have to play the model with the book on the head and like not turn too hard yeah some context there um yeah this is the first time i'm speaking at any con um so i was like little nervous so i just said let's all wear trs and be goofy and then just give her shocks so i started this hashtag tiara sec on twitter which somehow just took off and yes i will also be judging the tiara khan tiara contest at tiara khan so if you guys are around feel free to come it'll be fun so yes um moving on so given that we now know these things and given that we now have this

knowledge and we can we can now see that these things could be engineered a certain way all that's left to figure out now and yes that's not trivial but yes from a theoretical standpoint we need to figure out how to order this information in a way that we could use formal engineering techniques are computer sense algorithms or machine learning algorithms or pattern recognition algorithms or natural language processing algorithms or whatever techniques exist in engineering to solve this problem so what do i do yes we discussed that there were a few common threads so um when you think of these things they're all names like email address some um twitter handles or like your billing address

so they're they're kind of identifiers in a context in a space which is exactly what namespace is so we don't need to care uh what platform or what domain or what service this is at we just need to care um look at them as name spaces now so now now it doesn't matter like who the service provider is what domain it is on we can still solve for it so yes look at them as namespace compromises yes yes yes i know it's cool um and then human interactions um client server uh yeah we yes this would be obvious by now because of the way i narrated it human interactions are basically request response scenarios client server

interactions then yes visualize these in terms of authentication attributes because all of these namespaces whatever thing is so called whatever are just being used for authentication right things that shouldn't be used for authentication like emails and phone numbers are still being used yes we complained about that but yes they're being used so given this information we now have our points of commonalities enough to structure the problem a certain way so when you look at it what's your attack surface um you literally have two entities the service and the client and within the client you have the malicious client for the sake of simplifying terminology let's just call them attacker and victim yeah there are no users in

the system anymore you gotta pick a side either you're an attacker or you're the victim you can be in between so yes and then what do these actors in the system do they perform actions like reset passwords or call or request or whatever and then um yes and your attack service has this obvious authentication attributes that we've been harping on about which shouldn't be used for authentication uh like your pii your financial information your contact information and knowledge like your security questions passwords one-time passwords pins codes whatever so um now that we have this structured how did i derive um the whole engineering thing that i'm talking about yes so this is the engineering part

the not so good part is yes we still don't have a very reliable database for this we don't have any database and yes as i said even if you do have a database the reliability the legality of it that's a whole different kind of forms so what i did was yes scouted news stories hacker forums um personal blogs of individuals um who got comp whose namespaces got now that i defined it i can use that term yes um uh whose name space has got compromised this way and i had to manually verify and this is um the whole metasploit um exploit i talked about where h.d morris said so hdmi tweeted that they got um expl uh hijacked a domain hijacked

because of the facts and later another pr person from the um domain registrar uh said that they did not in fact get hijacked by a fax but another employee one of their employees was social engineer or something less like that doesn't make it any better but sure uh maybe you're trying to save face i i personally believe hd more more than i would believe a random pr person of a domain registrar so that is why um this is unreliable it just based on who you instinctually trust more maybe you try you don't trust hd more and you trust like a domain or destroy better because you believe in the systems and entities and whatever i don't know

um so yeah that is where the whole database thingy got tricky but i used my best judgment and wherever i did that i marked that with terms and conditions attached and with like all the associated disclaimers uh yes and then i had to convert them into structure them and convert them into request response scenarios which we just talked about um and then i sanitized and sanitize the data and perform lexical analysis what i mean by sanitizing and i do have a slide after the end of my talk and if we do have time or if people are willing to wait i can get into that but what that just means is i remove the stop words like a and

uh and um random things like that and then punctuation marks um and lexical analysis is mostly um uh it's easier to say it with an example for example when you see the word reset um you know it's either going to be a security question or a security answer or a password and that is going to be within two or three words away from when you ask for a reset i want a password reset i want to reset the password for my whatever so when you remove d like the software's it'll be a reset and password that you get in your database so you see this as bi-grams and trigrams now so you now see the engineering part

coming out so yes that's how i did the lexical analysis and that's how i structured my data and derived an ontology and rob graham who conned me into giving this talk yes i hope you're watching he basically just called me out on twitter and said hey your thesis would make a great dog give a talk and then a couple of other people uh munin who's sitting right there was also privy to this uh con we're like yes yes that would be an interesting talk yes dude i'm like okay so uh he says people don't really use the word ontology around here so what that just means is a way of ordering knowledge it's not taxonomy because

taxonomy just means i have to give names to it but names are already given so i'm just arranging this not already existing knowledge a certain way which could be engineered so that's what i derived and i know you can't really see much but like that kind of looks like this so just to give you the scope of what i'm getting at there i will tell you what they mean they're the financial information like knowledge the contact information and the pii and these are the uh attributes that are derived uh by using that lexical analysis from the case studies that we just discussed and i analyzed over 70 or 80 um individual cases so um it's basically

like social media facebook linkedin or um then contact information like text facts voice call basically all these key attributes that people use for authentication so and then um so now we know what we because we got our key stuff and we arranged it a certain way now so we kind of have an idea of like what's important now so now we know what we require to form a system like this so and yes stateful sessions that's the most obvious one which i've been harping on about like and you probably got tired of that um and then track attributes in authentication request response because when someone requests you for stuff there cannot be a lack of response you

shouldn't be able to sweet talk your way out of things by giving a fake employee code irrespective of how charming you are the system shouldn't let you do that so this now feels like it will have a whole different um aspect of human computer interaction hits the isec so yes and then track actions track actors yes because and then yes figure out points of compromise where exactly as i said uh when you have this whole path of how things are going you will know exactly what combination would leave you wide open so um that's session separation yes as i said in the amazon example you need to know when the previous session ended and when the session

started just so you know what information was done there which would be potentially could be uh used to uh do things in the next session so this is i can get into detail again in the interest of time if you want me to talk uh more detail about anything like again uh please feel free to ask me but in the interest of time i'm moving on but i think you got a sense of what i'm trying to say here so yes this is interesting because yes this looks very simple this looks very stupid but we just saw why stupid works something as simple as this is not holding up in the real world apparently which is

why i needed to come up and do this so what does this mean like it's just nothing it's like the smallest possible um transaction or like a set of request response scenarios whose integrity shouldn't be violated if stupid shouldn't happen so for example when someone requests a transaction uh and this one requests an authentication information and what authentication information does this request in its internal system it needs to know so and this is where engineering the policy comes in which is what i was talking about earlier so then um authentication requests and this and this can't not happen for example every authentication request should be followed by an authentication response uh that's very simple yes intuitively

but apparently not being enforced um yes and then you have to verify your authentication in real time not like verizon where they did not um and then yes you respond so this is exactly um what ross anderson talks about in his paper programming satan's computer where he gives three or four uh steps of cryptographic protocols that shouldn't fail that seems so obvious uh but they fail in real world um so yes this is not just me i've not done anything magical and revolutionary uh very simple protocols fail in the real world and we just need to figure out how to not make them fail and this is my attempt at that and yes as i said we have this

information that we did uh and now we just need to order it and like represent it so information is coming from various sources you don't know when it comes to social media when it comes to people you don't know where they attack you from you don't know where you're vulnerable you don't know where loopholes in your policies exist so maybe you need at least if not a tool at least a way to visualize this even to intuitively know what's going on even that is not there right now i mean i have an easy job when zero exists even point one is fine i mean you can do a hundred percent tomorrow that's fine but i'm saying the

zero and maybe this is one percent maybe not 100 but yes so yes and that's not an error it's intentional i'll just give you a snapshot of how um this uh representation i came up with looks so all the external information like for example if i uh doxxed you or if i looked you up on a whois uh database that will all come here and every actor is defined and you're tracking every authentication attribute um that is being used in that transaction and what are those authentication attributes go back to the ontology we just defined that that little things that you can't see where which i said i just included just to give you the idea of a scope

those are those so they all come from that and now it's a summary and then yes there's a session delineation and you have uh the next session starts here so you have uh knowledge of peer session kind of works i think um yes so if this was so easy why isn't it done yes it's not easy um and there's no tool yet and also current tools they do exist some semantic solvers like the z3 prover uh and a couple of other tools um which um work on the principle of satisfiability modular theory which could be applied to this problem um but um we don't know whether the granularity of what we want works with the granularity of what the

tool does and if not it's not that hard to make new tools for this provided people are convinced about this and how would people be convinced about maybe i should like come give a talk which i'm doing right now so yes um what what about formal modeling what about tool compatibility so yes these are the things that um because we just started out with this we need to like look into it further and future work um all the limitations are potential for future work um so yes viability analysis why aren't we able to visualize attacks um this is my last flight i know i'm over time uh why aren't we able to visualize the attacks that happened in 1995 which are

happening now because we don't have something like this to at least intuitively see what is going on so yes we now have it so we can go from here somewhere and maybe do more formal stuff and do more math as i gave my disclaimer right here uh i should be exempt from doing that um right now so yes um we can do um at least retrospective attack analysis is also valuable here in which case we don't even need to predict and prevent attacks we just we can at least ensure that whatever happened like when the cia director got hacked in 2015 the director of the office of science and technology policy of the white house

will not get hacked the same way by the same hacking collective the very next year at least we can do that much if we have a system in place like this so that's the usp i mean i'm not saying i solve for world peace i'm saying i'm giving at least something where nothing exists so um yes and defining risk metrics as i said how do we even define what's a high value target for us anymore at mac no my comcast account no but yes because so and so that's a whole different kind of forms where you use game theory risk analysis risk assessment and potentially use machine learning um to maybe even predict risk so there's a bunch of ways you could go

about it as it's a separate problem in itself this is a separate problem in itself and total development is a separate problem in itself but these are now doable because yes we just discussed how we can structure this information and what this is even right now so yes any questions yes so uh just so you guys know the closing is going on out there so we can definitely do q a in here but i don't know i'm happy to stay if people are happy to stay okay yes please you talk about the victim the attacker and the services right as a victim what can i do to be less of a victim that's a great question and no no no

that's honestly a great question because let's say you now have a tool um that could give you um these kinds of information let's say you input these attributes and you name your service like say amazon or apple it's public knowledge as to what attributes they take correct because when we saw from matt honan's case you know amazon asks for billing a billing information and uh email account in the first pass

i haven't answered your question yet no so let me answer my question your question and then if you have it another question i will be happy to answer that so yes if you have a tool that way and if you input your service and the authentication attributes that uh this tool that service would take and you can do that as a victim you can do that across services which will then show you what information is private this which this service considers private which another service potentially considers public and you as a victim even if the service doesn't do anything about it can figure out where you're vulnerable and maybe mitigate that for example in matt conan's case

he probably wouldn't have daisy changes accounts that way if he knew about this so that i believe answers your first question so yes that's a good answer but what i was hoping to drive to is like can i force amazon to ask me a password can i force them to go outside my policy some places you can this is also a great question which is why i needed to answer our first question to get here yes great no seriously these are the questions i was expecting and i don't know who you are but i like you so that for me what you just asked boils down to a protocol policy plus an interface problem because as i said

irrespective of how charming an attacker is he shouldn't be able to sweet talk his way without giving an authentication response so let's say the interface doesn't show the customer service executive what the answer is but if they're i'm just giving a trivial example here but if there exists an interface where the customer service representative inputs whatever a person claiming to be the legitimate user says then only then it will go to the next step so you cannot guess they shouldn't be able to let you guess so that is one way of going around what you just said there are other ways as i said this would be a very good problem for hci sec um and there are multiple ways you can

implement that and yes if you have a system like this in place we can make making tools is purely dependent on context and we can make tools based on context and i just give one context so this is an interesting talk but i come from a risk background great um have you ever done a risk assessment before not very so as i said i'm a computer science engineer but i did look uh read up enough about it for us to to intelligently at least talk about it on a basically so i've done them for clients before and they hate them they these are companies these are big companies right have like doc they have known threats and things like

this and i'm looking at this and i'm going my mom would have a stroke before she would ever do something like this because it's so complicated it's it's something that involves a tremendous amount of of you know analysis over people's lives and these are people who for the most part i agree no i agree so i'm not saying this room it makes sense no no i totally agree with you and which is why i'm talking to people in this room because now they will go back to the companies that you speak of and the service providers might evaluate it so that your mom doesn't need to do it so my whole point here is as a tech savvy user yes you can still

apply this but technically users shouldn't be shouldn't need to you should make protocols and policies better than what you're currently doing and as a company if you probably look into stuff like this you could make better protocols where your mom doesn't need to do the things that the company should be doing so the the the problem the quagmire that you run into though is is it's a trust issue for one and it's also an information issue there's an information block box between companies so information so the companies themselves amazon doesn't know what apple makes public apple doesn't know no but but they do that's my point so how did the attacker know when you ask

for these um how did i know i just called them and said look i'm logged out tell me and you will know what attributes they use even if they don't share it is it is not difficult to figure out

i do have a question for you sure another one slightly from a risk background i'm curious as to whether you're aware of any uh related research whereby you could combine this work with a risk assessment that shows say the annualized loss expectancy of any particular that was yes please finish your question but i see where you're going please any particular thing because you propose so many different mitigations here and they all seem to be ones that have the potential to actually be totally effective um are you able to first off break it down into individual actions that a company might take and second of all is the information even out there for you to be able to estimate loss

expected yes yes so see this was the exact questions i ran into when i was doing this stuff so my primary um contribution as a computer science engineer was this part where i ran a bunch of algorithms machine learning natural language processing pattern recognition stuff mind data like figured out like what needed to be done the next um step though and i did go to business school just because of what you said i mean i knew my formal knowledge as a computer science background person wasn't enough so i just went to business school to study risk assessment i mean among other things yes um and that would be the next thing i would want to do

so i now identified these problems so as i said when i talked about these this each one is a problem in itself and it's not even a sub problem it's a total legit problem in itself and that is highly impossible for a person to do in a period of one year but yes this would be my future work or whoever is working uh to look more into defining risk metrics as you just said no i mean i'm so glad people are asking all the right questions because they totally tie into what everything i wanted to talk about so yeah that is a totally uh legitimate area that i would want to work on on this in the future

any other questions thank you