 see there's a little less people today than yesterday maybe the bar open was not so good in the end there are still some places in the front that's where you'll see the best so we advise people to come closer to me. Just a quick reminder that COVID is still something that exists we had two incidents today so one of the speaker is going to be remote because she caught COVID last week and another one got a visa delay because of what that is COVID related so two of the talks will be streamed that's unfortunate but still I guess the content is the same and you can still feel the energy through those giant screens. Can I have the slides please I'm just going to do a little quick announcements and reminders so the schedule is available online that's where you'll find all the information and it's being updated today we have an APSEC block that that's what we're starting with we have a cryptography block after that and then we'll end with a red team block one of the the talk is cancelled the red team tradecraft because of COVID also I just realized that my spacing is a little bit sketchy and that's really shameful of me and we also have the community room so I I don't know if everyone went there and explored there's a lot of things there it's downstairs inside the Lacomune the Lacomune hall you have to go downstairs and there's a lot of activities it's a bit chaotic noisy it's awesome in there we have an amateur radio club go and talk to them that's super interesting it's an old technology but that's still super relevant today we also have a flipper zero meetup if you don't know what flipper zero is I advise that you google that thing and order it it's really awesome it's like a portable universal hacking tool it's really awesome we also have soldering on the Nordsec badge so you can put there are lights on that if you didn't know and you can light them up if you go downstairs we will also have a Nordsec legacy swag giveaway table so we'll have a table packed with old well they're not old they're still new because nobody wore them but they're a legacy swag that we kept and you can now take all of it it's going to be during the day downstairs and we also have two workshops one is the reverse and bypass of modern Android runtime protections that's going to be in the I think it's in the I don't remember exactly so you can see on the schedule that's why the link is there then we have advanced process and process injection technique which is virtual and the zoom link will be posted on discord we will also do something a bit special there's a book raffle so downstairs in the community room there's a reading corner with more than a hundred hacking and tech books we're going to give them all away and in order to do that we'll pass tickets to people that are interested and after the last conference so it's around six five thirty six people can go downstairs and will give all of those books away so you can become more intelligent after reading those books I guess you're already pretty intelligent but more knowledgeable and just a quick reminder for those that are interested tomorrow there's a black black black light party at the CTF everyone with a conference ticket is welcome to join it's going to be around 10 there's going to be a hacker joe party which is really awesome if you never saw that it's going to be in this room it's going to be followed by a black black party we'll have glow in the dark drinks it's going to be really great the rooms we are right now in Salville Marie there's a ball room where the workshops are and the CTF is it's on the other side of the little bridge and then the Lycoming Hall is downstairs that's where the community room is just a quick reminder of the code of conduct that's really important be friendly and welcoming of course be patient and constructive sometimes things are noisy people might be intoxicated don't be intoxicated be respectful and collaborative that's the the purpose of Nordsec is for people to being able to collaborate and share information be responsible if there's any emergency please contact us we have a report at insect.io email and you can use discord insect staff and insect moderators are us and otherwise anyone with a pale blue t-shirt or me i don't have a pale blue t-shirt but you can still come to me if there's anything and we'll do what's needed to help you a big thanks again to all our sponsors you're going to see them throughout the event they all provide something to the event as i said yesterday we don't take free money we only take involvement in the event so without further ado i will pass the mic to Guillaume from KPMG has a little something to say thank you hello bonjour tout le monde hi everyone thank you to be here thank you for the Nordsec folks you organized again this year a very great event we miss you guys you know since two years it was a little bit boring and i i couldn't go you know i saw the setup here and the the investment of time and effort to to make it pretty very nice KPMG is a proud sponsor of this event it's been many years now that we we come to this event we recruit a lot of good talents throughout the years and we are still going to encourage this event for the following years my name is Guillaume Clément i manage a wonderful team at KPMG division specialized in uh i would say technical cybersecurity about 140 colleagues one of the greatest team in canada and i was wanted to say a few words today around how cybersecurity changed in the last 20 years i don't want to go back far away but for the ones who knows not a long time ago we were doing cybersecurity and selling cybersecurity based on you know potential scenarios yes there was events here and there we had the virus and warm events in 2000s and you know it was a great credit card data breaches in 2013 14 uh they were you know it was cyber attacks here and there but not like we had recently in the past three four years then you know cybersecurity was hard to sell we were basing our recommendations and work on you know risk scenarios and you know we were uh an expense and we were kind of the first cut in the in the budgets you know uh and the sales cycle you know when i was selling this uh a few years ago when 2000s was was the worst but even almost like uh five six seven years ago the sales cycles in canada was about sometimes a year okay now it's kind of sometimes a week you know it's totally different and why is that it's because you know the the recent attack surge that we had um the past three four years um gave us some facts and real examples real life examples of what of what the impacts are okay if you don't invest in cybersecurity and now we we were an expense not so long ago and now we are kind of we're bringing value and we're kind of becoming an asset for uh organization and our role is is very important and that's what i'm trying to say to my my my colleagues and and everyone you know we're not just there to do our work we're there to sometimes uh save uh organizations and uh we can be proud of this you know it's it's it's it's an important job an important um uh domain and uh either you are a student researcher professionals uh vendor a firm um you know we are kind of becoming more and more important and that uh economy and and and any industries then um you know and i think that the future is great for us um i think the advantage we have i think the business will be good and we're gonna have jobs when the economy is good but even if there's some economic crashes or anything like that no criminality uh go up and we're still gonna be important then you know i think future is good and um i mean your your role is more and more important and uh let's keep going that's it i'm gonna make my i'm gonna make enough my my team because they told me just before that i can extend my speech because they had some technical issues but at the end i think it's fixed then because they always say that i take a lot longer than i'm supposed to then yeah thank you Guillaume uh yeah don't worry it wasn't too long all right so we're gonna uh kickstart things right now with the absec block um so i'm gonna present you are your moderator for this block um she's joelle alexandra de marais she's been involved in the nortech community for a few years now uh she now works as a security director implementing security practices from the ground up in a fintech startup disrupting the market mortgage market uh so please welcome her with all your applause with me and i'll give it to her alexandra hi everyone as a you go say merci go my name is joelle joelle alexandra you can call me joelle today i'll be your moderator some of the talk like serge mentioned are online some of them are live which i think is going to be pretty fun and we'll have a small uh qna at the end well it's going to be hybrid as well so our first presenter that we're very happy uh to present here today is vikili uh if you don't know her she's an experienced web developer with an avid interest in security research uh she's author of a book which i think that's the topic of the talk today um you can also find her on multi different platforms she's on youtube she has a pretty successful channel where she uh simplified security that's why it's called security simplified and she also have a a blog it's called viki dot dev where she talks about security new techniques and latest bug bounty findings so please welcome me uh with applause for vikili merci hi is there sound now okay awesome thank you so much uh for the intro and um hi everyone welcome to this uh the first talk of the second day of norsak i'm super bummed that i'm not able to join you guys uh at the event today and meet y'all i'm actually currently under covid quarantine at the moment but so uh thank you guys so much for the opportunity to present this talk remotely uh let me start sharing my screen one moment please can you all see my screen right now so hi everyone and welcome to i thought writing a tech book was supposed to be fun uh my name is vikili and i am the author of bug bounty boot camp which is a book that helps beginners learn web security and get into bug bounty hunting and also i write a security blog um online and i also work as a technical writer for multiple cyber security firms doing things like documentation tutorials and corporate blogs for a really long time and the topic for today's talk is how do you write better technical content more efficiently right i think as security professionals we probably all have the experience where we need to write some sort of technical document right sometimes it's it comes in a form of reports from pen test report pen testing engagements or sometimes it's some sort of documentation that you need to write to document the tools that you've developed right so in this session i'd like to first talk a little bit about the strategy that helps me write better technical articles more efficiently and then um so i'll talk about things like how to write better documentation better guides and better tutorials and then i'm going to go into um how to write approachable and appealing blog posts online and how you can optimize for that experience if you do want to start a technical blog of your own and then finally i'm going to go just a little bit into the process of writing a book and if you do want to write and publish a book um what do you have to do and what kind of key decisions would you have to make so i started writing technical content when i was trying to transition from development into security i tried to learn bug bounty hunting as a way to learn more about web security and what i would do is that i would go on to hacker one and find all of these disclosed vulnerabilities online and look at the vulnerabilities that they reference and try to learn about them and i start spending a lot of time reading these reports and learning about the vulnerabilities for each vulnerability i want to learn about i would search online for information right i would do tons of google searches about sequel injection and read all the um articles that come back in my google search and what i found was that there was tons and tons of content online at the at that time to learn about web security right but a lot of the times these blog posts only mention one or two very limited aspects of that topic or sometimes these articles can be um sort of outdated or misleading in some way right so it's really really hard to learn everything about a single topic as a beginner because there's it's really hard to get the big picture or the comprehensive view because there's no such resource online for beginners in that way right take sequel injection for example it often takes like 10 to 20 google searches and reading every single article that comes back from these searches just to understand the big picture of how it all works and what someone can do with it so i started to do a lot of research by myself um organizing fact checking and curating the information myself and with all that googling and organization i started to accumulate a lot of notes that turn into a large repository of knowledge about web security that i um accumulate while i was learning myself so i thought hey i can turn this research and this content curation i've done for myself into a book so i can expedite the learning process for others and this is why i started writing bug bounty boot camp and the expectation um before i started the book was sort of like this is going to be an easy side project and i'm going to be done with this project within six months of working on the weekends um i was very innocent the reality was that it took me nearly two years and um over 40 hours per week of work to complete the entire book um so it was a giant giant massive undertaking that i didn't expect but no regrets because i feel like i've learned a lot about web security in the process i had a lot of fun and i met a lot of interesting people because a lot of people in the security industry actually started reaching out to me once my book was announced and i also really love the process of technical writing because it's a way of sharing knowledge and you can share what you've learned and really use that to expedite the learning process for others without ever meeting them in person um i've had people reach out to me saying that bug bounty can help them learn web security for themselves and start hunting for bug bounty themselves so i encourage low security folks to give technical writing a try because it's a great way of clarify your own thoughts and helping yourself learn and understand a concept more deeply and also participate this sort of indirect mentorship and knowledge sharing using the time that you've already invested in research um but the one caveat is that writing is really really difficult right writing is really a specialist skill that a lot of the time are not taught to us um either when we're in college studying some sort of technical topic or on our jobs right there's no really any formal training program that we can take on writing and it's one thing to produce documentation and notes that you can understand yourself but it's a lot more difficult to write something that can be used and understood by other people so in this talk i want to talk about how i make this process easier for myself and how you can optimize your technical writing process to produce um better more understandable technical content more efficiently so i think writing is way easier oh technical writing in particular is way easier if you break it down into three distinct steps research and outlining content dumping and editing so let's get started with the first step research and outlining this is where you're figuring out what information to include in your article what information to not include what sequence to introduce concepts in and what structure of writing would be the best to present your information at hand so i will first do research on the topic i try to find out everything i can about the topic right even if i'm already familiar with what i'm trying to write about i try to read as much documentation blog posts write-ups and books about a technology and just in general collect as much information about a subject as possible just in case i'm missing some aspect of the topic or um that i want to enrich some parts of my article right i will make detailed notes during this process and organize the information i found i also fact check everything i read about and test out all the payload and all the code to make sure that they all work and it's really really important to do all this research prior to starting to write because it helps you get the full picture of what you're writing about and it also helps you with planning and thinking about how you can structure the content and best present this content to your reader after research you can slowly well even during research you can slowly start listing out the topics that you want to talk about and try to think about what a logical progression would be for your article and this is where you get your first draft of outline so here you can see like let's say that we are writing an article that teaches developers what sequel injections are and how they can prevent it you can start to list out the different things that you want to include in the article such as how sequel queries work and how that leads to sequel injections what are some types of sequel injection vulnerabilities and perhaps include some real-life examples of sequel injections that you've seen and then include a section on how to prevent sequel injections and it's important to remember that outlines just like articles they go through multiple drafts and this outline can be changed and refined as you do more research or as you start writing and this step often takes lots and lots of times right and i often find myself changing the outline or and the structure of an article later in the writing process or the research process so for example you can add sub topics to refine the points that you want to touch on or you can delete something that is you think is too much for this article and perhaps move it to a subsequent article or even break the everything that you want to talk about down into a series so here you can see that i added some points to my outline and the outline is really becoming more detailed and is starting to provide you with a concrete direction for what you want to write about right so um you can see here that in the prevention section um we added parameterization so that you know that you're gonna have to touch on that point when you are writing that part of the article and most planning of the article should really be done at this stage before you start writing because this is where you'll be deciding exactly what to present to the reader and how and outlining and planning the article in advance this way will really help you write a more coherent article and make sure that you're not missing any important point that might be important for your reader to know and once you have your outline ready you you can start going through your outline and filling out all the relevant information you have for each outline item i call this my content dumping phase i typically will have notes from my research phase by my side and then i'll start translating the concepts that i've learned during the research phase uh into plain spoken english so think about how you would explain a concept like sequel injection to your friends and start dumping out whatever thoughts you have into um either a text editor or on paper if that's how you prefer to write and all like all you're doing at this point is dumping content out right a very very important thing to remember at this point is not to edit yourself when you're writing i think a big tip about writer's block is that a lot of times when people feel like oh they can't figure out what to write or they can't put anything on paper is because they it's caused by inhibition and the fear of their words not coming up right so you don't want to censor yourself at this point simply capture all your thoughts that you want to express and don't worry about styling or grammar or even typos or anything that would affect the reader's experience those can all come later in the process and it's very very important to compartmentalize writing and editing because you'll be able to write much more freely um all you're doing right now is to say everything you want to say about a topic and make sure you have all the content down onto a paper or a text editor but this also means that your first draft would probably be absolutely trash um like my first draft 100 or 100 percent of the times is not something I want to present to my reader right that's where editing comes into play but we can talk a little bit about that later here you can see that we have an outline here from our previous step and we can simply pick one item in the outline it doesn't have to be you don't have to work on every single item in the outline like one by one you can also skip to a certain outline item if you feel like it and start filling out information that you feel like is relevant for the reader at that point and after you have the baseline of technical content ready the next step is to ensure that your article is something that you can present to your reader right and that's when editing comes into play and for editing I typically do three types of editing in sequence so I first go through a technical edit and then I do what I call a common knowledge edit and then finally copy edit for the technical editing phase this step is to ensure that both your text and your message and your images and your diagrams are technically correct and don't contain any mistakes and besides blatant technical mistakes you should also look for things like technical contents uh technical holes in the content um are there anything that you fail to explain are there any logical jumps in the article or do you have anything um that you need to rearrange to make it easier to read or is there something that could use more explanation or reference to another resource and after you do a technical edit the next step is what I call the common knowledge edit and this is really the phase where you will try to optimize your article for the reader's experience so in this phase I try to read my writing as my target reader as someone with no prior knowledge about my topic as and is instead equipped with the common knowledge for my target audience so for example if I am writing a security code review article for developers I can probably assume that my readers already understand concepts like hgp cookies encryption but I shouldn't assume that they already know about how to conduct a security code review and at this point the technical content of your article is fixed the next thing to do is to refine the words and sentences so everything that we skip during the last phase so you can start deleting the content that don't add any meaning or clarity to your article or think of ways of phrasing each sentence or each word better just in general clean up the language and make sure that the article flows and makes logical sense and that it's easy to read and then finally I run my article through a grammar checker and um read my article out loud or in my mind as a final sanity check that the article indeed flows and doesn't contain any last-minute mistakes so that's basically the process or that I take and the strategy I use to optimize my technical writing process but now that you have a good framework for writing technical documents efficiently a lot of people tell me they want to start a technical blog I think writing an internet blog is very different from um how you produce other documents while the principles of good writing still very much applies you have to plan in advance you have to read your article as the reader and you have to do fact checks and grammar checks but if you want to write an approachable and appealing tech blog there are two more principles to keep in mind to optimize your experience for the online reader experience so the first tip I have for you to write an approachable blog post that people will want to read is to simplify and the next one is to keep things short and sweet and what do I mean by simplify right good technical writing is always easy to read and but this is especially true when we're writing on the internet because on the internet your technical blog post has the potential to be shared anywhere in the world right and you never know who will come across your content and what their background will be and simplifying articles allow people like non-native speakers and novices to consume your article as well and you want your content to be understood by the largest group of readers and even if your readers don't have prior experience with your content and are indeed native English speakers making your article simpler just makes it easier and faster to to read by everyone so try to use simple words and sentence structures whenever possible and when you can explain something in one sentence never use 10 avoid things like jargon abbreviation acronyms and obscure references because a lot of the times these would not be common knowledge for every one of your readers so here we have an example of of me trying to explain sequel injections and it says that sequel injection attacks are a type of malicious activity that enables dangerous attackers to craft malicious sequel code to change the structure of a victim application sequel queries illicitly to steal sensitive data modify confidential data or potentially execute arbitrary commands in the underlying operating system and you can see that this is an extremely long sentence with a complex and structure and a lot of unnecessary adjectives and all that does is that it takes away from my main message and makes it difficult to understand what I'm really trying to say in this sentence so we can instead rewrite the sentence as sequel injections allow attacker code to change the structure of application sequel queries to steal data modify data or potentially execute arbitrary commands in the underlying operating system and you can see that the sense is a lot shorter and more to the point and as compared to the last sentence it actually doesn't take away any meaning from the actual sentence itself so this is how you simplify a sentence right and I know sometimes it's difficult to figure out how to simplify a sentence or a paragraph and a good role of thumb that I use is to delete every single thing in a sentence or in a paragraph that doesn't help you illustrate or clarify the message that you're trying to convey so as you go through your sentence or your entire article you want to look at each component and really question yourself does this really help me say what I want to say or is this just fluff or does this even distract from my message that I'm trying to convey in the article another thing to keep in mind is that when writing for the internet is very very important to keep things short and sweet and to divide things up into chunks so writing a blog post it sounds like writing a research paper or a report because the way that people consume information on the internet is different when people are reading a blog post they might scan the entire article for headers before committing time to reading it I know I do that a lot and they might also be browsing twitter or checking their phones at the same time while they're reading your article or they might be reading your article on the tiny tiny smartphone screen right it's very different from the traditional reading from a paper or even reading an entire pdf on your laptop so when you're writing internet content it's very very important to optimize for a digital experience so part of that is to divide your article up into easily digestible chunks ensure that each section is marked with appropriate headers and sub headers and this makes it easier for your readers to jump to different sections of your article if they do get distracted and to just in general revisit different sections that they're interested in or share or reference different parts of their article with people online also try to keep things short and to the point to make your article more digestible during a short time frame so if you're covering multiple topics in a blog post you should consider chunking it up into multiple sections with header and sub headers ready so that people can quickly skip to the parts that they're interested in and another role of thumb i use when i am deciding how to divide things up in my article is one idea per sentence and one concept per paragraph so i'll only try to say one thing per sentence and i also only try to explain one concept per paragraph don't try to say too much in one go keep your sentences short if your sentence is getting too long then you can divide it up into two sentences if your paragraph is too long break it down into multiple sections and finally if your blog post is getting too long as long as more than five minutes of reading which is approximately 1500 words consider making your blog post into a series of blog posts instead of stuffing everything into one single article because we probably all know people don't really have that long of an attention span on the internet so it's important to make your article feel like it's easily digestible and very quickly readable uh yeah short sentences and paragraphs also make your article much easier to read um when people are using mobile devices they don't have that big of a screen to work with and i think so those are my tips for you for optimizing for the internet but now that you understand how to write technical content what if you want to write a technical book right there's a lot that goes into writing and publishing a technical book that's not just writing but business and marketing decisions and it's really a long and complicated process in this presentation i want to present with you a small overview of the process i won't be able to go too much into it but if you're really really interested in writing and publishing a technical book and my experience doing it feel free to reach out to me um after the talk or via twitter and i'll be happy to answer any of your questions so this is um what i think the overall process of writing a technical book would be like um of course this process will be different for every single author but um this is what i think most author would need to do some parts of the process is like we just discussed like you have to research your content you'll have to structure and write the book you have to work on the text the diagrams the code examples and you have to work with multiple editors through multiple edits to make sure that your book is technically correct um but a lot of other decisions and processes that goes into writing a book doesn't really relate to the writing itself things like choosing a publisher or deciding how to package them market the book um these are i think what traditionally we don't consider when we're writing blog posts or technical articles and um so i'd like to just quickly go through two key decisions that you'll also have to make that would impact your book writing experience a lot and the first key decision that you have to make is deciding on the scope and the audience of the book so with blog articles you're most often just writing about a single topic at a time right but writing a book is different when you're producing like a 300 page book or 400 page page book um it's more like designing a college course or a curriculum so you really need to think about um who should uh like who should read it and what they should get out of it so a good strategy of doing that is to define broad but clear learning goals for a specific audience so you can say things like i'm writing a book to help beginners how to find their first bug or i'm writing a book to help Python developers build dedicated security tools using Python so defining these broad but clear learning goals will help you really decide what topics to include what kind of prerequisites you need to require for your book and how fast and with how much detail should you introduce concepts in the book and another key decision that you have to make very early on the process is whether you want to use a publisher or not publishers usually help you with things like book editing and they coordinate things like printing shipping and making sure that your book um hits different sales channels and they also help with some marketing and some pr tasks and you don't have to use a publisher if you do decide to publish a book a lot of people choose to self publish with great success as well um but the pros of the pros of um self publishing is that you get to do whatever you want with your book right um publishers sometimes have certain styling or writing standards that they stick with um if you self publish um you are in complete control of your book and you also get to keep more of the profits usually when you work with a publisher you'll get anywhere between five to 20 percent of the proceeds um if you self publish you'll probably see more of that uh more of that income but working with a publisher means that a lot of the messy task of making a book is done for you for things like finding the right editors the right illustrator is making art and dealing with marketing tasks these can be very tedious and really probably not in most uh technical people's expertise so it's just makes things easier if you do decide to outsource that to a publisher so it's and it's really you know a trade-off of what you want from your book writing experience and lastly um which publisher should you choose right there are quite a few publishers that specialize in tech and I honestly have to say that they are quite different in the way that how they work with authors or how they edit books um how they draft their contracts um I'll be happy to talk more about it um in person so just reach out to me if you're interested in that so to wrap up um technical writing is a great way to help you learn faster learn more deeply and help you share knowledge back to the community and mentor others and a few takeaways that will help you write better technical articles more efficiently is first to write with simple language right you want to write as though you are speaking to really make um the reading process a smooth and easy one for the reader second is don't write and edit at the same time um when you write and edit at the same time a lot of the times you're censoring yourself and you're feeling yourself with inhibition and fear of your words not coming out right so if you can um compartmentalize these two tasks a lot of times you'll be able to produce a lot more content more quickly the third one is that you should always keep your reader in mind and really optimize for their experience when you're writing your article uh thanks and please ask any questions in silo and if you have any private questions about this talk either about writing about publishing about blogging feel free to DM me as well on twitter all right thank you viki um so we're already running a little bit late so we'll take a two minute break before our next talk so see you in two minutes boom so that's pretty cool welcome everyone b45 and chief researcher uh research officer at apsec engineering he's focusing of course on apsec um abe is a builder and breaker of application he's the chief architect of orchestrant a leading application vulnerability correlation orchestration framework he has created some pioneer works in the area of dev secups and apsec of the automation including the world first end zone training program of dev secups uh focused on application security automation up high is a speaker and trainer at major industry event including uh dev con blackout ops and apsec cali and yeah so please join me in welcoming up high for his talk today and we'll be right with you after this thank you thank you so much uh thank you for the introduction i really wish i could have been there in person but uh unfortunately uh travel is still a little elusive uh at least to canada at this point in time nevertheless i'm really happy to be here this is my first ever talk at not sec and i'm really looking forward to it i'm looking forward to hearing uh getting some questions and comments on the talk that i have as well um so i'm gonna quickly get to it because i have 30 minutes and i don't have too much time and i my talk is uh loaded with a lot of content so i'm gonna quickly start sharing my screen um i'm guessing everyone is able to see my screen uh yeah okay sorry about that i i think you're i'm presenting from one screen so i'm uh this is unlike probably most speakers who are going to be doing it remote i'm just gonna start my slide deck and i'm gonna get started um all right so uh this talk actually is a culmination of a bunch of research efforts from 2021 uh that is now being showcased uh all over so this is called hook line and sinker pillaging api webhooks now webhooks are something that uh a lot of us use and i'm sure members of this audience as well are quite familiar with what webhooks are we're gonna quickly get into what it is and how it works and all of that stuff and then i'm going to be looking at attacking it and some case studies around how we actually went about this particular piece of research so just a quick introduction my name is abhai i work for a company called we 45 and i'm also uh i'm also the chief research officer of apsec engineer we run a training platform on apsec cloud security kubernetes and so on i do a lot of training i do a lot of talking uh i do a lot of research on mostly defensive stuff so this this talk actually is a departure from my typical style of talks which is way more defensive than uh offensive so most of my research is defensive but in this case the talk i'm going to be focusing on is explicitly offensive so i'm going to get started with it uh if you're interested we have a very interesting youtube channel where you can check out a lot of interesting stuff on apsec and so on and if you want to check out my blog that's there as well i highly encourage you ask your questions on twitter because i am currently suffering from a back injury and i'm not going to be there for a q and a session on on the not sec channel so if you want to ask questions please reach out to me on twitter i'm going to respond i'm barely holding it together sitting and talking right now i'm just on a lot of pain meds so that's i just wanted to let you know that if you want q and a please reach out to me on twitter that's the best way that i can respond to you all right so my talk today is going to be full of memes i'm sure i'm not sure how many presenters use memes in in not sec but my talk is going to be nauseatingly full of memes and i have one live demo as well so i am going to have to pray to the demo god and i'm going to have to ask all of you to pray to the demo gods on my behalf so that everything works because live demos as they go a lot of things can go really really wrong so i'm hoping that everything goes pretty well i did test it before i just started but you know things can go wrong uh every single time so you never never really know anyway today's agenda is going to be pretty quickly uh what are webhooks how do they work we're going to get into this pretty quickly i have 30 minutes so i'm not going to take too much time in the explanatory segments we're going to be looking at some common webhook attack patterns and this attack is not in the common webhook attack pattern so the attack that i'm going to be referring to in this specific presentation is not a very commonly seen attack but i think it has the potential to really uh explode on the scene we've seen it explode on the scene uh at least with the kind of bug bounty targets that we've been working with it's it's really uh performed really well against a lot of these targets we're going to do a quick introduction to ssrf because that's the underpinning of this and ssrf i'm sure a lot of you have heard of ssrf probably uh do a lot of ssrf as part of your offensive work or even do uh defend against ssrf in which case i pity you but nevertheless ssrf is something that we're going to be focusing on this talk is a lot about ssrf i'm going to look at ssrf we're going to look at a new class of flaws that we dub webhook boomerang flaws now these flaws have been there there are they've been in and around but they've not been as well exploited i think as they could have been so this is where we're going to be talking about this is the meat of the uh presentation and then i'll talk about some sub variants and so on right so basically when you are building an api the first thought you have is interaction right you want to respond to events and one of the big things when you are building an api is to respond to events so when a new user is created or when there's a new customer that signs up or a new payment that comes in or you know blah blah blah whatever it is you are typically dealing with events right apis especially with apis you have a lot of events that you want to deal with and a lot of times when you are dealing with events you need webhooks because you need to post that event somewhere so let us say i'm a new e-commerce uh you know i'm a new e-commerce merchant and i have set up a new site on whatever and i'm using stripe or top or fire what have you now in that case the first thing that i'd like to know is hey when am i getting paid have i gotten this customer when have i gotten this customer so webhooks makes it really really powerful way for your api to start reacting to these events so when a new customer is created you can send a webhook to slack and say that hey a new customer signed up or you receive payment of this webhooks make all of that possible right i'm sure a lot of you have heard of webhooks most of you are probably dealing with webhooks on a day-to-day basis most of you are probably writing a lot of webhooks as well now so webhooks basically are user-generated callbacks so i set up a webhook uh so i'm a user and i set up something called a consumer so i say that you know what whenever a new user is created on my e-commerce store i want you to make a webhook request to my consumer app so i've written this app somewhere here and i want you to make a request to that so with a particular json that says that this user with this email with this whatever other information is signed up so in a webhook transaction there are typically two entities that are involved one is the provider which would be your Shopify or Stripe or what have you any of the these providers that are reacting to the events and then there would be a consumer that would actually be receiving that event and saying that and they're using it for processing whatever they need to process right so this is a very common setup that you have so these are essentially user-generated callbacks right so that's how webhooks work so in this case we have a webhook setup whenever a new user is created there is this event that is triggered that hits the consumer the consumer app essentially uses that to maybe store it or send them an email or process it forward or whatever they need to do right so these are basically how webhooks work now webhooks are literally everywhere right now you'll see webhooks in not only apps like Stripe and Zapier and Shopify and all of that jazz you see this all over the place you see this with Kubernetes you see that with CICD systems you see it with CICD systems I would say use them extensively right any kind of build systems or CICD tool use webhooks all over the place even basic even apps that are related to marketing automation and so on use webhooks extensively anything that needs to integrate with a whole bunch of other applications especially through event-driven workflows webhooks are the number one way to do that and it's very popular very commonly seen pattern that you do in fact companies like Zapier I'm sure you've realized also they run their entire business on top of running webhooks or triggering webhooks as consumers and providers depending on who they are in the piece of the transaction now common webhooks are trades at least they're event-driven they're typically post requests which is basically post JSON of course you still have the odd XML one but most of them today are post JSON which means they post JSON to the consumer they also you know they also are sometimes protected by HMAC or API keys with an HTTP header so just to ensure that the webhook consumer is somebody that is actually legitimate they also make you also need to authenticate the transaction through an HMAC or an API key depending on the kind of webhook sometimes they're there and sometimes they're not it really depends on the provider and the kind of configuration the provider is using and of course in some cases in some cases remember especially in the case of build tools or CICD tools you will see that producer systems allow you to add your own custom header so let's say you need to add an API key for your system or your application which is your consumer application you can set up a webhook with additional headers as well it's not only that you make you just give it a URL you might also be able to add your own custom header so that you can actually get your event and that would be identified with this HTTP header with a bunch of custom headers right so that's basically what the common webhook trades are now if you come to think of it the natural type of assumptions are attack focused that one would have so let's say you're a pentester or somebody doing offensive security on a webhook the natural assumptions would be that let's try and compromise the consumer most of the attacks are trying to compromise the consumer right and to prevent other kind of replays and things like that again most of it is trying to compromise the consumer so can I compromise the consumer with a DC realization payload which means that let's say I put in some kind of malicious JSON or YAML or whatever it is can I run my code on the consumer can I compromise a whole bunch of consumers you know with an ecosystem style attack can I tamper with the payload can can the consumer detect tampered payload can I replay the attacks can I attack from unknown sources so it depends on whether you know it is whether the consumer is making provider can make random requests to another consumer so a lot of these are typical attack scenarios that you come up with right so these are typical attack scenarios that you see and a lot of them and a lot of you I'm sure do this as well so when you're trying to can you do a replay can you run the same transaction a whole bunch of times is there a way for the consumer to detect that it's a replay happening so all of these things are natural attacks but in our case what we're going to do is going to we're kind of flipping the script in this case what we're trying to do is can I compromise the provider our focus today and our focus in this entire class of attacks is can I compromise that provider this provider that is sending me the event payload can I compromise that particular provider through some type of attack so basically what I'm trying to do in this case is that I have a provider which is my you know striped Shopify what have you I mean I'm just using them as examples I'm not saying that they're vulnerable please keep that in mind so whatever I have this provider now this provider makes a request obviously sends this HTTP request to the consumer now the consumer in turn instead of processing this legitimately like a normal or a good consumer would the consumer makes a request or somehow finds a way of attacking and compromising the provider and the internal applications of that provider it could be a database it could be an internal application it could be metadata it could be whatever now as soon as you think of a scenario like this I'm sure the first thing that comes to mind is naturally SSRF right now SSRF is one of those attacks that orients itself towards doing something like this right because SSRF allows you to redirect or facilitates a redirect based on a user controlled URL so in this case it has all the natural makings of a classic SSRF attack the idea here is that when I the user can can use a particular URL of my choosing so it could be a URL that I can select or I can enter or I can use as part of the attributes and I can get this application this target or victim application to make an internal request to one of their internal URLs or to a metadata URL so let's say I want to compromise AWS credentials I make a call to a metadata URL and that metadata URL gets I get access to the credentials and from there I get those credentials and then start exfiltrating information from AWS I can escalate privileges on top of your AWS account so this is SSRF this is classically SSRF right most of us are aware of this most of us have seen this SSRF is super common you see this in nearly every third bug bounty report at least is I mean I obviously don't have the exact stats but SSRF is super popular it's very very commonly seen now you see of course SSRF you have a lot of attacks the capital one breach where the attacker was able to find SSRF on the mod security mod security deployed by capital one they were able to use that get the make a call to the internal 169.254.169.254 AWS metadata they were able to get the credentials those credentials had a large scope access to the amazon s3 infrastructure that was run by capital one and they were able to gain access to all those s3 buckets and exfiltrate a whole bunch of user information from there then of course you've constantly seen this SSRF is super common you've seen this as part of the proxy logon exploit chain it is one of those one of those extremely common and extremely popular attacks that is also hard to prevent by the way it's not very easy to prevent SSRF there are a lot of different nuances to prevent SSRF anyway so the idea here is that with SSRF you can do all of this stuff one of the the reasons why SSRF has become so popular is because SSRF is used extensively to compromise cloud environment so if you're running Kubernetes or AWS or Azure or GCP the idea here is that you have some metadata URL or metadata file path and you can access that particular file path gain access to sensitive credentials that are mounted on that particular file path or URL and then use that to escalate privileges into the account SSRF can also be you reading a remote file and executing that through a remote port execution it can be denial of service it can be information disclosure so through SSRF I'm able to access internal hosts and those internal hosts have sensitive information that could be information disclosure so you have a wide array of possibilities with what you can do with SSRF so I'm sure a lot of you are aware of this now here what we want to do is leverage SSRF against our provider so we want to use this attack essentially as a boomerang so what we want to do is to say that look hey the provider is going to make a request to me the consumer I am an evil consumer and I get a request through the provider now I want to be able to use that same request chain against the provider right so I want to redirect a request back to the provider where I do something where I'm able to compromise internal assets so I'm the idea here is that my provider makes a webhook request whereas my consumer redirects that particular request back to an internal URL or metadata or what have you and I'm able to compromise that as part of this now remember a lot of times the reason that this also works is because a lot of these providers store previous results of webhook execution right so for instance let's say I'm a I'm strike and every single time I receive a payment I trigger a webhook or I've the user has configured a webhook where I can trigger a webhook on this particular on this particular event now I keep a log of those uh the requests and responses so strike maintains a log of that and a lot of times you as the user are able to see that log so the idea here is that the consumer who's also a legitimate user of the application wants to leverage this attack and then use the webhook that they have set up to compromise that provider application or that victim application right that's basically what they want to do but there is also a problem now if you are familiar with ssrf you'll know that ssrf works extensively with get requests right ssrf works when there is a get request involved so when you take a get request and you are able to uh use another get request you can do ssrf you can manage ssrf however most of the webhooks right most uh I'm not saying all but probably close to all most webhooks make post request or put request right because they are sending data they're not only making a get request there's no point of a get request most of the time they are making post request because they're posting json to that particular uh consumer right so the idea here is that you are getting a post request but how do you use that to make a uh to redirect that into a get request that's so it's hard to weaponize especially with pure ssrf so this is where a very interesting header comes in now there's there's a header which is a uh which is a very popular not I wouldn't say very popular but at least a well known redirect header which is called the HTTP 303 redirect now the way this works is that if you send it a post or a put this redirects as a get so you can set up a redirect on your consumer application that says hey whenever you get a post request to this particular path let's say whatever slash webhook whatever you need to 303 redirect it now a 303 redirect automatically converts that post request to a get request on the redirect and it requests a particular new location and that is where this really works this attack really works because 303 converts that redirect into a get request and sends it back to wherever you've redirected it now obviously people creating the standard didn't imagine that this would be the case or this would be how it would use but 303 allows that to happen right unlike most other uh redirects that you have so uh so the idea here is that the in a response so whenever you have a HTTP 303 which is see other it essentially says hey this way please and makes it a get request so basically redirects it as a get request and your clients essentially just follow along they just said oh okay I need to redirect to this location so I'm going to make a get request this particular location and that request turned now into a get request now which means that you can leverage that SSRF in full uh scope right so this is something that 303 allows you to do so what we want is essentially we want to provide our application we want this webhook request to come in and once this webhook post request hits my consumer the consumer remember the consumer is another web application that's just listening for these requests so as soon as this post request comes in this sends back an HTTP 303 that redirects to an internal metadata service like 169.254 or some local host service or some internal IP address or whatever it is that it's able to access that URL and get whatever information whatever uh response that comes from that particular URL get request is stored as part of the webhook logs right so that that's the idea so the attacker wants to be able to do this because the attacker wants to be able to store uh redirect boomerang this attack back to the provider get that provider to talk to an internal metadata service steal credentials and then use that in the webhook logs use those stolen credentials and escalate privileges into their AWS account or use that to access an internal resource or what have you right there are a whole bunch of things that you can potentially do with this now this is something that we have extensively used against a whole bunch of public bug bounty targets wherever we've seen bug bounty system wherever we had bounty programs we have tried this out and it has had amazing results the the kind of results that you've seen with the webhooks system that they had have been quite amazing and we've used this on Docker and we were we were able to use this successfully on Docker right now Docker obviously as all of you I'm sure a lot of you use Docker every day Docker is a massive service that allows you to host your container images in their container registry Docker was the original registry of course now you have a whole bunch of other registries but we were able to do this on Docker we were able to compromise and gain complete access to their whatever their AWS credential provided which was quite highly scoped at this particular point in time so I'm going to explain how we did this now in Docker in Docker Hub there is a functionality where you can create your own webhook right so we created a webhook in this case and we set up the webhook to a ngrock URL to to a URL that we controlled of course and behind the scenes we essentially wrote a small piece of code with that said you know what whenever you whenever you get a request a post request here what we want you to do is run a 303 redirect back to you know 169.254.169.254 slash latest slash metadata which is a very common path for the metadata in an AWS EC2 instance or not only EC2 but any many other compute instances of AWS you're talking about elastic beanstalk we're talking about Fargate I think Fargate has a slightly different IP address but it's pretty much the same idea regardless right so but it is essentially gets you access to the instance metadata on that particular node and through that we were able to identify this so once we did this we pushed so this webhook would be triggered every time we pushed a new container image to this particular to this particular Docker registry Docker repository right so we pushed this container image which was generally a random container image and once we did that we saw that the Docker Hub the webhook trigger the Docker Hub essentially was triggering the webhook of course but we were not able to get the webhook logs we were not able to get the log of the webhook and when we actually saw the request and responses we found the webhook log in the request it was not being shown up on screen but we found the webhook log and in the webhook log we found that they used the metadata credential the AWS roll name called this right so prod whatever whatever something they use some AWS roll name here and once we were once we used that particular URL in a subsequent request we were able to dump the AWS credentials and as it so happens those AWS credentials were related to their EKS infrastructure that they were used they used to run Docker Hub with so the EKS infrastructure and probably a lot more we didn't go beyond this because obviously we wanted to report it as soon as possible in the interest of vulnerability disclosure so in as soon as we found this and we and of course they mentioned to us that this was scoped to the EKS cluster on Amazon and obviously this means that this could have been a much larger attack because the Docker Hub which is which contains a lot of the base images and the trusted images potentially I don't know maybe they could have been compromised as well so the idea here was those AWS credentials we were able to identify and using those AWS credentials we were able to access their AWS account we were able to potentially compromise their AWS account and gain access to whatever scope that particular role and that particular privilege is granted to that role could provide us so this was a huge attack simply because Docker is as you all know a extremely public service that all of us use and this could have had a pretty huge impact so we immediately reported it to them in fact we just didn't get color identity and it was giving us a legitimate role on their AWS account so we were immediate we immediately reported it to them and they of course they fixed it in a matter of about two hours as soon as we reported it a couple of hours later they said that we fixed it we re-ran the checks and we found that that actually indeed fixed it so that is one of the things we found and thankfully it was fixed quite a while back so it's quite this is not something that we need to worry about anymore so they were able to address it almost immediately so we have I have a quick demo that I have set up here as well I'm going to quickly run this now if you see here we have our application so I'm just going to quickly walk you through how the demo works or the demo app so I have a provider application as you can see here and I have my evil webhook consumer that I've set up now every time I make a webhook post request payload when I trigger a post request payload here my evil consumer with HTTP 303 with a redirect to a CouchDB database so CouchDB is a very popular no SQL database that you can directly access through HTTP like a REST API so the idea here is that I'm going to use this to access my data internally on the CouchDB so CouchDB should not be exposed but because I'm redirecting it and because this application has access to CouchDB the idea here is to get this application to connect to CouchDB and store those results as part of the webhook request and response framework right so now let's quickly go into this I've already set up the demo I'm running my application stack here so this I'm running on our training platform on AppSecEngineer in fact so now let's I think I've already set up everything I need I'm just going to log in and explain how the attack so I have I'm going to log in as the user so this is me logging in as the user and I get JWT or you know an authentication authorization token once I've logged in as this particular user right so if I do an echo dollar talk I get this right so if I if I just paste it here it's a genuine jot that I can use on my application so in this application so you'll see that it's a valid JWT blah blah blah has it's logged in right now I am going to list the user's data so I'm going to list the user's information as part of my application so the user in this case has set up a webhook and this webhook makes a post request whenever a new build happens so imagine that this is a CI CD system and a new build happens this triggers a request to my to this particular URL right so that's basically what happens now I'm going to quickly simulate this I'm going to simulate a request in this case what I'm going to do is here I have set up my webhook now in my webhook what I have done is I have set up my redirect URA to the CouchDB service so I've said that whenever you're trying to do this redirect it internally to a CouchDB instance so make a 303 request back to the CouchDB instance right I've just set it up as a redirect so if you see my code you'll see what I'm talking about you'll see that every single time a request comes in make a 303 redirect to this URL this hook URL that I've set up right so that's basically what's happened so I'm going to run my hook this is me running my webhook my malicious webhook and once I make a request which is basically like I'm going to trigger an event you'll see once I trigger an event this this comes back with the CouchDB all databases information so if I see what is actually returned by this you'll see that the CouchDB database hack has a database called users now if I change this request you are hook you are I and I instead of all databases I make this users now this is me escalating privileges 984 slash user slash all docs sorry about that so every time my hook is reconfigured to redirect to another location so in this case now if I trigger another webhook event you will see that it fetches oops I'm not sure what happened okay I think there is something wrong with the URL that I was trying to access oh that was the issue sorry looks like I've added some unnecessary characters here and so let me just rerun the the webhook simulation yeah yeah I think I only have it so you'll see that it returned with a whole bunch of characters so if I do echo like we should have just done a jq here so you'll see that it returned all these user values right so these are just user IDs but of course I can fetch pretty much anything at this particular point in time now so this was the demo of how this would work right now of course one of the common things is okay this is a get request what's so great yeah in many cases you if you have metadata a lot of times those metadata to access cloud metadata if it's not AWS in many cases you have to add additional headers but a lot of times you will see that a lot of services allow you to add custom headers right to the webhook so in that case one of the things you can do is add custom headers so in this case we were able to compromise a CI system where they were using GCP and because we were able to add custom headers we were able to simulate a system where we were able to add the metadata flavor header which means that this would make a get request to the GCP metadata with that mandatory HTTP header which is metadata flavor google and through that we were able to still perform this attack so if you have a webhook system that allows for custom headers you have that possibility as well I don't think I think I've run out of time now I'm just going to quickly run through the defense the first thing you have to do is one of the simplest things that you should do for this is to not follow redirect so when you have a webhook setup when you're when you're using APIs and you're using webhook functionality the first thing you have to do is turn off follow redirect on our HTTP client that would essentially bring down the possibility of this attack by quite a bit you have to figure out what type of HTTP client you're using and not follow redirect in that particular HTTP client that's something that you have to do of course you can add additional security elements like network security policy you can add DNS so that it does not resolve to a local internal IP address you can add a validating validation for the webhook URL although that's a little difficult to do if you have a publicly public where users are providing their own URL so that may be difficult to do or you might have an IP denialist to say that anything that tries to talk to 169.254 local host or 10 series or whatever it is you do not allow that in your webhook URL so these are some of the areas of defense that you can use that's really it conclusions again webhooks are a very powerful way to integrate but again with these kind of boomerang attacks you can have a very serious set of issues with webhooks so definitely look at those possibilities and consider this as part of your threat model I think the first thing you should do is consider this as part of your threat model that really makes it a lot more powerful for you to think about these type of attacks and how you can potentially get hosed by these kind of attacks so that's something you'll see SSRF of course is the attackers very good friend in this particular case now with that I come to the end of my talk I realized that it was probably a little rushed but I hope I was able to convey everything I wanted to convey and I hope it was useful thank you so much for having me and that's really it all right thank you so much all right um so quick break again this time so a few minutes two to five and the next speaker will be live so it's pretty exciting we're kind of shifting in second gear for our next section of the talk if you do have question please um for hop high please go on twitter he's not going to be part of the q&a session at the end and uh don't forget for the next speaker if you have any question go on slido and we'll answer them during the talk thank you welcome back I see a lot more faces this is very exciting again all right so we'll have our third talk today please let's welcome you see wise man you'll see is a senior security researcher in the cloud security research team yeah welcome in come on in he has more than 10 years of experience in security research field starting in israeli military he's his current role in his current role he focused on container security uh all right so please hello i'm you'll see first of all it's very nice to be here um i'm yours wise man i'm a senior security researcher at microsoft and today i'm going to talk about lateral movements in kubernetes um so this is the agenda for today we are going to start with a short overview of kubernetes uh then we'll talk about identity types in kubernetes um we'll speak about lateral movements both in the cluster and from the cluster to outside resources and then we'll have some takeaways so let's start so first um what is kubernetes but before that what are containers so um containers um container is a unit of software that packages your code your applications code with all of its dependencies so you can run in everywhere without worrying about your dependencies um the executable itself is called image and at runtime images become containers um which are run isolated from each other now usually it's not enough to run one container on one computer um you want to run multiple containers on multiple vm's or computers and you need to manage it somehow and that's why you have kubernetes um kubernetes is a container orchestrator and it basically manages a cluster of container cluster of computers each run each computer run multiple containers so let's see how it looks like um so this is a kubernetes cluster and you can see that it has two main parts it has the control plan which is like the brain of the cluster and we have the nodes which run the actual computers actual containers so um the control plan has several components um the what's especially interesting for us is the api server which is like the front end of the cluster so every request um to the cluster goes via the api server for example if you want to create new containers it goes through the api server if you want to list all the resources in your cluster it goes via the api server so that's what's especially important for us to this session and then we have the nodes which run the containers and each node also have an agent that is called kubelet which allows kubernetes to manage that node that computer in managed clusters in the cloud such as aks in azure aks in amazon or gcp uh in google gke sorry in google um the control plan is fully managed by the cloud providers so you as a user don't have a direct access to that control plan in kubernetes we usually don't talk about containers because containers are not um kubernetes objects we're talking about pods which are the lowest level components in kubernetes um so in this session also we're going to talk about pods usually users don't even deploy pods they deploy higher level components but since pods are the lowest level components in kubernetes we'll focus on pods um pod can run one or more containers um that share um resources um so in this session uh we'll concentrate on pods um so now that we know what is kubernetes let's talk about identity types in kubernetes and we can split it into three main areas so the first one is how users from outside the clusters like the administrator can authenticate with the cluster with the api server actually the second topic is how applications in the cluster authenticate with the cluster and again with the api server and the third is how applications in the cluster authenticate with resources outside the cluster in the cloud so in this talk we are going to focus on questions two and three because that's what's important for us for lateral movement so what is lateral movement in kubernetes so um back in 2020 um so this is the threat metrics to kubernetes um which we released at microsoft um back in 2020 um the threat metrics is a knowledge base of attacking techniques of kubernetes and it was actually the first attempt to systematically map the attack landscape of kubernetes last year in 2021 we released a second version and as you can see we used the format of mitre attack probably many of you are familiar with mitre attack and last year mitre released their own um metrics for containers as part of mitre attack framework that was actually a result of a joint project of mitre with other companies including us at microsoft if you want to read if you want to hear more about the threat metrics and the differences between the threat metrics and mitre attack you can watch our session at kubicon from a few months ago but um for now we can see that the lateral movements has many techniques and um we are going to cover um some of them during the session so we are going to start with inner cluster lateral movement um but first we know we should know some basic terms of cluster authentication and authorization the first term is service account which represent an identity of application in kubernetes um kubernetes uses rback role-based access control it's not unique for kubernetes of course um and rback has roles which is set of permissions and role binding which which attached um identities to the roles so for example here we have service accounts one two and three and we have roles one two and three and you can see that service account one has roles one and two and role three has service account two and three attached to it so this is rback and that's how rback works um in kubernetes so service accounts can be mounted into pods allowing the pods to authenticate with the api server so the full chains look like this we have pod the pod has service account mounted to it service account has roles attached attached to it and each role has permissions which are the rules so here's our cluster again and now we know um that uh we have service account in the pods for example pod has service account and with that service account it can communicate with the api server so let's talk about the lateral movement so what is lateral movement inside the cluster so let's assume that we have a pod that is compromised and how pods can become compromised so for example if the pod runs a container which runs a web application and that web application is vulnerable and somebody exploited it so now we have a vulnerable container uh sorry um compromised our container compromised pod in our cluster so let's say the pod a is now compromised so what is lateral movement it could be a movement between one pod to another pod in the cluster it can also be a movement between a pod to a node in the cluster and if the attacker get access to a node usually it means that the attacker can perform a full cluster takeover because the node has a strong permission it has an identity in the cluster and if the attacker has access to the node it can read um the uh permission the credentials of that token of that identity and perform a full cluster takeover so usually access to a node to a node allowing um takeover of the cluster so the key point here is that attackers um can use the service accounts of the pods in order to move laterally in the cluster so we have pod and the pod has a service account and the attacker can use it so which permissions might lead to let to inner cluster lateral movement in other words which permissions the service account of the compromised pod should have to allow the attacker to perform lateral movement and the answer is that there are many permissions that might may lead to lateral movement and we are going to see two uh um two examples real world example that we saw in real environments so the first example is the read permission to secret so kubernetes secrets are objects um that store sensitive data in kubernetes for example if you have an application that needs a connection string or a password you can store it as a kubernetes secret and then load it into your running app um kubernetes itself uses uh kubernetes uses uh secrets to store tokens of the service accounts um so if attacker has permissions to read those secrets uh they can steal the tokens of the service accounts so in this example um on the left uh we can see a role definition that allows reading all the secrets in the cluster so if the compromised pod has this permission um it can allow it it can allow the attacker to use um this permission to read uh token of uh a privileged service account and in that way to move laterally in the cluster so let's see an example um so pod a um has read permissions so now pod a can the attacker can uh can request the token to um a privileged service account token and um with that token it can impersonate to that service account and now the attacker can move laterally in the cluster for example it can deploy a new container or it can change the configuration of an existing containers to run its own malicious code so that was the first example now we're going to see another example of a permission that allowing lateral movement and this is self update permissions and this one is based on a vulnerability that we recently discovered um and the root cause in that vulnerability was self update permission now in this case what happened is that application had permissions to update themselves now it sounds maybe harmless because you can update only it's yourself but it means that applications could change their own configuration and specifically change their own configuration into privileged and if you change your own permission um your own configuration into privileged it means that now you have a privileged container in the cluster which allows access to the underlying node and again if you have access to the underlying node in most cases it means that you can perform a cluster takeover so let's see how it looks like so pod a has a permission to change its own configuration so we turned itself into privileged now a new pod is deployed this time the pod runs a privileged container so we have uh the new container here the new pod and from that um from that pod the attacker can access to the underlying node and perform cluster takeover so those were two examples of permissions in Kubernetes RBAC that allowed lateral movement in the cluster so now for mitigation detection how we as defenders can uh prevent it so first is adhere to the list privilege principle which means don't give service account permissions they don't need second in most cases your pods don't even need any access to the API server they don't need any service account um by default um Kubernetes loads or mounts a service account to each pod but you can disable it so in the pod configuration you can specify that you don't want a service account so if your application doesn't need access to the API server just don't mount service account and as for mitigations so what we need to do basically is to monitor the API server of Kubernetes and luckily we have a very powerful tool to do it and it's native in Kubernetes and that is the Kubernetes audit log which allows you to um basically see every operation in the API server in that way you can um find suspicious deployment of a container with suspicious images you can find deployment of pods with suspicious configurations at such as privileged containers and you can also monitor suspicious or sensitive API operations such as um read secrets from Kubernetes all right so uh we talked about um inner cluster lateral movement now let's move to cluster to cloud lateral movement which is in my opinion even more interesting so um workloads in Kubernetes may need access to cloud resources for example let's say that we have an application that needs to store data many applications need to store data so we can use cloud storage for that now if we use cloud storage so we need to authenticate with that cloud storage so we need to access to cloud resource in case of managed clusters such as AKS, EKS, GKE they must access cloud resources because they rely on cloud services for example the Kubernetes nodes are virtual machines or um the cluster uses a cloud load balancer so they must uh they must access cloud resources and the question is how do workloads in Kubernetes authenticate with the cloud provider API and there are several methods to achieve that we are going to go over the main ones so the first one is um specific to Azure and it used to be until quite recently the default method that Azure used to authenticate the AKS cluster to the cloud and in that method we use service principles and service principles are um application identities in Azure it's like in Kubernetes we have service accounts so in Azure we have service principles very similar and with this method each Kubernetes node stores a file with um with credentials to a service principle and by default this service principle has contributor role to the nodes resource group contributor with a strong um um um role in Azure so basically it means that that service principle can um modify or um do whatever it wants to the um resources of that particular um cluster but users can bring their own service principle or giving more permissions to this service principle according to their needs so again if we have an application that needs access to a specific us um um blob storage a cloud storage so the user can grant permissions uh to this service principle to that storage account so um so here's our cluster again but this time we have one more type of an identity so we have besides the Kubernetes service account we have also the Azure service principle in each node and let's say once again that pod a is compromised and again pod a I mean the container that is running in pod a is compromised not the pod itself because pods are just a Kubernetes object what's actually compromised is the running container so let's say that uh pod a or the container of pod a is compromised and what the attacker wants is to access to the service principle now the problem that the attacker cannot access to the service principle because there are a there is isolation in containers so containers cannot access to the files in the underlying nodes so what the attacker can do is to try to use the methods that we saw before and that's leveraging the service account the Kubernetes service account to create a new a new pod in the cluster but this time to mount the service principle into the new pod because in Kubernetes you can it's not only Kubernetes also in docker containers you can mount files into containers from the from the nodes but you need to specify it in the container's configuration so if pod a of if the service account has permission to create new content new pods the attacker can use it to create a new pod and this time to mount the service principle and now the attacker has a backdoor pod with the service principle in it and with this service principle the attacker can access to cloud environment so we saw one method and the limitation here the limitation of the attacker is that the attacker needs to somehow create a new pod and mount the service principle into it which in many cases it's not the case I mean nobody says that pod a the service the service account of pod a has permissions to create new pods and second this method is only for Azure so now we are going to see another method that doesn't require any operations with the API server for Kubernetes it doesn't require any service account and also working in other cloud providers and this is and it's also related to the last talk and this is using the metadata service so the metadata service is a special endpoint that allows VMs to query information about themselves and this endpoint is implemented by all major cloud providers you can see here AGO AWS and GCP and among other information this special endpoint the metadata service allows the VMs to get tokens for cloud identities that are attached to them now in all cloud providers you can attach identities to VMs allowing them to authenticate with the cloud API every cloud provider has a different name for that concept in Azure it's called the manager identities in AWS it's EC2 roles in in Google it's called IAM roles IAM IAM service IAM service accounts but all cloud providers have this have this concept and with the metadata service VMs can query the token of the attached identities and this query doesn't require any authentication so every application on the VM can query that endpoint can send a request to that endpoint and get a token to the attached identities now in the cloud Kubernetes nodes are actually VMs which also have metadata service and by default pods can access freely to the metadata service of their nodes so it means that pods can acquire tokens to those identities that are attached to the underlying nodes the permissions of those identities are really depend on the cloud provider because each one has different default settings but also by the specific environment because users grant different permissions according to their needs so now we are going to go over the various cloud providers and we are going to see the default the default settings but we'll see that in each one of them users can also modify it and user very often modify the default permissions to grant more permissions according to what their application actually needs or in many cases not only what their application needs but also excessive permissions so in AKS we have managed identities managed identities are those identities that we can attach to VMs and not only VMs in Azure and AKS uses several managed identities to operate the Kubernetes cluster the AKS clusters but users can also add more managed identities if they need to if they want to add more permissions they can add more managed identities or alternatively they can also give more permissions to the existing managed identities and this is the list of the default managed identities that AKS uses they are quite a lot it really depends on the AKS configuration and we see many cases in which users give very strong permissions to those managed identities according subscription owner which is super powerful so that was AKS now let's talk about AKS Amazon so AKS has EC2 worlds and by default the EC2 world has two policies in it the first one allow it to pull images from the container registry and the second one allows it to read its read permission to the compute environment so read read its read permissions for the EC2s vpcs and etc but again users can add more policies if the containers require to access additional cloud services in GKE we have IAM service accounts not to be confused with the Kubernetes service accounts IAM service accounts is the name is the term of Google to the those identities that you attach to virtual machines and by default all the VMs all the VMs in a project share the same default service account and by default this service account has editor role which is quite permissive and users can also add more permissions to that service account or replace it to another service account so this is a summary of what we just talked so by default pods can access to the metadata service of their underlying nodes so pods can acquire tokens of the nodes and the permissions vary based on the cloud provider and the specific environment as the user configurates and here you can see that you can actually access to the tokens from a running container in each one of the cloud providers so let's see how it looks like how lateral movement using the metadata service looks like so here again we have our cluster with pod a which is compromised and now we are going to make some space so we're going to remove nodes two and three just to make some space you can imagine that they are still there so now we have node one with pod a and node one has its metadata service metadata server and pod a can now request a token the metadata service returns a token of the cloud identity and with that cloud identity based on the permissions pod a can perform all kinds of operations for example list storage account keys or get blobs it can be list secrets from a secret store like key azure key vault or kms and it also can the attacker might get credentials of other Kubernetes clusters that are deployed deployed in the in the cloud and out of time so oh five minutes all right so i have five minutes great i don't i need less so the problem that we just saw is that the pods can freely access to the metadata service and they can acquire tokens to the nodes cloud identities and all the pods share the same cloud resources the same cloud identities and those identities are actually the nodes identities what we want is to allocate a specific identity to each pod if the pod actually needs to access to the cloud api and make sure that pods can access only to their own identities so they don't share identities luckily all cloud providers allowing us to do it we don't have time to go over um each one of them with details but we'll just mention that um those are the solutions that allowing you to give specific identities to specific pods they work differently some of them are based on intercepting the traffic to the metadata service some of them are work by using kubernetes as an identity provider you can read about all of them but we'll just say that they are not enabled by default by default what what we just saw is working and if you want to restrict and use this option you need to enable it this is for matter attack this is a technique that talks about using the metadata server to get um to get um cloud identity tokens um and if you go to that technique you can also see details about attacking groups that use it in containers so what is the mitigation so first um again adhere to the least privileged principle don't give um to the cloud identities permissions they don't need second is as we just said allocate specific cloud identities to your pods that actually need access and third is to restrict the access of the pods to the metadata server as for detection um what we should do is to track the activity of the cloud identities that are related to our kubernetes workloads or nodes and in many times it's quite easy to do it because the behavior is relatively constant constant so if we can see that there are some suspicious operations we can we can look for it and in many in many cases the normal behavior is going to be quite consistent for example in azure we have the azure activity log so you can see in this example that there is a managed identity that is used by kubernetes nodes to list storage keys which is not one of the normal operations and we have the same thing also in aws and we have the same thing in gcp um aws it's cloud trail in gcp cloud audit log so key takeaways um so when you secure your cluster consider the various identity types also the identities in the cluster and outside the cluster always adhere to the least privileged principle again both for identities that are into your kubernetes cluster and your cloud identities and third is to monitor the activity of the identities and look for uh suspicious operations that's it uh thank you very much i hope you find it interesting all right merci you see so we'll take a five minute breaks and after we'll have our last talk for the block of apsec uh please go on slido and answer or submit any question that you might have we will answer them during the q&a merci all right everyone we're back for the last talk of this block which is apsec we have here on stage nate nate wort wordfield he has been an hacker since his first lay hands on 20 2004 at a 2400 bot modern after his first hack on dial up bbs at 12 he was hooked and over the following 25 years he sharpened his skills through job in network engineering vulnerability response endpoint research and site projects such as hacking phones um and researching network attack surface so please join me to welcome nate to the stage for his amazing talk test test are we live can you hear me not yet oh there we go all right uh thank you everybody uh welcome to im become load balancer owner of your network um i'll do a little introduction about myself um yeah i'm nate i have been hacking networks since i was about 12 years old i spent about 17 years building and troubleshooting networks i worked for microsoft for seven years four of those years or two of those years i was in the network engineering group um i spent a bunch of years shipping out windows patches for patch tuesday so i'm sorry but you know that's what i did uh and i did a stint in defender for endpoints doing some endpoint research and i'm about to start a new job on monday that i'm not going to give away the secret just yet uh i worked at f5 networks for 10 years seven of those years i was microsoft's dedicated engineering design escalation support contact which is where i get fun pictures like an f5 device encased in the block of ice which we will kind of get to the the story behind that a little bit later um i like to speak at conferences this is my first time at north sec um i've done primarily blue team sort of defensive focus focus talks so this is the first talk that's more on sort of offensive like evil shenanigans thing which i'm kind of excited for getting a little bit of feedback um i was in uh i was featured in wired magazine in 2020 i helped start a group called cti league we built a 1500 person volunteer info sec group that was giving out free uh threat intelligence and sort of perimeter assessments to hospitals to try to prevent them from getting ransomware during the pandemic um and then my side stuff i like to spend drum and bass music because i'm an old school techno kind of guy enough about me so um the tl dr for those are maybe uninitiated what are load balancers um these are very large expensive pieces of networking hardware um they're usually deployed and what they call a failover pair so if you think of like hsrp for routers it's the same concept right you've got a device that's passing traffic if something happens to it you can failover and can ideally not lose not lose any of your own connectivity um they do layer four to layer seven load balancing some of them can be web application firewalls you can do vpn you can do dns load balancing they're sort of like a swiss army knife of networking um for things that are not just your basic switching and routing um they also do ssl and tls offloading so people will use these things when they're the actually f5's biggest selling point at first was you could have a very powerful ssl accelerator chip slap the certificate on it load balance it across your pool of dozens or hundreds of servers and save money on ssl and also be more performant than going to specific servers themselves uh the nice thing about these things is because they're so uh they're such a sort of a core routing and traffic shaping device you get almost unfettered access to the internal network once you hack on to one of these devices um they're generally on multiple vlands most of them have internet connectivity some of them are talking to active directory there may be vpn sessions so they're a very juicy kind of fun thing once you get on it to see where you can laterally move and pivot and the other sort of maliciousness that you can perform um and they're mission critical right these things are the think of like your core routers these are very important devices which are generally not updated unless someone absolutely has to um f5 has had some code quality issues over the years and people who've managed them kind of get to know that if you don't need to upgrade the thing just leave it running so a lot of these things are running two three four five ten year outdated versions of code uh and the nice thing about these from the attack perspective is because they're proprietary you don't have much in the way of edr or endpoints so like solutions that can monitor what's going on with these devices so even when we were at microsoft there was we had remote logging and things like that but there wasn't really any way you could detect if someone got on the device at least not in any timely fashion um another fun thing about it which is we're going to get into here with these vulnerabilities is that these devices always have a web GUI enabled um the f5s in particular are Apache with tomcat i wish i could tell you it was updated it's not um so there's also other vendors like citrix um a 10 a few other companies i'm going to be specifically talking f5 today but the design concepts are very much the same right citrix runs bsd is their management operating system f5 front sent us you can pretty much most of what they do is identical um it's just slightly different like commands and things to get around and then they also have shells um so bash is the standard one they have their proprietary tmsh one i will point out that as i'm going through these slides you're going to see tmsh commands the reason i'm sticking them in there verbatim is because you can then plug them into the poc that came out last week uh and run these commands so the idea is you can copy paste and play with this stuff in a lab which at the end will talk about how to build one um so the deployment methodology um when i was building this talk i was initially going to use the cve from 2020 this 5902 um past reversal vulnerability that f5 had in june of 2020 that was what i was going to use to show all the demonstration stuff for you however they blessed me a week ago with an even more easy to exploit and an even easier to abuse vulnerability that's also a cvss 10 which essentially without getting too deep in the weeds you take a connection header you basically stuff a authentication connection header inside the connection like the connection colon header feed it to the device and it believes you now have root access to the machine zero authentication required you can run any command as root it's gorgeous um and all devices have management so they sell these things it's generally a big networking switch um they also sell vm versions of it we're not going to go too much into the vm stuff except at the end because that's how i built the lab to show you this stuff and i hope that's kind of readable i mean it's green on black if you're not using green on black are you really hacking things um so uh they have an u management interface the hardware devices will have a switch a bank of switch ports and they'll have an actual like gigabit interface that people can plug into the management side um they also have these network interfaces you generally plug them in to a trunk port a lot of people then tag vlans on top of them and then because it's in a hsrp kind of design each device will have its own non it's stick a static ip that's attached to the device and then there's an ip that they call the floating address um this is bound to the device that's passing traffic this is where your server's default gateway will be if the device fails over that ip address will float over to the other device as it takes over the thing that people don't realize and we saw this last week when people were doing incident response is that not only is the management gooey and ssh enabled on the management interface every single self ip address on the device by default will be listening on management traffic so people may be thinking oh i'll just turn the management interface off and i'm safe i'll know every other self ip the device has is also listening on those management ports um so it makes it makes locking these things down complex um behind these things are generally pools this is the taxonomy that f5 uses pools of servers which is just your server resources um this is all stuff you can look at in the config you can kind of figure out what's back there most people name these pools fairly explicitly so it's like web server pool or my active directory pool or whatever their load balancing so there's all sorts of juicy stuff that we may not be able to get too deep in the weeds on the virtual servers are the actual traffic interfaces this is the thing that's going to be facing the internet facing the clients this is what everybody talks to you and then it sort of just disperses traffic across the back um they use these concept of profiles um this isn't super relevant but i'm trying to give you an idea super isn't super relevant to attacking them but it's useful to know how these things operate so they'll make a virtual server what these things will have is a like a layer four profile if it's going to serve let's say it's serving tls it'll have a layer four profile for tcp then it won't have a profile for http because it's going to be doing http traffic then it will have another profile for ssl which is where the certificate and all these other details are stored so these things have a very it's a very kind of convoluted way of configuring them um but once you start digging around you can start to understand okay how is what is this thing doing and it's yeah it just takes time um one of the other things to notice about these is that when they fail over because they need to shift the layer to address that all the servers are talking to for their default gateway and at the very least they need to update the switch with where this layer to address is like they have a concept that they call mac masquerading where you can have a mac address that's on the floating address so if it fails over the mac address isn't going to change for the back end servers what it is going to have to do is the switch the cam tables in your switch are going to have to know this mac address changed from this port to that port um so if you fail these things over by accident you're going to get and that's going to get noticed they're going to all the CNC a failover event they may notice that traffic gets interrupted for a second the idea here is i'm trying to teach you how to not get caught if you hack onto one of these things and only a red teaming environment of course so a little bit about how these things work at the low level um this is a slightly outdated sly or a slightly outdated picture they split the things into sort of two planes this aom part of the graphic that you're looking at is for one of their older platforms i don't believe the new platforms have these anymore that was the always-on management it was a literally a separate cpu that ran its own separate instance of linux that you could mess around with if you got onto it but the really important part is there's what they call the traffic management microkernel this is the code that f5 writes that the excuse me processes all the traffic it's what handles all the load balancing it's all the sort of brains of this device everything production happens there you'll see this hms part this is the host management subsystems so this is where your linux stuff works this is where this is the part we're going to be attacking the other important thing if you break tmm if you do something that causes it to lock up the devices will fail over and you will probably get caught if people are paying attention this is usually noticeable now the management side is sentos it's not a very updated version of sentos i think their most current up-to-date code is running like sentos 73 and i believe sentos eight is current some of their older platforms go all the way down to sentos like 6.5 so you could pretty much do whatever you want here and the interesting thing about how the architecture works is when the device is boot up at least the hardware ones the first thing that takes over all of the resources of cpu and memory is their proprietary tmm code then it yields back a certain percentage back to the linux side so you're kind of ice you're kind of protected from really going breaking anything too badly because there's a check there it says okay if this if the linux side uses too much cpu resources it just stops giving it resources so the traffic the idea is they want to always pass traffic and never let you you know infinitely loop something in linux that then takes down the whole device now your traffic plans on these things can be tens possibly hundreds of gigabits a second at this point this is a little bit out of order but should you get on one of these and should you decide to start sniffing around or maybe you just trying to capture sensitive information or some whatever your your sort of mission in this engagement might be don't put tcp dump on any of these interfaces that have tmm attached to them if you've ever been a sysco router or a switch person that's like doing a set debug all you will basically be dumping 40 to 100 gigabits of traffic into tcp dump on the linux side that will cause tmm to lock up the device will stop working and you will probably get caught one of the ways to figure out what platform you're on is this is our first of the tmsh commands if you ask it to show sys hardware and i apologize that i don't have an example of it what it looks like it will actually tell you like what hardware platform it is is it a virtual instance you know how much processing power it gives you ideas and then you just go look it up on their website and say okay how big of a box am i on right i was like am i on the two million dollar chassis or am i on the like forty thousand dollar chassis so once you get on one of these things let's say we use one of our fun exploits to get root there's some things you need to know once again not get caught these devices because they're in failover pairs use the concept of a shared configuration right so this is this stuff where you add your virtual servers your server pools your ssl things and this is of course synchronized between both devices so that if it fails over it has the same config if you change things here there's a fairly good chance you'll get noticed the devices are smart enough to notice when a change is made to one side and it'll say oh i'm not i'm no longer in synchronization and if somebody's paying attention a big if they may say why did the devices just go out of sync in their config let's go take a look as i said changes that impact the traffic plane will definitely be noticed if you start doing things like changing these you start messing around with the load balancing configuration or trying to fiddle with the actual stuff that's serving traffic a lot of times it'll happen when you when you apply the change it sort of resets that configuration so you may drop active sessions you may cause a traffic interruption like some blip that will get caught people say what happened to my f5 why did it why did it's like have a blip um now if you just change stuff on a single device there is a section of the config as i mentioned like the cell 5 p's are just for the single device that doesn't get synchronized nobody really notices that so keep that in mind and if you don't know how these things work if you're not familiar with the underlying tech don't touch the traffic plane they have this cool technology that they call eye rolls which is basically a tcl tk modified tcl tk language which allows you to do deep packet inspection on traffic flowing through the device and then you can manipulate and steer traffic based on like binary payloads i think i know one person in the world that's good with these things um yeah i mean if you want to mess around there you can but i would highly advise that you either steal their config and then set up a vm lab and try to do it um but it's it's it's it's there be dragons there um so once you get on uh all of this is sentos right so the logging is all in var log um they do have like i mentioned remote logging so this is the type of thing you would you can check using this exploit you can actually say you know before you maybe jump on the box and start doing things you could say look tmsh lists this syslog it'll tell you if the device is doing a remote syslog um if you dig further into their configuration documentation you could in theory disable the remote logging before you hack onto the device and sort of pre cover your tracks um they have a proprietary somewhat proprietary authentication system it's based loosely on linux pam um the only account you'll ever be able to add to the linux side is or you won't be able to the only account you can log in that's actually a linux account is root so trying to echo something into etsy password and create a user through the ad user thing it's not going to work they just you can create the user but it won't let you log in with that user um history files you know clearing our tracks a home user is where all your history files are created um there's two of them there's your normal bash history and then you've got the tmsh history um you need to clear out both of those if you're trying to keep people from seeing what you're doing and let's see here so user accounts so if we're gonna hack on to one of these devices right we've got this cool exploit from um last week the idea because it gives you root access you're gonna need to log into this thing somehow now more advanced red teamers you may be able to spawn like a netcat reverse shell um i'm not a red teamer full disclosure so you probably have better tricks than i do and if you want to talk about it later please come see me um but you can create user accounts and it will be noticed right if you created a user account you'll notice that it goes from online and in sync to online and changes pending so this is the kind of visual cue that if someone's watching it they'll notice well something just went differently um however because users are not a traffic serving part of the configuration you could then just synchronize the configuration it won't interrupt anything and the all of a sudden the devices will go back to being in sync and you've created your own user and now you can log in and do whatever you want the advanced the advanced shell and i i have an example of this coming up when you create a user when these user accounts are created they give a whole bunch of different permissions but there is an option of which shell you give them um if you say say shell none then they can only log in via the GUI if they say shell tmsh then they can log in only with tmsh which restricts command line access you can generally feed um bash commands through it it has a bash option you say okay just bash minus c give it the bash command it'll run it but what it won't let you do is just drop to a full bash shell and start running around in the file system and doing all the the fun you know evil things we like to do um the other interesting thing about these devices is you can actually disable the root account um at microsoft we did this all the time we would basically set them up we'd lock them down we restricted ssh access we turned off the root account um the fun thing about this i was testing this in my lab as i disabled it and then i used the exploit to check whether it was disabled and i was like oh the root account is disabled so then i used the exploit to re-enable the root account and now i could log back in now this seems like pretty cool but keep in mind i knew the password for the device so if i don't know the password for the root account my options are either change it which now if they go to log in and it doesn't work that's definitely a sign that something's wrong or just you know add a user and give them bash access and then continue on with your day but it's just it's an interesting way that these management um the management stuff that they've done is is sort of convoluted and there's so many attack paths uh the vulnerability that came out in 2020 like i said pass traversal against a java servlet page in tomcat that allowed you to run tmsh commands as root this one was you know the connection header which hit a different it hit the rest api that allowed you to log run commands as root um it's it seems like we're in in a groundhog day sometimes the other interesting thing about it is they don't have a firewall per se like these things have the concept of what they call a net um it's a self allow list let me see i have a picture of that so what this is is it's essentially just a list of ports and protocols that you will allow to be accessed on the self IP address um now some of them if it's a ssh there is a daemon running there if there it is you know tls there's a daemon running there um if you turn on some random other port it may it just means that you can talk to it on that port um the fun part about this is because they're not shared you know and again we can go you know if you if you get one of these devices you try you see okay well there's a root account or i've created myself a new account and then you try to ssh in and you get a connection refused well you throw the exploit payload and you look at what the actual self allow list is and you're like okay well ssh is disabled well then you just throw the exploit payload and enable the ssh port and now you can get back in and this isn't shared nobody's going to notice unless they're paying extremely close attention they also allow outbound connections by default the thing though to keep in mind is and the way we would deploy these in sort of the like a really good environment is the actual device itself had no default gateway um there would be a default gateway for the management network but what we would do is we would put them in a network we would plug them in trunk them put a bunch of vlands and then the device doesn't need a gateway to talk to to pass traffic back and forth they use this funky thing that they call auto last hop which essentially the device will record the layer to address that it received traffic from and then when it goes to respond or it's you know it's passing the load balance traffic back it'll say well i don't have a default gateway in this network i'm just going to send it to the layer to address that sent it to me so it's an interesting way of routing without actually needing a router if you will and then to be consistent they have three different names for their uh self IP ACLs um if you get on the device itself it's called a self allow list in the configuration or it's a self allow list when you're changing it when you look in the config file it's called an allow service in the net in the net self configuration and then if you go to the gooey it's called port lockdown um confused yet um back towards the web shell so the thing about these devices like i said they run sentos they only have python 2 i was going to do a whole bunch of cool demos with like impact it and a bunch of other things and i realized most of the fun hacking tools are written in python 3 now um the other thing about these devices is they've stripped out all of the stuff that would be useful for you so there's no compilers um they are sentos but they don't have the rpm command so you couldn't even like grab a python 3 rpm and just you know install it when you got on there so if you're going to take post exploitation tools with you you're going to need to build them and test them in a lab or in an f5 vm lab make sure that they work and then you can just drag them over to the device when you actually get on to it um they're mostly sentos on x8664 most of these devices run intel chips so it's not really that difficult to do this stuff it's just it takes some preparation and planning what they do have because of the way these devices are set up and because of some of the things that they need to be able to do is they have a full suite of ldap tools so this is i believe it's all the standard sentos stuff so you've got ldap tools you've got smb client um you've got netcat ironically um it's cron you're rc rc scripts you've got an ssh daemon um i think they might even have ftp and telnet on them still um not as a service just in the daemon itself or the the client itself so this brings me to a kind of fun part uh which is as i was building this talk um i was first i was like okay this is cool and then i don't know if anybody's going to grok this mandiant comes out with a report two weeks ago about this threat actor called unc35 24 which they believe is a russian associated state actor whose way of getting into networks was hacking into load balancers sand devices conference room cameras phone systems all of the devices that run for proprietary code where you cannot run edr it was almost like they copied my slide for their blog and i was like so honored um so if you want more information i highly recommend this article it's super fun um so i noticed as i'm reading this they're talking about their quiet exit backdoor which is this modified drop bare ssh daemon and this really funny part was i somebody sent me this all i was building the slides and i had just finished pocking out a crown entry to build a reverse ssh tunnel on reboot now again not a red team or probably not the most efficient way to do it because i had to you know generate an ssh shared key put the private key on my c2 server and do all this other sort of tom foolery but this worked i was like okay i just plopped this in there i rebooted the device and then it boots back up and it makes an ssh tunnel back to my c2 once again i have to log in with an actual username and password on the device but again you read teamers you this is you can do all of this stuff probably much more um elegantly than i can and then the other thing to meant to note is if you're going to drop a web shell i believe the web path is like user share dub dub dub something they mount the user file system read only so i've seen a lot of attempts when we were doing ir where there there's these commands trying to sort of echo a php file into the web directory that's not going to work the advanced actors have figured this out and we saw this in 2020 they would the first thing would send was a remount command to remount user is read write then they'd throw their web shell on there and then they put it back to read only so it doesn't look any it doesn't look like anything happen and that k number is the knowledge base article on f5's website that you can go and find out more about this there's also a bunch of links at the end that you'd maybe useful for you there's some fun things you can do with network device discovery on these things so one of the features that their customers remf i really love is this concept of cookie persistence i believe they actually have a patent on this thing but what it does is you say okay i want users to get a cookie that persists them to this specific server and that way you know the traffic will work and the concept too is if it fails over because the configuration is the same you'll you'll still be re-homed to the very same server because you have the cookie the device is oh i know what server to send you to so it's it's actually one of their cooler features the better part about this feature is you can decode these cookies and you can figure out what the back end sort of ip addressing scheme looks like because and it might be a little hard to read um you do a showdown search for big ip server that's what the cookies named by default and then you can actually look in the details of it and it tells you the pool name inside the device and then the the numeric strings or the ip address and then the port that it's running on and i think there's some other piece of detail that i it's been 10 years since i worked there so that's kind of a fun thing if you're you don't even have access to it yet you figure okay what does the back end server network look like um the other fun thing like i said these things are ssl tls um um concentrators so a lot of places will just not run a ssl on the back end so they'll do it securely on the front and then everything in the back is clear text now most banks don't do this they do have the ability to do re-encryption on the back end so you see like financial institutions and people that are super security aware will re-encrypt but a lot of people that are like i have an online commerce website i'm just going to ssl it in the front and then clear text it in the back yolo um so like i said be careful if you tcp dump but it is a full-fledged tcp dump if you start to figure out what server you're going for just craft a tcp dump string to only pull traffic for that specific system and then it's far less chance of you getting in trouble um they do remote authentication so they can authenticate against LDAP actor directory radius tack acts um this is all stuff you can see in their config files so um again tmsh list auth will show you whatever their remote authentication stuff is set up as um if you see an auth source of just an empty parents it means that it's only using local accounts on the device um if you see anything else it'll say you know type is actor directory it'll have the um sam like the the dn search path it'll have the sam account name um i couldn't figure out how to crack the passwords i think they are using salted um encryption when they they do these things but if you're a password cracker like go like go to town on it um then tmsh show off will give you users failed logins and accounts that have been locked out i have never seen anybody actually set up a lock out like a login limit on their local means the devices they just kind of leave it as the defaults and the default does not lock you out after a number of failed attempts and then one of the fun things about these is because they deploy them in pairs they actually have this concept of clustering so you can deploy three four five of these things in a cluster i don't know why you would um but you can use the exploit and you could actually like discover other devices on the network so let's say somebody forgets and leaves just one interface in a place where you can reach it and everything else is firewalled off well you can use this you know list cm device and it'll show you all of the other devices in the cluster and then you can go and theoretically laterally move um i'm going to redevelop this talk later in the year and probably try to basically have the device exploit the next device by using the exploit say okay send this command use the payload to get to the next device pull a shell back to me so it's just how how how evil are you um then the gooey runs on eight four four three for vm so if you're scanning four four three in a network scan eight four four three you might find some virtualized f5s and then i have showed enquiries that i like to throw out there i like to discover things on the internet when the vulnerability comes out you can get some of those there um valuable config items and this is where the beer thing comes in so this was actually one of the xbox alive of uh f5 devices when they decommissioned it um they were so happy to have it out of their network they threw a party and this turned into the world's most expensive beer tap you're looking at a 750 thousand dollar piece of networking hardware that they ran beer lines through and then encased in a block of ice uh not even joking and the beer was pretty good um so configuration items are all in slash config the big ip base conf is your base device and networking this big ip conf is your shared configuration the user config is here and big ip user you'll notice that this is actually the old 2020 payload pulling out the uh the user information which is kind of ugly and then this was the new one from 2022 which is cool because it's json so it actually comes out formatted and it looks beautiful and then tmsh list author will give you hashes the hashes are not in the config uh config file store this is where all the configuration ssl certs keys all the juicy stuff that these devices can have is stored in there uh config gtm uh we don't have time to go into the dns side of these things but if they're doing dns load balancing and you can get root on one of these you can imagine all the evil things you can do it's all in config gtm uh you can also do what i would prefer to tell you to do is do a tmsh save the ucs which is the config backup it's just a tar gz file that they taught they renamed it dot ucs save it download it rename to tgz unpack it you have every valuable file that the device has and you can go through it without as much risk of getting caught um so how to build a test lab um this is uh this is what i did so they give away virtual edition uh vms for free for all your major hypervisors right so we got kvm hyperv vmware uh they also give away vulnerable versions so the version that i was running was vulnerable to the 2020 cv it turns out it was also vulnerable of course to the 2022 cv but it's cool if you figure out what your what version it's on just download that version and now you can start messing around with it i thought you would delete vulnerable versions of code from your repositories but they don't um like i said this is how you test your toys uh and they want if you want to do load balancing like actually license it you need a 30-day demo license you can use a throwaway email to get one of these like they don't check to see if it's a valid like a like a legitimate company just go to like throw away mail or any of those sites you can you set up an account ask for registration keys they give you a set of three they're good for 30 days you can do this as many times as you want i think i generated 30 of them in the process of testing this lab um i use proxmox this screenshot is actually the config from my proxmox server it's very complicated and finicky to get this working if you have problems see me afterwards um you can also run these in clouds as your aws virtual licenses same process for a demo license except you also have to pay for cloud computing time up to you and then you can download isos to the same thing with the throwaway account so if you'd like to pull apart isos and look at all the stuff that's installed and see if there's old packages that you can exploit you can do that too uh don't buy them off ebay if you buy it off ebay you will not be able to use it until you have a valid support contract from f5 which costs thousands and thousands and thousands of dollars a year and if you're interested in doing any of this stuff i'm happy to help you with research find me later hit me up on twitter and with that your reference material is here i will be posting these slides to my github later on today um like i said come find me and um thank you very much and like i said i mentioned i was a dj this is me 20 years ago before the beard i promise i wasn't born with this thing um i have a sound cloud because it's what you do and thank you very much north sick all right uh thank you very interesting we'll take a few minutes break and after we'll uh please join us for the q and a let's see all right so we're back at it again so we're here to have a quick well quick 30 minutes a q and a um regarding apsec or any kind of related topic do we also have viki connected all right awesome well hi viki all right so how it's going to work is that will hi sorry there might be a slight delay so we'll be careful about that um so before we start i'm curious i know viki your talk was specifically about how to write better technical doc are you guys writing some technical documentation blogs or books or anything of of some sorts i'm not but i probably should start okay um yeah i i release from time to time blog posts and i also talked in the session about the threat metrics which was quite a significant publication of us um so yeah and uh the tips in the session were definitely helpful all right awesome so this is supposed to be a conversation so viki if you also have questions for people on prem or live with us please ask away if not what i'll do is i'll go through some of the popular question on slido um so we do have some all right this one is very generic okay so we're open to any tips and tricks but what kind of protection can we implement on database of the provider side to prevent an evil consumer from stealing data is using a different database an option it's to everyone it's fine if you don't have the answer perhaps it's a question two generic question for for our speaker today i mean i'm not a database guy but i have done a talk about um basically finding unsecured no-SQL databases out there and it seemed like the biggest problem was people forgot to put authentication on it or they forgot and they left it open to the internet um i don't know that you could switch from say like elastic to mongo i'm pretty sure that there's very different data structures but um basically security 101 is the only advice that i would give someone all right sounds good viki uh raise your hand if you have any additional uh comments to add on this question all right um follow up question can we restrict unknown ip addresses with acl in f five if there is indeed an acl in place how can we work our way around it again is that too generic no um so the f five is the only place you're going to be able to put an acl on that's that's realistic is the management side of the network um so you can either you know acl down the management ip or the self ip's um there's it's it's pretty it's pretty robust though you're not going to have an easy way of working your way around it um because even using the exploit you won't be able to view that acl list because it's going to just kick any request out that's not coming from a trusted network um that's actually how when we part of the when we secured them at microsoft was we had a microsoft has of course a very robust networking team we had a network a full uh you know private address space that was only for management and every device before it was even plugged into the network had acls applied so only that trusted network could get to it so yeah good luck all right so the next question is specifically for viki um any tips for people who aren't native english speaker on writing better technical content sure yeah that's a great question um i am not a native english speaker myself and i certainly struggled with writing and even speaking english right when i first moved to the united states and i think the most important tip that i have is to do intentional practices so what does that mean right um getting good at writing takes time and it's very very important to write a lot right your first few um pieces would probably suck but that's okay because you'll get gradually get better over time but another thing to remember when you're practicing writing is that it's not enough just to write a lot it's also really important to get um feedback about your writing right so um when i first moved to the united states the way that i got better at writing is that i had a writing mentor that would take my pieces and tell me how she would improve the piece um but i do understand that i think that's the best way of actually improve uh your writing um a lot in a short time frame but um that is not available to everyone right another way that you can get feedback from your writing is through grammar checkers so you can install one of those free grammar checking software and run your articles through that grammar checker see what kind of feedback that's giving you and try to model correct grammar or good sentence structures from the recommendation you get back from grammar checker and another thing you can do is that you can find similar articles online that you think are well written that talks about the same topic that you are talking about and compare what makes your writing better than yours and what can you improve in your own writing and model how they're structuring their articles or structuring their sentences and their word choices as well all right awesome tips and tricks maybe it can be useful for english speaker as well all right um let's do a question for you son you see pardon it seems that all cases in all cases we rely on Kubernetes to be the IDP to the cloud IDP that means trusting the configuration of the cloud providers configuration and key management question mark that's a well written question but uh not sure that i understood it but if it talks about the IDP it talks about IDP it does yeah all right so yeah i just mentioned it in the word in the session i didn't get into it but uh what i tried to say i mean i didn't get into the details but uh now our cloud providers have the option to trust uh um Kubernetes as an IDP so service accounts um from the cluster are trusted by the cloud provider and that's another way to authenticate your workloads your pods um with the cloud um you can read about um for example in azure it's called um it's called um workload identity federation i think and in the aws it's called rsa so you can read about the whole flow but generally it means that the cluster is trusted as an um identity provider all right thank you this is more a generic question that maybe has nothing to do with your specific talk but since we're here talking about application security um you all know that developer it's hard for them to take security seriously um does anyone is experienced and maybe tips and tricks on how to or has experience on how teaching developer uh to know when their stuff is broken uh well i can say that um well i work in a like on a product group at microsoft and it's really important to um to be aware that um as a developer you should i mean i think we do it quite well at microsoft is to really be with security in mind um and it could be with education just to show examples of how simple mistakes at code become uh vulnerabilities or or misconfigurations and um so i think that the main thing is that you need to educate the devs to be with security in mind um it's a generic um answer um but uh i think it's really important and that's the first step and how do you do that with bribes and cookies well i think that first show examples and to show i mean um to show how sometimes simple simple things it looks like just little bugs um can cause to a serious vulnerability as to a serious security issue um i think it's helpful and um i think it's another thing is the organizational culture i mean to to to be aware of the security so at microsoft the big organization it's obviously it's obviously a thing so everyone is aware of the security but maybe in smaller um dev groups it's different and it's super important um so i think that's another thing absolutely ma nade i feel like you have something to say about this um so uh in my experience and this is this is not from the sort of developer side but i have done a i did another talk about the last f5 vulnerability in 2020 um the interesting takeaway from that was the the 2020 cv e the path traversal one it was almost the exact same poc as a citrix vulnerability from six months prior against their load balancing devices both of those used a technique that orange sigh had talked about a black hat in 2018 um so the advice that i would give is especially when you're using open source software um you need to be paying attention to the ecosystem your your developers and your security teams need to be looking at what the current attack surface is don't send them a black hat just so they can go to parties and drink they need to be going and looking at these talks and saying hey do we use these components in our product if we do you know like quite literally oranges his slides had the same poc dot dot semicolon forward slash that was used in both those attacks so they had 18 months to look at their code and say hey is this something that would affect us had they done that they would have realized yes it did so by keeping abreast of the ecosystem and also looking at your competitors and seeing what types of vulnerabilities affect them um you know in the load balancing world like i said they're very similar products so had it and had someone from f5 said hey citrix just got whacked with this really bad vulnerability we do almost the same thing we should go take a look um you need to be cognizant of what's going on around you and not just head down you know writing new shiny features like security is boring we get it but new shiny is what's going to get you in trouble all right thanks so i'll relate a question to viki viki do you have any tips and tricks on how to on board dev into the security journey sure i think i can share one of my experiences that's sort of like my aha moment in security right before i got into security i was actually a developer and i wrote lots of lots of code and because i was a web developer um a lot of the vulnerabilities that i studied as a security person actually relates to the code that i wrote for my development job right so one of the great aha moments i had about security and how to teach developer security is that i went back to one of the projects i made when i was developer and i just started to find like all of these different ways to exploit it right and that really showed me what the experience should be like when we're teaching developer security it should be about contact right we should make it relevant to their work we should make it understand this is exactly why this is bad and this is what the attacker can do with your customers with your clients and with your data i think grounding the security education in that sort of context is very important into making people actually care absolutely thank you for that viki let's jump into a different topic um i believe this question's for nate for load balancers would a honeypot based on your lab setup catch anything interesting you think oh absolutely um i believe that's kevin bowmont who goes by gossy the dog on twitter set up a f5 honeypot um shortly after this vulnerability came out um i know that people as soon as these as soon as these vulnerabilities have come out different security groups have set up honeypots just to see what sorts of exploit payloads are coming in um so i guess you in theory could set one up on your own internal network to sort of like maybe try to you know um confuse an attacker however if i'm an attacker if i'm playing around in your network the first thing i'm going to do is see is this device actually interesting and if i find it that it's just sitting there with no load balance configuration or it's not passing any traffic um i'm going to either assume okay this is just a lab box or maybe this is a honeypot um so yes it could be it could work um i think it's more useful for sort of the the internet spray of attack payloads and sort of collecting and seeing what the ttps are you know the iocs of what's being dropped all right awesome um question regarding kubernetes um for lateral movement why it moves sorry weren't where pad security policies config mentioned as it would allow escalating the not even faster maybe this is a trick question yeah for kubernetes lateral movement so for you why weren't pods security policies config mentioned as security policies config mentioned did you mention that in your talk yeah yeah as it would allow escalating the not even faster all right the question is which configurations of the podge can allow us to move to the node fast we can take the question however we want and make it your home i can select another one if you want no no worries i'm not sure that i understood but if the quest if the question is about pod configurations perhaps let's take it this way yeah okay um so i'm not sure that i'm answering the right question but um regarding pod configurations that may lead to lateral movement so we talked about several in the talk i mean we mentioned it really briefly but uh privilege container first uh have full access to the underlying node we also talk about uh mounting files um so if we have a pod with the configuration of mounting file into it um so it also may lead to lateral movement um then there is the whole topic of networking so for example you can specify that pod has um um has access to the host networking so the bunch of configurations of pods that may lead to lateral movements if it was the question um and if not so um you can ask me again i'll answer all right if not they can hit you up on twitter and see the real answer for you all right um for nate another question for you um yeah what do you think of asking for software bill of material that lists all their dependencies and their version on those proprietary devices um i think it's a good idea and at least uh in terms of f5 you can somewhat figure it out there's one of the the reference links i had in my slides um they do list what operating system versions they use for the management side of things um so you could you know take a look and say what is sentos 7.3 running what library does it have um those operating systems are not updated the way that we would update our linux server so i think it's during like major revs like when they go from 11 to 12 or 12 to 13 they'll update to a degree um but your best i mean you're not going to get much of a software bill of materials from them as far as i know unless of course you're a big enough customer and you pay them enough money then that was one of the things that i would have done which was to say okay let me let me pull this for you um but yeah and that's that's only going to be the linux side of things if you start asking about like supply chains of where their firmware is coming from and the the code that's running their asics or their fpgas um you're going to have a a non-trivial time getting that out of them all right so viki maybe a question that it's for you but also for from one of the speaker that could not join us today so it's kind of a in between or a hybrid question um what do you think about web hooks and would it be a good target for bug bounties program or any i don't know if you written any blogs or anything about it in your experience so i've actually written about web hooks before and i think they can potentially be a good target for bug bounties but in reality i haven't really uh hunted that much in bug bounty programs um for web hook related bugs so i don't really know the answer to that i think potentially i don't really know how prevalent it is though do we have any strong opinion all right so i'm reading the question that are remaining they're quite similar to or uncomprehensive so i won't go through i won't go give you any like a weird question anymore all right so thank you guys so much uh please ask them your question privately if you do hit them on twitter or yeah we're just here to help so please feel free to reach out merci tout le monde hey welcome back um so now we're kicking the the last afternoon of the conference with the cryptography block uh your moderator has been president of north sec challenges on your conference organizer everything pretty much uh so yeah so he has 15 years of experience he loves cryptography uh he was working at delve that got acquired by secure works uh you might know him for his smart uh smart card challenges uh i remind that reminds me that my first montryak was the smart card challenges and i was like oh my god i'm not smart enough for for security uh but yeah i stick around and uh you know uh whatever happens happens um so yeah so let's give it up for pierre david oriole thank you it's uh it's a it's a trick there's not a lot of smart things about smart cards it's just overly complex for no good reason to be honest and he agrees um so welcome to the uh cryptography block if you thought this was about any other use of the term crypto even though there's mushrooms everywhere i'm sorry for you it's really about cryptography so y'all i'm here to present yolan yolan romaye he's a cryptographer worked at uh kudiski and now uh works at a startup where uh today he's going to talk about uh randomness uh it's going to be a very interesting talk he's a previous north sex speaker he also spoke at black hat besides uh other crypto villages uh and uh so i'm really pleased that he could come again to montreal i think it was three years ago uh that you had your your talk here uh and so i'm very pleased to introduce yolan so please give it up for uh yolan thank you everyone yeah thank you hello everyone so yeah i'm super happy to be back on stage after all these years without conferences it's super nice to be able to present again and uh so yeah so um as pure david said uh i'm currently a software engineer working on randomness i used to be an applied cryptographer looking at other software engineers code and avian nightmare about what i saw you know so i'm here to make it sure to make sure that you want to do the same mistakes when it comes to randomness as what i saw in the past and i'm also super happy to um play the ctf tomorrow i well tonight already and uh yeah let's start so today we'll discuss about what is randomness and its different flavors uh next we'll go uh we'll talk about why do we even need randomness uh when do we use it why and so on um we'll see what are the problems with randomness and why it's hard and finally we'll see how we do good randomness in practice and what remains to be done so what is randomness if you look up in the dictionary that's a quality of being random great they go on and refine a bit saying so that's a quality of being random happening done or chosen by chance rather than according to a plan that's not exactly how we see randomness in computer science right so i found another dictionary which has a bit of a better definition so randomness is the quality or state of lacking a pattern and here there is a very important word it's it says unpredictability and we'll see why it's very important later on so here i've picked a few random strings binary strings um 37 bits we can tell me if the first one is random doesn't look random right so how about the second one is it random probably um the third one doesn't look random neither right so probably not random the first one looks random but if you look at the hexadecimal representation it doesn't look random anymore and the last one also definitely doesn't look random so what that means is that even though all of these 37 bits random strings have the same probability of being grown at random we have some kind of intuition of what's random and what's not right so we'll see what that intuition actually means right now and when we talk about randomness we have a way to formalize it a bit we use colmagorov complexity to look at randomness and say oh that looks random or oh that doesn't look random and colmagorov complexity of a string is basically a way to see if you can compress it you know how much can you compress the old one binary string well a lot because it's only once so you just say oh it's 37 times one and you've compressed it on the other hand if you've got a truly random value it's way more difficult to compress in a general manner so that's the intuition we have about randomness and it's going to yeah that's also why we want about randomness right being able to not easily guess what's next and so on and we'll see what unpredictability and bias are later on so next is the you know my talk is about public verifiable distributed randomness and you might be asking yourself what are all those keywords right so public randomness is basically just a value that is random but that is that is meant to be public like think of lotteries if you you know buy a ticket you choose your numbers at some point they will draw the winning tickets by drawing a random value and that random value is public anybody can look it up and see oh that's the winning number for today's lottery and that's really what public randomness is about it's something you want everybody to be able to access and use for their own needs whatever it is a bit for I don't know like a lottery game like if you want to have some kind of gambling and so on and next we'll make the difference between public and secret randomness because public randomness is cool but I guess you've all ub keys ssh keys pgp keys on your computers right and these are secret keys that are not meant to be public so if you take a public value a public random value and use that value to produce your secret key that's not going to work well so we also have the notion of secret randomness that is meant to stay secret and that's typically the one we'll use for cryptography stuff like generating key material nonsense or number that are meant to be used only once uh on so on so it's super important to keep that in mind do not never use public randomness to generate secret keys seems obvious right so next public randomness is cool but oh do you know it's actually random right we've seen earlier it's very difficult to even intuition of what's random and what's not and even though we have one we might have some doubts about you know like the honesty of the person in front of us like if you create a tumblr game and you give tickets to everybody and then one of your good friends win the tumblr people might be like hey you cheated so that's not something you typically want when you do something public like on a blockchain typically you have smart contracts which need random values or in the luxury ecosystem on for other use cases as well so what we need next is a way to verify the randomness and verifiable randomness is just that it's a run it's a public random value that's that you can verify somehow um that's typically done using hashes signatures or complex cryptography and uh we'll touch on the ways to do it uh when we'll see the concrete instantiation uh in the in practice part of my talk and finally we got the distributed keyword uh in the title and distributed randomness is just like what you think it is when you hear it it's a random value that was achieved like that was created by a distributed system and that distributed system needs to achieve consensus and the random value because otherwise it's not going to be a good distributed system if each node has different you know values at the same time in point and that's very difficult to do because you want your randomness to be unpredictable but at the same time you want all of your nodes in your network to be able to generate the same value at the same moment so how do you make it so that it's you know unpredictable but still generated on time by all nodes and that's again a very difficult task blockchain system may struggle with that if you look at ethereum for example smart contracts on ethereum have a very hard time trying to generate random values and if you look at other distributed systems usually what you'll find is that you have some kind of trusted third party providing the randomness and that's not too great because you need to trust somebody and decentralize decentralization and distributed system usually try to decentralize trust you know so we don't want to trust a single third party about anything even our random values so that's going to be a fourth section but why do we need randomness while I spoke about lotteries and gambling already these are like abuse things other things you could think of is like jury election or sortation and these are the kind of things where you really like need proper public randomness probably because you wanted to be publicly auditable and so you wanted to also be verifiable as well next you obviously have all the cryptographic protocols if you connect to a website nowadays your computer is probably generating between two and five random values just for the initial connection you know like generating ephemeral keys noncease and that's a lot of secret randomness obviously next we have the abuse case of statistics and control trials in medicine if you can you know if you have a bias distribution when you pick your sample the results of your study won't be really good and it won't be yeah what you wanted to be so you need good randomness there as well without any bias and finally we use it a lot in software in general like if you do fuzzing chaos monkey and so on you also want to take random values but these values can be generated by some that by a PRNG absurd or random number generator that's going to be seeded in a way that's uh repeatable so you it can be deterministic it doesn't need to be secret it doesn't need to be public but it still needs to be uniformly um distributed in the wow in the values you're interested in so next we'll look into what are the problems we have with randomness because randomness seems easy right you just take a random value and you're done so why is the problem and i've talked about this a lot already but randomness is difficult because you want it to be unpredictable and bias resistant um i mean being unpredictable it kind of obvious if you can predict the next lottery ticket you can win it or if you can predict the loot you'll get in the game you you can cheat and so on so it makes sense right but the bias resistant thing is a bit less obvious and actually for cryptographic uh algorithms it's super important because the most used signature scheme nowadays is probably ecdsa it's used for tls it's used uh on bitcoin ethereum and a lot of new systems nowadays are running using elliptic curve cryptography on signature schemes such as ecdsa are super sensitive to bias uh you will typically get to take um at random a 256 bits value well if you have just one bit that is bias or three bits it's already a potential vulnerability that could leak your private key so leaking the private key is the most catastrophic thing that can happen for a cryptographic system you really don't want that to happen so it's super important to have really unbiased random values for such cryptographic schemes and i guess a lot of you have already developed something where you needed a random number right so how do you do that if you want a number between zero and 255 that's easy right you take a random byte you can call your black device you you run them to get uh random byte out of your machine entropy pool and you get a value between zero and 255 now it gets trickier if you want a value between zero and 106 right how do you do that well the typical way people will do that is taking a random byte and then reducing it modulo the values i want to be the limit right so here if i reduce it modulo 107 i'm happy because every numbers up to 106 will be will stay the same and then 107 will become zero 108 will become one everything is mapped you know onto the range you want to to query from but that's actually an issue because you don't have a multiple of 107 amongst the 256 possibilities you can get from a random byte so what you've just done here is introducing a modulo by us because for the first 107 106 uh values that's fine the next 106 values it's fine again but once you reach 214 up to 255 these are going to be mapped towards the first 42 first values and so you get bias randomness and it's super easy to get bias randomness because you just picked a random value which was good you reduced it modulo the value you wanted to reduce it to and suddenly it's not a good random value anymore and this is leaking your private key already if you're signing stuff with a value that was generated in that way and so the best way to avoid such bias is obviously to not do it yourself and rely on your cryptographic library python has a secret module signed since 3.6 go and rest a very good random generator functions but in general if you need to do it yourself what you want to do is rely on so-called rejection sampling where you will pick a value at random see if it's in the range you want if it is then you're fine if not you reject it and you pick a new one against at random and that's going to be uniformly distributed and it's not going to be biased and i've got the cool link to a guide to modulo bias and how to avoid it it's a blog post i wrote like two three years ago and if you want to check it out i recommend you read it so now we've seen this cool different kind of randomness let's see oh we can solve the issue of public verifiable distributed randomness right so if we look a bit at the history of public randomness we can see that michael rabbin already proposed the use of random beacons and that's where the beacon word comes from in 1993 to secure transactions well that was before bitcoin and before blockchain so these transactions are not the same as the transaction we might be looking at nowadays but the the base idea was the same as what we have now and and what he says in his paper is that it is impossible without a trusted third party and that's something we are actually going to challenge in a bit next we can see in 1998 a website such as random.org that offers a true random number generator anybody can use and they are getting their randomness from the atmospheric noise physical process good entropy everybody's happy right well do you verify it was actually taken from atmospheric noise you cannot and so you have to trust them and usually you don't like trusting random people on the internet right so next we have NIST which comes in 2011 and says the internet needs a public verifiable trusted randomness beacon system and it's funny because NIST is not the most trusted party out there right but they went ahead and they launched their first NIST beacon in 2013 and the NIST beacon is based on a secure hardware so you have to trust the secure hardware NIST is using to produce the proper true randomness from quantum entanglements which is a cool way of producing randomness and then they publish it online with a signature you can verify the signature on everything that's that's public verifiable randomness except it's generated by a single trusted third party which is not something we want right so when we look at previous attempts to generate public randomness we can see none of them are really great there was a paper about using bitcoin to try and do it because why not no promising but bitcoin is super slow and it relies on proof of work which is not something we really like nowadays right so next in 2016 another paper came out which had a super cool technique to do distributed randomness in a publicly verifiable way so that sounds like the the way to go right except it was super slow and it was using snore signatures which were yeah it was doing a bunch of really nice thing but it was not so efficient so the question we had was can we do it in a simpler and faster way and that's how we came up with the answer that yes we can and so the internet needed a randomness service that is just like the NTP servers you use to get the time on your device right that is public free and available and so we came up with the notion of D run which stands for distributed randomness which is highly available decentralized and publicly verifiable source of randomness and we'll see how that works so D run is an open source software you can download it on github you can check it you can review it it was even audited so so far so good next it is really meant to be run as a network of nodes so you will have multiple nodes running the same software I mean you could reimplement it as well there is a spec but running the D run software spec and then what it does is basically it relies on distributed key generation which is a cool way of using verifiable secret sharing and threshold cryptography to generate a key that no single node ever sees or gets in memory but that every node in the network can agree is the right key and then it will use BLS so Bernaline Shasham signature scheme on the BLS 12381 pairing curve to do signatures and the funny thing with BLS signatures is that you can take any number of BLS signatures and you can aggregate them into a single signature and so each node in the network is going to sign a value and that signed value means nothing until you take them together aggregate them and get the aggregate signature which can be verified to be coming from that group and the nice thing is you only need a threshold of nodes so if you have 20 nodes you could say okay my threshold is 10 and you generate during the distributed key generation a public key that will allow any 10 nodes to generate a valid signature for the group so those are called group signatures and we use the signature as a way to produce randomness because a good signature cannot be distinguished from a random value so that's a rule for cryptographic signatures if you have a good signature scheme you cannot distinguish a signature from a random value so we take the group signature from the group of nodes and that gives us a random value and that random value is generated in a decentralized way is unpredictable because it's indistinguishable from random it's resistant to bias and you can verify it was generated by that group of nodes since it's a signature so yay we did it right and we actually did it so we launched in 2019 the league of entropy which was a team of people who decided to run d-rand under servers and you can try it out now on your browser you just or using curl whatever you can just see it running for two or three years now and the league of entropy was actually founded by cloudflare kudoski security protocol labs a bunch of other companies which are running you know internet stuff and it's really meant to provide you with public verifiable randomness which is unbiased which is unpredictable and that's highly available and it's been running like that with these 16 members with 23 nodes on a threshold of 12 so it means half of the nodes can get offline and you would still get proper randomness produced and it's been running like that oh sorry since 2019 which is pretty cool because it means we we did it right and a nice thing is also cloudflare has a set of lava lamps in their offices they could use as a true random generator to bring fresh entropy into the network so we get all the benefits from on one side we get a set of nodes where we don't need to trust a single node on the other side we get some nodes which are providing fresh true random values like the university of chili is also part of the network and they use the data from like seismic events in chili to produce the randomness and so on so that's that's pretty nice and the nice thing also with d-run is that it's supporting so-called multi-protocol support since very recently we launched last week actually and that means we can expand the network to do more things that we couldn't before like we could have a post quantum algorithms running we could have a faster network because the current tick is like every 30 seconds so we could say oh it's ongoing and the other nice thing about d-run is also that it used to be chained randomness because we were looking at blockchain tech and all they did thing and we decided it was pretty cool to be able to you know chain all the beacons together and what we recently changed about d-run is that instead of producing rounds that are linked to the previous round which means it's super difficult to verify because you need a stateful system and look at the previous round and it's a bit annoying you know we decided we could just get rid of the chains and now we have like one round which is signed and the next round which is signed and they are independent so you don't need the state anymore and why am I talking about unchain randomness you might be asking is because it's pretty interesting because it enabled us to do super cool things such as time lock encryption and that's something that's upcoming we're currently developing it but it basically says you can encrypt something toward the futures so let's say I want to encrypt something which cannot be decrypted until I say August I could use the trust assumption that we gave in the league of entropy to produce proper randomness on time every 30 seconds until August and thanks to the pairings and all the fun crypto we use behind the scene we can encrypt data that you can decrypt once the network will produce a signature so we are kind of using a signature as a secret key yeah you heard me but it actually works and nobody can decrypt the data until the given time has arrived as long as the network still runs obviously and this is pretty cool because it's something which was first it was an idea in the cyberpunk mailing list that was submitted by team may which is like the founder of this cyberpunk movement and the like crypto anarchists and that has been unsolved for 30 years and now we're bringing it live soon and yeah I'm looking forward to it so obviously it's cool to have a public randomness service but we need people to use it so I'm here to tell you it exists we did it we solved the issue of public verifiable distributed randomness it's highly available it's been running for three years without a single description so yeah if you have any kind of cool project where you need to do I don't know a lottery or you need public randomness please use it and I'm here to also answer your questions and help you with that if you if you need and finally I know I'm talking to a lot of security professionals so you could go ahead and say oh we want to build our own public network which is running next to yours that's cool do it please by any means but you could also say hey I want to join the cool league of entropy thing because I got the server sitting in my house and I'm not using it so please do as well we were looking for new members it's not taking too much time to set up and then it runs so yeah and with that I'm done so thank you very much for listening about randomness and public randomness and you can send the questions on Slido all right super thanks everyone so you can send some questions on Slido you might have been given the URL before I don't have it handy unfortunately I think it's on the website send some questions thanks a lot you know I guess this is maybe something we should be looking into at Nordsek seeding the randomness with incorrect flags being submitted over time or types of drinks at the bar that are being chosen so we'll take a short break probably five minutes I guess and then we'll be back for the the next talk thanks everyone okay all right so my next speaker here is Christian Paquin he's a principal program manager of Microsoft research in the security and crypto team cryptography team for the last 20 years he's been living at the edge of academic research industry in a you know focus on privacy preserving sorry identity technologies notably you prove but he recently joined the COVID response effort and helped with the design of the smart health card framework contributed to the specifications and co-implementation of the dev tools to validate SHC implementation so you know the Vaxi code app that some of you might have used makes use of this he also very passionate in post quantum crypto and zero knowledge proof based in DC but of course repeat speaker for Nordsek likes to come back to his native Montreal so please join me in welcoming Christian for the stage thank you okay thank you everyone and I'm happy to be back at Nordsek especially on a beautiful day like today was awesome to go have lunch outside in in super sunny old port Montreal it's the best time of the year to visit as I tell all my my American colleagues now um so uh yeah I I'm from around here I've been studied long time ago uh quantum cryptography at the University of Montreal right here and after that I joined the industry I did uh yeah most my career doing cryptographic development I'm not MSR working on all sorts of cool advanced crypto technologies trying to bring them to market and see what what what can be the future of security a lot of it deals with uh premise enhancing identity technologies zero knowledge proofs a lot of the focus last year the last few years have been in post quantum cryptography we're avidly waiting for the NIST decision for what's going to be the next post quantum algorithm if NIST makes the announcement during my talk please just interrupt me and let me know we've been waiting on that news but like most of the world in the last uh two years there's been some interruptions because of COVID and joined an effort to help with the smart health card framework which I'm here to talk about so first what's what's that what's a smart health card so I hope the organizers did not invite me because I thought it was smart cards especially we heard that our host here uh is interested in smart smart cards uh well yeah he has nothing to do with that that's a an acronym or a background from the medical community it stands for I have to read it because I don't know it by heart this is a substitutable medical application reusable technology it's a set of apis in the healthcare industry to to to avoid vendors lock-in and whatnot so it's for health cards to be able to be able to present a medical information in in a convenient way so what it means for uh the COVID so in in the US uh nationwide people add these little paper cards here in Canada the provinces at beginning before the QR codes came in everybody had a different solution either a little sticker with the information either a pdf you would download which would contain use your name date of birth your vaccination history and that's what you could use to prove to various people uh that you've been vaccinated so of course that's very susceptible to to fraud and and forgery modifications so the question becomes how do you create a a digital version that can prove authenticity and cannot be modified and so that's what a smart health card is um so the QR code first it's not a a URL like it typically is when you scan these with your phone it brings you to a website these QR codes actually contain all the information and that's all you need you don't need to a call back somewhere to verify the information of course most of you here in Quebec you you might have not known that you've been using the standard here it's been branded as Vaxi code by by the government so but your Vaxi code is actually a smart health card so if you want to learn more about what's contained there then I guess that's a good talk for you before I delve into the details of of the framework how it came to be in some of the security properties I'm just going to give a description of how this QR code is created to just have a clear representation in your in your mind of what's going on so the the paper information named date of birth vaccination history it's transformed into what's called a fire bundle fire is another health care standard it's called I have to read it again fast health interoperability resources so that's how the the medical EHR vendors electronic health record vendors they they talk through fire protocols so it's just a JSON structure with if you can zoom in you see the the elated data is what's on on the paper that gets then encoded into a jason web token payload that's as some metadata about who created the smart health cards some some other metadata the fire bundles in there and then this is signed into a jason web signature but because the target is a small QR code with very limited payload size we have to make an effort to make it small so it's minimized compressed and then it's base 64 URL then it is signed using the jason web signature format a standard some header that's added the signature is added there and then anyone who has this data is able to verify because they can look up the public key of the of the issuer that's in the header and and verify the signature this is then transformed into a numeric qr encoding if you know anything about qr code it's very standard if you didn't know anything about that like i did a year ago your plus ago then you go read that then it's just a normal way to do that to transform any data into a cure code and voila you have your your final qr image of course there's there's a lot of details surrounding what's what's happening there so that's where all all this is defined and specified in the smart health cards framework so the goal of of this framework i've highlighted here is to provide a way to to provide authenticated and immutable medical facts so it's not to act as a an identity document it's not meant to be a green check mark saying yes i can go into this this thing it's policies around the world policies even across time week to week change so the medical community wanted to provide a way just here's the medical facts these facts happen and then some other part of the of the of the process needs to make decisions if that's a a an okay condition to do activity x or whatever so as i said it's not an identity document it only as a name date of birth and it needs to be matched into some other form of identification to make sure it belongs to the right person and all these this minimal set of data has been highly debated in in the framework community to see is that not enough data too much data and the level risk about the usage of these things and whatever level of fraud right somebody with a matching name and date of birth could use your QR codes okay acceptable that's fine all the specifications are open and the work started before the pandemic in the medical industry of course it got accelerated and and covered became the focus of the use case and the success of this framework versus other approaches there have been a lot of competing proposals in the US there have been some other approaches selected in Europe for example they have the digital COVID certificate the DCC thing which is very similar to the smart health cards just different set of decisions they came up with a slightly different format India has their own solution and other parts of the world as well but this one you can find everything you want to know about that the smart health dot cards my team actually we developed this this portal demo partals that smart health dot cards it's it allows you if you want to go scan your own QR code and see all the details of it as I've shown the previous slide you you can do that and a part of the success of the framework is its large implementation base so it's been picked up by by Apple and Google so they in your phone it there they support it net natively there's a lot of specific apps in different jurisdictions like Vaxi code here New York they call it the Excelsior pass and Louisiana also had their own wallet a lot of states in the US chose to just use the common apps without their own in province or in state app um okay let's leave it at that for now here just to give you an idea of the adoption of the smart health card framework you can see it's it's mostly a North American or Canada and US standard with the deployments but there's some other parts of the world that have adopted it and are more and more okay so now what's all these things are issued so first to become a smart health card issuer you just set up a just create a key pair very conventional cryptography and well in Canada it's mostly the provinces and health ministries that do that in the US it's a bit more complicated there's no central health authority that oversees everything and if they do they don't have the mandate to to issue a certificate vaccination certificates to everybody so it's mostly industry-based so you will have some state registries you're going to have some big pharmacies like Walgreens or CVS you're going to have your hospitals they're going to be issuers so there's a wide variety of parties so they can all self-host and create their own key pair and when a user given a specific interaction with that party can prove that well they got their vaccination then they can get this QR code it can be held on any medium so it could be in a specific app it could be on the Apple wallet or the Google wallet it could be printed on paper makes no difference and then later when you go and present that to a party that has a verifier you can they can just download the key that's identified in the QR code and validate the information so in fact what that's one value of using a framework that's common and that's standard is that when I came here during the pandemic visiting I had my Virginia QR code and at the beginning the Vaxi code would not validate it because it did not recognize external keys but at some point it did so I was super happy that I could go to restaurant just scan my my US QR code and it was validated by the app just because it was based on a standard and not a one-off solution and vice versa so my family when they came to visit in the US also they're they're they're external because you have two versions here the one that's made for travel is is a confirmed smart health card so we can validate it anywhere in the world that supports the standard so now as I mentioned anybody can just start issuing smart health smart health cards very easy to to self set up there's a lot of software for it of course not everybody should be trusted to be a valid smart health card issuers so the question becomes okay how do you create that list in in security and cryptography we have this notion of PKI right public infrastructures that's very convenient that's the most common mechanism to establish trust is a trusted authority and it can delegate trust in different environments which in Canada was very simple because everything here that the health care is provided by by the provinces so here each province became the authority about issuing these these credentials in uh in in the US it was a mismatch of different things as I said before so there was a need to um to create in PKI we would call that a PKD which is a public key directory um and this organization's the VCI which has been kind of renamed with a broader um with a broader scope to verifiable clinical information their goal is not only to oversee the smart health card specification but also to decide who is a trusted issuer so there's a a set to make sure that there are verified health care organizations that are actually and they have COVID vaccines and then once they've been vetted and audited and verified then they can be part of this VCI trusted directory in fact all the Canadian provinces are part of that directory uh the directory is public if you go to VCI.org you can see all the information you can verify there in fact we were part of our team wrote some auditing software for that directory to make sure that everyone there is online that their key sets are cryptographically cryptographically correct and um that all the the information is is uh secure using the right TLS config and all these things okay so um so that's the kind of overview of this kind of smart health cards I hope you have a clearer idea now what's in these QR codes uh I'll now discuss a few uh just uh a few few more security aspects because we're here at Nordsec um one thing that that became very apparent or soon is that we there was a need for a revocation feature for the smart health cards you know normal certificates can can be revoked um and in the smart health cards there's at the beginning of the framework because of the rapidity at which the standard came to be and uh because of the nature of the information which is are just clinical facts so they should not you know change or you don't lose access to these facts so there's I mean the security practitioners among this group were not able to to get a revocation feature day one in in um in the specification but of course as as it was easy to predict there was some reported fraud and not really on the on the on the cryptography of the system but mostly on on the the human factor here I've seen some headlines in in Quebec about either uh nurses or medical practitioners getting bribed to get invalid entry in the vaccination registry or you could have fake the paper trail and coming from cross jurisdiction to say that you had your vaccine then you get issued a valid um credential that can be a layer proven false by by by the police so we had to develop this revocation mechanism that was added to the specification and it came a bit later than then after the first wave of QR codes were issued so there are two mechanisms to revoke these cards one that's forward looking where these cards can now have a revocation ID built in that can be uh listed on a reduce the acronym CRL for card revocation list here and there's a legacy one that derives a dynamic revocation ID based on the on the content of the the fire payload there so let's just do a hash of a few fields and these can also be time stamped in the certificate list the revocation list so that if you're you know a naughty user who got fake your paper trail and then got convinced to go get a a vaccine and therefore a valid card then if you're get your your revocation ID a card with the same revocation ID later then you you can be revoked up to a certain point and then later your card would be valid so that's uh one thing that that emerged uh after the initial launch of the framework the other work that I've hinted to a bit earlier was the VCI directory auditing and snapshotting so the the I mean the cryptography and all the security of the card itself is not too complicated it's pretty standard uh but the uh the devil is in the details and then big part of the making sure of the the security hygiene of the system is to making sure that these issuers are not um uh they are trusted right so if you start seeing weird issuers there there's going to be a lack of trust in the system and the VCI got a lot of proposals to be joined like hey I'm a clinic here and I'd like to start issuing smart health cards so there's been a big list of of of proposed issuers that just been rejected because they didn't mean the the minimal requirement of what's a trusted issuer so um yeah so our team we've been involved in the uh creating of two things uh one is uh the audit script that I mentioned that just make sure that once you pass the test to get into the directory then you're still okay uh day after day and not just your security just goes crazy or you go offline or you disappear then uh we we keep track of that uh the other thing that we've enabled also is to create a snapshot of the directory including all the keys because the flow of of if you remember the the diagram is that when you verify this QR code so if you're the quibac app and you verify quibac QR codes uh you know every five seconds it's fine you have the public key but if you're at a super ball uh sports stadium with visitors from all around uh the continent then you might need to get different keys and there's a lot of fetching keys all over the place so you're able to download this offline version of the directory that that the VCI provides and you're you're able to uh to validate the QR codes uh in an offline manner which yeah for big when there's a lot of of users and you don't want to have a lot of bandwidth it could be like a transit station New York metro station for example that would be useful um okay I think that's all I want to say about that um I let's see how am I on time okay that's good so I wanted to present the work that's been done on smart health cards but I wanted to reserve some time to talk about the future of digital identity so I've been in this field for a while and we've been pushing this idea of user-centric identity documents uh for users to be able to prove any identity facts about themselves to whichever uh stakeholder it could be online it could be in person and I guess not a QR code that people had to present forever uh in the last year then that's kind of unlocked the the imagination there and and I'll to explain some of these scenarios and make them very concrete so as a immediate next step um we prototyped a system that's similar to the smart health cards but that instead of having a medical payload it could have any claims there so any JSON web token payload or data any attributes uh you can encode them in these QR codes and you're able to uh present them and verify them in a similar manner so um okay let's but one important aspect of that um is the ability to add privacy on top of of the of the framework for smart health card that's something that's been debated a lot okay do are you disclosing too much information every time you're presenting it so when you go and board an airplane you disclose your name date of birth and along with all this information already that they already know about you the and way more data that you have to present well when you go to see a movie you typically wouldn't want to or need to present a date of birth and and a name even so um for a general uh identity document then you don't want to force always presenting everything about yourself and the main identity document that people have in in North America as a driver's license that what you show to to present uh some identity attributes about yourself so to disclaim QR framework we've added the ability to to present a subset of these things so that's it's a simple mechanism versus more advanced cryptographic ones using zero knowledge proofs that you could prove properties of yourself like I have a date of birth and I can prove I'm over 21 but uh that's a bit more complicated what's very easy is just the ability to take the equivalent of a black marker pen on your driver's license and just hide the data you don't want to show and present the rest so we call that subset claim disclosure and the way it's achieved is that instead of the issuer encoding these claimed data these attributes directly they're ashed and salted so that uh for brute force resistance and that's what gets encoded in in the the QR code and to disclose this value you have to show to the verifier uh this these digest along with the data that was used to generate these digest so it's it's as if you're presenting this um this uh driver's license with little puzzle pieces cut off and you can see you're seeing uh you don't know what the pieces I removed but if I take a piece I can put it back and you see that it matches perfectly and that's the only value that could have been there so just as an example um I have a little demo but I think my slides might be more illustrative so I'll just start with these so imagine I have this data that I want to encode in the QR code so I have adjacent web tokens there's an issuer the example.org issuer there's an expiry date and these claims on the right are the ones that I want to be able to selectively disclose so it's my name my real date of birth I'm super young and then these are transformed by the issuer and there are there's a random salt which is just a random value and uh along with this with the claim attributes and then these get ash using the salt and the claim value and they get encoded in the jason web signature payload then using the mechanism I've explained before that these gets transformed into adjacent web signature they get get signed and then turn into a QR code now that I have that if if it's on paper oh sorry I forget to I forget to mention the last part on the the little green part of this gws it's a it's an appendix so it's extra data and it's actually the claimed data that would allow a verifier to understand these digests there that otherwise would be opaque now when I'm presenting that if I'm presenting that on paper for legacy kind of users everything gets disclosed but if I have a an an app a client app that understands this the user could decide to remove some claims let's say removing these two pieces of data from from the claimed data object and then regenerate the appendix with these two pieces removed then regenerate the QR code and present that instead so what will the verifier do he was going to verify that yeah the QR code is signed the data that's on the bottom left side didn't change that's the one that's signed and I can prove that these two pieces out of four that I'm presenting corresponds to the data that was encoded in there by the issuer so that's the mathematics of what I just said I will go to my final slide instead of presenting the demo which is something you can go and run yourself it's an open source project so if you want to do is just a web portal that's going to try that but I want it instead to spend a minute to discuss what I think is the future of digital identity for a user-centric approach so some of us cryptographers that are dealing with digital identity have been proposing some of these ideas for for many years almost 20 years ago as part of a company here in Montreal they've developed a the u-proof system that's listed down the the list here doing all sorts of cool zero knowledge proofs on data and being to prove properties about yourself without just closing set attributes and it takes a lot of at some complexity to to these systems so I think these claim qr approach that I've just explained with the selective disclosure is kind of a let's go step by step and improving from the status quo and what's what's going on today so that's why the the type of projects I just presented stepping off from from what people have been used to will allow us to get to these advanced features which so one one interesting thing development is that there's a new ISO standard that that's coming out it's called the mobile driver's license the mdl which supports a flavor of selective disclosure like I've disclosed and it's going to be for as the name says for driver's license I know it's going to be adopted in some parts of the states I'm not sure about I'm not sure about Canada but that is a that will be a big stepping stone and a big milestone for for the world of user centric digital identity but there are more privacy featured are it will be needed also for long long term benefits one is unlinkability so all these tokens that you receive that are signed by an issuer a signature is just yeah it's a ends up being a random value unpredictable value but once you have it then you're presenting it you're you're presenting essentially a long live cookie to different parties so if two parties collude or if a party goes back to the issuers okay I got a ticket for the claim said it's an over 21 user I don't know which one it is but you sign and the signature is 0 6 1 7 3 then say oh yeah I get that to question like two months ago so so this data can be randomized using what's called blind signatures or you could prove your you could prove you have a signature with zero knowledge proofs without disclosing its value itself so there are some approaches in cryptography that will allow us to break this linkage between issuance and presentation and derive claims which I've briefly talked about earlier are a good way also to add some features and give power to the user for example to be able to show that yeah my date of birth is such that I'm over 21 without disclosing it or here I would say over 18 or that my name does not it's not listed on this denial list or this no fly list or whatever without actually disclosing my name so there's a lot of powerful techniques that have been explored we've prototyped some of that I'll just cite one of the projects I've been involved with in the past you prove does that and there's some activity in the w3c verifiable credential standard that's that's upcoming and then people are also working on these these type of features and you know love it or hate it the the web three the web three blockchain community have been developing some of these these techniques which uh it's going to be for some of their blockchain type use cases but also love this this base cryptography can be reused and applied in a wider variety of scenarios so I'm kind of very excited about this work and the the future for user-centric digital identity which gives a lot of power and privacy to the user so on these words I'll conclude and I'm looking forward to the questions in the next session thank you thank you thanks a lot so we'll be back at three for the the q&a you still have some time to send some questions on slido please do there's a bunch of them but you only have 10 minutes left to send some more so eagerly waiting all your questions thanks a lot everyone awesome welcome to uh north sick psychedelic edition um so you're not seeing it but I don't have the uh the q&a anymore um but it's all right I have it here so welcome to the uh cryptography block q&a panel discussion um you know we're doing this live so it'll you know take its own form um there's been a lot of questions uh on slido so I'm quite happy about that um it was very interesting topics to be discussed um I think the first one really uh the first group questions uh about d-rand uh quite a lot of interest on the you know the the resilience of the network the the threshold I know how many new nodes uh introduction would become a problem um you know what kind of protection mechanisms exists to avoid these kind of takeovers by nefarious actors maybe you know someone thinking about uh what we have heard potentially uh could happen with door or other types of distributed systems uh I don't know if you want to talk a bit about this yolan can you hear yeah so that's a thing I I haven't really um discussed in my talk but the the trust assumption and the way the the randomness is generated make it so that it's enough for just a single node to generate proper uh randomness during the setup process for the whole uh thing to be properly random so that's a very strong assumption we it's a very strong result because you don't need to trust any node but one and then you're sure you get proper randomness at the end so that's super cool uh the current threshold is at like 12 so it means half of the network could go down and uh that's I've I've discussed but the thing is as long as among the 12 signers you have one honest party and the very and the signatures checkouts at the end you're good to go so the the main issue is as soon as you have a threshold of my issues no then they can collude you know they can work together and produce signatures ahead of time they can go faster they can break the trust assumption you have in the network and that's the main issue you have if you have a threshold number of nodes that are my issues so the the bigger the threshold the safer you are against collisions but the bigger the threshold the the less safe you are from a liveness point of view because if a few nodes go down I don't know like if aws goes down and we have like maybe six nodes on aws then we need to make sure the rest of the network will keep working properly um thanks yeah all right let's uh I think it's a it's a it's a very good answer um there you know of course lots of concern on resilience but you know probably also uh on capacity you know what's what's the speed like how many um you know random nonces can you generate per second per minute per hour what are we looking like is the addition of nodes going to influence that um you know are these sorts of things I don't know if you can cover a bit on that yeah so the the current way it works is each node will generate a signature every six seconds so the the current networks is generating one random 256 bit value every 30 seconds so that's really the current bandwidth the new network which launched on testnet is generating one value every three seconds so it's way faster the lowest we tried to go is one second you could go lower in theory but then you start to have issues with latency and like the current latency and signature aggregation is around 800 milliseconds so if you want to go below one second you would need very good connections between the nodes and it becomes then very also difficult to consume so yeah all right quite a few um quite a few questions uh for you christian um you know about you know claim qr nshc um I think you know at the end of the talk I'm talking about digital identity um you know some people I guess we're we're kind of asking because it's it's in the air so to speak right especially here in Quebec when you're when we're talking about the the efforts that the government is is looking at for for digital identity um you know could claim qr help for instance in replacing social security numbers or other elements of of identity that that we use on a not daily basis but quite a regular basis and we've seen issues with you know leagues and whatnot um well um I think these types of uh of credentials can help in yeah in day to day life maybe not so much social security numbers because that's typically a very infrequent way and the way they're a leak it's not when they're presented but mostly when they're you know stored in the database and then the database gets exposed but um it's easy to imagine scenarios for things we use already right so the driver's license is the one that most people use to you know get into a bar or whatever and but once you have these type of things in place then you can imagine a lot more scenarios especially uh online let's say yeah your school could issue you a a alumni credential you could use to get some some rebates online or some restaurants or whatnot or same thing exploit employers or employment verification um you uh I hate to use this word the metaverse identity you know you could you could give your your online avatars and presents some some actually identity attributes and of course they wouldn't be in the form of a qr there but if if they're just packaged in a in a type of credential for which the user controls the key uh therefore the ownership and they can decide and select how this information can be disclosed and by whom so I mean user centric in the sense of user empowerment so okay that's what the verifier want to see and um then uh what's uh I can make the decision if I want to present that information and what's the minimal set I can present that's why I like to use the word minimal disclosure so the minimum that's needed for a particular transaction so sometimes that's nothing it's anonymous sometimes it's your full identity for you know crossing a border um so the the qr form is interesting because it it bridges the gap between these online credentials for which you need you know a key store and maybe a smartphone but there's a wide range of of scenarios before that that's just qr you can carry it on paper literally and it so there's there's a few opportunities I think that hopefully the ecosystem can help build thanks a lot and um you know are there any any attempts to kind of unify um these various health guards that exist around the world you mentioned that there were uh you know multiple competing standards I guess um you know and when we're talking about um digital identity might be just broader than than vaccine scenarios are you aware of any such attempts to to unify some of these standards yeah so there's no effort to unify them the same way there's no effort to unify the passports you know it's like each country do their own thing and that's mainly the result of you know all the planet trying to solve the same problem at the same time in a very rapid time frame so these identity um specifications they take typically years to to develop so it was it's a miracle that it happened in search so I think the framework is like a one year old and uh the reason it succeeded it because it was um rooted in in the medical world um where they want to use that for a long time for when you know for your kid's school vaccination history that you have to carry over from state to state and then be able to present that to schools for travel immunizations in the future so they say okay let's use the situation to build something that's going to be lasting and reusable so that's why here it was successful and other jurisdictions in the world had to solve the same problem for their own case so in in europe yeah they decided to their green certificate is not just the medical fact it's also a decision you know so it could be a lab test it could be an exemption and it's it's you get a green check mark out of that so it was the different scope different decision here is and I said we don't want to make these decisions here's the facts and whoever checks it makes a decision based on the current policy yeah thanks um all right I want to I want to go back maybe to to talking about you know we're you know talking about entities and how these get set up um you know you know you've had to set up um uh well work to set up the the the league of entropy I like I like this this this this name um but there were a few questions about you know how this was set up as a as an organization how one gets to join it uh you know is there any paperwork involved is there any uh some you know formalities uh or is it just you know open to anyone I guess you know people want to maybe see what it entails and if they can help yeah so the it's basically a question of oh do you do your governance and your network right so currently the league of entropy um has a notion of each member is voting a new members to join maybe we'll come up with a better way to do the governments at some point where we can delegate voting power or whatsoever but currently that's how it is because we are only as I said 16 members so it's still okay um the um to join it's uh you just need to show interest show that you've got the the proper setup and infrastructure and then you can onboard on the test net if you get accepted and uh once you've shown you were able to run a node on test net and it worked you can upgrade to main net so that's how it works um on our side yeah so if you I guess if you got a bunch of lava lamps you're good to go yeah that's how it works or even just a fish and uh some bubble generator in your aquarium you know that's also chaotic so awesome um so there there was a um you know there was a mention uh you know in your talk about um time locked encryption um and I think there are a few folks that I'm seeing here asking you know how does this work I think it's a very new research and you know might be a bit uh a bit complex but can you maybe drill down a bit on on how this is uh thought about and um you know if there's going to be future work on that and what it's going to entail yeah so the time lock encryption is something I'm super excited about because it's it's super cool in my opinion to be able to encrypt something toward the future um the thing is we're still working on the paper and the blog post so it's going to be released in July or maybe August uh hopefully we will also realize a open source tool that allows you to use it so no worries it's coming um that technically it's a bit difficult to just explain you know like out of the blue without a um a whiteboard but um what you do is you take the value you want to encrypt you pick a random value which is secrets you can explore the both together and you get a encrypted message which is a one-time pad basically you you encrypted something with one time pad and now that random value will get committed towards the round in the future and using the pairings um we can decrypt well decommit that commitments as soon as the signature is published for that round and that might give you a bit of an intuition of how it works I guess so I guess it's upcoming work so maybe uh north sec 2023 yeah we hope to be done before that I guess all right awesome um so let's step back a bit and maybe go into the um um you know the more theoretical well theoretically called applied crypto you know there's there's been a you know some questions about I know just maybe a bit of background there on quantum cryptography uh you know what's uh in your opinion and you know you along of course you as well being a cryptographer what do you think um you know how far are we from mainstream adoption what's you know what what are the hurdles basically for it not to be post quantum crypto for it not to be adopted today what kind of standardization do we do we need um you know and and you know maybe what's uh what's the in your opinion what's the road to getting there yeah first a a little terminology explanation so uh quantum cryptography it's typically uh typically means quantum key distribution uh which is uh the ability to using quantum mechanisms to establish a a shared key that you can use then with conventional encryption so I think that that's very little chance of being uh widely deployed it's been deployed kind of in pilot in very specialized environments but the the classical uh cryptography that we have today is sufficient I think for real world scenarios um the other word that's post quantum cryptography so that's that's what it means it's normal cryptography that you run with ordinary classical computers but for which we don't know how to break with a future quantum computer so a quantum computer is a machine that if if we end up building could break the crypto that we use today and the problem why is that a problem now if it's going to be built in 20 years is that you can record the traffic today and decrypt it in 20 years which in some cases if you're a Coca Cola and you're trying to protect your recipe forever then that might be a problem um so this as I mentioned in the talk at the beginning just NIST is uh which is the national institute of standards and technology uh there are uh yeah working on replacements of quantum algorithms so they're now waiting or waiting any day now after a three plus year process to to see which is going to be the next uh round of algorithms are going to replace rsa and and they see dsa and so uh these are the ones that are they're very close to to be picked and then it's going to take a year or two to ride up and standardize so we're gonna comfortable let's you know change the uh the underpinning and the machinery of the the crypto pipelines before uh it's too late so I think that's in good shape yeah and if you look also at what's being done in the on the mailing list and you know online people are still not super are not agreeing on oh we should do it like should we combine current classical algorithms with the new quantum resistant algorithms should we switch over to the new algorithms even though the current ones have been battle tested and we know they work properly or at least we hope they do um these are questions that still need to be answered like because if you want to do hybrid encryption or you combine both quantum resistant algorithms with the classical algorithms it's not the same as if you say okay we ditch the classical stuff and we jump on the new cool quantum resistant uh train you know and um people are getting worried as well because like the recently I think it wasn't in the US as I said okay now all the secret top secret stuff needs to move on to a quantum resistant deck like within five years or something like that and people are like what what's happening they didn't even standardize the post quantum algorithms yet why do they do that now so yeah yeah I can just like add a note to that so uh yeah that's a it's a fair point that there might be this transitional period where we're going to use hybrid uh encryption hybrid in the sense of yeah combining more than one scheme and that's something that uh we've implemented uh it's not something that's pushed necessarily by by NIST as their their goal is to say is the new standard but it's something that the industry is wondering about if that would be a good idea there's this project which I've talked about in the two north sex ago uh it's the open quantum safe project if you look that up it's led by the University of Waterloo and we've prototyped all the new algorithms including in combinations and hybrid way with uh the current one with with RSA or ECDSA and or uh sorry EC D'Fielman um so uh you you can run that in open SSL and open SSH CLA looks and at the end of the day there's going to be some people it's going to be their choice their their policy to what's the performance versus uh expected security and there's going to be a large body of people who won't care that just follow the government standards whichever they'll pick so um it's yeah hopefully NIST will will you know in the academic community will will have picked good a replacement so at some point that that's going to be the new the new one all right thanks so I think that you know that leads kind of well into the next question um maybe a bit even even broader you know there's been a lot of um we've seen the pickup of certain popular software like um you know like you know wiretruck to give an example versus open VPN very different approaches um and you know you've just mentioned that the government um you know the NIST will standardize some form of algorithm maybe people can use some other algorithm um you know in cryptography there might have been some times where we had a discussion about enforcing sane defaults versus letting the users choose themselves um what to what to what to use in terms of algorithms um you know what what's your what's your take on this um you know what would be a preferred approach should we let the users choose which algorithm when it gets standardized uh or some configuration but then it could lead into the you know tls uh ssl tls issues where you know basically uh death by a potential thousand paper cuts um so what's the what's the you know what's the the theme there the leading discussions around uh quantum resilient uh cryptography yeah I mean it's I'll give a a kind of like a large vendor answer it's like Microsoft which we have such a varied uh set of customers from all over the spectrum so it's it's really hard to pick for them so as a crypto developer it's yeah it's kind of harmful to give too much choice and and it's easier to give just you know a very minimal set of configuration so you can shoot yourself in the foot on the other end depends you know sort of like the cryptography in China is very different uh than in the US and we we you know we provide software all around the globe so uh the platform itself needs to be uh adaptable for that um but I think it's recognized right the mist it's not mistakes because you know it's doing the best we can but the the crypto community learned a lot of lessons in the last 10 years we see all the tls attacks like hard bleed and all these things year after year and then the tls 1.3 is I think is a good example of a a standard that had a good uh analysis and review by the academic community and a lot of the research was applied there and there's a way fewer choices so when it came out of the box it was okay okay great like good configuration and then the industry or some part of the industry fought back to trying to put back some features like the rsa encryption because they needed them middle boxes for for uh traffic intercept for you know some time valid reasons so that you know kids don't go and browse the nasty parts of the internet so it's just they when they're in school right like so there's going to be an equilibrium but I kind of tend to like the direction where where the practical security is going so it's yeah it's it's it's a complicated answer in situation for sure all right Yolanda you want to chime in I know we discussed a bit about you know this topic earlier on yeah well I would say crypto agility is a good thing for protocol designers and for software developers but it's a terrible thing for users in my opinion because it it allows you know like non-crypto developers to shoot themselves in the food way too easily like if you look at the joyous pack or they could choose the non encryption algorithms which wouldn't encrypt anything and that kind of issues I mean sure they wanted to do good and to provide a lot of options but at the end it where it was too many so I like also the way TLS 1.3 reduced the number of options to just a safe set and how they did it and I think it's super important for us as protocol designers to be able to quickly switch to new algorithms if we see something got broken and that's not working anymore and it's in my opinion also a good reason to go the hybrid way rather than directly jump the to quantum resistant algorithms but yeah we'll see all right so I guess the debates lives on but there's a tendency towards simplifying things and and you know leaving less options to shoot yourself in the foot all right so it was a it was a it was a you know great session lots of good questions I went through most of them thanks a lot you know and thanks a lot for for all the for all the help and answering these these questions Christian as well if you have any more questions you can probably find both gentlemen maybe grabbing a beer at the bar or later in the in the chill room thank you all for submitting all these great questions and I guess see you on the next the next block and that will be the red team block in almost 30 minutes now have a good one everyone hello hello hello so welcome to the last block of the conference the red team block so I'm going to present to you your moderator for the next few talks his name is Martin Zubey he's been hacking for 15 years you might know him from his challenges and his windows track at Ackfest he also did it for one year at Nordsec you remember the Neurosuf the windows track that was him so give give all your thanks for all your points that year to Martin Zubey and now he leads a large team of ethical hackers one meeting at a time please welcome Martin Zubey thank you we go I hope you have a very very good Nordsec as good as I do I hope also that you will really enjoy the CTF this weekend I'll jump right in with the introduction of our new or next guest Olivier I know Olivier since a good time and I really really appreciate his work in especially all the open source stuff he did like mailboxes and many more products sorry tools Olivier is he gave so many conference at Black Hat Def Con Bot Con Derby Con Hackfest Nordsec he's involved in Nordsec Montréal and you will see him a lot at a lot of places and today he's going to talk about RDP which of course is a remote desktop protocol he's been studying for the last three years this protocol and today he's going to talk about how to attack and defend RDP so I'm pretty sure it's going to be awesome thank you Olivier thanks so much Martin I rather applause for Martin it's true it starts to be way back right since we know each other it's pretty crazy anyway all right so originally today we I was I planned to talk about the risks of RDP and how to mitigate them but then I realized I only have half an hour so I needed to adjust so this is some risks of RDP and how to mitigate them but then I found some problems and it became some risks of RDP how to mitigate them and a villain reported to Microsoft so we're going to go through this it's heavily edited the edition of the talk I gave a month ago at ETSCon which was 45 minutes so I switched a bunch of things and some of it might not be super coherent because I was doing CTF 101 yesterday and I had a hacker jeopardy tomorrow so I didn't have as much time as I wished I had to prepare but you'll have a great ride I'm sure all right so about us no time for that no actually I should say so I was supposed to present with Lisandro but Lisandro his visa didn't get approved in time so apparently when immigration Canada says it's going to take 23 days well they don't mean 23 days for real and it's not even 23 business days it's like 23 days of Jupiter or I don't know what but one day you'll see Lisandro I'm sure you'll have a visa they are good for five years so once once you have it you'll present here either here or at Gosec we'll see all right so it's just by myself so RDP RDP as many of you know is the remote desktop protocol it allows you to connect to a remote system and have graphical mouse and different kinds of IO forwarded in a secure fashion and it is basically like for geeks it's like SSH with more features and or problems so the RDP layers so this is why this needs time but you know what let's forget about most of it it's not that interesting and it's been already hammered on a lot of time before so we're going to focus on IO clipboard and drives and by IO we mean display keyboard and mouse so these are the areas of focus of RDP today um so RDP security what happens with RDP you have at the beginning uh like ancient history of RDP you had RC4 and graphical login so why I precise graphical login this is pretty important in the design of the RDP protocol and its early flexibility but was also a mistake so we're gonna spend some time on that but so RC4 was a custom I think semi hardcoded key anyway right now almost nothing supports it and if you do that people can pwn you in like fractions of seconds can enable supported breaking the RC4 connection mechanism like 15 years ago I think so what most people doing non-NLA which is the modern one that we're gonna get into uses right now it's TLS plus graphical login and yes this is the TLS like transport layers security but then everything like all the channels IO channels are set up and then you authenticate via the keyboard and mouse and graphical just a lot of code and surface what happened after is TLS plus network level authentication so NLA which relies on credit ssp and we're gonna talk about that and I had planned on talking about remote credential guard and restricted admin but these are not enabled by default either on the server or the client so unfortunately they didn't make the cut for the 30 minute version so risk of RDP well of course the biggest risk is a monster in the middle attacks or Mallory in the middle or medler in the middle I don't know what to say anymore but I don't want to say man so it's gonna be monster in the middle for me all right so what are the risks well the risks are of a security downgrade attack so NLA goes down to TLS and this works by default what happens also is that user can click through warnings although you'll see later that this might not be relevant anymore and the impact of that monster in the middle attack is access to display access to keyboard access to clipboard server site takeover client side file stealing and client site takeover implementation pending we'll have that one day so why am I talking about RDP well I have a shout out slide way later but I need to address that two of the guys who worked on PI RDP are back there in the corner Emilio and Maxim round of applause for these guys and Emilio Emilio presented about PI RDP here but this so this talk is basically the the broader protocol look into the protocol instead of look at the tool of it but so all these references which you'll have available as clickable links in the slides are to the stuff where we presented PI RDP and how to use it so we're not going to spend time on that just going to focus on the risks and impact but without these guys none of this would be possible so what does a protocol downgrade looks like so you can identify that risk so the normal flow for a modern RDP connection with NLA is you get a dialogue a native on the client side dialogue that where you input your credentials and then you go you get the certificate error if any you don't have certificate error you don't get any if you map a drive you'll get an additional warning because mapping a drive has security implications which we'll see now what does the degraded flow looks like so if someone has PI RDP in front of you somehow what you'll have is you'll have the certificate error first and then a graphical login so on any system that you connect that then you get to a graphical login there's something fishy going on because in most cases even if RDP is not RDP even if NLA is not enforced on the server if your client supports it it will be upgraded to NLA automatically so having the graphical login is a shows you that something's really trying to negotiate at the lower security level of RDP so this is the basically one of them is the graphical and the other is the the windows native and so why then Microsoft did graphical login well I assume that it's for flexibility reasons because everything is delegated to the graphical pipeline so no matter how you want to authenticate now or later you can do it because as long as it relies on keyboard and mouse and and graphical interactions whereas when you implement this like the the right hand side then it's at the protocol level so if you want to change anything it needs a change in the protocol which means a change in the client and the server so they kind of thought they were smart but they weren't so NLA so it's as I just said authentication before the session establishment what are the security advantages attack surface reduction think of all the code that is exercised to do all of these mouse input displays and stuff well I'll show a list later also dust resistance so if you send one packet to connect to RDP and then the server replies with like virtual channels and and display bitmaps and stuff like that then you can do potentially use that as a denial of service and also a lot of resources on the server side are allocated to set that up right oh I have a client I need to set up a whole virtual desktop whole desktop shell and allocate like at least 60 megs of RAM maybe more and so if you do that consecutively then you have a dust on the server side also allows a single sign on it was introduced in RDP 6 by default since server 2012 and Windows 8 and it's the famous tick box usually in a lot of legacy system or the shady deployment things you'll see like oh go untick that you know then you shouldn't do it so I mentioned the attack surface reduction imagine all of this needs to happen at the server side and on the client side even before authentication is done so the untrusted user has access to all that surface and this is why they got rid of it by using NLA now what is what does the authentication part of NLA looks like so it's called credit ssp and inside the espinego you can do either ntlm or Kerberos I'm not super good with the ad stuff I'll need help on and some further research is related to that but what's interesting that I want you to get out of this diagram is that the crypto prevents a monster in the middle attack because it mixes the the stuff the fingerprint of the public key with the challenge which means that you cannot monster in the middle it in the TLS sense like negotiate on one hand and then fake a new negotiation to the victim this doesn't work because of that mix in the challenge so how do we attack NLA what are the risks so the first one that was obvious because I mentioned it earlier is a downgrade attack so that works how do you prevent the downgrade attack well you enforce NLA at the server side obviously and you can also enforce it with power shell with group policies which are listed here and one of the the power the group policy way prevents users from disabling it later even administrators which is good now we were like okay that's not cool but how do we attack these environments so we thought well if the server decides what if and and we are in the network path how about we redirected to a machine we control well it works so we detect that NLA is enforced on the server side we decide okay we forward the packet to a different destination to an attacker control non-NLA system and if the user is curious and clicks through the warnings he'll get in and we'll have him so this non-NLA redirection unfortunately is as designed so we had an exchange on Twitter I asked the Marc-André Morro a very prominent expert on RDP like what can be done about it isn't there isn't there a way to enforce NLA in the client and basically it was like not really and unfortunately the more mitigation advice the good news that I had is the stuff I cut from the deck so I'm going to tell you right now if you want to mitigate this attack you need to look at restricted admin or remote credential guard why are there two different features because one of them works for AD and Kerberos environment and the other one works for when stuff is not domain joined so they cannot overlap the technologies are just incompatible and this is why it's not enabled by default and this is why this whole thing is a mess so the third attack Alex Beaulieu who is probably or maybe not but he is at NordSec did implement that attack and so we we draw we whiteboarded this with Emilio way back and we were like they got the crypto right unless we found an implementation error there's no way we're gonna we're gonna attack that and then Alex one day working on Pire DP said well this blue part you're right we can't attack it but the I realized after it's done we are we fall back to TLS there's no keying material derived from that used after which means that if we have the server's private key which works in forensics context or honeypot contexts well we can't just pass the encrypted blob don't look at it don't understand it and then we fall back to TLS and so the attack works so we are able to attack well we the whole world is are is able to attack RDP NLA if and it's a big if you have access to the target's private um so I'm gonna demonstrate the NLA attack uh the NLA bypass attack and for this specific case we decided to try if we use let's encrypt certificate does it work do we get warnings certificate warnings or not do we can we use pretty much any cert to authenticate RDP and uh look at this I'm gonna pause it a couple times so we are connecting so on the left inside is the victim on the right hand side the shell is a pyrdp running and we are opening the player so the player is the interactive attack tool where you can take control of the RDP session so now we set all that up so the victim connects first warning okay first warning I'm mapping a drive so this is expected unless someone click don't ask me again I never do that because I always want this to be in my demos because it's important caveat to understand so if the users are properly trained this doesn't happen well I'm clicking through anyway here but then no certificate demonstrated I'm authenticating the victim is authenticating regularly we have control and this is an NLA system and you can see on the top the padlock right so no certificate error whatsoever nothing was uh no no warnings and the padlock is there and then uh access is granted and so this now will become a generic short video of the risks of all the stuff that we can do once we convey the user to to uh get in like that but think about one scenario so manage them in linked someone where you have access the private key can be a relatively rare occurrence but so one way this was weaponized in red teams is that you send a dot rdp file as an email attachment almost no provider blocks it credentials are pre-populated oh like we see so right now I am capturing all keystrokes I am um saving files from the client at the attack level without the client knowing that files are being looked at then we you can save them interactively this can also all be automated to be done automatically because it doesn't scale in a pen test to be looking at people's screens like that so now we're looking at the secret and it was collected and it's a video from ATS account unfortunately but so the red the the red team tech technique that I just mentioned is called rogue rdp there was a nice blog post by uh ready today guy it's in my notes I don't have access to them um but uh Mike Mike Feltcher Fettcher uh a red team guy from the us and he's pretty he's very good and very solid and it works right because all of the the the IOCs are of the stuff generated is um is coming from legitimate processes of the windows stuff that works on the server and the mstsc on the client side so it's kind of something that is flying under the radar right now from a lot of the edr's perspective so now we're taking control so this is another feature that I wanted you to realize so you can see that on the right end side stuff is happening because we took control what we do on the client side we just block it so we don't you don't see anything and then you can run a payload this was an example and then um you uh we can give back control to the client and then the client will have access to the the system again last is the clipboard stealer so an interesting thing about the clipboard stealer right now uh is that I use the clipboard on my host but it is automatically shared to my client vm and this is automatically shared to the server and the server always says I want it so boom clipboard stolen we are collecting stuff from bad guys right now using this clipboard feature and it's pretty interesting chat messages ip addresses so what's the villain I mentioned at the top of the presentation well it's the it's a net ntlm hash capture it's a feature lisandro added back in november november december I reviewed it for a long time it was complicated so we figured like the ntlm exchange okay we need the private key for the nla stuff if we want to do the nla bypass attack but the handshake is still happening can we fake our own challenge instead of using the server's challenge with we we can never do anything with it can we generate our own challenge and then whatever the client sends back to us we're gonna use it for uh crack to crack the hash so we can crack that net ntlm v2 hash and we knew it was gonna work because responder implemented it but it's like it was super badly documented and responder is not a comprehensive rdp system so they really did what they needed to do in order to do the attack but we wanted to support all rdp versions and integrated this in our toolkit so we we thank them and we give them credit for how it come up with the attack but we implemented it in our own tool and so what does this looks like is that we basically in the monster in the middle layer uh send the challenge dimension we steal the hash and then you send this to john the ripper or hash cap and so it looks like this and when you crack it with john for example with the work list uh you do then crack them so again this is a hash hash cracking attack so depending on the complexity of the user's password it might not yield to automatic results but as pentester will tell you the more you collect eventually you'll crack one so how can you prevent this hash capture attack um you verify the connection to the rdp server so server address domain name you always look for valid certificates but as i've shown you can get a let's encrypt one and turns out that you don't even need to respond to the the HTTP challenge of let's encrypt in order to get one someone after seeing my talk sent me a resource on how you can generate let's encrypt certificate for your land so there is a way with the eff to do that so if attackers would be doing this it could get nasty but what i wanted to get at is how bad really is it and this is where we needed to report something to microsoft so we have our victim on the left attack tool on the right and we're we're connecting we're uh sending the we're sending a password so okay i did a failed login attempt just now i know it's super small trust me we have the hash at the right hand side it doesn't really matter just trust me here but the um so i did a login attempt failed but we did collect a hash but where was the certificate error we didn't get it is it possible that it happens after so this was for a login failed even if the login is failing we could still crack that hash by the way and get the password that the person did input so now at the second time i i put in the right password whoops missed it from a split second so if the user correctly attends k you will you will get the hash that you could crack and the this puts the client in just a weird state and so it happens to do an rdp connection internal error occurred and i played i played with it with this for a long time and the internal error is so deep that all subsequent connection even good good ones are going to fail i don't know what's what's changing in the state of the client something's getting really weird here um but so this means that we can collect legit uh hash of a user that's successfully authenticated and the error message um is kind of not obvious not something you're going to report to uh if you're being attacked to your it and you had no certificate error so this means let's just finish is it long i think okay so yeah the video ends with uh we're gonna take the hash and we're gonna crack it and john uh i have time because i cut so much content so i'll let it go to the end we'll see and the password is a bit you know it's purple i think but so use john on the hash so priority p features can attack a whole land by the way so if you are uh in the middle on the network path you could you know just monster in the middle a whole slash 24 and then just collect these hashes and try to make sure that when the user gets pissed off you just you know shut down the thing so that they can work it's pretty destructive at that i have to admit but so imagine in an internet cafe or something like that so here we the video finishes with we crack that hash but so what does that mean okay it means that pretty much you must never use rdp uh on untrusted networks because everything by default that could be done was done was enabled but still we collect the hashes so without vpn rdp thrown in the garbage or yeah i'm not your home maybe you trust your network that's fine we're not even in internet cafe as much anymore anyway um but so the other uh thing we can recommend is avoid ntlm use kerberos and audit ntlm usage i was told this is possible but i would need someone with uh better knowledge of ad to help me in that research i just don't have the lab or the capacity and or the enterprise network to validate that and i don't know how practice practical this is anyway so wrapping up attacks on the client what can we do what are the risks so we can steal files clipboard keystroke record the screen uh steal hash or plain text credentials so if we can perform the darn great attack we steal plain text if we can't we scan steal hash passwords we can do code execution via dll side loading implementation pending but this is what the red teamers are doing with the rogue rdp system and they are using py rdp by the way but so the way i say implementation pending is that we have access to the file io channel channel but we just created it to steal stuff uh right now but probably before the next north sec will have a path to write files and so the right now trendy attack is you put a dll in the teams uh you know very popular teams uh chat client and teams is vulnerable to dll side loading so you implant a dll with the good hijack stuff in it and so if you generated the dll um specifically for the target so it's not you know the hash is not known then what they what ttp can the the blue team really get right because this is coming from rdp you know stuff that no one's looking at right now so i think this is probably a very effective red team technique to use but i'm only a researcher so maybe the practicality is not there if anyone is really trying to use it go look at the rogue rdp stuff and if you want help or feedback i would be interested but uh we need to talk about the blue stuff too right we need to fix this um so attack that can be done with the server well credential credential brute forcing sessions take over common injection as we demonstrated now the future we're just just opened up so much so rd gateway i'm not looking at remote desktop gateways at all apparently i can probably support them and attack them um require i would like to see do we have any options for i want the tls certificate to come from a specific ca otherwise i don't allow the connection this would get rid of the whole uh let's encrypt can sign any cert and this makes the user think he's safe i want to look at ntm at restriction shadow framework which is both on the defensive and offensive and i want to start documenting some of this stuff inside in blog posts now what are your red team takeaways i'm wrapping this up um so rdp is often misconfigured and under the radar and you can do more than credential brute forcing with it um i think so it should become part of your attack and again this is niche corner try your regular stuff first but think about it once you uh you have you you are against walls the blue team takeaways now are never allow your employees to use rdp on protected networks and i know this is completely opposite of the zero trust people who are trying to get rid of the vpn but you'll have to encapsulate this in a web somehow right to remove all of these these attacks so if you're like oh yeah we're we're zero trust but rdp is still going like on its own without the vpn doesn't work train your users not to click through certificate errors now make sure nla is enforced by default i gave the group policy to do that in the talk um and long term we'll have to think about and you didn't have the research unfortunately but you'll have to think about rolling out either remote credential guard or restricted admin for client side enforcement but since i've written these lines microsoft patched uh last patch tuesday maybe not this month but the one before it was uh uh critical vulnerability in an enterprise network having either of these activated so they some some people are still finding problems around those security technologies i want to give a big special shout out to marcandre morrow a weight coding um he works for devolution and he is really helping me validate like when i i'm like is this a vulnerability or does the microsoft people are really aware of this and he's like no i think i think they're not aware of that i think they haven't looked at it that way because they're not attacking it like you are so he helps me a lot and um together well he he's like really connected with the microsoft guys and he's like on twitter like tagging them and saying like you should look at this and reply to this and so devolution are really trying to fix the problems of rdp that even microsoft is uh is in denial of it i opened a case with them regarding the the net ntlm attack and they said it's as design they closed it uh two weeks ago as design i don't know what i'm going to do with it but i mean he he so while i'm looking at attacking rdp morrow he's looking at like okay how can we completely ignore it he works for devolution who are providers of remote access um security and and stuff and they had a booth here at nord sec but they are really trying to do the right thing and have the problem fixed at microsoft in microsoft's product so i i'm gonna finish with the thank you special thanks to those that made priority p possible so citronar the rdpi guy emilio gonzalez in the back francis labelle i haven't seen him but he might be here um maxim carbono in the back alexandre bolieu and cool acid and so i had the question but it's more see you at the panel thank you for being here awesome mark olivier awesome uh so don't forget to send your questions on slido and uh we'll take a five minute breaks we'll see you after he has a diverse background with several experience in military radio satellite iot homo domination and and i think you you mentioned you are working on your and so some certifications so i wish you good luck with them so uh we're gonna have a talk about passive recon and intelligence collection using cyber squatted domains uh the floor is yours yeah so hi guys um thanks for sticking around until the last talk of the day um i know everybody's probably pretty tired um this is a little bit less uh less high tech than olivier uh so hopefully uh hopefully easy to follow along with and if we go through it a little bit quicker than half an hour uh don't hold me too accountable um this is a subject that i've been thinking about quite a bit since work i did with the army about two years ago uh taking a look at domain names in the public infrastructure i've been quite curious about what's possible uh with a low sort of a low hanging fruit style of attack um probably a lot of you especially if you're more technical familiar with the internet and the way it works dns is not a mystery full of vulnerabilities um in the army we talk about something called an asymmetrical attack so the cost of putting a roadside bomb for example uh is a fraction of the cost of defending against that attack i think this is a similar a similar thing in cyberspace that's worth considering that's something that's been around for a long time and we'll dig into that a little bit um yeah so introduction uh currently sock analyst at commissioners de kebek uh big thanks to jp and the rest of the team for encouraging me to to come up here today and give my first talk at a security conference um it's a it's a hell of a place to do it too so it's exciting uh also cyber protection team lead with 34 signal regiment in west mount we're a reserve unit in the army uh previously spent many years working as a home automation integrator a smart home guy a lot of custom av home theaters lighting control hvac that kind of thing um also software product manager for a mobile app where i spent a lot of time dealing specifically with user behavior and user issues so there's a lot of overlap there too i think this talk is a bit of a culmination of a lot of my my experience so what's on the agenda i want to talk quickly about human fallacy and the role it plays in some attacks i want to talk about dns specifically some of the challenges with that and email security challenges uh we're gonna take a closer look at cyber squatting and maybe refresher for some of you maybe some new angles to think about um and then i want to bring you sort of on the inside of a little evil experiment that i conducted uh over the last 45 days um then obviously we'll talk about protecting ourselves and our organizations and then some closing thoughts uh maybe we can talk about more in the panel so it's a cartoon that resonates with me pretty well on one side we've got data security and firewalls and everything that goes along with that on the other side we have dave who's the walking epitome of human error um because the point is that we put a lot of technical controls in place but it's really hard to account for some of the human factors involved now we see that firsthand a recent report probably i'll saw this in the news it was released by belling cat a bunch of us soldiers were using flashcards to study overseas and uh we're leaking top nuclear secrets uh some of the most top secret information in the united states uh was revealed 100 human error op sec issue there more recently city of Ottawa we saw humans involved in a scam uh social engineering experiment where somebody was pretending to be a a partner on behalf of the Salvation Army requesting the city of Ottawa changed the bank account that they transfer money to they made away with five hundred and fifty eight thousand dollars in city funds uh 100 human driven probably my favorite example if anybody should be secure it's the president of the united states uh op sec fail even surrounded by the best people in the world in cyber security arguably uh still using a password like mega 2020 was the first example if i remember correctly second one was you're fired happened twice his account was guessed by security researchers from uh from i think it was Denmark so why does all of this matter you know according to agress report 94 percent of organizations have experienced a data breach in the last year with human error being the leading cause of serious incidents on the other hand only 21 percent of technology leaders surveyed said that human error was their biggest concern mid-pandemic this issue is only grown um accidental and improper sharing of data by employees is grown to become probably one of the most critical threats facing uh we're concerning security leaders and then finally uh the last five years and even up to today we see uh a growing concern with the introduction of things like GDPR uh privacy protection laws ccpa in california more close to home bill bill 64 in quebec and and other such privacy regimes where the penalties imposed on organizations and the costs incurred are much much higher and it's now a regulated uh issue it's it's no longer should we care about security it's uh you better care about security or it's going to cost a lot of money uh to the organization and in some cases even criminal liability so let's back up a little bit let's talk about what is dns i'm not going to read the slide i'm not going to take you through how dns works you can do that research on your own but essentially dns is a system that is designed to point users to ip addresses and software applications to ip addresses because humans have a hard time remembering ip addresses names are a lot easier to remember dns has a long history started all the way back with arpanet in 1972 the concept of a of a host or an arpanet host name was was introduced and then dr paul moch petrus pioneer of dns publishes rfcs 882883 with some evolutions by 1986 into rfc 973 and finally you know uh the isc is founded dns systems that we still use today like bind or introduced by 1987 with rfc 1034 1035 we basically have the dns that we still have today it's a 30 year old technology that hasn't really evolved in 30 years long before a time when people were thinking about cyber security and what are the security implications of the way dns works uh for those of you who study internet history you'll know that the internet was not designed to be secure it was designed to be robust so a decentralized naming system was designed to stop a bomb from destroying our infrastructure and it was to route packets and be resilient but not necessarily concerned about data security or privacy so important considerations for putting on the black hat for a second the important consideration is dns not built with security in mind we didn't talk about it but you probably all know that's very trivial to register a domain name you can do it anonymously go buy a prepaid credit card at shell throw it into your your register of choice and register a domain name it's very inexpensive and finally humans often make mistakes and the component that dns relies on is human input more than anything it's built for humans so those are the things we want to keep in mind step aside for a second look at email look at email you know again first thing we'll we'll notice is as we look at the diagram is that the very first step in composing an email is choosing a recipient and how do you how do you designate a recipient you put in a name add a domain and right away email is dependent on the domain name system and if we take forgetting the details of email if we take uh this concept that dns is inherently insecure if email is dependent on it well then email is also insecure um history of email very similar timeline i'm not going to go through it completely but roughly the same timeline we're looking at email that by and large hasn't changed and i know some of you are probably thinking oh what about dns sec and what about encryption and what about all of these other protocol extensions that have come to pass since then well let's do an exercise show of hands who sent an encrypted email in the last month okay i see about five percent of the room has done that now show of hands who sent a sensitive document by email in the last month okay so different people different priorities it's maybe not the effect i was looking for there but um the point is that email is um you know basically unchanged since the last 30 years with with some minor caveats important considerations we know email is not built with security or privacy in mind really it's trivial to send or receive emails anonymously it's actually quite easy to stand up and operate an inexpensive email server or email infrastructure and once again humans make mistakes and they make them quite often let's move into cyber squatting so i'm sure you all know what cyber squatting is but basically it's a practice of registering a domain name with the intention of infringing upon the intended destination of the user so i could register self-sec that might be a form of domain squatting trying to leverage the trademark of north sec just one shitty example many different types of cyber squatting if you break them down into categories we can look at typo squatting which is quite common so in this example we have something like gmail or facebook with an extra o simple typo mistake put in by the user we have bit squatting which is really interesting um it's when you know cosmic radiation from outer space comes and interferes with whatever is stored in your memory and flips a bit in the character and all of a sudden you typed in microsoft but you ended up with mic post off dot com uh in in memory in the computer and that's what gets processed by in this case dns combo squatting so taking a brand name putting a dash in some other trust word or something like that it's not owned by fedex but it's made to look like it is homograph squatting which this is an interesting example uh hot mail to a human looks exactly the same as hot mail to a human but in this case it's a different character it's not the same character that's registered in dns finally paypal this one is a shout out to the frank phones out there uh pa ie pal dot ca um and then level squatting is another interesting technique that we see a lot especially with mobile given limited screen size uh sometimes what happens is the domain name is truncated to the left hand side and everything on the right hand side is ignored so you know the user is not actually paying attention to the real uh domain or tld so cyber squatting not a mystery we see it all the time uh it's very common in fishing campaigns uh you know it was a way to bait people into clicking links that you seem trustworthy it's also a very common technique in spam and marketing um one thing that's maybe a little less common but it's still out there is you know watering hole attacks man in the middle attacks and finally the thing I want to focus on today um is intelligence collection and using this as a tool to to gather information against a target so let's get to the fun part time for the experiment um I want to put a disclaimer out here so uh when I started this thing I didn't know what I was going to find I was kind of hoping like maybe somebody's going to send me an email and it'll be interesting uh turns out I actually collected an enormous amount of personal private sensitive information um none of it's going to be shared it's all going to be anonymized I'm going to give you the meta analysis and um everything that I've captured is basically analyzed and deleted on the spot I'm not storing I'm not interested in anybody's private data but I am interested in in in showing what's possible with this kind of attack so I had a few hypotheses going into this thing my first one was that some small but you know given a large enough scale not insignificant number of users um will mistype the domain name of a popular uh or you know an email address when they're typing in their recipient I'm going to mistype the domain we should be able to register some of those typosquadded variants they shouldn't be that expensive and uh we should you know we should be able to do that easily and then finally the hypothesis is if I put a catch all email address on the end of that typosquadded domain I should start receiving emails intended for other people but they're coming to me so some of the key questions I had is what kind of data can we capture this way is it possible to remain passive and anonymous in doing so and can we employ similar techniques um or sorry can we detect other actors employing similar techniques can we hypothesize who might be out there doing similar approach and finally how can we defend ourselves against such an attack so remember the email diagram from before so this is a shitty edit I've made to it to sort of convey the idea so Alice means to send an email to bob at b.org but he mistypes any types in bob at c.org well the email server has no problem with that the email application accepts it sends it for an ns lookup and there's an nx record at c.org and it says yeah sure I'll take an email yeah we've got to catch all email address I'm happy to receive an email for bob at c.org and the email gets processed and delivered right into in this case the attacker or the the malicious listeners email inbox so just a little bit of info to set you up for you know how the experiment is set up we have 12 different domain names that were registered and I want to give a thank thanks a shout out to a colleague of mine at commissionaires I don't think he's here today Simone who uh who'd also done some similar work here and was able to help me get the setup we set them up on a shared webmail inbox with a catch all email address and every single one of those domains and we let it collect data for 45 days okay so results 123,000 emails I was hoping to get like five okay um 2700 emails per day is you know that's like one a minute or something ridiculous you can watch them come in in real time it's really interesting um you might be wondering what kind of emails we received well a lot of this there's a lot of spam which was the first challenge that I came across was how am I going to eat all of this there's like a ton of spam to deal with um it's ridiculous so the vast majority of his spam frankly not unexpected uh when you when you stop and think about it um maybe maybe for the next iteration of this talk we'll talk about who the top spammers are and there's there's probably a lot of work that could be done just around analyzing that but that wasn't the focus of the talk so I didn't spend too much time on it so emails of interest here's where things get really interesting I received at last count 204 interact e transfers with a total value of tens of thousands of dollars a lot of package tracking links and not the spam variant that you're all used to receiving these were legitimate personal banking notifications so whether those are like um you know you you spent money some of you probably get those and reuse your debit or credit card you spent money here you spent money there there's a problem with your account your account balance is running low those types of emails we collected and classified them as personal banking sales receipts lots of sales receipts coming in you know is sure any one of you shopping downtown you've probably been asked if you want to receive an email receipt well maybe the girl mistyped your email and I got it account verification this one's dangerous so a lot of account verification and activation links you know this this we can talk a little bit more about types of attacks we can pull off with this appointment confirmations dental appointments doctors appointments sales meetings all kinds of appointments personal resumes and employment applications think about the amount of data that's on your personal resumes sensitive data there's you know even over 45 days this is almost uh uh yeah almost one a day um password reset links loan applications and service contracts tenant notifications personal medical information x-rays all kinds of information you know people's private health data lease documents um I got a completed security clearance application form complete with passport photo and 10 years of personal history um and finally the most impressive one I received was uh I don't want to reveal too much but it's one of the largest labor unions in the country they're in the middle of a draft negotiation with the government and I got an early version an early look at the contract uh before before anybody else basically except for the lawyers so some idea of what can be accomplished and collected and again just 45 days just 12 domains so let's talk about the exploit opportunities here they're basically endless um identity theft comes to mind extortion social engineering I can gather personal information that people may not be you know aware is out and available to others doxing I can do a account in credential theft financial theft um impersonation I didn't I didn't claim any e transfers I don't know if that would work I'm not interested in trying um impersonation you know once I know enough about a target I can pretend to be them and finally I'm in the army I've personally seen people send things over a gmail account I've seen them send things over hotmail accounts is there a national security threat here maybe so how common is it um I was curious to look around I only registered 12 domains but there's a lot of squatted variants of these things so I looked at three examples it's by you know not not anywhere near exhaustive but as some examples if you look at gmail.com and you start looking at typosquatted variants you'll find that there's 155 adjacent domains registered and about 70 of them have active mx records on the domain outlook.com similar stats yahoo I guess it's been around longer more highly targeted um that's a lot of potential for theft right there and we don't know who's behind these domains and I can tell you when I looked at them many of them share the same IP address so one has to wonder who's listening who's receiving those emails um well one thing that's interesting about this and this is an example of what you can do against a public email service but what about against an enterprise you know what what about um against a company domain or an enterprise domain can we do the same type of attack and part of what inspired me on this talk was uh was one that I saw at the rsa conference um where they used this as a red teaming technique and and one of the researchers said hey you know what for 12 bucks let's register the domain and just see what we get and they got the keys to the kingdom by like day six of the engagement they they received a mistyped password reset for their most sensitive database they were able to change the password and log in with admin rights to the thing that the company most wanted to protect if you want to see the talk I highly recommend it um I'll share the slides afterwards I guess through north sec I can probably do that um this link will take you right to the interesting part of the talk um okay so how can we defend against this the first thing I want to talk about is I alluded to it earlier as encryption I wouldn't have really learned anything or at least not anything meaningful if these emails were encrypted they were all in clear text and I could read them however I wanted there was no as my certificates and use I didn't I didn't detect a single encrypted email and what I gathered awareness training is a really big one so I was digging for stats because I started to ask myself well what about digital literacy do people understand that this is possible for me it's shocking but what about for other people um stats can the the most recent most recent stats I could pull were from 2018 where they were looking at student digital digital literacy ratings um so in this case 15 year old students um only only like in Quebec I think kind of a wide 38% in Quebec we're actually the lowest in the country 30% of students reported being taught how to identify phishing or spam emails you know that that's a pretty big problem um I think awareness training across the board maybe in school all the way up into the enterprise is really important um and then finally DNS solutions I think solve a lot of these problems so monitor your DNS take a look at what requests are happening uh there's DNS firewalls DNS filtering out there uh passive DNS is another interesting tool to detect things like newly registered domain names there's a lot of research out there that shows if a domain name is new enough it's probably malicious with a high degree of confidence so don't resolve new domains um there's a lot of tools for this farset security domain tools um there was uh there's a few vendors here today flare systems was there they have a really neat platform that looks at a lot of this kind of thing uh and then finally um if you talk to dr paul vixie the guy who wrote bind and maintains bind for for many many years or the father of the the DNS um they'll tell you to run your own DNS resolver it's really easy to set up I know it's really easy to go and and say hey you know what get get your domains from or your IP addresses from 8.8.8.8.8 or you know what cloud flare wherever you want to resolve your DNS but take control back it's actually quite easy uh you can throw it up on a raspberry pi play with it and you can use things that are called DNS response policy zones so if you detect domains that are targeting um your enterprise domain you can set up a response policy zone that says hey if somebody asks for gmail.com well send them to gmail.com give them the result for that instead you can set that up and you can do it in response to the things that you're seeing on your network maybe specific to your domain or the types of traffic that that's happening on your network um so DNS big one and then finally some food for thought you know the question is this brought up for me it was it was quite shocking the first one was is email an essential service or a critical infrastructure you know for the the importance that it has in our lives is it considered critical infrastructure and if so who's responsible for protecting it does this fall on the public email service providers does it fall on us as individuals or maybe the root root root authorities in the domain name system uh the second question I had is can I automate the analysis you know I started getting a little bit uncomfortable looking at some of this data and um tried to remove myself from it as much as possible so can we can we do this kind of research in a more automated way um that that generates meaningful threat intelligence but also respects privacy and finally can we use similar approaches exploiting typosquadding against other services there's really interesting research done um regarding ntp bit flips uh some of you may have seen that research the researcher that um basically realized that every I think it's every day every 24 hours a windows machine checks in with time.microsoft.com and he knew that bit flips were a thing and they were theorized but he wanted to measure the rate that they happened at and uh he registered time dot some bit flipped version of microsoft.com he got millions of of of uh ntp requests to his server um in a very short amount of time uh and then finally uh man in the middle excuse me monster in the middle uh we'll make that a standard uh or you know reverse proxying against web pages and popular web portals you know that could be another abuse that's interesting to look at thank you working okay it works um thanks and good job for your first talk honestly very good great results uh so guys again if you can ask questions on slido i'm gonna take care of them right after one talk left we probably start in five minutes thank you right ladies and gentlemen welcome back to our panel on of uh red team block so i'm gonna start with a few questions dedicated to our two speakers and then i'm gonna go more to general red team questions if we have time so i will start with you olivier um we had some questions about rdp of course rdp is very well used in the industry is built in on windows you can use it on linux you can use it on mac uh the question was are there better alternatives to rdp um i would say wrap rdp in an ssh tunnel but that that might not be convenient that might be a bit of a troll no i think so i think this is the standard it's it's really efficient so there are some proprietary alternatives uh and if you the problem is you need to control the server and the client you need the flexibility you need the deployment so it kind of makes sense that it is in microsoft's control um so it's a difficult question and i think it relies on a lot of things but like let's say i would be i don't know i i i i just don't i control all my computing i don't i don't care about anyone and i don't need to because let's say i'm csc something like that right there are a secret service then okay just use something else and enforce it and make sure you audited it properly because rdp has been audited a lot right but if you are anyone else then secret service i mean you must pretty much use rdp and using something else uh it might not have been scrutinized as well as rdp so no i think my advice to this still holds is wrap it in something else wrap it in vpn um keep monitoring it and maybe uh maybe you know speak with the evolution and i i don't know i'm plugging a vendor here but they really understand it and look at at what they're trying to do to make sure that it's secure and if if you can't do vpn or if it's too conky too complicated but there are also other vendors doing that but if you want to avoid additional costs i think just vpn and making sure that nothing is exposed uh is a good step and keep patching keep patching all right thank you for voila do you have insights on which type of domains like big tech large orgs brands that you got the most amount of emails from i don't want to single out any single provider but i will say that in general um it's a it's a it's a game of it's a numbers game so the more key strokes and the more attempts i guess to communicate with the domain name system the more likely you're going to land on a typo squat um so the longer the domain the more likely it is that there's a typo in it and the more in this case emails are being sent uh the more likely it is one of those is going to be a typo um so i would say think about the big providers that have millions and millions of emails going through every every second every minute uh and typically the longer the domain the more likely it is there's going to be a typo in it cool um next one for olivia um and you researched it i don't know if you read about ms remote desktop services which encapsulate rdp into htps uh do you know if it resolved many of the problems you presented today i honestly thought that this was rd gateway so uh i had i i think it is rd gateway does the person who has the question still here because if it is rd gateway then it was in my future work slide so if it was not if it's not already gateway then i want to hear about it but uh no honestly i think this is uh the the so the remote desktop services you can enable a gateway which encapsulated in htps and so for that the uh mtlm attack it means yes but now how have they implemented it if they have implemented it by just layering htp on top of it then as soon as i get to implement that in priority p i'll have access and if they haven't changed anything and they have no reason to have changed the underlying protocol it's just another encapsulation uh i believe that our attack would still work but right now it doesn't because we need to do that htps decapsulation and to be honest that code is so complex the guy are are they still here that code is so complex and hard to maintain that i if i ever keep up with it i might attack it but i i or i i'll need other interns to do it for me because i'm i'm not that bright okay it's sad but i'm aging so next question would be for rola um so you mentioned how to do typosquatting but let's say you are being typosquatted so what would you recommend to blue teamers in the room sure yeah that's a really good question um i think the first thing is to be aware that it's happening it's really easy to look around dns there's lots of good tools out there dns come dns twist comes to mind it's a free python uh script on on github you can find it for free there's a lot of web implementations of it as well if you're not into running python um so just being aware that it's happening to your domain is is interesting enough um and then you can start filtering for it and looking for instances of it uh you can use tools like dig ns look up and just see what what what kind of records are on that domain name um if there's an mx record uh that's a red flag just being aware that it's there and you can do a lot to protect yourself and your users from reaching out to that domain but it's really hard to to to police everybody on the internet from looking for that domain um so i guess the next best thing is depending on who you are and how much leverage you have and where the domain is is registered uh you could you could try to do a takedown request if it's a brand infringement um i think the key is first understanding if if somebody's doing it simply uh you know i would i would recommend looking at the tool like dns twist um it's probably a good place to start may may i uh add an additional question do you know if they are provisioned to like so we know that you can't purchase like uh nestly uh because it's a brand that is a trademark right but do you know if typo squatting kind of falls under the trademark uh infringement stuff um i'll say that from what i've seen there are definitely efforts out there to police it but i think it's on a registered by registered basis i think it's going to depend on the tld um there's a lot of factors at play but generally um if it is being policed it's not being policed very well i think it's incumbent on the trademark owner to actually fight to go and have that domain revoked and they do have a lot of power there's a lot of levers in place for for brands to protect their their trademark that way um i think it's a mixed bag about whether or not you'll be allowed to register at the first place but so you sorry martin you type of squat pretty big uh names right yes and you got nothing you like no one kicked your door or you know not yet after the talk maybe we'll see what happens but um no not yet for 45 days so uh i'll say that i'll say that those domains have been registered and active for a lot longer than what i started working with them okay um but there's a lot of conversations now about what do we do what's the responsible thing to do with the domains um so i'm open to discussions if anybody has ideas i have ideas about it as well but um yeah so far uh got away okay i'm gonna jump i had some i had a pocket question about uh you know legal legal concern of of your research so i'm gonna i i'm not i'm just gonna jump on i am on this question um so are there legal concerns about doing typo squatting uh on a specific company is it considered as attacking this company uh yeah that's a really good question and i've lost a lot of sleep over it recently especially knowing that i'm going to present it in a very public forum um i think yes i think depending on what you're doing with it i don't think owning the domain is necessarily enough to to call it a criminal act or an illegal act i think depending on what you do with it and how you use it maybe um is it illegal to steal mail from somebody's mailbox is this the same thing uh i think there's a lot of questions about it i think intent is important but i mean if i'm in front of a judge and saying hello i really wanted those e transfers that's one thing but if it's for security research i would like to think anyway that we have a society that um wants us and encourages us to point these things out and try to correct them so i mean in my case it's a risk i'm willing to take i'm not going to share data with anybody i'm not going to talk about personal information uh and i would discourage anybody from trying this it's already been proven you can do it you don't need to do it at home um in the case of a red team engagement a great tool um i think awareness is probably key so i think yeah it should be illegal but how do you enforce it how do you police it those are the bigger questions i agree and audio would like to add on this uh no no thanks for asking though but it was very a very good question and it's it's very difficult situation i agree i agree too okay uh i work a lot with the cyber threat intel team and most of the companies are based their security prioritization based on threat actors with documented activities so i was wondering if you have for your both research used such intel have you seen attacks like that been made by for example ransomware or publicly known groups uh in their campaign in their ttp wanna go first yeah so recently the octa breach which we heard about was rdp so yeah i removed that from the slide unfortunately but i mean it was just a screenshot saying hey rdp is important octa but uh yeah no so rdp is attacked and uh there's a lot of ip's out there and some of this some of them are my honeypots so you know i'm increasing the number of exposed rdp systems but uh it's used then it's a low hanging fruit and it's brute forcible so of course and and you know the ransomware groups they're going after a low hanging fruit um but in the octa case they purchased credentials on a forum and then you leverage them and there's a they are rdp credentials for sale on forums so yeah yes it's real it's used and it's it's not gonna go away but uh i mean stop exposing rdp in my case of what i can say for sure is that there are a lot of i mean they spoke about it a little bit in my slides just from the three sample domains i looked at i think it was over 400 different domains with active mx records that were nonsense domains that don't have real services that i'm aware of behind them the bigger question is who's behind them and what are they using them for i think the part of my talk that was most interesting and i think impactful for me is that it's a passive technique i can stand up a mail server uh completely anonymously on a vps anywhere in the world and i can receive these emails what i do with them i think you know um as an attacker i think that's something that needs to be researched maybe canary tokens and sending things out to these these addresses and just seeing what happens i'm really curious about that question as well um and i don't know who's behind them it would be interesting to see i don't know of any known cases other than other research i've seen on the subject but i don't doubt that it's happening um would be my take on it okay thank you a quick question for olivia about rdp did you did you do you know if two factor authentication or multiple factor authentication would mitigate uh or will mitigate what you just presented this afternoon so i think it depends on how it's implemented uh and i haven't looked at implementations i would be interested in knowing popular free ones because i don't want to pay for service to just attack it um but um i let's let's assume that it's a pin added at the end of your password uh then the net ntlm capture would work but the hash would potentially be harder to crack unless you know that is the nip appended and then you add that to your cracking rules so this would still work but is this how the implement um two factor for rdp i don't know i'm sorry i don't know but i mean i needed to ask but uh it's fair i think it's a fair answer now we're gonna talk about honeypots um because it's a field that is growing in the cybersecurity industry and there are some companies that dedicate they really make products that make it easy to deploy honeypots so i think by rdp is a great project to build honeypots uh probably there will be probably something to do with with uh with your work uh but uh do you think it would be a great idea to to use pyro dp for honeypots and literally have uh let's say uh sophisticated actors with breadcrumbs with you put some hints you put some password on the network and have them reach your server and monitor it what do you think about that i think this is what i'm doing right now no but the the problem is that uh like lately we we had um we had actor interact with our honeypots and i i we some of the attacks they kind of stopped doing them and then i was like why is so and at looking at the replay i was like okay they're transferring a large amount of files so um i i reproduced it and uh it turns out we have a bug so the the transfer really slows down uh i'm not sure quite what this is but i think that we're so eagerly fetching client-side files that even on a stat system call so the equivalent of a stat system call but like i want to know the size of the file and i want to know the the permissions for example we are grabbing the file so if the person mounts a drive with a lot of stuff on it and then drops uh with thousands of files you know drops uh folder well explorer.exe will do a stat on all these files in order to just show how long the transfer will be but pyrtp in the middle is doing just like i want all of them and so i we have issues to work on regarding that so unfortunately i haven't caught but we know so we've seen the minor crypto miner stuff being transferred and stuff like that but we do have um scalability things to look at also uh for example like on a on a typical week we'll have like 17 000 replay files to look at so i really have a triage problem the problem with those replay files is that they are all unique and binary but because they are all unique and even if you hash them they're all unique because they are timestamp in that protocol so i need to find a way and and uh lisandro was working on that actually not so long ago but we need a way to uh factor out all of the time stamping and the the bits of the protocol we don't care about and then focus on the interesting things because the only the other thing i want to do with those on it but more so than finding threat actors is finding also uh attacks like potential zero days or you know blue keep and stuff like that we do have blue keep detections and we do have detection for a couple of them built in but but um but like why did the protocol fail or who is this what tool is this guy using that is creating this kind of interaction uh at the protocol level so we're all looking at that but it's a shit ton of work and i'm have a small team and we're not making money with any of this so this is why it's slow make sense uh all right i'm gonna jump into more high level questions about red teaming the field in general just do your best guys i think it's gonna be fun so my first question would be based on your work what do you think is the cyber security industry's best next move uh that's yeah that's that's a really kind of big question i think um the next best move for the cyber security industry i think is train more people uh i think there's there's a lot of uh meat in cyber security and not necessarily experts of a super high caliber but um there's a lot of work in this front work that goes into research whether it's going through honeypot files or uh looking at stats and email collection and there's a lot of work that can be done and i think there's a lot of interest in the field and i think uh hire more people is probably the the first thing i would say is the next best thing we can do train more people i'm glad you finished but with train because hiring more people is stuff right now okay i'll try this this is super accurate and good uh i'll try to do it's go in a different direction um okay so during the pandemic something i was not doing a lot that i started doing again is play dnd dungeon and dragons and i'll i'll link it with cyber security so one of the first things uh not the first one of the latest offerings of my company is uh tabletop exercises for threat simulation and so the um what i like when i heard that is that we are now in a state where we are assuming breach we we we no longer think we're gonna protect them we are assuming breach but now we are testing you how are you gonna react and you know what's the drill do you have plans and this can be done in a simulated way without much cost and and what's interesting is that you can go deeper and then validate it one day will you know we'll have red teamers validate the plans but for most organizations and we deal with medium-sized company and smaller companies but for most of them sitting down with smart people who you know play some corporate dnd you know okay let's simulate like oh you this user received the email and clicked on that link what's your visibility uh what it was downloaded what do you have on your endpoint you know and then you just go through this mental exercise and then eventually you say like oh the computer is getting encrypted what are the map drives that are you know accessible to that computer and you just you know played you know you even could roll some dice if you want you know uh like oh this the the n drive was encrypted i had eight you know i i'm making this shit up i know i don't and i'm not doing the service that probably doesn't look like that at all but to me it sounds like interesting and then you can uh you know this is very effective and low cost because it's just a long half hour half day meeting of simulation and then imagine the client has a long list of stuff to look at he was like i couldn't answer half of the questions and so then you come back and then you iterate so i think we we are at the maturity level where we can get a lot done and effectively done to get better by by knowing how long to spend and then buying the things that will protect us you know but not not buy first because you have capex you know use humans to buy intelligently products instead and i think this is where we should go awesome awesome answer i was gonna talk about purple teaming i think the industry really needs uh purple team exercise they shouldn't pay for big red teams just for you know having a surprise and a big report that show them that they have some mistakes uh but i i really like your answer i would love to be invited to such a dungeon and dragon game so another question not an easy one but uh anyway what's the best way to use a red team for companies uh again based on your work if if you can uh like should it be to shake to to rattle the company's cage to show the secret that security is important should it be to ramp up the technology the process the humans uh how do you see red teaming in the industry um it's a really good question and i think a lot of times the red teaming penetration testing is misplaced um it's the sexy thing to do right we're gonna hire some hackers and they're gonna show us how they broke in um i think it's often mistimed or maybe not conducted in the right frame of mind in the right context um you know if i did we used an analogy earlier if i take my five-year-old and bring her to the to the taekwondo arena and i say tester you know what's the result going to be um i don't know if it's a very productive exercise to just do red team engagements without first taking the the baby steps before you're ready for it um i think purple teaming is a great use of red team assets to to work alongside and train blue teams uh train against each other um and i think that red teams are a great validation tool and i think when you reach a certain maturity in your security organization that's when a red team is is really valuable um but i think you can start with basics um and not necessarily need a red team to to introduce you to the basic best security practices all the time would be i guess my opinion on that thank you and it's also a kind of a bloated term right now like everyone's a red teamer big i don't know man i'm sure you're not and the if you have a scope are you really a red teamer you know type stuff but i think this is the the definitions and i and we don't have do we have a standard bodies that defines like what are these or we're just like the problem is that there are many definitions if you follow spectra they have their own definition of red team if you read someone else it's something else i think it's a language abuse so red team is usually used for offensive security or just pentesting ethical hacking uh in my opinion red team is really about uh you know training uh technology process humans i follow more the spectra of definition so it's about simulating threat actor based uh by using several ttps to create training opportunities for a blue team but in the industry it's used for anything you're right um yeah good answer about no but i just want this to be clear right that he is the one who should answer those questions so this guy manages a red team at a large institution and he like i am a director of research and what about you i didn't read you i like red teaming stuff but i'm not a red teamer either i'm i'm interested in it but i'm i'm definitely not at the caliber of either of these guys but i don't need to be to pull off an effective attack either which is sort of what i was getting at is we don't need the best hacker in the world to prove that you're fundamentally insecure so i think there's a time and a place to to conduct these exercises and again you know my white belt five-year-old is not going to stand a chance in a sparring session against uh Mike Tyson yeah exactly there you go so i i think context matters and time and place and asking yourself why are we hiring a red team for what to embarrass us are we doing it to actually improve our security culture i think that's what comes down to me all right that's gonna be the next red team questions goes to martin's directly you want me to read it uh okay i'm gonna try but we'll have like us and then you that's nice i think well i was gonna say it's my last question we have just a few minutes left uh but i will try to answer it uh and it's i like the it's the worst question because i know it will it will raise a debate but uh nice it's about red team uh the rt ost debate so red team open source tools so a lot of people uh care about sharing they they say that sharing is caring you should publish your open source tools you both have very awesome research uh it can be good it can be good use for the good but also for the bad and uh so what do you think about publishing all your work you said ralain before that you wouldn't publish your data but maybe you will publish tools to accelerate your this work uh so what do you think about this debate and would you publish your your job um i'm a little bit biased because i'm a net beneficiary of open source tools i'm not i'm not a net contributor um i think there's a lot of value in open source and but i do i do respect the fact that people will spend a lot of time developing techniques and and developing tools for themselves um personally i'm on the side of open source i think if you discover a vulnerability you should disclose it and do course i think putting tools out there that people can take advantage of they're great learning tools as you say i tend to be on the open source side of things um but again i'm biased because i haven't spent hundreds of hours developing a tool uh that may be obsolete three days after i release it thanks you want me to answer first oh man i'm i'm a kind of a philosopher in my times and i think i think we lack perspective like pirate re existed and was authorized or you know or happened without no one doing anything against because it was you know all countries were separated but then eventually the pirates did so much damage that the countries had to get together and create this international zone and then fucking kill them you know get rid of them because they were losing so much money so i think we're at the era like basically we're we're creating firearms okay i wouldn't like uh this is not gozegir's opinion of anything this is my own here okay i think we're creating firearms and uh i don't think you're allowed to create firearms right now right i i don't know i to be honest i don't know i know people try to pre-treaty print them maybe we're allowed and and in canada and the u.s it's probably different but i think that we lack this perspective so for now we're doing it we're having fun but eventually a hundred years for now if climate change didn't kill all of us uh we will look at this and be like these guys were crazy like they were allowed to create destructive tools and put them online whereas the defenders were not sharing right that that's the asymmetry of it right now and now the blue team folks now are sharing you know twitter accounts with iocs automated and stuff like that and and there's a lot of blue team talks good blue team talks now when i started that didn't exist blue team were kind of like uh this must suck you look at ids all day i'm bugging the pentas badass you know now blue team is sexy and which is good which is very important which is part of education that is going on but they still have sharing problems because the organizations that they are in don't understand that they should share it's not the fault of the blue teamers themselves it's the fault of their organizations and so this asymmetry is not helping them and so the red team they collaborate they create patreons they have tools you can now have like paid for offensive tooling that eventually becomes free like the porchetta industries guys which are very good they're actually like really really good with rdp right now and following all that stuff um and at at one point maybe will be like you know what like and it will be an incident like something will get hacked that it's so fucking bad that will be like okay you know what it was a bad idea the whole thing of like because they'll use fucking cobalt strike and stuff like that and so and sorry if i'm talking against you you'll have time you'll have you'll be retired by then but i i i i i don't think it makes sense if you think of it from far enough and last thing i'm i told you i was a philosopher okay so think about this at one point fire protection you had to pay for it okay you had a badge on your house it was like up in with money and if you didn't have that the fireman would come and water the house that had the little badge but the other house would burn right so eventually it became so much of an issue that it was nationalized or municipal allies i'm not sure which but like it's it's part of the things that we need as a society and so i think eventually government will be so pissed off that it costs so much money to so much companies that there will be like you know avi and you know isp protection and security in general will be mandatory like built in the things and which means that and if it's regularized it will mean like anything trying to be against that will be outlawed maybe i don't know i'm just a philosopher i should write a book we would just need to finish on that that was an amazing question so thank you everyone i hope you enjoyed i wish you a lot of flags this weekend pray with me for a windows track maybe it would be fun and that's it thank you everyone test this okay so just before you quit we do have a feedback survey so if you want to give comments to the conference uh yeah uh go go to me or just go to the survey we have the link there thank you very much we'll send it through our social