Uncommon And Advanced Techniques For Account Takeover Attacks by Ayoub Safa

um hi everyone I hope you are having a lovely day so this target will be a little bit technical I will try to uncover some technique to perform some uncommon adverse techniques to perform account takeover especially against your applications so before we jump in let's start by introducing myself so my name is Ayu I am originally from Morocco I am uh an inch I have an engineering degree in computer science I have been a bit tester for over a decade now currently I'm working as a senior security consultant at mgsec where I engage in security assessment with different kind of clients also I am a bug Bounty Hunter but only like in free time and I have been doing background

hunting for since 2014. if you want to reach me this is my Twitter handle so some disclaimers so please don't click the law be nice be ethical and of course my opinions are my own so in this talk I will try to highlight some techniques and base my experience as uh so so what is an account takeover basically an account takeover is an attack where anauthorized the individual take over another user's account thus enabling them to impersonate that user and even like sometimes access that user sensitive affirmation so this kind of attacks have like serious consequences on both individuals and organization so why account recover basically it's been considered an attack with high security telecritical security impact

also this kind of attacks are not easy to be detected detected by firewalls since they are not like Mormon attacks like payroll based attack like SQL injection and xss this kind of attack requires some analysis and some understanding of the logic of duplications so you can find that your way for discovering this kind of effects also there are multiple ways all depends on the context and or application logic and from the bhagavati perspective it's handsomely rewarded as you can see Facebook pays out 40K for security researchers who was able to find to share multiple vulnerabilities and perform an accountable so in three points well this is always juicy the shop is a web application used

for like practicing was obtaining abilities so as you know like there are many ways for a user to access their accounts so they can primarily familiar is by the login form like using the combination of email and password there are of course other ways like if that user has a social media account they can use what we call out protocol and authenticate to their accounts also uh users can even create new past new accounts by following the registration process so even in some cases that user forget passwords and you can do what we call an account recovery process where they will receive some reset reset tokens and then you can create new passwords so since we

have many ways to access an account then we have many ways to perform an account recover so for example account will cover targeting the login process let's call them login takeover so we have login to over registration takeover password reset recover sessions so in this talk I will be only focusing on login takeover session takeover and password takeover due to the limited time frame so let's start with uh session takeover so we all know that our web application maintained the state of our user account using what we call the cookies basically they are just a data in the form of string that are being stored on the client side so one way to like Implement those

cookies is by using what we call a GWT so if you are not familiar what is the GWT is basically it's called Json web tokens basically an open standard for transmitting for security transmitting data between different parties as a decent object and you can identify this GWT by looking at the first three characters it starts with e y g so this is just it doesn't look some it does look random but this this data is basically just a base64 encodation for three Json object so if you decode this GWT you will get this kind of a formation so you will have the first the first Json object what's What's called the header then you will find the points

and then the next Json object and the third one so let's understand first how GWT works so when uh a clients send the a request with GWT as their cookies the web application will first start by uh encrypting to header and do payload and using what we call pitch mark function basically it's a combination of hashing and symmetric encryption and then it will calculate it will encrypt the header and the payload using a secret key that is only accessible from the application side if we have a match for the signature we want to do one calculated and one provided by decline then we know for sure that this is a valid one otherwise it's not acceptable so this token is

consists of as we said three Json object the first one is a header the header is where we Define encryption algorithm also in the payload is where we Define some information related to that token itself for example you will find the expiry date do admin or do user ID efficient admin or not and finally the signature so this this implementation of cookies is widely used nowadays for many reasons one of them is performance so when using normal cookies the application needs to do some database lookups because a cookie is basically just a normal a random value so then it will go to the database check if that cookie exists and then we'll fetch the user ID associated.cookie

and when dealing with a lot of users it will take of course a lot of a lot of time so it's not that practical so when using GWT all the information that we need about the user are already into payload you will find the user ID and username so you just need to verify if that token is is not being forged by a malicious actors so let's see some bad implementation for this GWT sometimes developers forget in users do not algorithm when using the null algorithm for example if you use no algorithm instead of this algorithm the GWT doesn't require a signature meaning anyone can force valid GWT thus impersonating other users uh accounts meaning you can put anything here like

for example instead of using your ID you might use that victim ID and then access the accounts sometimes we might find confidential data especially the details about that user and even sometimes developers tend to use weak GWT which are brute forcible and even sometimes they don't like check this signature at all so this is some common misconfiguration now let's see some uncommon risk value in this configuration also if you are using verb this is a great tool called Json web token attacker basically it will highlight any HTTP request with the color purple that contain a GWT and also it will allow you to perform those common attacks like for example switching to algorithm mode so before we dive in this uncommon

vulnerability I want to share my experience as how I was able to discover it so this was our application that belongs to one of targeted that running a program in hacker one and I I'm hiding these details for respect of draw in the a so that's like I will try to like but it's uh showcasing like a house application works so as you can see this is this web application interacts with an API and this API endpoint like it only tries to fix user details and this is the cookie being used and basically it's just a GWT and as you can see this is my ID and this is a production uh like an application also General

production Wireless so if you decode this GWT will find that it contains a formation I could do ID so basically to application takes this ID and it will fix that user the base in that ID so I tried every common misconfiguration I even tried reinforcing some Secrets but with no success so I decided to take a step back and see if I can find any issues in other assets that belong to the same Target so then I found a similar application but this time is being hosted in a station environment and this is uh uh uh a register request where you can create an account as you can see here this is the same token uh but this time like

it's it's been used for uh different kind of application but it it uses the same the same mechanism of handling the cookies so if you decode these cookies then you will get this information this time the ID is 538 which does look interesting so from this information we it tell us basically that those those applications are not using the same database which is like uh common sense however the question here what happened if I use this GWT in the production environments and then you have access to the user 538 but this time in the production environments it seems it appears that both applications are using the same encryption keys for encrypting GWT which is which is what I considered to be like

a critical sense now basically if you do the maths I can hack more than 12 000 accounts using this issue so for the for this issue it was assigned as high because normally it's supposed to be critical but the registration process is protected by capture but nevertheless I got like a nice multifide so this attack I call it GW is attack basically you try to reuse a token a GW token from another source and used in that targets so there are different ways to find this uh like valid tokens for example as we said in this example stage environment sometimes similar with applications like even if they are hosted like they don't like similar but

sometimes the same company like or developers uses the same encryption Keys even like GitHub is your fan for example you might find that that company is hosting a project that has been accessible publicly and sometimes you will find GW key Secrets key that can be reused for like other applications that belong to the targets so now let's move on to login takeover um so in this in this topic we will see will not uncover an upcoming technique but we will see a way to perform this attack which is a credential Staffing attack so conditional Staffing attack basically is when an attacker tried to like get a collection of of Sonic Edition that can be retrieved from data breaches

or even they can buy them from the dark markets so uh and this attack rely on the fact that this victim might use the same credentials for other services so I believe everyone is familiar with have I been found which basically you enter your password and see if that password is being exposed in one of two data Bridges so my question here is there a way that we can get other users passwords like without tracking down uh data breaches and large and like a well the question for that the answer for that question is yes and it's very easy well there is a website on n10x.io basically this website is a collection of a lot of data breaches and what's

cool about this website is that those datas are being indexed and this website have a really cool search engine so you basically can put an email address and see if you can get any password associated with that email address so in my case well you'll find I have been using this password which is like stupid but I was only using it for Relevant websites but you can try that and see if you can find your password or other like someone you want to hack s so yeah so you might find this password in a clear format or like in a hash format so it depends on that data Bridge and another way to find this kind of

password is GitHub GitHub is a really awesome source for usnet and will find a lot of information if you would like to collect information and to perform enumerations for example you can see this is a full database lamp contains email with the associated password in a clear format so so you might want to keep an eye on that uh yes so this is an example from the back Bounty perspective I was able to find credentials in one of a Target users I'm using those credentials I was able to access their SharePoint instance where I was able to find some really juicy information related to their business and even some information related to their clients so now let's move on to password reset

takeover so basically password reset cover is our password reset is a mechanism where users like or forgot their password can still like access their account by like creating new passwords and for that developers tend to use what we call tokens this token basically is supposed to be a random and not guessable otherwise it will not uh be practical in this case and one way to implement these tokens is by using what we called a geoid or uid basically uid stands for Global unique identifier and uid stands for universal immigrantifier joint is being used a lot with Microsoft ecosystem Android for like other other platforms so let's stick with you is enjoy this since it's easy to

pronounce so yes so during the are like away instead of using ID you use a value that is is is difficult to brute force and is difficult to to guess and did you know that there are different version of geoid in your ID so for example you want version 0 which is all zero it's been used a lot in testing purposes also you have version one uh Venture the version two three five and four so how can we like distinguish a version of agility by just looking at it while there is a way actually so if you take the first number after the second hyphen it represents the version of that geoid and it is a problem specifically with

version number one version number one it's a Time based basically it's using the time of the system where it's been generated so let's look take a look up at the algorithm responsible for generating this version so you will find that this version basically like the three parts of this joid are the timestamp and the last part is just the MAC address of the the host where this joid was generated and uh there is some open open source uh some like Services where you can just put a new ID and like record it and take back like information about the host from which this token was was generated like the time step and also like a

node which represent to Mark others of that host so since this version is usable we can then like guess other users tokens to do that there is a tool a great tool called your ID tool so basically to use these tools first we need a valid join the value this can be used generated by using your account so you try to create account testing account then do a request for password reset receive that token and copy it in here then you will try to use the victim email address request a password reset for that victim and while doing so you will take into consideration the date for performing this action so that can be retrieved

either by from sometimes the application like there are some headers where it contains the date value otherwise you can use your your local date so by providing these two values this tool will generate possible join this value as which of them can be the token needed to reset that victim account ah yes this is a real world example of a reset password link and as you can see here it's using the version number one so it's been used in the world so it's wise to keep an eye on it yes and thank you I hope you learned something new from this this talk if you have like foreign foreign