BSides Oslo 2023

we we have uh public sector representation here at the b-sides as well and I'd like to introduce Stefan torkerson who is a uh a tech guy from the 90s and head of digital forensics section at the national cyber crime center with 25 years of experience and Sans CTF starting downstairs on the small stage during first break so all right let's go thank you thank you okay first thank you for having me today uh as you said a tech guy I started programming when I was 15 and I was in 95 or something uh 90 something like that all right um I uh is about to talk about cyber crime fighting but from a tech point of view I

would like to have [Music] give you hopefully some new insights it in what our capabilities are today I will try to give you a glimpse of where have what did we do 20 years ago how uh how uh what do we do to keep relevant so what's up

so my background I'm a head all at the the digital forensics section at the national cyber crime Center we have our headquarters here in Oslo we are part of the national criminal investigation service that's NCIS what we do is we assist the uh all right hang on

that's it uh and um okay sorry about that um this is our headquarter based in Oslo brand new building quite nice actually we started building and expanded a few weeks ago and in two years we will move the rest of the NCIS into this building uh my unit section is in the sixth floor and when you will see some pictures photos or what kind of equipment we got in that laboratory you will wonder why did you build such an laboratory in the sixth floor when the building is waving well I want to answer it it was not me to decide all right the inside CIS the national criminal investigation service that's investigation not intelligence all right

we are a special Agency for fighting organized and serious crime and just to give you a picture of what we do in Broad we are 750 people half our police officers have our engineers and other kind of non-police Provisions we have our men half are women all right we are expanding when I started back in 2002 we were like 200 now 750. my experience is that all kind of Public Services for security and we guess investigation and such are expanding rapidly all right so we for the Norwegian police we are the national uh contact uh point of contact for international uh cooperation and police uh work we assist the all the police districts uh with the kind of crime that

need special competence equipment and and stuff like that well uh nc3 which is one-fifth of the NCIS we have given a mission our mission is to be the national capacity to combat cyber crime buzzwords I know online sexual abuse you know the europol the European cyber crime Center in their definition of cyber crime science sexual abuse is within that definition we should and will contribute to the increased awareness and knowledge about the cause of crime in a digital Society but uh and where I come from capacity to preserve digital evidence so therefore we have this uh uh laboratory which have become quite advanced uh well we are six sections I don't uh in it's not necessary to dig or dive

into the organization but the digital forensics section is one or all the six well digital forensics what would you well uh copy data uh as evidence analyze prepare a report give the investigation team done well digital forensics is from uh as a discipline from the forensic science discipline you also got a digital investigation and sometimes we do the tech people do some kind of Investigation task and some times the police officers do the forensic tasks so these days it's been a mix in for us it's uh very important to follow a few principles order of volatility are you going to dump the ram before you turn off the computer you should the credentials are still

very or not still but today it's very important to get the credentials before you leave the crime scene uh Channel custody everything we do is supposed to be uh uh trackable uh reproducible uh uh we should all kind of tasks we do uh we it's important for us to ensure the data Integrity well you can think if you come to a crime scene a live crime scene well there are a lot of computers you are going maybe it's some cyber crime attack you will do some incident response but at the same time our task is also to preserve the data and because our trial our exam is the trial court all right so we need to what

did we do how did we do it and uh and ensure that everything was done as forensically sound as possible that's very important for us so fancy animation copy the store data easy dump volatile data easy Maybe often uh volatile data is often uh the uh the step into the cloud to decrypt the data nothing new well I jumped to mobile phone acquisition that's where we have been very uh how do I put it we have succeeded a lot because as having the national capacity for uh data acquisition is not only in the cyber crime cases it's in the murder cases in in robberies and all that kind of serious crime different levels of phone uh

Acquisitions today manual extraction logical well the CC hex dumping JTAG other kind of interfaces we look at the pcbs or external uh whatever exposed uh something interface uh chip off is not used very often anymore what is chip off well do some desoldering heat the PCB up and the chip will go off uh you can then but hey it's uh many vendors many interfaces many protocols but yes we do a lot of them but cheap off well today as you know Hardware encryption is by default on turned on also you got encryption and all levels of software and stuff like that so you've got to be better micro read all right you can do some special equipment going deep into

the ones and zeros and level six what is that I will try to give you a glimpse in what it can be and how we work to uh develop and innovate those levels all right fancy and animation often we we uh well we have to dig inside often we got damaged or broken kind of devices so we are very become experts to fix uh what is a broken glass and all that kind of stuff uh well extract the data that's also easy or here yes they are random components only for the animation

so when we got a data we reverse it what do we use well either Pro all that kind of free tools out there maybe some own tools well you know this I guess how many of you have done reversing firmware from Modern smartphones a lot you didn't know okay or you won't tell me okay but it's uh today is like finding the whole jump through it jump over the fence because there are security measures all over the place okay uh uh as I said uh live forensics I meant computer forensics today it's at a crime scene it's uh balancing or doing live forensics and the incident response uh you cannot turn off the computer you

cannot shut it down because then the the opened uh like drives which are encrypted will well you'll lose the the passwords the the session Keys you lose your access into the data the what we are able to do as a police we have by law uh different police methods to uh for evidence Gathering we can ask companies to give us the data we can uh well all kind of stuff we can do lawful interception what is that well we can tap the phone we can tap the internet uh wire if it's very very serious crime uh also a few years ago no Norwegian police got the ability to uh to do what is called some kind of surveillance at the

device itself because if you tap in the middle or outside the tunnel you won't get the raw data so what we are able to do is do we well hack the phone hack the computer some kind of software in there then read the data is it easy no it's not and can we do it yes we can do it but I won't tell you anymore stuff about that my point here is that the the forensic tools itself is not enough to get the access you need to have all kind of police methods and the main point here is that if police is meant to have ability to fight crime you also need the tools or methods to do so but of course

you have to uh uh to guarantee privacy and all that kind of stuff which is of also very important so balancing privacy and uh police matters are uh uh of course important

well uh back in 20 years ago it was kind of a bunch of tech people did a lot of stuff Windows 95 well that's kind of easy fat 32 kind of easy and each investigator or Tech uh person could do or handle a lot of different exhibits or devices there was Nokia Ericson and stuff like that or renders or phones what we are experiencing now is that there are so specialized so we need a team uh one person fixing the software firmware may be the only interface the JTAG and it's so Advanced need to be updated one person needs to fix the device before we open it and stuff like that and we need a coordinator to coordinate all so we

have changed our way of working the way of well nothing new but still it's a challenging for an organization to adapt all right a lot of fancy animations how does it look for real okay we have a laboratory in the sixth floor as I told you it's about 800 900 square meters something like that it's uh ESD all over the place uh we have shielded the different uh functions of the our workflow uh in this picture we have a special room for handling dirty stuff or uh I mean we get exhibits devices from all over different crime scenes uh DNA fingerprints we should preserve them as well that's another department but still in this picture we see an well a simple SD card

that is from uh bad accident and the police believed there are some photos in there describing what happened all right well we use some assets to remove the plastic we are soldering thin thin wires directly to the the storage components but it's easy uh well this is easy because it's a large you mean I mean what we will see further on is that thing are becoming quite small miniaturized and we are talking about micro meters nanometers and stuff like that okay so uh uh kind of a laboratory put together with all kind of equipment not for forensics tasks for production for reversing for failure analyst analysis and stuff like that all right here we got a phone that took

everything out I mean the PCB the main board and we had to remove broken components and do some hot swapping or not hot actually but cold swapping uh resoldering in order to make it work again so we could uh read out the data well uh as you see sometimes modern chips today are multi-layered what if the data is stored inside the middle layer and the wires are not exposed outside the chip well we need to get inside we can do some in circuit data read as I saw the fancy animation quite easy well of course as you understand it's very challenged to have the tech people uh to to constantly be updated on all the

standards uh it's not easy to get the standards uh details uh as well because well we have good relationship and cooperation with a lot of privacy companies but still they protect also because this is company confidential stuff uh so that's a challenge too when things are really bad it could look like this uh do we are we able is it possible to read data from burned heavily burned stuff sometimes we have a moto that we never give up it's possible we cannot say upfront it's impossible all right uh broken device from another accident and about with the navigation problem

interesting challenge what does what happens when electronic components are exposed to salt water and air oxygen well it will start to change or so you have to be quick you have to do it in the proper way you have to it's a good advice to transport all the components in the same environment stuff like the water take a big bag or not a bag but a box with the same environment and bring it and when you're exposed to air then clean it well uh I won't go into that further this is more uh okay a bunch of devices well what an example uh well what is this some sport watch you know tracking Health Data GPS

the question here was murder case all right when did the heart stop to beat well then we had to reverse this one we took the hardware apart the firmware software and everything just to um just to reverse while the data formats in order to try to find out the specific time stamp for when the the heartbeats seem to stop okay what's why is that important in an investigation well uh if you are not sure when the time of death occurred it's important to narrow down the time a period of time for other kind of evidence Gathering like so if you if you uh thinking like uh well reducing months to days or minutes that's important you can

focus and narrow down the investigation actually this was well it looks like well every can everybody can do this except that there's a lot of protection mechanisms in from the vendor side so this is actually a quite Advanced glitch attack we did uh please don't tell the vendors but of course we protect How We Do It and the question if we find some kind of vulnerabilities we find a way in do we tell the vendors do we tell the vendors no I don't think so but we can we are obliged to do it if there are severe uh series stuff if there are systems that are critical for some reason of course we tell that's uh that's important and

this kind of stuff we we then nobody will uh we don't expose our way so doing what we actually did that's not the point we can tell the the the vendor the vendor can also we can just say well we got this dump can you help us please or we will reverse it anyway can you please help help us well yes we can so often they do not always they they don't right I won't tell you about the glitch though but we needed a faraday room certified for 40 50 gigahertz we had an interesting setup for the side Channel attack and the glitching uh actually the further room we bought it for doing live forensics on uh equipment

that is functioning all right so the the signals the online communication is uh is not possible but what we found out that when we are uh doing some very low level signaling in the it was it was it was canceled or it was uh polluted with signals from the railway on the subway and everything so we we are doing a lot of stuff inside the Faraday room now so opposite use but okay what I'm actually talking about well today it's about for us about getting access to the data from the technical point of view so you can of course through internet you can get a evidence you can have through software through Hardware okay nothing

new but forensics to us and data acquisition is about finding vulnerabilities all right then the digital forensic discipline is starting to mix a lot with other kind of uh disciplines like cyber security and in general uh and because we need to develop new methods to defeat or bypass the security protection mechanisms in order to do the data acquisition and follow the traces online we thought 10 years ago each device Hardware forensics very important because everything is in the cloud yes as a stepping stone or as an entrance to online data it's still very very uh Ohio value so can we do all this kind of stuff alone oh I don't think we should the public

and the private cooperation and collaboration is very important I saw that many nice companies are uh paying for hosting and for uh the sponsors and also so mnemonic I got for my kid I got this reflex and thank you for that nc3 the national cyber crime Center and the mnemonic we have an agree agreement we are cooperating and because we see that you cannot fight cyber crime uh alone of course and what I will go into now is not the private public collaboration and partnership but with a more academic non-profit organizations how can we how where do we get a money from okay except from the tax money well we identified the European r d

programs for funding have you heard about those Horizon Europe 95 billion euros that is a lot of money we found that if we go together with our equivalents our similar cyber crime centers throughout Europe we could uh apply for or ask for money if you had a good reason for a good challenge and we need to solve there's also another funding fund we identify so so which will contribute to reach high level of security in Europe in particular by preventing and combating terrorism radicalization serious and organized crimes and cyber crime all right that's a lot of money too so what we did we get together a bunch of uh mix of law enforcement agencies academics and uh three private companies

not in a way well we our aim in this project is to develop new forensical models and methods for accessing data by bypassing security features in modern mobile phones non-invasive semi-invasive and full invasive 10 15 years ago we wouldn't even tell any about this there's something going on change this is wide open our projects is soon to be completed in this October we have done it for three years uh and all the results are downloadable you should probably visit this website read the papers uh a lot of very good stuff and it's probably state of the art into this field which is public available so I this has been an interesting trip for us it also interesting to see uh

what the focus focus points are at the other organizations as well X-Files all cool projects need a very nice name you know so extracts for instance forensic information for law enforcement agency from encrypted smartphones X-Files just no one fox Mulder that's the TV series all right okay second project we are in the middle that's a uh also that's not the device itself it's combat encrypts encrypted communication platforms uh used in the organized crime and gave police investigations access to the decrypted data that's a simple uh abstract for a law enforcement agencies non-uh non-private non-academic we haven't published anything so far but that's also kind of interesting that's more into the cloud you know uh so

that's interesting and the third that's a forest forensic reverse engineering of silicon chips Norway is one of the most digitized countries in the world we see a lot of modern Electronics as exhibits in use by the criminals we cannot have a low ambition our ambition is to be able to extract data from whatever that comes on our table so this aim is we are performed fully invasive operation and on Leading Edge semiconductor devices uh develop necessary tools and methods to attack the hardware chips or no chain or trust and Advance the capability of extracting used to data from highly integrated devices okay and we are going to publish a lot of stuff there too so I'm wondering how the

the industry will react up on this it's kind of interesting that the European uh uh the the EU are funding project like us at the same time they are funding project that will protect them build build better security of course and that's important but it's a cat and my mouse uh kind of game uh but uh well that's interesting and we'll just started started this last week so uh we look forward but how can we deal with it what kind of equipment do we have to support uh this kind of uh project well um uh well we established a a nano lab we bought uh scanning electronic electron microscope with the focus iron beam uh

lapping machines Ultra collimators we had a lot of stuff from uh back in the days and now they're all coming together to work on a very small scale physics scale all right uh we built a room it's anti-vibrational anti-noise anti-everything because we are in sixth floor not my idea uh so example well we got some kind of electronical device there's a chip we need to get inside we use the micro Mill acids whatever to remove the uh or get physical access we could put it in the X-ray the 3D scanner and we could dive into it so we have the equipment but the competence how is it possible to reverse this kind of very advanced technology

well we need a good plan and a framework for Innovation and then that's what I talked the then we found these funding and the projects okay so other kind of equipment the further room I showed you the micro mail uh CNC routers 3D scanners and this is only uh a few uh so it's been quite advanced 20 years ago we had one Ida and SKC cable that's it now we are here very advanced okay one case I'm allowed to tell you about but not too very detailed just to have you a short Glimpse because now I put a lot of focus into physical devices in this case a lot of people or other sections has of course worked in this

well the Cyber attack on have you heard about it did we believe it could happen no did it yes it did 18th of March 2019 late night the ransomware local was detected all right the attack affected the production worldwide almost all factories and production lines had to be isolated and put on manual control imagine being ICT Personnel or manager or whatever in such a situation well we got nodded not notified quite fast the same evening and morning and received information about a very very good Corporation they um was actually a well they had 35 000 employees they are factories in 40 countries on every continent and so on uh here in for fighting cybercrime it's

borderless you have to have the international cooperation uh we are europol and Interpol are information hubs europol also have the uh cyber crime Center facility and in The Hague and we organize their cooperation in um yeah of course a very big case in a very few slides but still the main focus is to collect the information through the hardware acquisition through online acquisition and also cooperation data from others too there was a lot of common control servers live forensics you cannot shut it down what about the network forensics all disciplines at once at not only well one crime scene but systems all over the world so cooperation between technical people and the police officer investigators the

money Trail ransomware money how do you track the money if it's encrypted it was easy back then but now with crypto uh money it's a more difficult task but still uh we identified that in Ukraine was a hot spot for the bad guys so uh we have a very close and very good cooperation with the Ukrainian police even if they as you all know they are in a very difficult situation but still they are heavily cooperating and uh in this operation as well uh we actually caught the bad guys here we had and there was a big uh uh targeted operation in Ukraine and one other country uh we participated and we found a lot of

stuff and during the investigation we all also found the keys to the locker Goga and mega codex ransomware we derived the decryption key from the software found on the bad guys computer systems and we put together a script drove over to their headquarters here here's the software decrypt here we are and I did and it was success but the company lost 800 million Norwegian kroners that they cost but very early in this stage they said we are going to fight we are not going to pay the ransom money so our experience from this investigation is that cyber crime is very time consuming but someone has to do it in to the investigation if you are doing incident

response and clean it up and fix and just walk just go further or then someone has to do the investigation so therefore we uh exists we also do a lot of prevention you cannot arrest all bad guys in the world anymore you have to do a lot of prevention all right in this came this case in specific we know what uh how it happened who did it uh we have the individuals in custody and we are still seeking the trial is soon to come and we found the decryption case uh uh it has cost a few years of Investigation a lot of money and almost half of our people one case in the meantime from 2019 there has been

several uh almost similar attacks but they are prevented during this invigation we found a lot of details about other attacks ongoing and we provided and shared all the kind all the information so they asked for prevention purpose of course uh another another International investigation I won't say a lot about that but uh there's a high brand somewhere when ransomware is becoming as a service uh it's a big case uh FBI is the main in main lead we have assisted because there are Norwegian companies hit by this one and we are assisting the local police and uh and uh and doing the analyze thing or investigation and analyzing the seized infrastructure and data so uh probably more to come but still very

interesting I won't mention what companies or public services okay from 10 15 years of fighting cyber crime and murder cases and all kind of stuff what have you learned well these are some lessons or observations so take it for it's kind of experience based on academic but uh I hope you will have some insights about what we do and why we do it and in this Final Chapter uh well in one particular order all right balance The Innovation and production rapid development all new techniques is impossible if the same group of people have the managed these techniques all right the ability to simultaneously explore and exploit enables us to adapt over time me as uh the head of the section need to

balance balance when should we produce I mean help in the cases and when should we uh do Innovation and components or training it's a two-sided dilemma case production using known techniques for the production innovatively find new techniques techniques for tomorrow case production there are a lot of history companies who didn't understand this one because they did a lot of production they forgot the Innovation all right number two you're only as relevant as your latest discovery when everyone all new techniques are like fresh produce at some point they will go bad and become irrelevant sharing new information is the key to obtaining new information you have to bring something to the table to get something from the table

number three it's good to have friends when everyone is working to solve the same challenges a joint International effort is the only sensible solution borderless uh fighting cyber crime often means fighting a high-tech organized criminal activity across borders with unequal legislation resources and regulation number four big data is here to stay the amount of data to be acquired filtered analyzed and transferred will only increase we have experienced experience using the Transformers technology you know the chat stuff for training with a large language model for uh in the Norwegian language and put it inside a lot of case documents that's kind of interesting and Powerful technology not intelligent I know but it's a very nice way of search after or

quickly find the needle in the haystack Okay so uh number five the Techno technological Evolution will determine your focus areas therefore we are focusing all the hard stuff that are hitting us through the cases in order to stay ahead in the game of cyber crime you have to continuously research and develop new methods techniques and knowledge um yeah this is known stuff but anyway number six encryption is mostly bad for law enforcement encryption makes DOTA harder to obtain however once decrypted the data may prove extremely valuable we have seen that in many cases criminals talk openly on encrypted platforms and consider them very safe but it's very expensive to defeat security mechanisms number seven zero days

old days or hard currency finding vulnerabilities finding an exploit and weaponizing and exploit will provide you with an extremely useful and attractive solution commercial tools are not always up-to-date it's like a Sawtooth function if you yeah okay and many are quite expensive so number eight the best defense is a good defense researching and the reverse engineering and system to find vulnerabilities could prove to be time and money well spent disruptive actions become a valid policy a police strategy too many criminals to fit in jail like I said prevention is here also to stay number nine burn bridges in the right order in digital forensics it's uh order of volatility but here there's usually more than one way to solve a

problem make sure you don't close the door on one approach before considering considering potential consequences stay true too long term goals don't be too short-sighted in these times of difficulties it's easy to say a good long-term strategy is to be short term but again we think what you're doing uh going in for landing number 10 don't ignore Outreach and prevention sometimes a non-technical solution is the best solution in a cost benefit perspective Outreach and prevention activity to many criminals to jail again number 11 invest in bright Minds that's you guys uh provide a work environment where creative can prosper Advanced digital forensics and digital investigations require skills which are few in Supply and AI in demand number 12 respect the

values of your own data algorithms are fed with data in the data driven world uh respect and understand and protect your data don't underestimate the consequence of data compromise and number 13 I know the password AI AI is also here to stay the reward is a function of Regulation and legislation understanding an actual application kind of deep but still new possibilities for law enforcement new possibility for criminals The Matrix is one step closer my kids said that you're stuck in The Matrix no I'm not um and that's it

[Applause] thank you very much have a little gift for you thank you for coming and sharing some of those pictures and burnt uh chips and stuff I'm glad that most of us don't have to work with the things that have been in a plane crash and recovered from a sunken vessel in the interest of uh time respect to our next speakers unfortunately we're not uh we don't have time for questions right now but I hope you will stick around and chat with some folks during the break I will stick around I'll be here for the whole day I was uh thinking yeah great thank you let's give it up

our next speakers are Nora and Kenneth from VIPs Mobile Pay uh Nora is a one of the organizers for uh Secrets Festival in I believe so uh I hope you will fill out the feedback form for this event and give us some pointers and uh Kenneth is uh is a manager engineering manager and developer with 20 years of experience and a one of the key people on development of VIPs auth app so we all know VIPs if we're spending any time in Norway so um interested to to hear how the technology that we we use and Trust to send money and receive money is secured it's secure right it's Totally Secure good yeah thanks for coming guys and there

are chairs on the top I can't see them now because the lights are shining on me but some people were standing at the back um there are chairs upstairs as well so we should have enough chairs for everybody I saw some people moving chairs around I don't think we need to move any chairs hopefully

okay

have some tactical swapping to do last minute here so there's a CTF sand CTF is starting uh at uh then the break after this talk and there will be there will be a prize of a net worth continuous license for the number one winner of the the Sans CTF so that's going to last for six hours and I believe we are streaming this downstairs so if you are Torn Between the CTF and the content here you can have both we're good to go all right let's give it up for Nora and Kenneth [Applause] all right thank you so much thank you for the introduction uh so yes uh we are Nora and Kenneth here to talk about API

Security today or more specifically security at high speeds how VIPs secures their apis or our apis and even more specifically than that we are going to talk about psd2 compliant login systems now yeah we know this is a very Niche topic so we are going to try to get into some of the technical details but also lift our view a bit and have some key takeaways that hopefully everyone can take with them even if you're not working with these systems specifically and now Kenneth will tell you a bit about the agenda yes so is the agenda we have for you today uh first we're going to talk a little bit in general about API authentication and what alternatives you

have when you are securing your apis we will also go a little detail into some of the interesting legalization that Nona talked about um before we dive into uh zero knowledge proof algorithms and how that is applied in the VIPs login system after that we're going to go through uh the different security elements that are in place when the website makes a request to the backend services and also we will go a little bit into what happens on the client side what kind of threats are there on the client side and how can you mitigate it from the back end lastly we will be speaking about a bit about availability and how to stay up

in periods of very high loud load right all right so first of all is anyone here from abroad and maybe doesn't know what VIPs is oh yes okay all right so to explain it quickly VIPs is known in Norway as a payment system mostly so it is a way to easily send money to your friends and family and also you can pay with VIPs online and that VIPs does a lot of other things but these are kind of the main areas that people usually think about and it's kind of fun to work at VIPs in Norway because many people know about this so you often get some kind of questions about the different types of

things and so for example sometimes we get asked how do I add a pay with VIPs button on my website or one time someone asked me how can they remove someone from a group settlement where you share expenses because we were at a party and he had accidentally put his real estate agent in a group for the party expenses and apparently it was not possible to remove people from the group yeah I didn't didn't know anything about this particular feature but yeah and I think one of the most like fun questions to get is that sometimes people ask oh but why do you even work at this because isn't the app already finished like what

else could there possibly be to do there and I think for those people it can be extra shocking to hear that what Kenneth and I work with it is basically this yes looks very impressive here three dots on the screen and just to say it also Kenneth and I we we don't even make these three dots we are not front-end developers this is the app and front-end developers that do so people can Wonder like oh but what do you actually do do you need so many people to work to work on this uh but yes what you see here this is the login system to the VIPs app so for those who don't know what you do

is that you can scan your fingerprint or face ID or write a four digit PIN and then you will see three dots on the screen and you will get logged in and what Kenneth and I work on is the login system that works in the background here so behind these three dots and yes this might still seem very simple like do you need a whole team working on this and just a disclaimer we work on a few other things too but yeah but yes to create this login system you actually have to be able to answer some quite a big philosophical questions questions so you have to be able to answer if it is possible to have a conversation if

someone is always listening a secret conversation you also be have to be able to answer is it possible to share that you know a secret without revealing any information about the secret at all so without saying anything about what it is or why it is true and the last philosophical question of all how to become psd2 compliant yes and for us the answer to these questions was our login system winks and the name Winx it comes from combining the word swings sorry yes combining the word Swings with a V for VIPs and this is because in Egyptian mythology the swings is the protector of the pyramids just in the same way as our login system is the protector of all

other VIPs apis so we thought the swings would be a nice mascot to use to use for the system and wings it needs to live up to some quite High requirements because we actually have 1.2 billion authentications per year if we got to billion and million yeah it is 1.2 billion authentications per year so the system needs to be able to scale quite well it needs to handle a lot of traffic and again to reach any other API in webs so to do anything else in whips you need to go through Wings first and this means that the system it needs to be quite quick so here it was not the alternative to make a really slow login system

that's very secure it needs to be fast because otherwise users they would just drop off so we needed to find some way to combine the security and speed of the system and also Winx has to scale quite well and we will explain this in the end of the presentation but sometimes we basically get almost like Adidas attack on wings so the system needs to be quick and scale well yes and before I go into more or we go into more about how Wings works we are just going to take a quick quick detour and talk about API authentication in general now this might be well known for many of you but we just want to be on

the same page before we start with the rest so if you have some API that doesn't have any authentication at all then you will have some URL and anyone in the world can go to this URL and get the information that's served behind it so apis with no authentication are just a URL where anyone can ask okay give me some data for this user and they will get the data back and you can secure apis or add authentication on different levels so the easiest level is to maybe add a username and password so you could tell people okay you can go to this URL but you also need to provide a username and password to get the data back and as

many of you probably know there are some security issues with this so if you only use username and passwords they can be Brute Force they can be efficed there are many things that can go wrong here so another way to secure an API is that you could ask users that okay you need to provide an API key to get access to data from this URL and an API key it looks a bit different than usernames and passwords it can look a bit like gibberish with letters and numbers so it might look like it is more secure but actually API keys they have many of the same security problems as usernames and passwords because they can also be brute

forced fish they can be stolen in many different ways so what many apis do is that they require something called an access token to get the data from the API and an access token can look a bit like an API key there are also some letters and numbers and you usually send it in a request header called the authorization header and when you send this token you get data back from the API and tokens they can also be stolen and they can get lost in various ways however if an access token gets stolen it is a little bit less of a crisis than if someone manages to steal a username and password and this is because access

tokens they always have an expiration time and so here you see an access token to the left it is encoded with base64 and decoded here on the right side and base64 encoding it is not encryption or anything like that so anyone who gets this token they can decode it and see the information on the right side and you can see here in the decoded expiration that we have added an expiry time of 10 minutes to this token so the apis will check is this token older than 10 minutes and they will not accept it if it is but I just said that anyone if they get the token can decode it and get this value to the right so what stops

someone from just changing the time here so for saying that okay this token is now valid for 10 hours and this is not possible to do because tokens it's important to remember they are cryptographically signed which means that you can always trust this information inside of them as long as you check the signature so for example our login system links it also signs tokens with wings private key and then anyone can check that that token actually comes from the wing system and they can trust that this information here is correct and it's also important to remember when we go on with the presentation that these values here they are called claims we will get back to that later

and uh yes Kenneth so okay we have now said our login system it also gives these tokens that you can use to access other apis and but this is not something new there are many many login systems that do this like log in with Facebook log in with Twitter and so can you say a bit more about why don't we just have login with Facebook to log into the VIPs app yes I can say a little bit about that but first I need to take this little detail into the topic that I know you have been waiting for to learn a little bit more about EU directives and namely the pst2 directive this is the payment services directive

and it's a second iteration and it was enacted in Norwegian legislation in 2019. and this sets some Central requirements for everybody who do Payment Processing like we do uh those are strong customer authentication uh we must really be sure uh that we know who the customer is who is actually performing this transaction and it sets some specific requirements uh on how we must verify this uh one of the most important is that we must always use multi-factor authentication so a pin code or Biometrics together with some possession elements like knowing that you have the phone or something like that and also we must be able to provide a mechanism called Dynamic linking and that is that not only must we be make

sure that the uh the customer the user is who we think it is but we also must be able to prove that this user approved this particular payment transaction

and uh uh this usually approved this particular payment transaction and and this Dynamic link kind of creates a binding between this approval that the user does when it gets up the payment confirmation screen and the actual processing of the payment afterwards so we can be able to to maintain this chain of evidence throughout okay but uh back to your question uh why can't we have this in the website wouldn't that be nice uh well we could but there are some problems uh one of the problem is that all of these are third parties and I don't provide the kind of guarantees that we need uh to to prove the identity of the user they also don't provide

these guarantees that we are required to to be able to do according to the psd2 legislation so they don't provide this Dynamic linking and I don't provide a good enough guarantee that they know who the customer are at least not in a way that we as a third party can use um and that's only part of the problem uh the other part is that doing login is just one that's just the first step right after that the app will make further requests to the back end and a lot of other things we'll go on and we must make sure that uh it is still the same part that is talking to us there has not been I mean

man in the middle somebody hasn't taken over the conversation midways so there's a lot of other mechanisms that we add to make sure that we have control over the situation so that is why you won't see uh sign in with the GitHub button in the website soon okay zero knowledge proves uh sounds like a quite academic topic but you're going to explain it in a nice and easy way yes so so far we have established that we have this login system wings and that if a user manages to prove their identity they will get some access tokens from winks and the question is now what happens in between here so how does a user in our login system manage

to prove that they are who they actually say they are and what we use in Wings is something called the SRP algorithm and it is based on a concept which is called zero knowledge proof and zero knowledge proof that is a way to prove that you know some secret without revealing any information about the secret at all so if you remember this was one of the philosophical questions that we asked in the beginning and cannot will go more into details about how this works but I will try to explain it on more of a high level with an analogy so the way you can think of zero knowledge proof is that you can imagine this so imagine that you have a

colorblind friend and you have a red and green ball so is there some way to prove to your friends that these two balls are actually different without him being able to see the colors or see the secret and here is how the proof system works so what you could do is that your friend could put the balls behind his back and then he could place one of them forward and then put it behind his back again and place it another one or the same one forward again and each time he will ask you have I switched out the walls this time and if you manage to say to him yes you have switched it out or you haven't you

managed to say it correctly one time your friend might become a little bit convinced but he might also think that oh you just got lucky and you guessed correct because there was a 50 chance of guessing correctly but if you repeat this experiment many many many times the chance of you just guessing it statistically goes a lot down so in the end your friend by just knowing if he switched the balls or not would hopefully become convinced that okay you are actually able to see the difference between them without being able to see the colors himself this is basically how the concept works and if you want to learn more about zero knowledge proof there is a nice YouTube

video that explains it in many different difficulty levels from like beginner to Advanced and we have also linked here the Wikipedia article for the algorithm SRP because in the article in the Wikipedia article there is a really good overview of all the implementations of SRP so if you want to use it in your own projects you can use some of these third parties in different programming languages and implement and integration yourself and yes so this was more of a high level concept of how our login algorithm works but can it will now try to explain in more technical details what actually happens um first before we get into uh to SRP and how we apply that I just wanted to

briefly mention the first step that we do whenever a new device a new phone uh tries to speak to the the webs backends um because I said that earlier that we must be able to maintain the that it's still the same device talking to us through the all the API calls that that the the phone makes and the first API call the app makes is uh it transmits a key a public key as it has generated a keypad locally on the crypto profess processor that is present in all modern phones and the private part is stored inside the crypto processor and can't be extracted from there and the public key is sent to uh to mix

and all requests that the app make afterwards is signed by this public key so therefore we know that well signed by the private key so therefore we know that the um whoever sends this request has access to this private key and this private key is locked inside the crypto processor inside the phone uh all right so this is just the first step but then we get into the SRP part um the first time you need to do before you can log in with your PIN code of course is to set the pink out so that you are allowed to do during the onboarding process when you set it up um and uh what we do then is we

calculate something called the verifier from the PIN code and also some additional data that we pass along so you don't have to worry about the brute forcing of four digit PIN code and then we send it as a verifier to the Winx apis this is a step in this in this SRP algorithm and later when you want to log in basically the process is that both on the upside and on the server side a calculation is done we start with random values each time uh and uh on the app we use the PIN code that the user types in on the server use this verifier and the calculations are a bit different on each side but uh the

end result is supposed to be that you end up with the same same C the same secret key this key will be different from each time you log in because you start with random values but it it's supposed to be the same value on both the app side and the backend side and if you manage to do this correctly that means you typed your PIN code correctly you end up with the same value and then you have a shared secret between the parties that you also can use and that has never been transmitted over the internet

yes after a successful logins emits or issues tokens just as many other systems do you get an access token which is short-lived and you get a refresh token that you use uh the next time you start up your app after yeah doing something else for a while um the refresh token is only used with Winx itself but the access token is passed through all the other website apis and they they checked that it's the correct access token that is sent and that is not expired and so on

and then uh I told you earlier about this Dynamic linking requirement that we have that we need to make sure that the user has actually confirmed the payment transaction we do that via what is basically a regular login but when you use your fingerprint or face ID or pin code to confirm the payment on the payment screen um when the app logs in then it's it passes some key data from the payment along with the login requests to mix and if the login is successful then that data is embedded into the access token and then later when the payment confirmation API call is actually made uh we have the uh the uh the data in the access token for the

payment and it's supposed to match the actual payment being performed so that means that you can't use one payment uh confirmation for one payment to confirm or have another payment process you can't edit the amount or the recipient or anything like that

yes this was a high level overview um now I'm going a bit more into the details about the different security elements that we have in our request to the webs backend so we have talked a bit about the access token and refresh token that is issued by uh uh by Links are also briefly mentioned that we sign each request with this private key that is created when the app first contacts the mips backend in addition uh I've spoken about this key that is calculated when you log in this is supposed to be the same on the uh the app and the backend side and these are all uh present in a request to the back end and I used to prove

different things so we have the request signature that is locked that is locking the request so that you can modify the request and it really uses on a different signature the access token also contains a reference to the key that is stored in the in the app you have this MFA signature and it's used to prove that whoever can sign can make design signature correctly was present or was was the one that actually did the login sequence and all of these elements are linked together so you can't take one out and reuse it on another device or in another situations real for instance you can't take the access token from one request and use it to make the same request on a

different phone because [Music] there will be a mismatch and you can't do two different requests on the same phone but change the details that won't work either so this is how a typical payment confirmation requests could look and we have this access token here in the in the authorization header it contains in the just subject claim it contains this key identifier that I talked about this identifier of the the key that is just stored in the crypto processor on the phone and it can also contain the payment details if this is a payment confirmation and then we have the request signature and that is uh basically a sign over all the key data and requests you have the

URL and the method the post method here and all and the hash of the request body itself and it also references then this this private key that you have on the phone and you have the hash here as well that the server that will then verify um and you have this MFA signature that is connected to the shared secrets that you um that is calculated during the login and it is linked to [Music] um to the access token so you can't take that and reuse it with different access tokenator

yes so so this was uh just a quick tutor to how it actually looks when you make a request to the the whips backend and how all these elements are linked together now I'm going to go into a different topic when I first started working at rips I was thinking okay I'm a package developer my job is to make secure apis and once if the API is secure and there's no known holist holes in it then my job is done right I don't need to care about what happens on the client side and whether the client has a compromise because that's that's the user's concern right whether the user has a hacked app or whatever I don't care too much about

that I just don't trust the client side and then I'm fine but when you work with this kind of like a high value systems that are very attractive to criminals and where you have a large user base that is not dedicated in computer security like we do with whips that is not good enough we must actually care about what happens on the client side we must actually help users so that are not victim of of different kinds of fraud that can result from having a compromised phone for example and there are different kinds of threats on the client side of course the most common is low Tech it's uh social engineering it's fishing but it's also possible to hack the app

of course and modify it you can have malware installed on the phone that prevents overlay presents overlays that looks like whip screens for instance or do key logging or other kinds of logging and you could have a jailbroken phone or rooted phone and it can have operating system modifications that can steal your data um from like when you're on the back end trying to defend against all of these it becomes kind of a cat and mouse game it's uh it's not as black as white and white as as for API security where you either are secure as far as you know or you have a hole and must fix it in this case it's it's a constant balancing of

how many fraudulent transactions you catch versus how many false positives you get so you don't want your we don't want to annoy the users either and I'm not going to go into in detail [Music] what kind of rules and texts we Implement here because that can change but there's one mechanism I would want to go into and that is that we use remote As at the stations that is a feature that is present in both Android phones and iOS phones and where you basically ask the you ask the the phone to to present to give you an attestation that verifies that the the environment that it's running on the operating system and the app itself hasn't been modified so the

app will basically make a request to Google or Apple and that request will then be sent to the Winx apis and we will validate that it really came from Google or Apple and that the attributes information inside says that this device an app can be trusted and if this check fails then the device is blocked from speaking with the whips apis

yes and then the last topic availability and how to stay available uh yes so uh at uh VIPs we have some very high traffic days where we suddenly get a lot more requests than usual uh so for example for those who are from Norway you might know about 17th of May the Constitution Day where everyone is trying to buy stuff at different kiosks and paying with whips because we almost don't use cash anymore at all then we also have Christmas Eve because we have a gift function so many people send gifts via VIPs and we also have something called te avakshoon and that is a big charity event in Norway where the states Channel they create a big

event with a lot of things happening where people are supposed to send as much money to charity as possible and during that time we have extremely high traffic via VIPs because that is one of the ways to donate and um so uh we will talk about how we ensure availability and one of the things is to make sure that our infrastructure scales but we also need to make sure that our system works quite fast at every time so what we try to be careful about is that every time a request happens there is not more than one read and write to the database so that is a good rule to remember if you're also making other systems and

then we also try to have asynchronous calls for various things so for example if we are going to block a user we don't like stop the entire login sequence to wait to see if a user is blocked even though they they will not be able to log in but this will be an asynchronous job happening it will not be one step that just simply waits for another at all times and then we try to have a scalable infrastructure as possible and what we use for wings is that we are on Azure so we use Azure functions and Cosmos database which is a nosql database and the Azure functions is basically a serverless option so it

means that you don't have to manage your own machines and it's supposed to scale automatically however before te avakshoon and some of these events we still have to make sure that we have enough standby instances in the background to be able to scale quickly enough for the first wave and with Cosmos we are also able to scale it inside of azure and yeah we have had experience with this working quite well for the recent years for tab action when we get a lot a lot of requests uh yes and so in the end we just want to say some quick key takeaways so when I first started working at whips I thought it was kind of cool to see the wing

system and the SRP algorithm because to me this was uh being able to see that oh it's possible to make a system that is secure but that also is really quick and hassle-free for users and I think in recent years we have actually seen more of these systems which are like both secure and easier to use for example with the 502 if anyone is familiar with that that is like a quicker passwordless way to log in it's so it's quicker and both more secure and also what I saw here is that when you have really high security requirements I think it can actually drive innovation in a way and this is because if you are going to make

a system and you have no limitations so imagine that you have just all the manual resources you want you have no security requirements then I think this will actually lead to a more inefficient system and so for example once I use the like a train app system where you buy train apps and this was in a country where they had access to a lot of lot of manual resources so someone was manually approving each like transaction in the background because they were able to do this but if you don't have all of these resources available then you need to think more about Automation and doing things quicker so I know I hear from some people that maybe all these

requirements that we have all these regulations and security requirements in the Norway and in the EU it will just slow us down we will fall behind mind but I think actually quite the opposite will happen because I believe these limitations will lead to more high-tech Solutions because there is simply no other way to get this done yes this was everything from us thank you so much [Applause] questions yeah um does anybody have a question out there anybody I can start oh okay we got one right down here in front easy peasy hi uh you said that speed was very important for you you know how long you have to wait for those three dots to

jump around uh but could you make the system slower but simpler instead could you choose different trade-offs and make this system more understandable for example to make the system more understandable you know speed security um Simplicity choose two can you make a different trade-off because of the business but I mean just to make the system simpler and then it would be easier to understand why you chose those uh trade-offs yes so so what's uh one thing that's been important for us to make it simple for the user that doesn't necessarily mean that it's simple for us to develop the system behind the scenes so that's kind of a secondary concern we've been able to we want to accept having complexity

on our side if it makes it simple for the user so the user experience is what's been most important for us

um yeah well you could use you could you could the question was how could we do make it easier for ourselves uh if you wanted and I think you could do it without you could do without these checks you could have less kind of cross checks less of these security elements that we have in the requests and so on uh that would simplify it for us but it will would make the system less secure and some attacks easier to pull off than it is now hey so how do you handle possible double paying events so if you have only 100 on your account and you do two almost simultaneous transactions given you that the system is asynchronous

asynchronous couldn't that cause a problem yeah for one thing we have the payment API has item potency built in so every payment has an identifier and if you try to repeat the request twice you get it only gets executed once and then of course there's online controls whether you have enough funds in your account was there a question up here on the balcony I thought I saw a hand before yeah all right there you go how about the um checks made by Google Play and App Store uh to sort of to test the Integrity of the app you said that if that failed then the VIPs API would uh block it how does how are you able to make sure

that you can trust uh the device telling you that these checks passed

um so yeah to work with these attestations we do a back-end check to see if this is reliable so it's not just the app telling the backend that that and we blindly trusting that maybe Kenneth can elaborate a bit yeah and and of course uh this uh this information that we get from it originates from either Google or Apple and um and they will as we mentioned with the access tokens they will sign this information and and so that we know that it actually originates from the operating system vendor um that being said of course it's always in theory possible to full listings but at least the operating system under is the one that kind of is in the best

position to remotely check the Integrity of the uh the operating system and the environment all right we got time for another question in the front here you couldn't have asked when I was down here before huh took time to came up pretty good question so uh you said that you use uh Cosmos DB with Azure too but you didn't specify what exactly is the data stored there so my question is as far as I know the cosmos DB doesn't provide the Geo uh so that the data stays inside the Norway and if you store the customer data for like the transactions how many they have in the account how do you handle that the data stays inside the Norway

foreign okay uh well we we are not actually required to have the data inside no way uh that's for one but we are there are geographical recipients um and uh an Azure has these different regions uh that you can set uh set up and so we basically make sure that our Cosmos instances are in the allowed Azure regions great thank you very much for that talk and for taking all those questions leaving time at the end uh we really want to have that interaction so fantastic thank you Nora thank you Kevin

so now we have a 15 minute break CTF is starting uh grab a cinnamon bun grab some fruit and they'll be back in 15 if you want to catch the next talk up here thanks

foreign

foreign

thank you

thank you

hey everybody thanks for getting back to your seats on time and helping us keep the program moving smoothly I just want to quickly again thank our sponsors especially our gold sponsors mnemonic spider bunk and defendable and remarkable I also want to thank all of our speakers and volunteers we have several volunteers and participants from a local high school very close by is there anyone from Edward Bakken in the room hmm they're still eating cinnamon buns downstairs but it's uh this is part of what we're all about here is trying to uh support and expand this community so next talk is uh more authentication you can never have too much authentication so Tobias is our first

Suite of the day thank you thank you it was it was bound to happen sooner or later uh thank you for uh agreeing to join us here today and and uh continuing this uh dive into authentication yep thank you I'm glad to be here at besides and that will be more on the same topic as the previous presentation so that was how we secure their apis and the focus was on a mobile client this talk will about will be about where we use the web browser and if you remembered from the previous presentation the login with the screenshot there so so imagine if you have a sort of open banking sites or that where you want to log in with all

the different bank IDs or support different bank ideas in the Nordic countries then there's a good chance that the client you're writing are using openly connected and oauth to enable that and to drive that login flow and if you follow the best current practices for this then you will use a backend for front-end pattern and I will talk more about that later on and this talk is about security weaknesses and pitfalls Mr mistakes that are easy to make even if you sort of have done your best and know the specs and yeah I'm Tobias and um I'm from Omega Point Gothenburg and we do penetration tests and Security reviews but I mean my colleagues we also

work as developers writing and maintaining code and helping teams with application security so together we have a lot of strong background in both attacking and Building Systems with oauth and openly connect and so we'll start with a little bit of history about around a world and openly connected and how we do secure implementations today and um he started out with the oauth2 and um there was a lot of sort of custom implementation of login or of uh but but that was a lot of weak implementation as well Facebook and Microsoft and so on all have done mistakes use implementing this and to sort of address this in uh things in the beginning and openly connect was introduced and provided

identity and login and sessions on top of what and but then it was an open connect was used in high security environments as well and you know in bank bank and finance and Healthcare and so on so there was security profiles and the best current practices and um the most well-known is the security profile for financial grade apis but that applies to any business with high security requirements and then we have the best current practices for for oauth and I gathered under author 2.1 and this is a lot of specs and probably like a two-day workshop at least to uh to go through all that uh so for this talk I will give you sort of a two

minute version of how we do secure applications following those specs and uh so the basic thing here is that if you have the service to service when a user interaction then you use something called oauth client credentials and you strengthen that with strong client authentication not just the basic authentication for the client instead you use Mutual TLS and or something called or avt assertions we saw this earlier the signed like looks like access tokens almost and then then if you do that you can do send the constrained access tokens which they also mentioned in the previous talk and did you either you sort of you link the access token to the certificate that was used and you can use symmetry tillers or

something new called depop and of course you should have short-lived access tokens and sort of follow list privilege and for yeah especially for third-party clients within bike in finance maybe concerning the PSD tool um directive you should definitely consider reference tokens to not leak information outside your organization and being able to revoke the tokens first um so that was the service to service and when we have users then it's more complicated and we use the code flow and the the Overstock code flow is when you just want to have consent to delegate authorization to a third-party application for instance but when we do login it's openly connected code it's uh yeah it's a similar flow

and we want to really distinguish between the two are the things I will talk about the concerns than both um so and we can since we use this BFF pattern we have a confidential client a back-end client this means that we can use the same hardening techniques as we did with the client credentials there so we can apply here things like this strong client authentication and send the constraint access tokens even if the user is using a web browser and of course we should follow the best current practice and 4p and the apply additional protections with the code flow pixie is mandatory power should be used but it's kind of new very few supporters today but hopefully in the

next year that will be better supported and um yeah so this was the two minute version so if we follow all this if is the problem solved then are we secure and ah unfortunately not because in reality many implementations they don't do this BFF pattern so they handle access tokens in the browser in JavaScript contents which is a very hard environment to secure so it's very hard you you can't keep secrets there and so so you should avoid having tokens there at all if you can and most implementations they don't bother with client certificates I mean it's quite boring to deal with and keep them rotated and things like that so it means that a lot of things happen with

just basic client authentication and the kind of static client Secrets perhaps and and then we have the it's better tokens they're not Center constrained I mean weeps do it well as we saw but if you don't do this um uh standard constraint tokens then you can just steal a token and use it from whatever you want uh so um and then we have this part that's not supported so it's it's a so there are a few things here that that open up for different attack vectors and we to understand these attack vectors we will start by looking at the implementation with the 2019 best current practices that's I mean that's eight years ago so whoever built apps like that and hasn't

updated so if we look at the so the the current best practice there really is a current there so so it's important to stay updated and um if we look at how that a spa here a single page application running in the browser it looks like this we have this token service or identity provider and and the token request and the authorization request it all happens through the browser so the token will typically be stored in local storage it's a common place to store the token and then the power can just attach the token we saw the authorization header with the barrier and the access token there usually a Json web token and they can call the different apis area and

there could be a lot of apis of course in this sort of microservices architecture here we just have two but the product API and the order API and what's interesting here to get a little bit of context is that of course the login user should be able to get the products this user can access not other products and the login user should also be able to get the user's orders not the orders for other customers and the login user should definitely not be able to use this endpoint get overlorders that is meant for system Integrations to sort of access all the data in the system in a in an easy way uh so they sort of ultimate attack here is that the

attacker can execute the get all orders uh colder and and one thing that we should note there is that if you have been following the best current practices from 2019 yeah you have built this way and then you also probably use something called a silent renew because access tokens are short-lived and we can't bother users with the logging in every now and then like every fifth minute or so yeah and so then there's something called Silent renew and that means that the smaller will silently in the background call the token service for new tokens and it will get new tokens because it can't present a session cookie to the Token service which also sometimes referred to a

single sign-on cookie because that always so enables singers around them um yeah so so they attack there to get all orders how can we get a token to get all orders and uh this is an a way to steal tokens um cross-site scripting is uh is common it's less common these days but in an old application like this from 2019 or something it's a it's a good chance that we have a crosstalk scripting vulnerability and if we can inject code running in that application there are other ways to inject code like supply chain attacks and things like that but we discussed cursor scripting here then that code can do the thing the same things that your application code can do

and that means it can silently renew tokens and send those tokens to the attacker server and from the attacker server we can access the apis just like the application would and so so that is of course not a good thing and and one thing to note there is that there are might be clever attempts to hide tokens in the front end but but it's it's you you can't really can't do that and if you want to look closely on this with the nice demos then Philip the Rick had a great presentation on and this is security earlier this year that I can highly recommend available on YouTube um yeah so how can we fix this or make

it harder at least um of course we we refactor to the best current practice of today and this means introducing the back end for front-end pattern and then it looks like this and we have introduced this back-end which is a dedicated API for the front-end application and it holds the session and it will also hold the access tokens and the sport is basically exactly the same it's now served from the backend for frontal and all the JavaScript code quite complex code has been removed instead we have moved that code backend so everything and the token request now goes from the back end to the Token service this means that this back-end is the client now is a confidential client

not a public client running in the browser so we can use things like Mutual tell us and send the constrained access tokens and things like that and um and another thing to note there is that we now secure that session with a session cookie that is properly configured you could of course do mistakes here and have an insecure session but that's not the issue in this talk so it's it's it's secure and um and then uh we have also introduced to to yeah to really reason the bar here that we have applied the infrastructure protection as well so which we missed earlier so because now we have this back-end front and the other API said the back-end apis

they don't need to be public on the internet anymore so we can um introduce a Gateway or firewall and make them internal which is great because you shouldn't really expose internal apis on the internet and of course this picture we don't have the infrastructure protection in front on the BFF there it could be a web application firewall and so on but attackers are quite good to bypass those so so yeah so that's not in the in the picture and um so so this is what we have and it seems pretty bulletproof right it's it's very hard now to to get all orders and there are no tokens in the front tends to steal more but the

the cross-scripting vulnerability it still exists it's it's really hard to keep uh front and the secure from cross-scripting over time so and and with the if the attacker can um in the active code in your application then they can now do session writing of course so that they can do anything the user can do with the user session there and so so that's it's a more limited attack than previous but it may still be quite bad so so what can we do if we can do session riding in this context uh well it's hard to tell without the proper testing perhaps pen testing or your own security testing and we can start by looking at the

requirements for this access model that we have here and there the first here is that we should be able to get product one because the user has access to product one that is a success we should be able to get the orders and our own orders not other customers orders quite easy and then we have this orders all and it's a little bit more we need to think about that a little bit more so it should return all orders but only if the caller is authorized for this all access and um to make this maybe a little bit easier to test we can write rewrite this as two test cases um should return orders if the caller is

a system integration should not return any orders if the caller is a login user and that's typical that's the attack so it's it's really a good thing to have those negative test cases for possible attacks because that is what the attack it tries to do so and if we run those on our implementation we saw earlier we have all the defenses we have followed the best current practices but unfortunately the last one fails here we're actually able by just changing the route and accessing still accessing the orders all endpoints even if it's not exposed on the internet and that's surprisingly if you ever end up here and certain and not good so how did that happen What enables

this attack and if we look closely into this this picture we will start looking at the the BFF what does it do it its route and we see the stars there so uh so so our default configuration for many reverse proxies or gateways like this is to look something like this they have a white list for uh hosts which I can route to but often it's sort of default capsule routing that with the Stars which means that they will route to anything that you pass in there not just the ones that the backend for front-end should be reaching and since the back and front thing can reach the host it could it should make calls to any

endpoint there and yeah so so that's that's not good we have the stars there um and besides proxy requests which what does else does the back and front do uh because I mean those were public before so so it can't be that bad but it also attaches the access token connected to the user's session uh so so that means that you can hit any API inside there with a valid access token it may not be valid for that endpoint you're hitting but does your average API do proper Access Control well the stats are against you perhaps but because if you look at the top five here it's all almost all broken off in some way so so it's a pretty good chance

that the API here it sees this token and it will accept the call and um but there are actually Four issues here for this attack to succeed and um if you look at that we need to access a low privilege session in a larger organization it's quite likely that during some point the attacker will be able to get hold of an account or misuse the session in some system you can also sign up to get a low privilege users so so that's really not an obstacle and then then the BFF here it needs to have access to the API hosts on the internal Network and especially in the cloud perhaps but also on-prem it's quite rare

to see network segmentation between the back-end front and the apis maybe you have Network segmentation to the databases and so on but but between those web hosts it's it's rare to see network segmentation so so that's quite likely that you can access and and especially since the the the this microservice architecture here it sort of maybe drives that the BFF should be able to reach every host to get some endpoints and and you mix host the system integration points endpoints are hosted uh together with the endpoints for users uh because it's easier to maintain and deploy and develop and so on so you can't really count on network segmentation to solve it and then we have this catch-all

routing um and that's just a common default so it's a pretty good chance that that's in place as well and finally we have the authorization bugs in the apis which also is likely so it might seem that a lot of things should be in place for this attack to succeed but in reality it's not that unlikely and it's definitely a risk that you should consider and so how could we mitigate all this well as always this guiding principles here zero trustless privilege and defense in depth will sort of guide us in the right way and talking about how we should apply this for a system like that is a talk of its own so we'll focus on two things here uh

proper Access Control in the API and the routing here with with the BFF that it only should wrote valid requests and if we start with the BFF routing that's kind of easy to fix but it's boring and maybe hard to maintain but they really know is no way around having a strict allowance to to close this possibility for an attacker to hit end points you're not supposed to uh and uh don't try to be clever here and introduce sort of patterns and regular expressions and things like that pen testers and attackers are really good at bypassing those kind of clever things so just do do a strict whitelist or allow list and so it solves the

problem but but from the previous slide we should apply defense in depth and Security in multiple layers we shouldn't just rely on the routing here it could be easily misconfigured right so of course we should also handle the um the API authorization so so if we apply this white list the routing history is sold so no stores there anymore and but so so this API authorization why is it so hard for apis to do proper access control and uh this BFF panel it's sometimes it makes it a little bit harder and it concerns the Scopes and they sort of add some challenges to the apis here and so now we'll look at that and so if we look at the authorization

request that initiates the login flow here with the openly connect and the code flow it looks like this and it goes through the browser and we have done a lot a lot of security and it's quite easy to forget that no matter what we do the attacker would always control this and can change this but the state redirectory client ID they are all validated and it will be a bad request if if the attacker changes anything here but this scope that's by Design the attacker can add a world user can add any scope that the client has access to yeah and um and and why why is that so bad it's sort of by Design but

um so if we just add Scopes there so because Scopes are easy to misconfigure it's it's it's hard to keep this list privilege when you do client configuration you might be reusing a client for different applications for different scenarios for instance you might combine a client where user do login but also with system integration if you do that that means that a user that is logging can add the Scopes only the system integration should have access to and then they will get an access token with those Scopes when all this redirects and the login is done so so and also apis could misconfigure which how they interpret the scope for instance so so keeping at least privilege there is

is really important and um yeah so we should of course only configure the Scopes and flows that the client actually needs and try not to mix those roles and if you have a high privileged endpoint then it's it could be quite risky to just base authorization on that the fact that the token is valid and that it has the correct scope you could use something more like perhaps the client ID or or authentication method and then and so on and the and then of course this sounds really weird why should the user and attack your control what Scopes or in the authorization request if you have a consent page that makes perfect sense because then you select

the Scopes and that's part of the design but if you're logging in there is no consent so why and for that we use par and Par is like this and then the authorization request only has those two parameters and if any of those are changed then the request will fail so the Scopes are sort of pushed from the back end and this is a reference to to those Scopes so so now so now we closes that attack Vector that someone actually changes the the Scopes there uh so that's a good thing but not supported by token surges yet but the RFC is there so uh yeah so so this was one part of the scope issue another part here is the

uh that you might end up with really really powerful access tokens and and if the access token is very powerful then it's harder for the API to make the right decision so if we look at what we have here from a little bit of different perspective we uh the back end for front and here will have an access token in order to provide the user with all the functionality it needs during its session it's it must get an access token that has access to all this functionality which means all the Scopes and audiences um and the depending on your system it could be all the Scopes you have in your system because it needs to to get user

data from all those microservices and um so that could be a problem and it could also looks like this sort of the chain pattern here which is a challenge for oauth implementations and uh and as you can imagine that can be a lot of Scopes and a lot of access if you just sort of pass along the original token and that token can then become sort of a glorified API key with access to all the apis in in your system and and that might be fine uh you may or a risk you willing to take but it could be really catastrophic if for instance the API 3 here may be another organization or a much weaker protection because apr3 will

have an access token and can start misusing that hitting API 2-1-1 so so that's one way to leak tokens um yeah so Scopes design is is quite hard in a lot of organizations and worth spending time on and one way to deal with this to sort of have more of least privilege for tokens is to yeah to create a new token yeah you have the token for API one but API that is not valid for 213 so API one needs to do client credentials and get a new token and we have like this and then we solve this scoping issue because then you only need the scope native AP1 and you have least privilege there and

that's good one thing that you might run into is that tokens get too large for the HTTP header and that's not a good design because then you probably have two powerful tokens that need to sort of redesign a good solution to that is not to increase the max size of the HTTP header for the for the web service but so it solves that problem but it introduces another and now it's kind of hard to have the traceability or accountability that the user actually initiated this call because API tour only sees API one so to handle both we can use something called token exchange that's also not supported by many token services but but there are

definitely a lot of them that do that so then we pass the original token when we change the token and we will get this act claim in the token that provides us with this chain of traceability so we can know how the request has been so this handles both and if you don't use this then understand the risks you introduce maybe accountability is solved in another way so it's not needed or you're comfortable with having sort of global access tokens and we should note here that this list privilege for tokens it doesn't solve the session riding in any way because the attacker who does session riding in the back and forth front end there it

will of course be able to do anything the user can do it this will only limit the risk of leaking uh Global access token but the session riding remains there

so with this I have shown how to build a secure openly connect with implementation and following the best current practices and it will look look something like this and and then we talked about how to avoiding some common pitfalls concerning the routing and the Scopes and how that may affect how apis can deal with authorizations and it's time to to summarize and um the first thing here is that please read and follow best current practice for uf2 and openly connect and the fourth pair is this very detailed on guidance and how to implement things so I can really recommend that and there's a version to uh dot zero right now and that's more easier to digest than the

uh than the first person but so that's important so even if security should always be proportional to your business so even if you're not sort of in the healthcare or more finance and have those High requirements then it's easy it's important to understand what protections you have and the attack factors that exists concerning those protocols so you know what your so so if you choose to I I will stick with better tokens and that's maybe a perfectly good choice for your business but you must understand the risks you introduce so it's it's quite good to understand those regardless of what level of security you you're on you're at and then of course for basically any application stop

handling access tokens in JavaScript front ends and start using the back end front-end pattern with a strict allow list so we don't so then so this it's a little bit unfortunate we have invested a lot in security here and it's we shouldn't end up with a vector for authenticated server side request forgery by having this wildcards uh routing uh so and then of course proper Access Control in the apis um so and we will sort of help to make this easier by following this privilege both for client configuration and when we do two token requests so even if the client has access to a lot of Scopes it shouldn't always request tokens with all those scopes

and finally when we have a browser based application cross-scripting is a really really serious problem if we're vulnerable to that because session riding is usually really bad and if someone has can run code in your application then they of course can then they can always do session writing so yeah it for me any questions foreign [Applause] questions

hi thanks for the presentation um my question is if we store access tokens for example in Secure HTTP only cookie would that mitigate majority of the risks that you mentioned about handling access tokens in JavaScript front-ends yeah yeah um in a way it's it's it's stronger to keep them in the back end but but storing them in a encrypted cookie not reachable from JavaScript is it means that across unscripting can't really access that but having a powerful token on the client means that if you have control over the client then maybe you can get a token so it's better to keep it in the back end but if the encryption is strong then it's really hard to get the token so yeah so

because some Frameworks they do that by default.net for instance and so if you have it in an encrypted cookie then you get less state issues with the with the back end but but but since we if you wanna add the things like if you want full control over session you want to be able to force the user to log out or end the session then you need complete control on the back end anyway so so but if you're sort of in a little bit of lower security requirements then that could definitely be a solution that's good enough and yeah yes so the best current practices for Spas also has a a recommendation if you can't do the bff or token service

pattern by using web workers what are what are your opinions on that the using web Brokers to in order to keep tokens more secure in the in the spots correct yeah yeah that's uh it's suppose it's very hard to secure the the JavaScript front-end and uh and if you can run a code there you can use this silent renew to get the tokens and so on so so the tokens are less protected in the uh in the front end than in the back end and they I think the the recommendations for high security environments are quite clear that you shouldn't have tokens in the front end even if you try to hide them in in

webwork or something things like that I really recommend the philippyrics presentation from MSC Security on that topic any other questions looking up in the balcony anybody don't let your BFF be a vector that's it all right everybody is everybody's got it thank you very much what do you see for the future um well concerning web applications I think the sort of the protocol has sort of settled and I think maybe that won't happen much but concerning mobile applications and how you do a good user experience logging in on that and also utilizing the possibilities to do biometric login and and the the fact that you have a really powerful device in your hand the sort of

the the touch flows and the whips there and we have the web open so I think there will be Integrations with that that will sort of change things and there are some new parts concerning those flows that probably will happen during the next years so as I think the integration with web often will become more common and and clearer but yeah anybody else I have a question I'm wondering uh if there's anybody who's into bug Bounty and uh wondering uh how they could look for this stuff do you have any tips for a quick and efficient uh Discovery and validation of these types of issues yeah um uh we often work with the port swiger

and the barbershop tool when we do penetration tests and they have excellent labs and on how to sort of attack and and explore attack vectors around concerning this so um that's that's a good place to start and otherwise the specs there and they have an excellent threat model around I highly recommend reading and that could give you some insights on how to attack those candle systems it's very important all right if there are no more questions then let's give a big thank you to Tobias thank you [Applause] thank you ah all right another talk completed another gift delivered our next speaker is starting uh in a couple minutes I can introduce him while he's getting up here

is coming to us from the Norwegian Bank National Bank investment management fund so one would expect that they are pretty serious about security and I think when you if you don't know Steve loretti after this talk you will know that he is a pretty serious about security as well um he's uh he's been gracious enough to speak at b-sides in the past and today we're very excited and grateful to have him back to present some new research that I don't believe this has been revealed anywhere yet and we we weren't sure if he was going to be able to give this talk today uh it was dependent on the timeline for certain things being being addressed in the ethical way as uh

to be as said so uh yeah super exciting for those of us who are on the red team side of things or interested in the in zero days and all that it's uh it's great to have some some original uh research of new new volunts uh coming here today so uh Stan will uh will tell us about his work in Python the python ecosystem with uh tools like Pi Pi and poetry for Distributing python libraries yeah thank you thank you give it up for Steam [Applause] um let's see if it works yep so I'm happy to be back at besides Oslo to present this research I did earlier this year so it's a hobby research

uh into the python ecosystem so first off the python package index is used by millions of developers to distribute python packages so it works in this way so you have the package maintainers that package and upload their packages to pi.org and then you have a package consumers that download and install the packages using a package manager like pip or poetry I'm going to use requests as the example package throughout the presentation but it's just an example and the attacks are not specific to that package so shout out to Steve and others at the hackerspace Ikea for inspiring this work and also the Pi Pi maintainers for how they manage the reports and also feedback I got on how to present this

so the findings were reported to Pi bi in June and July there was one patch in June and another in August and it was clear for publication in August I published for blog posts together with this talk earlier today because there's a lot of details I don't have time to go into so first let's look at the structure of Pi Pi packages so you have our projects and then for each project you can have zero or more releases and for each release you can have one or more distributions so distributions are just files so you can have Source distributions as storage is that or zip and you can have binary distributions in the real format

so the first issue is that it was possible to do a denial service on all the projects uploading their packages and the reason is that there's a global check to make sure that file names of distributions are unique across Pipi and instead of checking the project name exactly it only checks the prefix so it was possible to make a prefix project to attack another project so for requests you can make Riku and then write the file that the request project might write in the future and it's not that hard to to guess like future major minor releases so this was quickly patched by the Pi Pi maintainers and next there's a new type of attack at

least I haven't seen it before so please let me know if you have so I call it distribution confusion and the issue here is that you um basically can make a duplicate distributions so there's um the regular distributions I talked about before and then you can make a malicious variants that are equivalent so um let's look at how we can build an attack using that so first we have the benign distribution with a regular file name and then we're going to build malicious variant by changing the first character to uppercase r this will Target poetry and then we're going to add the leading zero to Target pip instead um and like this is just a most convenient

way to get the lexographical order correct but there's other ways to manipulate the Fallen to get the proper ordering so because these are equivalent seen from the package managers if you try to pin on like version or the platform or other tags it will still select the malicious versions but if you pin on the benign hash that will work but it will only work until you might add the malicious ashes so I I call this trust on every update because if you use like a poetry update the next time it fetches the hashes from the index it will include the malicious ashes so then it's still gonna select the malicious ones so the building hash

is just sort of safe until the next update you might of course catch that on the code review but it's not guaranteed okay so let's try a demo [Music]

um let's see so when poetry and pip are deciding which package to fetch they're going to Pi Pi dot org simple slash requests and we can see that that gives us a list of install candidates with the file names and also the link to download the file for the demo I'm just going to run this locally so on localhost I'm serving three variants so we have the benign one this one and then now we have the capital r targeting poetry and the leading zero targeting pip so if I first do um I I pin on the version and I pin on the benign hash we expect to get the nine hash so let's do that

so on here we can see that the file that was actually fetched it's the benign version but if I now do a pip install without pinning on any hash but still depending on the version we see that it's the the leading zero malicious version that's selected so um let's move to poetry

so first I'm going to do um I'm going to pin on the line hash as before and we can see that we are indeed getting the benign version but if I don't do poetry updates

it's fetching uh all the hashes again from the index

so now we see that the two militia sashes are added to the set of trusted hashes in addition to the existing Benoit Lash and if I then do our portrait install with this new set

I get the malicious variant with a capital r so if [Applause] like so if you either don't have ashes or you have the malicious ashes in the Justice set it will pick the malicious variants okay so this is just one of the malicious uh um distribution confusion sandwiches you can make you could also Target poetry and pip individually uh this is kind of interesting because there's no other mechanism to Target the package manager of course all other package managers are going to fall into one of those two categories as well you could also do the malicious variant in the middle of the sandwich so then like normal users will get the benign versions and then you could have a

malicious Insider depending on the malicious version and also like if you later delete the altar variants which is possible the malicious version would be chosen instead uh so that takes us to also like you can have time varying sandwiches of different sizes uh to change the behavior over time so like if you're doing a training or there's some reason you want to Target in time you could do it that way um so those who paid attention I said they can you can all have one source distribution per release and I just did a demo with more than one source distribution per release so we need the bypasses uh so the first bypass is that you could

simply say when uploading a charge is that you can say that this is actually our binary distributions rather than the source distribution and it will just work uh so this was this was patched in August and then um the other way to do it which is still not patched is that you can give a different version in the method rather than the file name and because the package managers just care about the file name you'll still get um this will still work and you can have more than one source distribution per um per release um so while it's not patched there are two open issues to fix this so let's revert a different attack called manifest confusion as this