# Media

url: https://www.youtube.com/watch?v=1yIj0h8R9eE
title: Pentesting By The Numbers: What Data Analysis Tells About What We Do by Charl Van Der Walt
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=1yIj0h8R9eE",
    "title": "Pentesting By The Numbers: What Data Analysis Tells About What We Do by Charl Van Der Walt",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 3279,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230413"
  }

  This text was transcribed using whisper model: large-v2

   Good afternoon, everybody, and thank you very much for taking the time to attend my talk.  I've titled my presentation, This is Not a Game, and it's about what data tells us about  whether or not we're doing our jobs. And by we, in this case, I mean security consultants,  penetration testers, vulnerability management specialists. I'm focused on that part of the  security problem. I've been thinking about this presentation for a long time,  and I'm not actually 100% sure what I want to say, which is a problem since I'm standing up here  already. But I thought I'll start with a story that I always like to tell,  and it always makes me feel comfortable, and I think it sets a sort of a context.  It's a story that comes from Africa. I'm a South African, born and raised.  I still live there now. And we're a land of big game. We have lions, elephants, rhinos.  We can see them all the time. It's a wonderful part of the experience of living there.  And there's a story that goes that in the morning in Africa, when the sun rises,  the lioness wakes up, and she knows that she has to run faster than the slowest antelope  in order to have a meal and survive. An antelope like the springbok and that thing.  So the lion knows she has to run faster than the slowest antelope.  The antelope wakes up, and she knows that she has to run faster than the fastest lion  in order not to be eaten and to survive. And so the story goes that in Africa,  when we wake up, everybody starts running. And I find this a very useful analogy for security.  It's what we do. We wake up, and we start running. We're running away from threats.  We're running towards compliance. We're running to patch vulnerabilities.  In fact, there's a corollary to that story about the cameraman who's photographing the lion  in the bush of Africa. And he sees these two cameramen.  They see the lion approaching them in a very dangerous way, and they realize they're in trouble.  So the one cameraman reaches down, and he takes off his bush boots,  and he starts putting on some running shoes. And his colleague says to him,  but listen, what are you doing? You can't run away from a lion. It's too fast.  And the cameraman says to his friend, no, I don't have to run away from the lion.  I only have to run away from you, because the lion's going to eat the slowest runner.  And so we have this idea, I believe, in security, that we're sort of running towards something,  some level of compliance, some level of benchmarking, some level of best practice.  And if we can do it better than the threat actor, or better than our compatriots,  then somehow we outrun the threat. The problem is that I don't think it actually works like that.  I think it's much more complex. It's much more like running with the bulls in Pamplona.  There's not one lion that we have to outstrip, or one other runner that we have to go faster than.  And if we look at some of the numbers around something simple like vulnerability management,  we very quickly see how overwhelming that problem is.  CVEs alone, around 18,000 new CVEs per year.  Our data suggests that on average across all the hosts that we do vulnerability assessment on,  there's about 19 unique findings. That's excluding the informationals and all the rubbish.  19 actionable things. The data suggests that firms are only patching between 5 and 10, 20% of known vulnerabilities.  And that number gets worse the bigger your organization gets.  So you would think big organizations with more maturity are better at managing their vulnerabilities,  but in fact the opposite seems to be true. The number of vulnerabilities per host seems to go up.  And we believe that only around 5%, between 2 and 7% of those 18,000 vulnerabilities will ever be exploited in the wild.  So we can't chase down all these vulnerabilities, just like we can't run away from all the bulls in Pamplona.  And the question then is, how do we choose which of these vulnerabilities we're going to chase?  How do we put our time and effort into running away from the right thing?  And I think, and I've used these two icons which you'll see coming up again and again,  the vulnerability scanning, vulnerability assessment functions, and the penetration testing functions,  red teaming functions, have in their mission the responsibility to inform the business and inform IT,  which of these things should we be running away from, right?  But that's not actually a very simple thing to decide.  And then I had this experience last year when I was looking at some of the data that we produce.  I'm from Orange Cyber Defense, I'll tell you about myself in a moment.  But I looked at three different data sets. The first was I looked at something called Bullwatch.  It's a security advisory service that we publish. We have very clever people working 24-7,  and they send out these notices to our clients to say, this is what you should be running away from today.  And of course, the big thing we were running away from last year was log4j, right?  Everyone's running away from log4j. In fact, we mentioned it in eight different advisories, right?  We spoke about it a lot. Then I looked to see what are we actually seeing when we scan our customer estates.  And in fact, we do see log4j, but we only saw it on six hosts.  Incidentally, out of 41,000, right? So it is a big problem, but it actually has a small reach.  Then I looked to see what our penetration testers are actually exploiting in the wild.  Not in the wild, penetration testers. And actually, we only exploited that vulnerability once.  And it made me very curious about this idea of what we're being told we should run away from  compared to what we're really advising, sorry, what we really should be running away from,  you know, where the line really is, compared to what we're telling our clients they should be concerned about,  particularly through these scanning and penetration testing services.  And that reminded me, oops, this doesn't actually work.  That reminded me of a presentation from 2011, 44Con in London, by a guy called Harun Mir.  Some of you may know him as an old friend of mine. We love each other very much.  We also argue very much. And Harun did this presentation saying,  penetration testing is considered harmful. We're actually doing ourselves a disservice.  I recommend that you have a look at it. It's a very interesting topic, and I wish I could comment more.  I disagreed with him, of course, on a lot of things. I was a penetration tester myself.  But one of the points he makes is that when we do penetration testing,  we're not actually emulating what a real adversary is doing in the wild.  We're not acting like the real lion. We're just acting like the other penetration testers.  And so all of these ideas sort of started to bumble up in my mind,  and I conceived an experiment, a thought experiment.  But before I tell you about that, let me just tell you quickly about myself.  My name is Charles, Charles van der Valk. As I said to you, I'm a South African.  I live in Cape Town, and I work for Orange Cyber Defense.  I spent about 15 years of my life as a penetration tester, running penetration testing teams.  I also ran a vulnerability scanning team.  But I now act as the head for security research at Orange Cyber Defense,  where it's my job to ask and answer exactly these kinds of questions.  I have a very luxurious job.  So the experiment that I conceived looks a little bit like this.  I said to myself, well, how can we know which vulnerabilities are actually being exploited in the wild?  And it turns out there's three datasets that we can look at.  We can look at something called the KEV, or the KEV,  which stands for the Known Exploited Vulnerabilities List Catalog.  And it's a list produced by the American CISA agency to advise American government agencies  which vulnerabilities are actively being exploited in the wild.  There's currently 860 vulnerabilities on that list.  Then we can look at something that was published by Avanti called the Ransomware Top 10,  which is a list of vulnerabilities that they report are actually being used by ransomware actors.  And then finally, we can look at the EPSS, the Exploit Prediction Scoring System,  which is a project of the first organization which attempts to predict,  and apparently does so with some accuracy, which vulnerabilities are actually being exploited in the wild.  So we have a reasonably good dataset about what we're being told is actually happening out there.  Then I can look at our scanning data and try and determine which of these vulnerabilities  actually exist on our customers' estates.  So is there a match between what's being exploited in the wild and what our customers are likely to be vulnerable to?  And then finally, I can look at the penetration testing data and try and determine,  are we as penetration testers, when we're emulating adversaries in the wild,  are we actually exploiting these vulnerabilities and reporting them to our customers?  I'm going to check my time because I'm probably going to take much too long.  Right, so I want to give you some background to this data.  It's part of my story because I think it was quite an interesting exercise for us.  The first dataset that I have is from our vulnerability scanning services.  So we offer, like many businesses, a managed vulnerability scanning service.  We use a platform called Nucleus as a kind of vulnerability aggregator.  So it doesn't matter what scanner we're using, we can kind of normalize these findings,  collect them all in one place, and then collect information about them.  So what we did is as follows.  We have various scanners, Qualys, Rapid7.  There are actually a few others, but those are the dominant ones.  The findings from those scanners get aggregated into Nucleus.  And then what we do is the operational team, so the scanning team,  we call them the VOC, Vulnerability Operating Center.  They anonymize the customer.  So they mask the customer name, the business unit, IP addresses,  anything that we might be able to identify from the customer.  We do the same with customer information from the CRM,  and then we can link those things back up together again so that we can get  demographic information, so how big is the customer, what industry,  what size are they in, et cetera.  And we pull those all into a database, and for this experiment,  we looked at just under 3 million findings on hosts.  That ends up then in just one big table, which is really simple.  You can see we've got an organization, an industry, country, employee size.  Then things like asset name and IP address, as I said, are hashed.  And then OS finding port, finding description, all the way down.  It's a very simple single table that we can now model to find information  about what are we actually reporting to our customers.  And then on the other hand, we have penetration testing reports.  Now, penetration testing reports, I don't know how it is in your organization,  but really the golden standard for penetration testing reports is a Word  document that's lying on someone's desk somewhere.  You'd think that we're aggregating all this data in a beautiful way,  but we're not.  It's all in Word reports.  Those Word reports have a template, so we can sort of group them together  by template and then start trying to extract usable information from them.  And the way we do it is as follows.  We take the Word documents.  Then we use some Python to unzip them and parse the XML,  and we try and extract the actual finding information from that template  into an XML file, which then consists of the details of the report,  who was it for, how long did it take, et cetera, and also the findings,  what was reported and with what severity.  Then we run an NLP capability called Spacey from Python to do what we call  natural entity recognition.  So can I pull out of that data things like a name of an operating system,  a description of an exploit, and for us, most importantly for this exercise,  a CVE.  And it turns out this NER, I don't know if you've played with it at all,  it's fascinatingly good.  It can really do some amazing things.  But there's something that it's really bad at also.  We want to know if the pen tester exploited a given application.  If the application contains the customer's name,  the NER will pull that out also.  My team's not allowed to see that, so the pen testers have to spend a lot  of time cleaning that sort of nonsense out so that we're not exposing things  like customer names.  And then we do the same trick where we hash the customer name on one hand,  we hash it out of the CRM on the other, and we can pull that into a database.  And for this experiment, we pulled out just under 1,500 penetration testing  reports to analyze over a period of time.  And that goes into a slightly more complex structure where we have  descriptions of the project, descriptions of the finding,  and then the NER findings are pulled out in a table of their own,  and we can link that all together to get a sense of, you know,  what are our penetration testers actually doing for clients.  And the NER you'll see is able to identify a whole bunch of different kinds  of things, application names, version names, vendor names, et cetera.  And for the purposes of today's presentation,  it's able to identify with some accuracy CVEs in the data.  And surprisingly, in the 1,500 reports, there's only 57 unique CVEs that were  referenced specifically by pen testers in the data.  So I want to give you just a little bit of background so you understand the  datasets that we're looking at.  As I said, in the scanning data, that's VAC,  Vulnerability Operating Center, we're looking at 41,000 hosts,  and there's a reasonable spread of those hosts across industries  and business sizes.  There's a little bit of a weighting towards manufacturing,  which I found surprising.  And obviously, some industries are more represented than others,  but I think it's fair to say that we have a reasonable representation across  different industries, right?  So no massive bias there.  Similarly, for business size, you'll see there's a reasonable distribution  of business sizes, mainly very big or very small,  but it's reasonably representative.  And then just some background in terms of the things that we find.  So if we look at confirmed findings per host, what we see,  I'll come back to this later, is that there's about 18 or 19 findings  per host, and they're distributed like this.  To my surprise, not that many of those findings are low.  The bulk are always medium.  It seems like we gravitate towards the middle with our risk assessments.  But there's also a significant number of what I call serious findings,  so highs and criticals, so about six highs per host on average.  And just under two highs per host on – or criticals per host on average.  And then in terms of the time that it takes to fix them,  this chart shows a distribution of the age of the vulnerability.  So how long from the first time that we saw it until the last time that we  saw it across all the 2 million, 3 million vulnerabilities in the database.  And you'll see that the bulk of it sits around here.  This is zero.  So these ones are brand new.  They haven't been addressed.  Then we get a sort of peak here at around 175.  Another peak here at around 300 days.  And then this odd peak here is what I call the long tail.  Those are vulnerabilities just simply never – they never get patched, right?  And the bulk of those are mediums for some reason.  But what we see is that about 28% of the vulnerabilities get addressed  in under 30 days.  About 72% take between 30 days or more.  52% in more than 90 days.  And on average it's 215 days to remediate a vulnerability.  Now bear in mind these are clients who are paying us to perform a  vulnerability management service for them so that you can assume a certain  level of maturity.  But still, that's how long it's taking us to deal with vulnerabilities.  Now you would think that critical vulnerabilities get more attention.  And that turns out to be true.  They do get about 35% more attention.  So they're resolved about 35% quicker than low vulnerabilities you can see  over there.  But that's still over six months on average for a critical vulnerability to  be resolved by someone who's paying us to tell them about that vulnerability.  So it's all kind of slightly disconcerting information, I think.  If we look at the penetration testing data, of course,  here I can't look at time to fix because we don't have the same repetitivity  and I can't look at findings per host.  But I can get some other insight.  As I said, just under 1,500 tests.  Again, we have a leaning towards finance and insurance that tends to be the  bulk of our client base, I guess.  But a reasonable distribution across all industries in this data.  Similarly, a reasonable distribution across business sizes with the bulk  being big businesses.  That's at 47% over there.  But other business sizes also represented in this data set.  Also a variety of different test types.  We ended up normalizing on this subset of tests, web applications,  external assessments, internal, some applications,  some mobile platform assessments, some red teaming,  which is kind of gloves-off, target-oriented testing as opposed to  kind of pre-scoped testing.  With the bulk being web applications followed by externals and then  internals.  And this is what we see.  So what we did here was to develop a metric that we call CVSS per day.  So we want to normalize because some pen tests are short,  some pen tests are long, some have one tester, some have two testers.  So this metric, what we simply do is we add up the CVSS score,  which is the risk rating score assigned to each finding.  We add them all up and we divide it by the number of man days spent on that  test.  So that gives us a normalized way to compare tests with each other.  And what we see there is that unsurprisingly the highest level of  findings is when the test is already inside, right?  Connected to the internal network.  They were looking at just under eight CVSS points per day of testing.  And that goes all the way down surprisingly to red teaming where we  report just over two CVSS points per testing.  But if you looked at the distribution of findings across these different  test types, you'd see that in the red teaming,  we tend to have very high severity findings, just a low number.  And with web apps and externals, we tend to have mostly medium severity  findings.  All right, this is all just background.  In terms of the severity between the two services,  we see that in both cases, most of the findings are mediums.  In scanning, it's slightly more mediums than in pen tests.  But then there's still a high proportion of critical, so 10% for scanning  and 3.5% for pen testing.  And the sense that you get is that the pen testers are more deliberate,  more considered in the assessment of risk ratings, right?  Whereas the scanner will blindly assign a very high risk rating,  the pen tester will moderate that risk rating, I suppose,  with more temporal and localized context.  But still, 46% of assets of findings from the scanners would be high or  critical, and from the pen testers,  22% of findings would be high or critical.  I also thought it very interesting to compare the distribution of CVSS  scores assigned across the two kinds of assessment.  Here, the green line represents CVSS scores assigned by pen testers,  and the purple line, CVSS scores assigned by scanners.  Interestingly, the pen testers will sometimes assign a CVSS score of zero,  whereas the scanner will never do it.  That stands to reason because we extracted the informational findings out.  And then you see this peak in both cases around four and five.  So that's where all the mediums are being reported.  The majority of findings in both cases are mediums,  but the pen testers are reporting more mediums than the scanners.  And then towards the end here, you see the pen testers very seldom  actually report high-criticality findings.  As I said, I think there's more consideration,  more thought goes into the severity assigned to a finding,  whereas the scanner keeps going up at the end.  But in the end, the shapes are actually very similar if you look at them.  It seems like there's a similar distribution of risk ratings across  findings for both types of services, one produced by a scanner  and one produced manually by a tester.  Also thought it interesting to look at the age of the vulnerabilities.  So this is not how long it took to patch,  but how long the vulnerability has actually been known about.  And I found this pretty staggering.  So you'll see there's a significant number of vulnerabilities over here  that are over five years old,  reported by both the scanners and the pen testers.  And I find that extraordinary that somebody pays a pen tester to come in  and test, and they have vulnerabilities on their systems that have existed  since 2015, 2010 even.  So 47% of the CVEs reported across both services are more than five years old,  and about half a percent are more than 20 years old.  So fortunately we're not seeing pen testers reporting those,  but the vulnerability scanner is reporting vulnerabilities dating all the  way back to 1999,  which also gives you cause to think a little bit about what we're really doing.  All right.  But I want to get to the main question.  The main question is, are we reporting vulnerabilities that are actually being  exploited in the wild?  And the first data set that I mentioned to you is that we can look at this  Ivanti Ransomware top 10 data set.  So this is a report that's published by CSW, Securin, Cyware, and Ivanti,  and it gives an analysis of vulnerabilities that are actually used by ransomware  threat actors in the wild.  Now they don't disclose how they get those vulnerabilities,  so this data set is a little bit difficult for me to make sense of,  but they publish a top 10 most exploited vulnerabilities used by ransomware  threat actors.  And the question would be, are we seeing those vulnerabilities amongst our  clients?  So what you're going to see now is I'm going to repeatedly show you two  graphs.  I'm going to show you vulnerabilities across a percentage of our clients,  so at what proportion of our clients are we seeing this vulnerability,  and then at a proportion of our assets.  So you're talking kind of breadth and depth, I guess,  is going to be the two charts.  So we see that of the ransomware top 10,  we only ever see half of the top 10 ransomware most exploited  vulnerabilities.  The other five never appear anywhere in our data.  The one we see the most at just under 18%, at 17% of our clients,  actually, is log4j.  So log4j appears at about 17% of our clients where we do scanning,  and then it goes down from there.  And then, of course, if you look at the distribution across assets,  it's going to look different.  Log4j doesn't appear on a lot of assets, right?  It's not hugely deployed on our customer estates,  but it is deployed at a lot of customers.  Just out of interest what those vulnerabilities are,  I'm not a pen tester anymore,  so I'm a little uncomfortable with all these CVE numbers.  I'm looking at the percentages, really.  But that one, not log4j, is a Microsoft Office remote code execution  vulnerability.  So that's the sort of thing you would exploit using a phishing attack  or a water-holing attack, right?  It's not something you would exploit over the network.  And that one, which is the most commonly seen across the assets,  is an incident explorer memory corruption vulnerability,  so also something that you would need a client-side exploit for,  not something you're going to exploit over the network.  Now, of those five vulnerabilities,  how many did we report in our penetration tests?  And the answer is exactly one.  So exactly one of those ransomware top 10 was exploited by a pen tester  over about a four-year period in that 1,500 pen tests that we looked at,  and that was log4j.  Log4j and log4j was exploited exactly once in one test.  The next dataset we can look at is the KEV,  the known exploited vulnerabilities, as I said, published by CISA.  They also have their own internal processes.  We don't know how they decide to add something to this list.  But at the time that we did this work,  there were about 860 vulnerabilities that were published on the KEV by CISA  and are mandatory for U.S. government agencies to patch.  There's a drive-down obligation on those agencies to patch these 860 vulnerabilities.  Now, this is obviously a much bigger dataset than the 10 ransomware top 10,  so we would expect to see them more.  And, indeed, we do.  This is kind of how it looks if I look at a distribution of those KEV vulnerabilities  across a distribution of our customers.  So we have to think of two proportions over here.  I'll try and explain it to you from here.  So 52% of the KEV, just over half of those 860 vulnerabilities,  are never seen anywhere at any client.  42,000 assets, we don't see half of the KEV anywhere.  And then it drops down.  We see about 6.5% of the KEV at 2% of our clients,  5% of the KEV at 5% of our clients.  And then there's this peak over here where we see about 14% of the KEV  at about 15% of our clients.  And those are mostly Microsoft desktop vulnerabilities.  So it's to be expected, right?  It's a very, very commonly deployed software, very widely in use,  also being exported in the wild,  and we are seeing it at about 15% of our clients.  And then the number drops down, and there's some vulnerability, basically,  probably one vulnerability in the KEV that's seen at about 44% of our  customers.  We'll look at what that is now.  If we look at what those vulnerabilities actually are,  you'll see there's…  I just took the top 10 here, by the way, or the top 20.  I can't remember.  It's not all of them.  The list is much longer, obviously.  But there we see log4j again at the top of the list there in terms of the  number of clients that are impacted by it.  And if we look at the most commonly reported vulnerability,  it's a Apache mod proxy vulnerability that allows unauthorized redirect  into an internal network.  So not a remote code execution,  but something that would allow you to bypass a firewall or something,  for example.  In terms of distribution on assets, this one is something,  a vulnerability in Next.js that allows for a redirect from an untrusted  domain, from a trusted domain to an untrusted domain.  Again, something that you would use in a phishing attack, for example.  So not very sexy vulnerabilities,  not the sort of things that you'd kind of want to sink your teeth into  and get all excited about.  But the point being from this graph is that we do see, if I just go back,  we do see a significant number of vulnerabilities,  48% of the cave somewhere on our customer estate.  And so the question is, which of those are we testing,  are we reporting on our penetration tests?  And in fact, we've only reported one, two, three, four, five, six,  seven of those 860 vulnerabilities in penetration tests at our clients.  So a massive, if you like, disconnect from the 860 down to just seven.  One of which, again, is, of course, log4j.  And this one, which is the one that's used the most frequently,  but still at less than 3% of our clients,  is a remote desktop services remote code execution.  So unpatched Microsoft Remote Desktop,  probably exposed onto the internet as being used to access the customer  network by our penetration testers.  And then finally, we can take a look at this EPSS model.  And just out of interest, can I check how many people have engaged with EPSS  as a scoring system?  One.  Really, are you guys being honest?  This is like a French thing.  It's not highly confidential.  I don't think if you are.  I'm surprised at how little we talk about this.  So EPSS is a project by the first organization.  It's an open source, not an open source, but a free public benefit project  that seeks to use machine learning to predict whether a given CVE will be  exploited in the wild.  And in the latest version of EPSS, which is now version 3,  they've got a big cloud-based machine that does all the modeling.  They look at about 1,400 and something different variables  to make a prediction as to whether a given vulnerability is going to be  exploited in the wild somewhere within the next 30 days.  And their results are really quite astounding.  Their predictions are almost perfect, right?  Straight up the line.  They've published a very nice white paper on how they do it.  And really what they're trying to do is to allow you to make the distinction  between the thousands and thousands of CVEs that exist and the exploited CVEs.  And they've just recently published a paper on the effectiveness of their  new model, which is version 3.  And basically what they're looking at is how much effort in this comparison,  how much effort would it take us to patch 82% of all  exploited vulnerabilities, right?  So if we wanted a coverage of 82%, how much work would we have to do if we  used CVSS as a guide or if we used EPSS as a guide?  And if you're using CVSS as a guide and you want to cover 82% of all  exploited vulnerabilities, then you would need to patch everything  with a CVSS score of 7 or above, which means patching 58%,  half of all published CVEs ever would have to be patched in your organization  to deal with just 82% of the vulnerabilities that are actually being  exploited in the wild, which means an efficiency of 3.9%.  So only 4 out of every 100 vulnerabilities that you patch would ever actually run  the risk of being exploited in the wild.  EPSS version 3, on the other hand, at a threshold of above 0.88,  which is a very low threshold, you would only have to patch 7.3%  of all vulnerabilities to get to 80% of all exploited vulnerabilities,  and that gives you an efficiency of 45%, right?  So it's a much more efficient, much more accurate way of predicting  what's actually being exploited in the wild.  So we draw a report of all EPSS-rated vulnerabilities with a prediction  score of higher than 0.03.  Now, the reason we chose that is because in their own analysis,  they say you can get perfect coverage or optimal coverage from an efficiency  score of 0.036, right?  So we went a little further than that and we said, let's take 0.03,  and we drew all the vulnerabilities that reached that rating level  for the period that we also have scanning data, right?  So we could see how many of these do we find in our scans.  And indeed, we do find them.  Again, 95% of those EPSS-rated vulnerabilities, there's about 155  vulnerabilities that meet that threshold for the period that we're looking at,  95% of them don't occur at any of our clients.  But about 5% of them do.  And this kind of shows the distribution, right?  So 20% of those CVEs appear at 0.37% of our clients.  It doesn't really matter.  The point is we mostly don't see them, but we do see some of them.  So everything under the curve over here are vulnerabilities with a very  high probability of being exploited, extremely high probability of being  exploited that are being reported at our customers on our customers' estates,  right?  We know that they're there.  And the question, of course, then going back to my original thesis is,  well, how many of these are our pen testers actually reporting  to our clients?  Sorry, these are the ones that they are.  So there's an OpenSSL DDoS, which is kind of really odd,  and then there's this Windows 10 HTTP server exploit.  Those are the ones that we're seeing on our customers' estates.  But as I said, the question really for us is,  how many of them are our pen testers reporting?  And the answer is an astounding zero.  We couldn't find one of those vulnerabilities in a single pen test  report that we gave to our clients.  Now, I'm not saying that's right or wrong or good or bad.  I'm not a pen tester anymore.  I'm a researcher.  But I did find it quite astounding.  And I thought it would be worth having a conversation with the security  community to ask, like, does this make sense?  If we're not reporting these vulnerabilities to our clients in pen tests,  then are we telling them the right thing?  I want to point out something else that occurred to me when I was looking  at this data, which also sparks debate.  So one of the things that we did was to look at how much are we reporting  to clients per day over time, right?  Now, these graphs get a little bit sticky.  But basically, when we went back as far as 2018,  you'll see that the average CVSS reported per day,  so a sense of how much are we saying to the client, in 2018,  in the first quarter of 2018 was 5.5.  By the time we get to the first quarter or the third quarter of 2022,  that's when our data collection stopped,  we're only reporting just over 4.5, just over 4.  So there's this dramatic increase in the volume of things that we're  saying to our customers.  In fact, if I were to show you this graph for only new customers,  so this includes businesses that are coming back again and again and again,  if I only looked at businesses that came to us for the first time,  you would see a 50% decrease in the volume and severity of findings that  we're reporting to our clients.  There's another perspective that we can use to look at the same data.  I just wanted to draw your attention to this drop.  Sorry, before I forget.  So this is at the peak of the COVID lockdowns, right?  I'm going to just draw your attention to this because we're going to come  back to that in a moment.  But this is another perspective on the same question,  where we look at the ratio between serious and not serious findings  in a report.  So in 2018, in fact, here in Q4 of 2018,  71% of the findings in a penetration test on average would have been serious,  high or critical findings.  By the time we get to Q1 in 2022, it's only 33%.  So we've gone from three quarters of the findings being serious to only  one-third of the findings being serious over a four-year period.  And this question of why these numbers are going down like this makes me  very curious.  Why would it be?  So another perspective we took, and again, there's that dip, by the way.  There's the Q1 or Q2 of 2022 where it reaches its absolute lowest.  So one of the explanations might be that as customers are coming back over  and over, the number of findings we're reporting is getting less and less.  And in fact, that does seem to be the case.  So for customers who only test with us once, we're reporting 4.7 CVSS points  per day.  For customers who come to us more than 10 times, it's like 4.6.  So there's a line downwards.  What's odd is this jump over here.  So I said more than one, but basically this means two,  because more than one but not more than two is two.  So I don't know why I made it so complicated, but it's two.  So this is two.  When they do two, we have the highest number of findings.  And the conclusion we reached is because normally when a customer does  exactly two tests with our teams, they're doing one internal and one  external once.  So basically, this is almost an anomalous situation where it's like a once-off  for compliance.  The customer comes in for like a one-two.  It's like a mani and a pedi.  You know, you get your feet and your nails done.  But you only do it once.  So that's where that very high number comes in.  But then it sort of drops down from there the more tests the customers do.  So why would it be that we're seeing this decrease in levels of finding  over time?  Well, the one theory could be that security is just getting better.  Maybe between 2018 and 2022, our clients have become better at securing  their systems.  Another theory is that maybe our testers are getting worse.  You know, I don't know how many of you are young testers, but obviously,  my generation were much better than Mia's generation.  You know, we had the...  But I don't think either of those are the case.  One theory that I've got, which I think is very interesting,  is that when we look at new customers who are coming to test,  they're generally testing new systems.  And those systems are now often being built with, you know,  cloud-based hosting, you know, all kinds of sort of cloud-based back-end  stuff, much more robust development frameworks, et cetera.  There's much less legacy in those platforms.  And that would help to explain why we see this massive drop-down,  which I think is encouraging and is a good sign.  And then Dominic White, who's sadly not here,  but he leads our pentesting operations, he made another point,  which is, if you recall that dip in 2022, he says,  what happened is that in 2022, we couldn't go onsite to customers anymore.  And so now testing started to happen over a VPN.  And so the perspective that the tester gets of the environment that they're  testing becomes much more constrained.  And of course, even though the lockdown's lifted,  those habits continued.  And so now basically the testers are getting a much more constrained scope of  what they're seeing.  Anyways, that's a bit of a throw-aside observation of the data that I  hoped you would find interesting.  I want to end with a bit of a different observation.  So we've been looking a lot at numbers and how much we see things and how  often, you know, they occur, et cetera.  But, of course, what people have been talking about a lot,  and I'm sure you have also, is this recent last-pass compromise.  And I don't know about you, but I've been working very hard to try  and understand exactly how that compromise happened.  Thank you.  And I haven't fully got my head around it.  But, of course, they were hacked purportedly for the first time in,  like, August of last year and then for the last time in March of this year.  And it turns out that it's actually a series of three interrelated  compromises, right?  So we know that in the beginning they compromised some development  environment using compromised endpoints, which allowed them to bypass MFA.  And now they're drifting around in a development environment somewhere.  LastPass catches them and throws them out.  And the report they give us is no damage done.  A little bit of customer data perhaps leaked out, but it's all in vaults.  It's all encrypted.  Everyone is safe.  Then we find out that there was a second compromise.  And this compromise involved a cloud environment, which was co-hosted  or shared with their owner, which is a company called Goto.  And they're able to get some other data, including access  to the backups of the full vaults, right?  So now they've got the full encrypted vault, but they don't have the  passwords to unlock the vault.  And so just a few weeks ago, we get the report that they somehow  managed to find a developer's home network, somehow identified a Plex  server that the developer was running that had a vulnerability on it  that they were able to exploit.  And then somehow from there ran a key logger on a machine that he was  using to log into the vault and then use that password from the vault  to decrypt the passwords from stage one and stage two.  And now it's, I don't know, now it's a disaster, right?  Now it's a big thing.  And I thought to myself, this sort of thinking, this sort of activity  is not being represented in my data, right?  This sort of stringing things together from like one environment  to another environment and finding the developer's home network.  How did they even do that?  I don't know.  You know, they found this guy's home environment, found his Plex server.  It's just a remarkable level of sophistication and operational coherence.  And it occurs to me that one of the stories we could be telling about  pentesting is that this is what pentesting should be showing us,  not reporting on the CVEs that the bad guys are also using in the wild.  Of course, the twist in this story is that they did exploit a CVE, right?  That's what almost everyone is talking about the most.  They exploited a CVE in Plex, CVE-2025-741,  high severity flaw in Plex media server.  And this was apparently what allowed them to get access to the developer's  network to deploy the key logger, to steal the password vault,  to decrypt the data, right?  Key.  So I got to wondering, well, do we see that vulnerability?  Turns out that if you take the EPSS scores for the last 12 months  and you look at everything over 0.03, it doesn't appear.  So I don't know if that would have been useful to them.  And, of course, we didn't see it anyway, right?  We didn't see it on any of our customer environments.  Anyway, I don't know what that means.  I just thought it provided a bit of an interesting counter example to,  like, how exploits actually happen,  or compromises actually happen and how useful our scanning  and our testing is at predicting how they happen.  I want to end with this thought.  Harun Mir, at the end of his presentation,  says having criticized pen testing left, right, and center, he says,  look, if you think you have smarts, if you think you're a clever person,  then maybe this is something that we need to think about.  I don't know what this data, what these observations are telling us  about how effective our risk assessment is using scanning and pen testing,  but it certainly raises a lot of questions for me about whether we're  doing the right thing to advise our clients about how to make sense of all  the threats that are chasing us down in the wild.  And that's all we're going to have time for.  Thank you very much, everyone.  Just a quick one.  If you want to read our report where most of this data is in,  it's called the Security Navigator.  There's the URL there.  Not all the data is in that report, but some of it is in there,  so take a moment to have a look-see.  Otherwise, I think we've maybe got a few minutes for questions.  Yes.  Thank you, Charles.  So, ladies and gentlemen, if you have some questions,  you have 15 minutes to ask Mr. van der Valk.  Thank you.  Please, somebody ask a question.  Oh, there's one.  Hello.  Thank you.  Nice presentation.  I love the slide background with the high score.  That was awesome.  But the question is do you think that one of the issues we're seeing with  vulnerabilities is that we have an increased number of vulnerabilities  with CVEs reported for very specific non-enterprise technologies like IoT,  OT systems that are inflating these numbers and so making it harder to get  stronger signal from that overall noise?  Yes, I do think so.  I think it's very clear to me that between CVE and CVSS,  we've created a bit of a monster that might not actually be useful to us.  And I think that the security community,  the vendor side of the security community definitely needs to start  changing our narrative around those vulnerabilities.  It's not useful, I think, to, you know, as a pen testing company,  one of the things that we're asked when we present to customers is,  well, how many CVEs have you published?  You know, so CVEs, publishing CVEs becomes a sort of a scoreboard.  And I don't think that's useful.  It's not helping us.  I think it's useful to have that common designator,  but I think we're using it in the wrong way.  And it seems also clear to me that the CVSS score, for all its good intent,  is not actually adding a lot of value,  certainly when it's statically ascribed to a single vulnerability.  I do think so.  One more question.  Oh, there's another one.  Yeah, inspiring talk. Thanks.  Thank you.  I wanted to follow up.  I thought the part of the different industries is really interesting.  And I wanted to ask if,  was there some indication that some industries which are maybe like denoted  to be slower adopting new stacks, be less tech savvy,  that they kind of perform worse in terms of your terminology of CVSS points per day?  Yeah, there is.  Let me see.  I might actually even have the data.  There's one of these slides.  There you go.  That's what it looks like across the industries we have in our data set.  Now, it's not a perfect representation.  The blue line shows the total number of days that we spend testing in that industry.  So it gives you a sense of how many customers, how much effort we put into that industry.  And the green line shows the CVSS per day.  Now, I think the ones with very low blue lines we can ignore because they're probably anomalous.  So I think you can ignore retail.  Sorry, you can ignore real estate.  That's obviously a very small data set, so I wouldn't worry about that too much.  But you can see, for example, as one would expect in finance and insurance,  the number is much lower than in something like, there you go,  in professional and scientific services where we see a higher number.  So there is a variance.  I can send you this data.  In fact, I think we published this data in the report also.  But I don't think that my data set is big enough to really draw conclusions  about whether some industries perform better than others.  I'll share another anecdote.  One of the things that my team has been very interested in understanding  is that we see, in terms of compromises in the wild,  we see a very high number of compromises in the wild at manufacturing businesses,  so businesses that are NAICS classified as manufacturing.  And we're trying to understand why that is.  And so we compared the manufacturing industry to all other industries  in terms of how long does it take them to patch,  how many vulnerabilities per host, CVSS per day,  all of those things to see if they stand out.  And actually they don't.  I was very disappointed as a researcher.  I had all this data and I thought I was going to be able to explain  why we see so many exploits or compromises in one industry  compared to other industries.  But the answer to that question doesn't seem to be in how long it takes them  to patch or how many vulnerabilities they have per host.  I don't know if that answers your question.  There's one more there, I think, in the middle.  Thanks a lot.  My question is, in my experience for pentests,  a lot of the things that you see are, I would say, maybe 40%,  in my case, are actually not really related to CVEs  but more business logic flaws and implementation flaws,  more credential management, clear text.  How do you deal with that and how do you put that in your...  In this study, we're not trying to look at that  because we wanted something that we could cross-reference  and, of course, that's CVE.  So I haven't actually looked at how often those kinds of flaws  appear in the data.  The NER is actually able to pull it out, which is quite nice,  but I haven't studied that.  I guess the question that I would ask back is that pentester  is reporting sophisticated web application business logic flaws  to a customer and they're fixing it.  That's obviously work well done.  But if the customer is actually being popped by ransomware actors  using a known vulnerability in Internet Explorer,  that's the dissonance that I'm curious to understand.  And I think that's the point Harun Mir was making  when he said, are we emulating the attacker  or are we emulating the other pentesters?  There's this sort of remarkable level of technical agility  that emerges in the pentesting space,  but really what's happening if you look at, for example,  cyber extortion and ransomware is it's password reuse,  credential stuffing, unpatched Internet-facing servers,  and phishing over and over and over again.  And I suppose exactly that is the question that I'm asking is,  should we be doing all that web application gymnastics  or should we rather be focusing on looking broadly  and identifying these vulnerabilities that are exposed in the wild  and patching those very quickly?  Maybe that's a more sensible approach.  I don't know, but I think that's the question I'm asking.  I think there was a gentleman over here.  And just to add, I'm sure there's not one answer to that, right?  It's probably some mixture between both.  The gentleman with the orange shirt.  Thank you.  My question was in the same way.  It was much more about context.  Because if you look at a given CVE,  it will not be the same risk if it's inside or outside.  How do you deal with that in your reports?  So I'm not trying to deal with it in my reports.  It is one of the criticisms that's leveraged against the EPSS.  It's exactly that.  And there's this concept of, what is it?  It's like path to code or something.  So what is the route that you have to get there?  But the EPSS working group counters that by saying,  actually, if you ignore that completely  and you just look at what are we seeing being exploited in the wild,  then their prediction system, path to code notwithstanding,  is in fact very, very powerful at knowing how you're going to be hit.  So I think, yeah, I'm not trying to address it,  but I know that EPSS addresses it by showing this perfect 45%  45-degree correlation graph that says,  if they said 100% it's going to be exploited,  then 100% it gets exploited, regardless of what the path is.  So I guess their model is perhaps taking some of those variables  into account, even if it's not deliberate.  Okay, I guess that's all we have time for.  Thank you very much for your attention.


url: https://www.youtube.com/watch?v=QUsZzILzJnA
title: Inglourious Drivers: The Revenge Of The Peripheral Devices by Omer Tsarfati
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=QUsZzILzJnA",
    "title": "Inglourious Drivers: The Revenge Of The Peripheral Devices by Omer Tsarfati",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2301,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Thank you. Hello, Insomniac. It's really great having you all here today. It's really great  to be here today. So today we'll talk about inglorious drivers. The less glorious drivers  that exist out there. And for those of you who already managed to detect the typo in  my slide, so congrats. There probably might be more in other slides. Those are not intended,  but this one is. So basically it's an homage to the great movie of Quentin Tarantino, Inglorious  Basterds, which just uses the same typo. Unfortunately, we are not here to talk about movies, right?  We're here to talk about kernel drivers. So let's begin. My name is Omer Tsarfati. I'm  a senior security researcher at CyberArk Labs. I'm doing security research for more than  eight years, something like this. In my spare time, I like playing basketball. When I'm  not doing that, probably I will play some video games. And when I'm not doing that,  I do some research for my own pleasure. All right. So today we'll talk about a few things.  So at the very beginning, we'll talk about the Windows driver framework. Right after  that, we'll talk about some common mistakes that driver developers tend to do. And then  we'll talk about one specific driver that created a really big mess and for some reason  is widely used by a lot of vendors. Right after that, we'll talk about how we managed  to utilize total for finding even more vulnerabilities than we found in the research that we conducted.  And at the very end, we'll talk about some mitigations to the vulnerabilities we found  and how you guys can mitigate most of them with one simple trick. All right. So before  we start talking about the Windows driver framework, I want to tell you a short story.  So a few years ago, I made a decision. Maybe not the best decision that I ever made, but  it was a decision. And I went to the store and I bought myself a gaming laptop. So I  got this gaming laptop manufactured by MSI. And as some of you may know, the most important  thing when you're playing video games on your computer, it's not about the graphics. It's  not about the whole experience of the game. It's more about FPS. So basically, the more  frames you have, the more fun you have eventually. So there are a lot of ways to achieve FPS.  One excellent way is to ensure that your cooling system is good and everything will stay chill.  Unfortunately, gaming laptops suffers from overrating. So basically, you need to set  your fans to their max most of the time. Another way to solve this problem, you can just add  a nice spoiler to your rig. It might also help. I don't know about that, but it might.  So MSI was kind enough to develop this program called Dragon Center, which allows you to  control a lot of things around your computer. And one of them is the cooling fans. But there  is one thing about that. I don't really like its GUI. So I wanted to create my own program  that controlled the cooling fans. And before I started to write any code, I started thinking  which component in the system controls the cooling fan speed and how everything works  around this. So basically, I thought that it's a user mode program application which  talks to a low level kernel driver. And before we're talking about user mode application  communicate with kernel drivers, we need at least in all operation system and specifically  in Windows, we need to talk about privilege level architecture. So in Windows, we have  four different levels of privilege. Four different privilege levels. So the lowest  one is the sandbox process, which there are not a lot of processes run as a sandbox process.  Mainly your browser, teams, Slack, Discord, stuff like this. And we have the non-admin  processes, which most of your program on your computer runs as. And then we have the services  and the admin processes, which are considered to be a privilege level, which means that  if an attacker runs as an admin process or a service, probably your computer could be  ultimately taken over. And last but not least, we have the OS kernel, which includes also  the kernel drivers. So some of those kernel drivers interact with hardware, and one of  them might interact with the cooling fans. So basically, MSI needed to develop kernel  drivers that interact with the cooling fans, but when one is developing a kernel driver,  it actually takes a lot of risk and also a lot of responsibility for this. So that's  because you are part of the kernel. So all the drivers just share the same system address  space and essentially are part of the kernel. Fortunately, nowadays, they all need to be  signed. So there is a mitigation for that. You can disable it. Don't do that. Also, you  need to be in admin privileges. So, yeah, just a good thing. And don't screw up, because  you're talking to hardware. You're filtering stuff. If you're not handling things correctly,  you will just crush the system, and this is not a good thing to do. At least if you're  a developer. If you're an attacker, do whatever you want. All right. So here we are as security  researchers, right? So from security perspective, when we are talking about drivers, we want to  know two main things. We would like to know which access we have to the driver. So do I have access  to talk with the driver and what are my permissions and how do I communicate with the driver and how  does the driver actually parse data that I'm sending to it? So let's talk about access.  In Windows, in order to interact with the driver, the driver needs to create a device.  So the driver creates a device object and should specify which user can access it.  So this is actually done by using a security descriptor, which can be located either in the  INF file that comes along with the driver or in the driver entry. And this is set by calling  Iocreate device secure. So as you can already understand, there is also a function called  Iocreate device. Not secure. Basically, what's going to happen when you call this one,  so the default security descriptor will be applied, and basically it means most of the  users on the system can interact with the device. So in order to make sure also the device object  accessible from user space, you need to create a symbolic link, and this can be done by calling  Iocreate symbolic link or Iocreate device interface. Then the user or the user application  or the driver needs to call create file or create file to have a handle to the device.  So here we can see a driver called VidSys exposing a device object called VidExo.  You probably can't see anything, so let's do a quick zoom. Yeah. All right. So on the left-hand  side, we can see the driver object and all the devices it exposes to the object manager, and  on the right-hand side, we can see the groups and the users that have access to the device  and what they can actually do with the device. All right. So let's talk about communication.  So the driver register need to register and dispatch routines through using the major function.  So basically, it means which operation the driver supports. So there are about 27 different major  functions that exist. Most of them are not commonly in use. Mainly those five are in use  commonly. So you have the create, close, read, write, and device Iocontrol.  Which is we'll talk about it later is the most important one for us. All right. So this is our  driver entry will look like. So it's like your main function of the driver. And we can see here  there is a call to Iocreate device, which will create a device called test DRV. And after that,  there is the registration of the major function. And as I told you before, the most important one,  the IRPMJ device control, which most of the interesting logic exists in at least for our  needs. All right. So just like in network, like network packets, we also here have also packets.  But little different packets. So those packets called Iorequest packets or IRP for short.  So IRP contains any of the dispatch routine you would ever need. So the IRP structure is  generated by the IOManager. And it consists of stack location, which is where all the important  members reside. We have the request mode. We initiate the call. If it's the kernel, if it's  the user land. The input and output buffer sent to the driver. And the IO status information,  which indicates how many bytes should be written back to the output buffer. Any misuse of those  fields would probably cause a bug. So you might crash the system. You might allow arbitrary read,  write in the kernel. So this is bad. All right. So besides that, the IRP struct also contains  a field called IO control code or IOctal for short. It's a number that's used as an identifier  for other programs to execute specific logic in the driver. So the IOctal is just a function  identifier, right? So it's basically packing a little bit more than that. So it's a 32-bit  packed structure. So the first two bits indicates what is the transfer type of the request that's  sent. And the 13 and 14 indicates the required access of the request. All right. So let's talk  about the required access. So it's actually described the required permission to send to  the device IO control request. It's based on your permission when you called anti-create file or  create file. So it depends on the handle you have. So there are about four different options. File  any access, file read access, file write access, and file read and write access. So those are  actually in order from the least privileged one to the most privileged one. Also, we have the  transfer type. So this actually describes how the IO manager treats the user data. So here we have  a lot of different nonsense that the driver developer must know. And when there are a lot  of different things you need to know, you should know there might be a lot of bugs. So there are  four different options here. We have the method buffer, method indirect, method out direct,  and method neither. So here it's also in order from the most secure one that is commonly  considered to be the most secure one to the least secure one. So method neither as one of my  colleagues call it the mother of all evil. So, yeah. All right. So in order to send a device  control request, we will use the device IO control function which takes a handle to the device. It  takes an IO control code and the input buffer and its size and the output buffer and its size.  All right. So by now we know a lot and we know how to interact with drivers in Windows. So let's  talk about mistakes. All right. So let's talk about method neither. So in this case, the IO  manager is actually pretty much lazy. So the buffers and the lamps will reside in user mode  and the kernel doesn't copy them to the kernel space. They can be paged out and it can cause  some problems. The input buffer will be type 3 input buffer. The output buffer will be the user  buffer. So the user can allocate and deallocate the buffers making those pages invalid. So you  need to be cautious when dealing with them and also you need to know that every access to the  buffers must be in a try except block. Also, you need to do some probing. So whenever you want to  read or write to the buffers, you need to use probe for read and probe for write accordingly.  But if you don't do them or you don't use them correctly, it will throw some errors on invalid  address. So the call actually, if it's not in try except block, will crash the system.  If the lamp is zero of the buffer that is sent by the user, so actually those probing do nothing  and the validation just passed away. It just passes. So if you're not probing correctly,  the kernel reads and the kernel reads from the buffer, you will crash the system at the very  least and, well, at least for us as security such as you might have some info leak and if you're  doing it for writing, you will either crash the system or allow arbitrary kernel write.  All right. So this is an example of a buggy code from a real driver. Here we can see that the  driver developers didn't hear about probing. So in the first box, the driver reads the  input buffer. We see there is no probing function before the usage. In the second box, there is a  dereference of a pointer without checking if the buffer is null. So this also might crash the  system. On the third box, the address could already be paged out causing a crash when writing  to the output buffer. And besides that, the input and the output buffers access not in a try except  block, try catch block. So the driver can get access denied and crash the system. And also,  in the second box, just like in the second box, also in the fourth box, there is accessing to  the input buffer without any validation. And lastly, it's not in a box, but the access to the  output buffer doesn't involve probing, which will eventually allow us to do an arbitrary kernel  write. Memory write. So, yeah, this is also a problem. Let's talk about the better brother  in the family. The method buffer. So method buffer, in this case, the manager copies the  buffers and the lamps to the kernel in a secure manner. So those reside in kernel memory, not in  user space memory. You don't need to probe anything. So this is good. But you have to  remember, if there's any fields that are embedded in the buffer, you need to treat them properly.  So you need to do validations when you're accessing those. In this case, the input buffer  and output buffer will be the system buffer as part of the IRP structure. And also, we have the  IO status information, which actually, as I told you before, indicates how many bytes should be  copied to the user's output buffer. If the IO status information is bigger than the input buffer  length and the output buffer length is bigger than the input buffer length, the rest of the system  buffer will be copied to the output buffer. It will be uninitialized memory. And this could  lead to info leak or crashing the system. So let's say we have one page of the output buffer  length. It's one page. The input buffer length, it's eight bytes. And the IO status information  will be output buffer length. So we will leak about one page of memory from the kernel to the user  space. All right. So here we have also an example to method buffer to implement a method buffer.  Again, it's not safe to assume that this code is bug free. Of course, it's not if it's in the  presentation. All right. So on the second box, we can see a nice length check. And beneath the check,  they initialize some memory. After that, there is a if statement. If we fail to go into the first  if statement, we'll go to the else. And in the else, there is a information with a really big  number. Around 11K of kernel memory that could be leaked. And in this case, we'll just have a huge  memory leak or we'll crash the system if we'll get into an invalid page. All right. Let's talk  about direct IO. So in this case, we have two different methods. So we have method indirect  and method IO direct. So in this case, there are two buffers that send into the kernel. So we have  the system buffer and the MDL address. The second buffer is a direct buffer, which always will be  paged in. So faster access for us. And this buffer can be used either for input or output.  A kernel driver can also create MDL by using IO create MDL. Which is quite important. We'll talk  a little bit about that in the next slide. And if this function fails for some reason, so let's  assume that you gave it an invalid page. So it will, for an exception, and if this one is not  handled properly, you will crash the system. All right. So you might ask yourself what is MDL?  So MDL is a structure that describes the fixed physical memory location that comprise a contiguous  data buffer in virtual memory or in simpler words. So the MDL actually describes the data buffer in  a fixed position in physical memory, which will be always paged in and locked in memory. So basically  double mapping one for the user and one for the kernel. Let's see an example of not writing a  good code with direct IO. So in this case, we can see in the red box, we have a full control over  the MDL. So there is a variable with an original name, controllable virtual address.  And here we can see that there is a call to MM probe and lock pages, which is not wrapped in  try except lock. And if we will send an invalid virtual address, we will trigger a BSOD and we  will actually crash the system. All right. So we talked a lot about mistakes that other developers  do. We also I also showed you some examples. Let's get back to the MSI thing. All right. So  back to my laptop. I tried to find the driver that Dragon Center interacts with.  Lucky me, I found the one that it interacts with. It's WinIO, which is loaded by the Dragon  Service. And I check if I have access to the device. It exposes. And fortunately, I do have  access to interact with it. So I open IDA and started doing some reverse engineering.  All right. So here is the decompiled code of the dispatch routine. Here we can see the system  buffer, which is the buffer sent by the user to the driver and its length. And here we can see  there is a switch case. A switch case goes over the different major function. And there's also  another switch case embedded in it, which goes over the different IOC that the driver supports.  And for those of you who managed to see line 47, you might already found a bug. So in line 47,  there is a mem copy from the user buffer with a controllable length to a local variable.  So it actually means there is a potential buffer overflow here. Right? So, yeah. If you send a  buffer in the size of 32X plus 8, we maybe would be able to overrun the return address. Right?  And this is what we did. So we send the buffer and because the system. So, basically,  we overwrite the return address and we manage to run code in the kernel.  You're probably asking yourself, hold on. Isn't there any stack that would prevent this?  So they didn't compile the driver with stack. And this is bad. Don't do that. Use stack. All right.  So don't worry. It's not the only bug that exists in the driver. Basically,  the driver also lets low level processes to read from IO ports and read to IO ports.  And also, it lets you to yeah. All right? And also, it lets you to unmap and map physical  memory into virtual addresses. So, basically, you can read the whole memory. Yeah. So, this driver  was a really buggy one. I didn't find what I wanted to find. But I found a lot of bugs.  Yeah. So, this is a lot of process. But wait. There is more. So, as I told you before,  as a gamer, I want as much FPS in games as I can get. And only real gamers know that RGB gives you  more FPS. So, I made another decision. Again, not the best decision, but it is a decision.  And I went to the store and bought myself a gaming keyboard manufactured by Razer.  All right. So, Razer was also kind enough to develop a program called Razer Synapse,  which lets you control the RGB lights on your computer and stuff. And of course, as a good  gaming program, it also has its own drivers. So, there is a driver that the Razer Synapse  service loads called R0 Razer Synapse service. Original. And it exposes a device object name.  Right. So, just like before, I located the driver file and started doing some reverse engineering.  So, let's jump into the code. So, we also have the main dispatch routine. We'll go to the device  control function. Yep. So, fortunately here, we can see that the driver developers did something  different. They did some validation over the buffer length. So, this is good. Right? So,  we won't find any buffer overflows here, unfortunately. Yet, there are still some  vulnerabilities in this as well. So, here we have a port read and write primitives,  just as before. And also, we got this thing. So, this is actually interesting. Because the  driver lets us to read and write to arbitrary MSRs. All right. So, at this point, you might  ask yourself what MSRs are. All right. So, MSRs are model specific registers. So, it's basically  any various control registers in x86 instruction set used for debugging, program execution pricing,  computer performance monitoring, toggling certain CPU features. And there is MSR called IA32L star,  which holds the pointer to the system call handler, which upon sys calls, this pointer is  loaded into IRP. And as you can already understand, if you will overwrite this specific MSR with  arbitrary pointer to whatever we want, we will achieve arbitrary code execution in kernel context.  So, this is not good for the developers. For us, it's great. All right. So, but we didn't  do one thing. We didn't check if we have access to device object. So, let's jump into the driver  entry to the Iocreate device. So, as I told you, the Iocreate device is the not secured one,  which will create a device with a default security descriptor. So, in this case, it means  that we will have access to the device and we will be able to trigger this vulnerability.  So, previous escalation confirmed. Or is it? When we went to the device object properties,  we looked at the security that applied to the device, and we can see that only administrators  system can interact with that. So, we can see a clear inconsistent between the driver code and  the device security object. So, the driver doesn't enforce any security descriptor.  So, the only logical explanation for this phenomena is that some other process just  changes the device object security. All right. So, basically, it will look something like this.  So, we have the WinRing 0 driver loaded. Then the WinRing 0 creates a device with the  default security descriptor. Then some random process just changes the security descriptor.  And here we are. Yeah. But there is a small time gap between the creation of the device object  and the time that some random process just changes the security descriptor. So,  there is a race condition there. And as attackers or security researchers, we can actually abuse  this one. This is true as long as we are managed to run our code before the random process runs  its code. Yeah. So, basically, after doing some research, some further research, we get into this  one. So, Razor signup service uses an open source project called Libra, which loads the WinRing 0  driver. Then the WinRing 0 creates a device object. And there is a race condition. And  some random process changes the device security descriptor. Fortunately, the Libra will monitor  Lib. It's an open source project. So, we quite easily could find its source code. So, let's see  what this one does. Right. So, here we can see the DLL actually open handle to the service manager  and creates a new service or, in other words, in this case, creates a new driver. And then it's  asked the service manager to load the driver. Right after that, it opens an handle to the created  device. Yep. All right. So, right after that, it opens handle to the created device and changes  the security descriptor. Right. That's cool. Unfortunately, this service runs way before us. So,  basically, we won't be able to win this race condition. As far as I know, we need only to  restore the driver in order to restore the service in order to achieve to win this race condition.  Yeah. So, this is bad. But they still want to find a way to exploit this vulnerability. Right?  So, in order to restore the service, you need to be admin or in the privileged level. Or you can  just trigger an update. So, basically, when there are updates, there is a signup program,  commit an update. Everything shuts down. So, all the services and all the other stuff that comes  with it just closes. The update is triggering. And then you can actually create a race condition.  Unfortunately, updates happen once in a month. Twice. Like once in two months. So, this is not  good for us. We want to trigger it upon our request. Right? So, we found that we can abuse  the plugin mechanism to trigger an update like scenario. So, yeah. Basically, Razer lets you  to install some three plugins, maybe more. And we whenever you install a plugin, so,  it will consider as an update. Everything will shut down. And then we can trigger the race  condition. And another fun fact about the source code, there is a to do, which replaced with call  to Iocreate device secure driver. They didn't do that until today. So, yeah. All right. So,  this is how the flow looks like. So, we will write our POCX. It will ask a Razer service to install  the plugin. A Razer GMS service will initiate an update like scenario, which shuts everything down.  Wing 0 will be unloaded. Then it will be reloaded and it will create an object with a  default security descriptor. We have our race condition there. And then the DLL will  change the device security descriptor. All right. So, let's see a demo.  Cool. So, you have the Razer setups.  All right. So, here we can see all the plugins you can install. We will install the Alexa plugin,  for example. Yeah. We run as low privilege user without that many privileges, unfortunately.  We will run our exploit. So, now, actually, we're downloading the Alexa plugin.  After it finishes downloading, we will send a message to the GMS service to install the plugin.  Here we can see that everything shuts down. The service is unloaded and deleted.  Now it's reloaded and we will try to open handle to it. We manage to open handle. We abuse the MSR  IA32 to run code and we manage to change our permission into system or application token.  Right. So, let's talk about aggregation. So, basically, we use ViewersTotal to find even  more vulnerabilities. Most of the time you will use ViewersTotal to run for malwares.  So, we came up with an idea to find similar vulnerable drivers. Because the one that MSI  used is really similar to the one that Razer actually is using. So, we thought that there  might be more. So, we wrote a simple return job query that includes some debug strings from the  driver and we found 114 drivers that exist out there by that too many vendors actually using  those. We are talking about ASRock, MSI, Razer, ASUS, memory, and much more. So, this actually  was really nice to find even more vulnerable drivers by just using ViewersTotal. Yeah.  All right. So, let's talk about mitigations. So, interestingly, just by having Hyper-V  enabled on your system, you can mitigate some of the risks we talked about. So,  hypervisors, by design, can intercept any modification action initiated by the OS kernel.  And Hyper-V, by default, prevents any modification to I32L star because it doesn't make sense that  you will want to change this one. As long as you're a legitimate user, if you're an attacker.  So, yeah. You might want to do that, but Hyper-V won't let you. Unfortunately, Hyper-V can do that  and won't protect you from buffer overflows and stuff like this. All right. So, this problem is  fixed. Sadly, only partially. The kernel driver is still there and it's actually still being used  by different vendors. I don't know why, but it still happens. As an end user, I will recommend  you to enable Hyper-V on the system and use antivirus that blocks malicious drivers. So,  some of those drivers are considered to be malicious nowadays. As a developer, please,  don't use the WinIO codebase. And neither any of the different variations like WinRing 0,  MSI 64, and et cetera. And if you do, please, fix the embedded security issues.  All right. So, we got some CVs during the research. We also wrote a blog post about that.  The QR code will be also in the next slide if you want to scan it.  So, yeah. Thank you very much. I had a great time presenting this talk to you.  And feel free to contact me via Twitter for any questions. I'm also around here.  Thank you.  Do you have any questions?  Yep. Might get you the microphone.  Thanks for the great talk. So, you have said that  the Hypervisor intercepts the rights to the MSRs. But does it do it for all the MSRs?  No, actually. So, basically, it can catch every MSR change, but it treats different MSRs. Like,  whenever it needs to block the change, it will. Whenever it just needs to pass it along.  So, is there still potential that maybe some other MSRs would actually allow you to, like,  exploit this further, even on the Hypervisors?  Maybe. It depends on the MSR. I know you might do some research on that and find out.  Yeah. And I've got also a question about the... Because you are changing the LSTAR MSR so that  if I understood correctly, you can then specify, like, what will be the syscall handler, right?  But how do you, like, place your executable code in the kernel?  Or is there, like, no SMAP or SMAP or things like that on Windows?  Right. So, this is actually a good question. So, you don't have SMAP with A. You do have SMAP with  E. So, you cannot actually let the kernel just change into user space code, and it will just  run it in the internal context. So, basically, what I did there, I used a really cool open source  project called MSR exec, which let you just do that. So, basically, you are creating a ROP on  the stack to disable the SMAP mitigation. Then you just jump to your user model function and  everything. Okay. Very nice. Thank you.  Okay. So, regarding the previous question, there's a really good blog post about secure  kernel page guard, which runs in the Hyper-V mitigation. And it explains in detail how it  works, what are the extents, etc. So, it describes all the MSRs which are handled, which are not,  and stuff. Because there's much more. It protects the core of the Windows kernel, so you cannot  hijack some of the pages, and more like that.  You're talking about the one that Jordan Shafir wrote, right?  Probably, yes.  Yep.  Hello. Thank you. Very nice talk. I have a little question. So, you said several times  developers have a lot to know about. How is the documentation?  It's pretty good. Well, the major problem here was that this codebase actually written in the early  2000s. And it's still being used today. And actually, this was written as a proof of concept,  not a production driver. For some reason, it's still being used as a production driver.  I don't know why. Yeah. So, it's created a lot of problems, really.  Any questions?  That's rather a comment. Maybe someone should create an AV product where they would try to  disassemble their drivers, like custom drivers, and try to find out those bugs and block them.  Yeah. So, Microsoft tried to do some of this. And also, some of the variation of this driver  is actually in the block list of the driver that should not be loaded. So, Defender should block  this one. But there are too many variations of this driver. And they always resign those. So,  basically, you cannot find all the different variations, as long as you're not really  putting a lot of effort into that. And unfortunately, nobody did it by today.  Other questions?  All right.  All right. So, thank you again.  Thank you.  Thank you, guys.  A round of applause.


url: https://www.youtube.com/watch?v=jy1filtQY4w
title: USBvalve: Expose USB Activity On The Fly by Cesare Pizzi
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=jy1filtQY4w",
    "title": "USBvalve: Expose USB Activity On The Fly by Cesare Pizzi",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2568,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Hello, everybody. Thank you for being here today. And we are speaking about USBValve,  which is kind of a strange thing that I created. So let's start with a bit of presentation  from myself. My name is Cesare Pizzi, and I work for an Italian company, Sorrent Lab,  which is doing a lot of things in IT. And I'm following more or less the security part  in that company. So I'm here today with you, because I love hacking, obviously. And also  thank you to the organizer, because I would like to thank them for such a great event,  because it's really, really great. And what I do usually in security field, it's, let's  say, I work a lot with open source software. I'm really an open source advocate, and I like to  participate and to contribute to several open source projects like, you know, Volatility,  Persistent Sniper, C2s, a lot of other have my contribution in some ways, PickEasy, I had a lot  of them. And also I have a couple of major projects run by me directly, like Resploit,  and CNUAL, some others. So if you want to have a look to what I'm doing, just have a look to my  GitHub. And open issues, get in touch with me, also on Twitter, with Redshift. So I'm more than  happy to hear from you, and to discuss with you about any things related to security and so on.  And okay, sorry for the flashy presentation today. I think I'm going to burn some eyes today,  but okay. I like very much these templates coming from Slight Carnival. And so I decided to use it  even if it's a bit, yes, a bit flashy. Yeah. Okay. Let's now start and go into the presentation.  And starting from which is the problem I would like to solve, which is, first of all, my problem.  Because if it's your problem, you will find a solution. Then you maybe also try to find out  if it's a problem of someone else, which is even better, because in this point, in this case,  you are going to solve also a problem of someone else. But let's start from my problem, which is  USB drives. And why we may think that USB drives are still an issue in 2023. Because at the  beginning, I was thinking that malware spreading via USB was something from the past. It's not  actually the case. Because I started to look around, and I see that we have a lot of examples  of malware still using USB to spread. And I did a little research for this. And I'm mentioning  here some of them. One is Mistclock. You can find some great analysis at these links. Okay.  They are written a bit, but I will release the slides with the repository, so no problem. You  can get them. Raspberry Robins, something like NJRat, Try2Cry, PlugX. These names will  recur into the presentations, because I would like to show you how this  software is actually using USB to spread, and why this is an issue for my side, and why I try to  build something to make these things a little better. And you may think that, yes, in 2023,  USB spreading, it's pretty outdated. Actually, you may think why it's still something  at these days. First of all, because the implementation is pretty easy. It's a lot  easier than implementing any other kind of warming, or network spreading, or whatever else.  It's just a matter of enumerating devices and write something there. Second thing is that,  probably, USB drives are easily exchanged without precautions. Even me, that I'm a, let's say,  security guy and so on, I see a lot of times USB drives put in some unknown PC and so on without  many precautions. And third, probably the most important reason is that USB allows spillover. So  when you deploy a malware, you are in some ways sandboxed in a network or in segmented  spaces, because you cannot get out of them. And USB allows you to pass these kind of  barriers and get maybe in something that is not expected. So I think that that's the reason why  this is still used, and this is still a problem, actually. It's not just something related to  malware, actually, because every time you are inserting a USB key in a system, you don't know  what is really happening. This is at least what, which is my feeling. When I put a key in someone  else's PC, I still don't know what is going on, because I don't have any kind of visible  visibility on that. And maybe it's just not a matter of something writing on my disk, but maybe  something is maybe stealing my files. Do I remember which file I had on this key that I'm not using  from two months or something like that? Probably not. And so this is why I decided to build USB  Valve. So what it is, it's a very simple way to have visibility on what a system is doing when  you insert a USB drive in a system. So it's actually a hardware project. And okay, now we  come to this part, because it's a keychain, we'll see. And okay, yes, it's built on something that  it's really easy to find, cheap, and well-known. And so I decided to build this hardware project on  a couple of things which are probably well-known, probably you know them. One is the Raspberry Pi  which is something like $6 board, probably you can find it also for less than this if you look  around in the internet. And the second part, which is the only other hardware part needed  for building this, it's an OLED screen, which is something like eight or maybe less dollars.  So it's something like $10 or something more you can build it, and you can have your own  checker for this kind of things. Why I decided to go with the Pi Pico? Because it is well-documented,  it has a very good SDK, it's well-known, well-supported, and so on. So it's really a  great platform and I would suggest you to use it also for your hardware projects if you have  anything about this. So I try to keep things simple in this case. So at a certain point of  the project, I thought to use a real SD card in order to emulate the drive and have some storage.  But then I decided to go with an emulation. So what I'm doing, it's actually, I'm emulating  everything into the RAM of the Pi Pico and nothing else is needed other than the two components  before. The very same code should run on any RP2040 platforms, like for example,  the Arduino Nano has a specific version of the boards with this processor on it. Probably it's  overkill because that board also has a lot of other functions and it costs a bit more than a  Raspberry Pi. So I think that you can go with Raspberry Pi Pico, but it's actually compatible  with any platform, probably, or supporting tiny USB library, sorry, which is the library on which  the project has been built. Also, I created a PCB because I would like to keep things  compact and tough. And so I created a super simple custom PCB where you can put the components on  and you can build your own key. And this is what actually results at the end. So this is  the final result. You can also build by your own with the instruction, the repository. And now  during the presentation, we'll go through an example of how it works and how it actually  helps you in securing your USB activities in the future, let's say. There is also,  if you want, there is also a surprise. I printed a bunch of, okay, this PCB is not mandatory. So  you can build your own with breadboard or whatever you want, just wiring and something.  But if you want a PCB, I have some of them here with me. I'm giving them away. So if you want one  for building your own, you can just ask me just after the talk, I will give you one of these  without any issue. I have a bunch of them, so not too much, but I'm more than happy to give it to  you if you want to build one. You will see at the end of the presentation if you want, actually.  So we spoke about the hardware because that was the other part, but obviously this is not  only done with hardware because there is also the SAM software, which is the firmware of this  device. And the software, it's based on TinyUSB library, which is a library built to emulate in  some way USB activities in a lot of ways, actually. So it's a very wide library doing a lot  of things. And what I did, it's to create a fake file system directly on the RAM of the Pico and  monitoring what is going on when this key is actually plugged into the system.  The file system has been crafted in a proper way. I use the word crafted here because actually  it has been necessary to put things in the proper place in order to avoid false positive and  something that we'll see during the presentation. Obviously, I'm exposing more space than what I  have available on the RAM of the Pico because the Pico does not have a lot of RAM. I'm exposing more  space. So the system thinks that I'm inserting a USB drive with some space, which does not exist,  actually. But that's not our point because we don't need to store files. We need to monitor  activity on the USB part. So not a problem, this one. And okay, we'll see how it works.  As I said, I had to craft the file system because in order to have it working in a proper way on  both Linux and Windows, I had to place files in specific clusters, in specific places in order  to avoid caching issue and some other things we will see during the presentation. And I created  this fake OS, sorry, fake file system. And this is already done and ready to be loaded. You can  also create your own. We will see how at the end of the presentation. If you want to personalize  it or customize it, for example, you can do it. No mockery here. The fake file system is just  a giant array like this one. So nothing, it's not rocket science. It's a giant array done with  things in the proper place. And okay, what I would like to do now, it's going with you through  some field testing because actually I built this and I would like also to show you how and why it  is. I think it's still useful to have something like that. I didn't mention that the PCB has also  a convenient hole for using to be a keychain like this one. For example, I'm using actually,  this is the key of my car. And I'm actually using, even if it's everything exposed,  it is pretty tough. So you can use it actually without breaking anything. And okay, field testing  means that we are going to test it with four real malwares. And we will see four different  techniques used by these malware to trigger execution and to infect through USB. We will  see that some of them will be pretty naive and not really sophisticated, but then we will see  also something more interesting and more difficult to spot out and to identify. Obviously, as I said,  these, all these malware and all these BU activities will be cached and disposed by USB  valve. And we will see some of the samples at the end. It looks, when I started this,  let's say this research on the field testing, I noticed that a lot of authors, malware authors  that are using USB spreading techniques are using .NET executables. At the beginning,  I thought it was because maybe we were facing some naive and simple malware, so written baby,  but not sophisticated attacker or something like that. And it is true, for example, for a couple  of the malware we will see, which are ngerat and try2cry, for example. ngerat, it's a random,  sorry, an access Trojan and try2cry, it's a ransomware. These two are actually not so  sophisticated malware, we'll see. But we have a couple of other examples in the same, in the same  testing. And one is Raspberry Robin, the other one is Plugix. And we are facing here a completely  different story. We are facing with some real complex malware here. And we see that they are  also using more sophisticated technique to trick the user in doing something that it shouldn't.  Let's start, sorry, let's start with the very first one, which is ngerat, which is a pretty  simple malware. This is, okay, it's, as I said, it's written in .NET. And we can see here one of  the most basic way of infecting or spreading through USB, which is the usage of the autorun.inf  file, which is a file that is saved on, could be, can be saved on a USB in order to  be, in order to trigger automatic execution of specific executable. This is done through,  you see, it's not even obfuscated or nothing into the, into the malware. And it's done in a very  clear way. What happens is that this is going to write this file pointing to an executable,  which is in this case, in number two, the svchost. This will be triggered if the system  where you are going to put the key has the autoplay function of Windows on. The autoplay  function actually executes this part. Most of the systems right now does have this disabled.  So it's not real, a sophisticated way of conducting an attack using USB. But okay,  it's, it's one of the way they can use it as being used by this, this file here.  Let's go to the second example, which is try2cry. Try2cry, it's a ransomware. Even in this case,  we are facing with a very simple one, very simple, very simple ransomware here.  And even in this case, we are going to use a very basic way of enumerating the devices and writing  on them. And the different technique used by try2cry here is just to create some files,  as you can see, in .3 and .4 on USB. And these files, okay, are written in Arabic,  so probably the target of try2cry was Arabic countries, are  some fancy, fancy name, let's say, in order to trigger the execution from the  user. Even in this case, okay, we see some files named important.exe, password.exe, and so on,  so that the user maybe double click on them, executing the ransomware itself. So even in this  case, nothing, it's really complex or really sophisticated. We are speaking about field  testing here, mainly about Windows environments, because actually, in this case, USB spreading  files, USB spreading malware, it's focused more on Windows. I tried to look for  Linux samples of this kind of things, of this kind of  spreading, but I didn't find any, probably also because, I guess, Linux has less the  focus on removable device, more on file system. So probably it's not really something that we will  see in Linux environments, because it's, they are more, let's say, Linux in general as environment,  it's more focused on file system view, more than removable or not removable devices.  Let's go to something more complex then, because now we are speaking about a different  malware here, Raspberry Robin. It has been around starting from probably November, December of the  last year, and we had some analysis done on that by Microsoft and Canary. This malware,  it's pretty complex, it's still around, and it actually use USB to spread, also USB, not only  USB, because actually, when it comes to this kind of malware, we will see that the spreading is done  through different ways. So USB, it's one of them, it's not just the only one like the previous two  we saw. We have a couple of analysis here done by Raspberry, as I said, from Red Canary and  Microsoft. They are very well done, so I will look to them. And this is the infection chain  used by Raspberry Robin, for example. You see here that we are facing something a lot more complex  than what we saw before. So it's not just a matter of a simple malware written in .NET and so on, so it's  really complex. And if you really want to go through and to deep dive into the complexity of  this, you may have a look to the sample or to this analysis done by Avast, where you see Raspberry  Robin and deploying also Roshistack, where you can see that this malware  has something like 14 levels of different encryption obfuscations, one into the other,  with tons of tricks of like anti-VM, anti-debug, anti-sandbox, and so on. So in this case, we are  facing with another story. This is coming from an advanced attacker and uses USB as one of the ways  for spreading. It creates, in this case, it uses a different technique. It creates a LNK file,  which is a link file in Windows, disguised as a folder. It can use a name like Recovery or  maybe USB drive brands like Samsung or whatever, or Fairbatim or something like that, because in  this way, it can maybe trick you in double click on it with thinking that that's a folder,  but because it has actually a icon folder on that. And now I would like to have to the last one,  which is probably the funnest one, I think, because in some way, it target as like a security  analyst or malware analyst, because PLUGIX, at least in one of some of the samples, has been  sent out as a XDBG DLL, so the famous debugger. You can have a look to it in this analysis done  by Palo Alto, where you can see this kind of analysis. And here I would like to stop one  second, because I would like to personally thank you to Duncan, who is the maintainer of  XDBG project, who is doing a lot of work on it. I think that as a malware analyst,  and all the malware analysts are using it, so I would like to ask him, I would like to ask you  to contribute to the project itself by donation or by also working on the project. He already  fixed this issue, because the issue that is using PLUGIX to spread in this case, it's because  it's tried to sideload DLLs into the XDBG, and he already fixed it, actually, as said,  as you can see here in the comment of his repository. So, big thank you and kudos to  Duncan for his hard work on this. Close parentheses, and let's go back on the PLUGIX,  which is, as I said, distributed as an X32 bridge DLL file, which is sideloaded when you start  X64DBG application. The payload itself, it's into the X32 bridge.file. So, that is something  that could be sideloaded starting. It was sideloaded, because now it has been fixed,  starting XDBG. And what is going on is that, in various things he's doing, it's also spreading  in a similar way of Raspberry Robin, but there is something more, which is very interesting and  very clever from this point of view. It creates a LNK file, again, disguised as a device in this case,  and then all the files that are used to spread are saved in a folder named with a Unicode char  00A0, which is a no-break space in Unicode. That's pretty interesting, because this is  a nice effect, like this one. So, you will see something like this, which is actually a removable  disk, the name of the disk itself, with an icon here. No other files are there, because  even if you put your check here on display hidden files, nothing else will be displayed, because  Explorer is not showing files with this non-breaking space in it. And so, this is  actually what you see. I don't know you, but if I see something like that, I probably wouldn't  realize that this is not a real USB drive, and I'm going to double click on it. It's very probable  that I'm going to do that, because it's very, very sneaky, it's very, very clever. But what  actually you see, and this is actually what you see even if you enable the check on hidden files,  because actually they are also hidden, but they have this additional trick of using  this not-breakable space. If you have a look on the drive itself, you will see the usbvalve.lnk  file, for example, here. And if you try to type it, you will see pointing to something which is  x32dbg.exe, but you don't see actually anything there. Switching to, let's say, a more  robust operating system like Linux, you will start to see something. This is the list of the  same directory done from a Linux environment, and you see here at point one that there's this  entry here showing something strange, because you see an empty entry of the directory.  And if you try to drill down, you will see that going from point one and point two, where we  change the directory, we see that in point three, we see another folder which contains some other  files and another empty folder here. And if you drill down even more, you will get finally  to the folder where the payload resides. And this is completely hidden into the explorer view.  So, I think that this is a very clever and a nice way to spread. Now, we saw four different ways  for using by malware for spreading, and I'm sure that you probably said, okay, the first two are  pretty much impossible to notice because they are very naive, very easy to spot out.  The other two, it depends. How USB Valve interacts. So, what you have to do is just to  put your USB Valve device into a PC, into a USB port of a PC, just to see what happens.  And what do we see at the beginning? It's something like this. So, when the board boots up,  you will see something like this on your OLED screen, because you will have one of the points  here, it's to have immediate output on what is going on. And okay, USB Valve run a self-test  before starting and seeing that everything is okay. This self-test is basically a self-check  on the USB, on the fake file system, just to check for the integrity. I did it. It's probably  overkill because I think it's pretty hard to being able to modify it directly from the USB.  It's something that's flashing on the RAM. So, but okay, I had some space, so I did it.  And then you will see something, okay, we are obviously here saying that we are putting this  into a Windows system, obviously. We will see something like an access to autorun. A couple of  things. When you see on USB Valve something marked with a plus, it means, okay, it's expected,  nothing to worry about. If you see something like an exclamation mark, it's something that you have  to pay attention to. In this case, why autorun is not an issue? Because, as I said before,  the autorun.nf, it's used to execute files if autoplay is on. But I actually realized that  Windows is accessing this file in any case. Even if autoplay is off, Windows is trying to access  it in a reader for reading. And okay, so this is completely expected when you put a USB drive  on the device. So that's fine. Okay, something is accessing the autorun.  Pretty normal. And okay, you will see here the read access beside the warning here,  which is not a warning in this case, because it's more an informative message, as I said, with a  plus. Now let's go to case number two. We actually inserted our USB Valve again in a PC. In this case,  we don't have an access to autorun, but we have something like, we see here an exclamation mark.  Why? Because I placed also some canary files on my fake file system, like a readme, for example,  which are telling us if something is accessing all the files. This should not happen.  In a default Windows installation with Windows Defender on, when you put a USB drive in a system,  it shouldn't access all the files on the file system. It could happen if you may have, maybe  have some other antivirus software. So I saw it during the tests, but it's definitely you have  to pay attention to, because that means that if you are inserting your own drive, in any case,  something is going to access everything that is saved on that system. Maybe it's benign because  it's an antivirus, maybe not, because maybe it's something, it's also stealing your data. I don't  know. It depends. But you at least have this information before doing what you want. You put  your real USB in the system. And that's kind of useful information. And the last one, the last case,  it's if something is writing actually on the device itself. In this case, we will see  a specific sentence here, a specific warning with the exclamation mark again, because something is  actually writing on the USB drive. And this is definitely wrong. This shouldn't happen in any  case, except for one thing that now I tell you. Something is, I don't know, encrypting your file  or writing something there, but this is definitely wrong. I saw some false positives in writing files  when you put a USB drive in a Windows system where the Recycle Bin does not exist on the device  itself. Because for some reasons, Windows wants to write a Recycle Bin file. So, the file system  built on USB Valve handled this and have the Recycle Bin created. So, we will not see this  false positive. But, and if you see this sentence here, that means that you are going to have some  issues if you are going to put your own USB into that system. Now, this is the basic functionalities  of USB Valve. So, you have just to put it into a system with a USB cable and you will have immediate  feedback. So, that's the device. You have immediate feedback on what is going on on that system.  But, you can also use it as a more advanced tool in order to do some additional  debug and forensics on USB protocol. Like, for example, monitoring what is going on in terms of  reading and writing at the lowest level, at the SCSI level of the USB protocol.  Once you put this device and you connect it to a Windows system, you will get  a USB drive, obviously mapped on the system, and an additional COM port  that you can use to attach your preferred terminal. So, you can attach PTTY or whatever you want  to this COM port and you will see something like this. So, here I'm emulating a write on the disk.  Here on the right side, yeah, for you it's right. I'm copying a file, one of the canary files, which  is the type the readme.txt in another one. And on the left side, you see what exactly is written  on the COM port, which are some debug information here saying what is actually going on at SCSI  read 10 and write 10 commands on the USB protocol. It tells you which is the sector written, the size,  it also dumps part of the packets, not the entire one, at least not this release, because  dumping the entire 512 bytes is causing some timing issues which are interacting with the  protocol. So, they are going to break things, but probably it's something that could be can be fixed.  And that's an additional way you can use it to debug at the lowest level what is going on  the USB drive. Another more advanced thing is that you can use it as a debugger in this case,  because Raspberry Pi Picon and also my PCB expose the three SWP pins. So, you can attach, for  example, a Jlink debugger at the device itself and then run GDB on it. And so, you can have  full access to one from outside to the firmware of the USB valve itself and on the activity done  on the USB drive. So, in this case, you can have a lot of insight on what is going on. So,  this is another way how you can use the device. Now, I said before that you can also customize.  I told you, I created a file system and it's pre-built on the firmware itself.  But I'm also providing a script in order to build your own, because if you want to  change something or try something yourself, you can actually do it.  The procedure is pretty easy from one side and a bit more complex from another.  In the sense that, okay, it's pretty easy to create a fake file system. You can just create  with these three Linux commands. Okay, you can create a file system on it and mount it as a file  system in a folder and then create whatever you want. Then you can run maybe the Python script  and create the proper giant array that I was speaking before to be loaded into USB valve.  But I would like to ask you one thing. If you are going to do this, I would like to  work with you maybe because we can improve the project together. So, if you think that  it makes sense to create a different file system with some other things and some other files and  so on, because you want to monitor specific things, I would like to ask you to open an issue  on GitHub where the project is published. And so we can work on it together and maybe improve  the project together. So, please do it if you have any idea on that. And thank you for that  in advance. And then also let's go to something that is curious to try. For example, what I'm  doing now that I built this one, it's just to try to put this device in every USB port I found.  Like in my house, for example, the television decoder, the modem, the Steam Deck,  or whatever I found just to see if maybe this device are doing something strange with my data.  So, I encourage you also to do that because it's quite funny to see. And the last part, it's about  open sourcing everything, obviously, because as I said, I'm an open source advocate. So,  everything I do, it's usually released in this way, unless very few things that are  too bad written to be shared. That's the only reason why I'm not sharing, because  I don't want to show you how bad am I at writing code. And so, everything is published  on my GitHub under the repository of USB Valve. Everything is there. You can build your own. You  can also download, if you want, the PCB Gerber file. So, you can print your, if you want.  But I remind you to ask me for one if you want to build one.  And okay, that's the repository. So, you can find building instruction for both the PCB version or  your own version. So, you can just download everything from there. And now, okay, let's go to  the credit parts, because I would like to obviously thank a lot of people, actually,  like, for example, the TinyUSB Project, which is the group who built the library, Adafruit,  because I actually used the Arduino IDE for Raspberry Pi Pico, even if I'm thinking that  it makes sense to migrate directly to the Pico SDK, to be honest, because it's more supported  and so on. So, probably, I will go to that direction. But so far, I used that part. And  okay. So, I also want to thank all the people who did the analysis that I mentioned in my  presentation. Also, the presentation template provided by Slides Carnival. And so, I think  we are at the end. So, you can take your sunglasses off, because the presentation is going to be  finished. And okay. If you have any questions, I'm here.  **BEN HONG.**  Any questions?  **BEN HONG.**  No?  **JASON LENGSTORF** Come on.  **BEN HONG.**  Anyway, if you then have any question, maybe it came to you later on, just write me a message  on GitHub or on Twitter. Okay?  **JASON LENGSTORF** Very interesting, this tool you're doing. What was the...  **BEN HONG.** Sorry, I don't see you.  **JASON LENGSTORF** Just here. Sorry. So, what was the most strange thing you saw that  something did with your device? So, you showed that it reads some devices, it reads some files,  it can write new files. Did you see something where it tried to attack the firmware or so,  which would theoretically also be possible? And would you see something like that, like  try to attack the firmware of the USB device?  **BEN HONG.** So far, I didn't see at least from... I tried to use it as, let's say,  canary to see what devices are doing. So far, I didn't see anything strange directly from,  let's say, home devices or something like that. The strangest things are done by, let's say,  the malwares we saw in the analysis. So, so far, I actually didn't see anything strange yet,  but I'm still researching on it. So, I think that something could come out from that.  Thank you. **JASON LENGSTORF**  Okay. I have one more question. **BEN HONG.** Sure.  **JASON LENGSTORF** Because your device, by default, exposes a serial port and it's named  USB Valve. Do you think that some malware in the future can just detect that it's not an actual  USB stick, it's just a USB Valve, and then just not do any suspicious stuff?  **BEN HONG** Definitely, yes. That's why, actually, it's provided as open source. So,  we can rebuild the firmware very easily, just renaming with your own name. And that's actually  a point, yes, for sure. You mean, okay, you can also hide the COM port, for example. It's something  that can be done, for example, yeah. But that's actually a point. And I think that it could be  easily solved. One of the things that probably have to do is provide a kind of, let's say,  firmware that randomizes names of the disk itself or the COM port and so on. So, that's  a good idea, for example. **JASON LENGSTORF**  Okay, thank you. **BEN HONG**  Thank you. **JASON LENGSTORF**  There is one question. **SPEAKER 2**  Have you considered to also have it work the other way around, for example, to detect any kind  of bad USB sticks that expose something else than just mass storage? So, basically, being a USB host  where you can plug in a USB stick you don't trust? **BEN HONG**  Ah, okay. On the opposite side, you mean. Yeah, good point. I think that's something that could  in this case, it's a bit, let's say, since in this case, the only way you can get infected by  something like that is that it's more under your control. I mean, if you're going to put a USB  drive which is infected in your system, it's your system, you know that maybe, I don't know,  you have autoplay run or autoplay activated or whatever, because you have control on the system  where you have to put the device itself. Here, I thought it the other way around because it's  actually something I don't have control to because I have to put my key into an unknown system where  it's become more useful, in my opinion. But yeah, in any case, that's something that could be,  we can think about use case about that. Yeah. **JASON LENGSTORF**  Sorry. I've looked at a project a long time ago called Face Dancer.  Have you perhaps looked at it also? **HONG** Face Dancer, you mean?  **JASON LENGSTORF** Face Dancer, yes.  **HONG** Yeah, it's something which could be similar  in terms that Face Dancer is more a framework in this case because it offers a lot of other  functionalities. The point here is to build something that you can bring in your keys and  have it ready for whenever you want to test something. Face Dancer, it requires a bit more  computer power, let's say, because it requires specific boards, which are bigger than this,  for sure. And it also offers more functionalities than this. That's for sure. But yeah, actually,  it's something that has the similar functionalities, but this is built for  specific usage like this one and to also be carried out together with us. Thank you.  **JASON LENGSTORF** Other questions?  Okay. So, thank you again for the presentation.  **HONG** Thank you very much.


url: https://www.youtube.com/watch?v=wROyhQMLyIY
title: Hacking Your Jump Rope Or Your Coffee Machine by Axelle Apvrille
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=wROyhQMLyIY",
    "title": "Hacking Your Jump Rope Or Your Coffee Machine by Axelle Apvrille",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2944,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Thank you, so my name is Axelle, I work for Fortinet, and I work mainly on Android malware  and connected objects, and today it's going to be mostly on connected objects.  I'm also the lead organizer of a phone CTF, which is a CTF in the south of France, and  which is dedicated to connected objects.  And last but not least, I'll be talking to you today about a smart coffee maker machine.  I don't drink coffee, so during all my research, my colleagues had to drink the coffee I was  brewing for that, so thanks to them.  So those are the two devices we are going to discuss today.  You've got on the left-hand side the coffee machine, which is connected on both devices  are Bluetooth, low-energy devices connected that way.  And on the other side, you've got the jump rope, we'll be discussing both.  Both have been integrated in challenges for phone, the coffee machine, it was in 2019,  and the jump rope, it was in 2022, in December, sorry, 2022.  So let's start with the coffee machine.  Well, actually it's really interesting because, well, I'll discuss actually that a little  bit later, but you can hack in three different points.  You can hack on the hardware, in the communication, and on the smartphone, okay?  So let's start a little bit, but with hardware reconnaissance.  In there, I opened the coffee machine, and this is what you see.  You see the buttons on the top, okay?  And this is the back of it with something, also all the mechanisms which control the  flow of the coffee.  And if you go beneath the buttons, well, you've got a PCB, and if you have a look at what  is written on the top right, well, basically you get some numbers, and basically it says  also I think that it's waterproof, one part of it, and the other part is helpful to find  it on the net.  And you can find the separate part for it sold on eBay, which is pretty cool because  it means that if your coffee machine has an issue, well, you can repair it.  It's something like 35 euros, depending.  So this one I think is from eBay in Italy, but yeah, it depends.  I also saw one in Australia, I think.  And the other thing that you see in eBay is that actually this PCB also works for lots  of different coffee machines.  So probably they, well, it's a supposition, I'm not entirely sure of that, but probably  it was sub-constructed to a company who then sold it to multiple coffee makers, different  brands, and it works for all of these.  If you have a look at the hardware components on there, well, you see an STM chip, which  is an 8-bit microcontroller, and more interesting to me, the other chip there is the BLE chip.  So actually, if you've got good eyes, you can see on the stamp on it that you've got  the FCC ID, you can go to the FCC.io website and look for that, and you get all the details  exactly what chip this is and all the specs which are there.  So this is pretty interesting.  And then the other thing which is really interesting when you're trying to hack a device, I think,  is to have a look at the documentation.  That is, if you are lucky enough to have some documentation, and for the smart coffee machine,  there is very good documentation there.  In the instruction manual, in particular, you can see the reset to factory settings.  Now, this is really, really important to have as an information when you're trying to hack  something.  I had to, of course, use it several times.  So this is really interesting information, for instance.  More information this time in the service manual.  This is awesome.  I wish that all manufacturers were providing such good documentation, honestly.  Look at this.  I mean, this is wonderful.  You've got everything you need to repair it.  Besides my work, I'm actually working in a repair cafe down in Nice in the south of France,  and if I had all this documentation for all the things I'm trying to repair, it would  be really great.  And that, okay, this is good.  So what have we learned?  Well, we've learned that the coffee machine has a BLE chip.  It's not a great deal.  We already knew that, okay?  But well, okay.  We know that the PCB is used for many different coffee machines, probably.  We know how to reset to factory settings, so this is going to prove out to be very useful.  And we know probably, or at least better, how to repair the coffee machine, and this  is really awesome.  If you are more skilled than I am in hardware, if you have, for instance, well, corresponding  to the previous talk of Thomas, well, if you have his skills in hardware, you can probably  dig in much more on the hardware part and find many more things.  Those are not my skills, okay?  So if you are like me, like I am, not skilled in that part, well, you have more than your  eyes to cry.  You can do something else still, is, well, you can hack, for instance, in the BLE communication.  So there we can try and sniff the Bluetooth communication.  There are basically two different tools that I know of.  Both are really old.  It's Ubertooth and Adafruit LE Sniffer.  I think that Ubertooth was presented, I think, in 2011, so it's pretty old, more than 10  years old, but it's still maintained, and you can use it, like the other one, to sniff  the Bluetooth communication.  It works very well, and you get all the packets, which is a little bit more than we really  need because in this particular case, we are only interested in one part, one specific  layer of Bluetooth, which is at the at protocol.  The other issue is that I'm not actually that much at ease with those sniffers.  I know how to use them, but I tend to forget all the time how I have to set them up again.  It's a little bit complicated.  You've got to flash the firmware, then you've got to patch your wire shark, then, you know,  all that stuff.  It's doable, but I probably don't do it often enough to be really at ease with it.  First two parts, well, it's not the easiest, in my humble opinion, or not for me, at least.  Of course, it's the last one.  I'm going to do everything from the smartphone.  You're going to see that, actually, we can find lots of information from the smartphone,  and it proves out sometimes to be extremely easy and handy to use that way.  One of the first things you have to do when you are dealing with a BLE device is to list  all the services and characteristics of the device.  That's the way BLE is organized.  We're not going to get into the specifics, but basically, you've got services, and in  there, you've got characteristics, which are kind of entry points you can read or write  to.  If you want to list out, you've got smartphone applications, like NRF Connect.  You've got others, but they give very good results there.  If you want to do it from your laptop, it also is possible.  For instance, I'd recommend, like, GATTool, well, it's deprecated.  It's been deprecated for years, but I know that some of us are still using it very much  because it's really simple to use and very convenient.  Its replacement is actually Bluetooth Control, which is also excellent as well, perhaps a  little bit more verbose.  It's a bit too talkative, let's say, but it works.  You can get the lists of exactly this, which is all the services that you have on your  device.  On the smart coffee machine, you've got standard services, generic access, generic attributes,  and then all the other ones are specific to the coffee machine.  Here in this case, we can see that the developers really kind of organized the various characteristics  in a thoughtful way, like you've got the errors at some point, things that users can customize  in another and things like that.  I think we're going to discuss those a little bit more afterwards.  Then what we want to do, of course, obviously, is to connect to the coffee machine.  First thing that happens, you try to connect, and it spits out an error telling you, well,  it requires authentication before read and write.  So there you can go and have a look at how security modes are defined in BLE, and you'll  see there is level one, two, and three.  Basically, what you need is level three, which is authenticated encryption, and which is  actually pairing.  It's kind of the same.  So if you want to get this, well, you use GATTool.  GATTool, you've got to say that security level here is high, because that's what means actually  level three.  Moderate, I think, is two, and low is one, something like that.  If you're using Bluetooth control, it's, I think, a little bit more intuitive there,  because well, you just say that you want to pair to a given device, and you get the pairing.  Then you try again to connect, and you think it's going to work, and no, not exactly.  It tells you this time attribute requires authorization before read, write.  So the first time I got the error, I read too quickly.  I thought it was authentication, and I thought, damn, my pairing didn't work.  It did.  It's not that.  It's different.  Authentication, authorization, totally different.  Now this is really rare in BLE devices.  It was the first coffee machine, well, smart coffee machine, first BLE device actually  in the end that I saw with authorization at all.  So it was particularly interesting to me to deal with that, because I hadn't ever seen  that.  It's totally implemented by the device itself.  This is not part of, well, the Bluetooth specs say that it's up to the device to implement  the authorization the way they want.  Sorry for this, but I'm going to move it a little bit, yeah.  So how do I get authorized?  So this is where I'm going to sniff the communication, but I'm not going to sniff using Ubertooth  or something else.  I'm going to sniff directly on the smartphone.  If you've got a rooted device, well, you can actually on Android pretty easily enable Bluetooth  snooping.  It's really not difficult to do.  It's like you click on various menus, and it works.  And then you get the PCAP on the smartphone directly.  You transfer that, and you put it in Wireshark.  And, well, I'm happy, okay?  And you get that.  So, well, maybe at the back you can't exactly read, but those are just a list of enumeration  packets in there.  So it's kind of enumerating all the services and all the characteristics, okay?  Then you get a read request on handle 16, okay?  Then you get a write request on handle 14.  Now, if you want to get authorized, obviously, you're going to have to write something, okay?  So I thought, okay, one way or another, the write request is going to be really interesting  to me because possibly this is what is going to give the authorization code and prove that  I am somebody to be trusted, okay?  Or, well, that I am this authorized person.  And indeed, it is that.  So in the packet, in here, we have the authorization code to be sent to the smart coffee machine,  okay?  Now, it's useless just to take a screenshot of that one because it is changing every time  we are repairing to the device.  So you've got to get this code by yourselves by sniffing the communication.  Then you get it, and then you are authorized for the rest of the long, possibly long session.  And by the way, normally, we'll have the smart coffee machine at Fortinet's booth today.  So if you want to try and hack and get your coffee that way, well, you can.  You're welcome to try and hack the machine.  Then in phone, what happened is that one of the challenges was that we wanted the hackers  to get a 90 milliliter cup, okay?  Normally, ristretto is 25 milliliters, espresso is 40 milliliters.  You see, I've learned quite a lot about coffee now, okay?  And lungo is 110 milliliters, okay?  So you can cheat, but you're not supposed to.  You can do two ristrettos and one espresso, that will be also 90 milliliters, but you  were supposed to get that in one cup, not in three cups, okay?  So we're going to try and do this.  So here we go in the code of the Android application, which is supposed to control the coffee machine.  And we see a class, which is named CupSizeVolume, and this looks like a good place to look into.  And you see the different ranges, which are acceptable for ristretto, espresso, and lungo.  So if we want 90 milliliters, well, it works for lungo.  It won't work for ristretto and espresso, because it's not beyond the range, okay, cool.  And now, how are we going to do to set this?  Well, we have a look at another class, which is called CupSizeOperations.  The name isn't obfuscated in the code, so this is handy.  And you see that there's a service.  The service is UserOptions, and then you've got two different characteristics, CupSize  and CupVolume.  So what we'll have to do is to specify we want to hack lungo, CupSize, and CupVolume  for 90 milliliters.  Now a small note there is that it's handy to work on handles, okay.  But sometimes you have only the universal identifier, which is there.  So if you want to make the matching and know what is the handle, well, actually, Bluetooth  control gives you both.  This is the UUID, and this is the handle in here, and this is the address of the MAC address.  So it's an easy way if you want to work with either, well, you have both information, which  is cool.  So CupSize, so it's a specific protocol, well, a specific packet format, so sorry, but it's  really extremely easy.  It's only two bytes.  And for lungo, well, you just have to specify number two, and it will customize lungo.  Cool.  CupVolume, it's slightly more complicated, but it's still not very complicated.  It's four bytes.  Actually, the two first ones is the volume in milliliters, and the last two are fixed,  always FFFF.  Okay, so we know, sorry, I'll come back.  We know how to specify the cup that we want to customize, and we know how to specify the  number of milliliters.  Now we've got to be able also to tell the coffee machine, okay, do me my coffee, okay?  And here I'm skipping a little bit of parts because, well, we don't have like a two-hour  session, but in the code, you see again that there's another command with a specific header,  okay, which basically would tell the coffee machine to brew a coffee.  And then you specify the delay.  When do you want your coffee?  Do you want it tomorrow morning, or do you want it just now?  And what type of coffee you want, well, what type of cup.  So here, for instance, if we want our 90 milliliters cup of coffee, we'll say that  we want it now, so the delay will be null, and the coffee type is going to be lungo,  so it's going to be 0002.  And you send this command, well, to this given service, which is here, and the characteristics  to send it to are written there, so it's the brew key in here, handle 24.  Now just a summary.  So if we want to finally get our cup of coffee, we've got to pair, to authorize, to get, well,  the authorization code, to customize the, say that we want to customize the lungo cup,  customize the volume, 90 milliliters, and then tell it to brew the cup of coffee.  And this is where I'm going to show you, well, actually a video because I didn't dare to  bring the coffee machine, just here.  So it's this one.  So on the left-hand side, you've got the script, and on the other one, well, you've got  the coffee machine.  And you see that on the cup of coffee, I've marked Ristresto R, E for espresso, and the  higher one is lungo.  And if I manage to get, so well, if we get to the 90 milliliters, it's going to stop  just below those, the lungo, which is 110.  So this is normally 90 milliliters approximately.  And by the way, that's some, that's what some participants had to do to flag the challenge,  so that was cool that some of them did.  So resuming, you can do actually more, but that wasn't part of the CTF.  I mean, this coffee machine is amazing, I love it.  You can do actually a recipe.  So you can say, I want a little bit of water, this volume, then I want a little bit of coffee,  then I want, again, a little bit of water, and you can build up your recipe.  You can tell the temperature you want it, and then you can create a recipe for that,  give it an ID, and it will do it just the way you like it.  Because that's another thing I've learned from my colleagues, is that nobody likes the  same coffee.  You can do much more, and this is where, if you want to play afterwards with a coffee  machine, I suggest that you take a screenshot of this one.  Because you can do much more, you can get, for instance, the control.  The coffee machine will tell you, for instance, if it's missing water.  So you've got all the responses like that, and you can get that.  You can also set up water hardness and say if it needs to be adjusted or not.  There's even a BLE command if you want to do a factory reset.  So plenty of other things that you can do.  If you feel like it, well, you have some more technical information in that document.  One of the issues I thought is that also, well, this coffee machine, it's a bit strange,  but the designer only thought that one person would connect to it, because you can only  be paired, well, it's only possible to pair one person at a given time.  Which means that if, I don't know, colleague A is paired, well, colleague B is going to  have to unpair colleague A, pair again, and talk to the machine.  I mean, this is never going to happen, and I'm sure you've all struggled with BLE pairing  before.  It's a nightmare.  So really, this is not really very practical.  So I thought, how can we make this available to all colleagues in a more efficient manner?  Well, simple.  You can just use a Raspberry Pi, and it will act as a BLE relay.  So I connected it to the Bluetooth machine, and then I built, well, a basic web interface,  which my colleagues would go to and say remotely, I would like my coffee.  I would like it here, where's Pedro, and things like that.  And that's also something I've got a short demo for.  I don't have, though, the happy face of my colleagues there to show.  But there, well, this is my web interface.  It's not very nice, but I'm not very good at design that way.  And there, you push a button, and you get your coffee.  And I even implemented the error feedback.  So if coffee is missing, it's going to complain and tell them, well, yeah, OK, you want coffee,  but there's no coffee, OK?  So that's the way it works.  So this is available also on GitHub.  If ever you've got the same or a matching coffee machine, you can get it from here.  And happily, you will be able to get your coffee over Wi-Fi instead of BLE.  We're done with the smart coffee machine.  Now we're going to do a little bit of fitness with a jump rope.  It's basically the same, because it's still a Bluetooth low-energy device.  Just the same, well, as you can imagine, you can hack it on the hardware part  or on the communication part.  But you already know that I'm going to do everything here from the smartphone.  So actually, that's something that Thomas mentioned at some point in one of his slides,  is that, yeah, do not forget to have a look at the system logs of Android,  because you can find sometimes really valuable information.  And here, it turns out that actually the application  is logging everything that you want on the Android system logs,  including Bluetooth packets.  So I'm going to show that.  And this is going to be a live demo.  So enjoy.  Hopefully, I will enjoy it as much.  It might not work, never know.  So screen copy.  I'm going to show you my smartphone.  So there we go.  This is the smart.  And now the logs and the logcat.  So it's logging everything with the tag, with the section tag in there.  OK.  So I can stop this.  I'm going to connect the smart jump.  Oh, yeah, it's working, right?  Yeah, I understood.  There we go.  There we go.  And it was disconnected.  So this is Bluetooth.  There we go.  OK, so this is all the logs that you get.  I don't even need to jump, but I'll come do it.  Because you'll see, actually, that you get more logs.  Thank you.  Yeah, sorry.  So you get it here.  So actually, if you have a look at in there, in the logs, well, we'll see some of them.  But I'm looking for, by the way, this is each time I was jumping, it tells you lots of things.  So that was probably the sixth jump.  And battery is 100%, looks like.  OK.  Not sure.  I'm looking for one specific log.  Yeah, this one.  Oops, where is this one?  Here.  This is exactly the raw packet, which is sent by Bluetooth.  OK, so this is pretty interesting there, because it will help you afterwards understand  how to deal with and communicate with the jump rope.  OK, so there you've got it.  As you've seen, well, I don't know.  Maybe you speak fluent Chinese, but I don't.  But my main difficulty was there, that you just have to translate it.  But once you translate it, it's OK.  It's relatively clear.  You've got, well, battery data here.  The battery level, in that case, was 70 here.  This exactly translates to, there is a buzzer.  You'll see afterwards, but it has a buzzer, and it can make a little bit of noise.  So it helps very much to continue the reverse engineering, because, well,  you basically go in the code, and you're going to copy those Chinese characters  to search them in the code.  And for instance, well, here, I end up in a method, which is called updateBattery,  and which was quite logical.  It was saying something about battery level, so this is fine.  And it tells me that, so probably BLE LiveData is a class I need to investigate.  For the one with the Bluetooth row packet, so I copied the characters in here,  and it ends up in a method, which is named parseCommand.  This is also something that hackers will love.  Whenever you see parseCommand, you know, stars in the eyes, things like that.  BlueLEService is another class which is probably interesting to look into.  And while you look into that, it takes a little bit of time,  but you will get the full picture, which is,  understand how to discuss with the jump rope.  Basically, there are three different modes with this jump rope.  The number countdown mode, which means that you are going to say,  I want to jump, I don't know, 500 times.  The time countdown mode is, I want to jump five minutes.  And then the free jump mode is, I don't know what I want to do, but just let me jump, okay?  So, this is the way to send this command to the jump rope.  So, in phone 2022, what people had to do was to try and initiate a command  where they would do 1,337 jumps, okay?  So, what they had to do is to connect to the device.  Then the organization of the jump rope in terms of services and characteristics,  it's much simpler than the smart coffee machine.  There's basically only one or two important services.  And so, you get easily the characteristics you can write to,  because I think there's only one, actually.  So, there's not lots of choices.  And then you send the command that I said over here,  which is, well, some basic thing at the beginning.  Then you say, oh, it's number countdown mode.  So, I'm going to specify a number of jumps.  Then in hex 539, well, that is the target number of jumps I want.  And the last two are a CRC, a checksum.  So, you just have to figure out that it's CRC 16 Modbus,  but that's the only difficulty you have to do, okay?  And yeah, I've got another demo.  Yeah.  So, we don't need a phone for this one.  So, I'm going to show you how I communicate with the jump rope directly.  Hey.  Well, looks like my screen has frozen or what?  Yeah.  So, yeah, it's not clicking.  Just trying.  Okay.  So, I'm rebooting.  Sorry for this.  So, I'm going to show you afterwards a program,  which communicates by BLE to the jump rope.  And we're going to send the commands there to start and jump and things like that.  Okay.  Rebooting.  Don't worry.  It's normal that you're not seeing anything because, well, I unplugged the HDMI cable.  So, yeah, looks like this is fine.  Well, unfortunately, I had set it up and I'll have to do it again.  But so, we go in jump rope directory.  And I'm going to try, oh, I need also to show you my camera.  Okay.  So, cheese.  So, what happens is that there's a small LCD screen on the jump rope and that's what I want  to show you.  Yeah, not too bad.  So, and I'll put this in there.  Okay.  So, I'm connected.  We're going to do, how many jumps do you want?  Okay, 800.  It's not working.  Okay, let's do it again.  Okay, so I should put it the other way around so that you see that perhaps better.  But you can normally approximately see that it says 800.  Yeah, sorry for this.  It's not really obvious.  Now, I do not intend to do 800 jumps.  So, we're going to cancel that.  Canceling it.  And then you can try a time jump and I'm going to jump for 400 seconds.  And this is, you see exactly the number count down there.  Then, you know, my colleagues were annoyed with the buzzer.  So, I had to do something about the buzzer.  So, this is buzzer off.  And now, let's try it.  And now, the free jump mode.  No, sorry, I've got to cancel first the other one.  So, it cancels.  When it cancels, it tells me I've spent like 22 seconds doing nothing.  Okay.  And now, I'm going to try free jump mode.  And there it tells me, well, okay, go on, but you've done nothing.  Okay, I can cancel that.  And then, because I liked noise, I'm going to put the buzzer back on.  You've got the buzzer.  Okay.  Okay.  So, let's go back to the slides.  I'm happy nobody among the audience connected to the jump rope.  Okay.  So, I'm going back to my slides, and we'll finish up.  Yeah, this is done.  Now, this is not totally done for a CTF, because how are we going to validate the flag?  We want basically the participants to know how to send the correct command,  but in return, we've got to give them a flag.  So, how are we going to validate that?  There are various options.  One of those is, well, to do the manual validation.  They come, they show us that they are able to trigger the number of jumps,  and we give them a flag in return.  It always works.  That's something we can always try.  Oops.  We have also the possibility to have a web server.  Okay.  And then people would enter on the web server that they know how to do the number of jumps,  but it's missing kind of the BLE interaction.  So, I didn't really like that.  The other thing was, well, we're going to modify the firmware on the jump rope,  and we will display the flag.  But unfortunately, as you might have seen, it's really only a four-digit LCD.  So, I don't think it's possible to display the flag in there.  Okay. It would have been really difficult.  So, I ended up with the last solution is that I would like to build a fake jump rope,  which behaves exactly the same from a BLE point of view, but just has no rope.  Okay.  So, I tried that.  I tried that for weeks, perhaps even months.  It was never working.  There are plenty of different packages to deal with BLE.  I don't think that maybe I was unlucky or else, but it was never working totally.  Sometimes the packages were extremely old.  So, I even could not install them any longer.  Some other times, well, it was working to some points, but then it was bugging.  Then probably I added my own bugs also on top of it.  So, I was like, you know, thinking that maybe I would abandon that.  And then I went to another CTF I participated to, which is hardware.io.  And they were featuring a very nice BLE challenge.  And I'm not going to ruin their challenge.  But I thought, yeah, that's exactly what I should be using.  They had kind of a server, which was like a small Arduino-like board,  which was acting as the BLE peripheral.  So, I asked them for the code after the CTF they shared, which was really cool of them.  And I had a look, and I don't know why I hadn't thought about that,  but it was really easy and straightforward.  Just use the BLE from, well, Arduino ESP32.  So, I bought like three different ESP32 boards and started designing the fake jump rope.  So, I reused exactly the same services, the same characteristics as the real board,  so that it really would look like the real one.  Except that, for instance, on the jump rope, there is an over-the-air service for firmware update.  Well, obviously, I have no idea how to implement that on the fake jump rope, and it's useless.  So, I just left it, but it wouldn't do anything on the fake one.  And I added a specific CTF service, which was pretty much recognizable  with a very strange UID, dead beef, in here, and only one characteristic with the flag.  Okay, now, if one of the team manages to know how to do the number,  the requested number of jumps, I don't want, they will get the flag,  but I don't want the next team to come in and see the flag without having to do anything.  So, to prevent that, the solution is, of course, to erase the flag between all teams.  And what we implemented was a solution where only one team would be able to connect at a given time,  and when they were connecting or disconnecting, I would remove and erase the flag.  It worked very well.  We implemented three different fake BLE jump rope servers just to make sure that, you know,  well, BLE is BLE, I'll talk a little bit about that.  We sometimes have bad surprises, so it's always good to have three different items in case it is needed.  So, a little bit of advice and takeaways from different perspectives.  Hackers, well, don't forget to inspect Android logs.  From a developer point of view, I'm not saying that you should remove all logs,  because some are just very useful, but if it's debug logs, then you should think about removing them.  Normally, if you're in, like, you know, a company which is used to producing code,  this is really standard, and there are procedures to make sure that the logs are removed.  But here, we're talking about connected objects, and I have the feeling that it's like, you know,  a poor intern who was affected to developing the stuff in overnight,  and sometimes the development is a little bit crappy.  BLE connection is always painful.  That's, I don't know, always the case.  I haven't experienced too many issues with the Smart Coffee machine except for pairing,  but with the jump rope here, sometimes I get unwanted disconnections.  I don't know why, but this probably means, from a developer point of view,  that the quality of the BLE chip is not the same at both ends, okay?  Or the way it is manufactured in the device is probably different.  As much as possible, if you're a developer, I would recommend not to use pairing,  because pairing, I managed to do it, but there's no way that my father would be able to do it.  I mean, it's really complicated.  Okay.  BLE notifications is also something I haven't discussed, but it was really useful,  especially for the Smart Coffee machine.  Activate all notifications that you can.  You will get much more messages, and it's helpful to see the status of what is happening.  BLE encryption, that's also another part.  I have hacked quite a few of different BLE devices.  None of them have ever used BLE encryption.  It exists, but nobody uses it.  So, well, if you want to communicate secrets, that's a way to do, at least.  Manuals, manuals, well, yeah, they are really useful, especially to get the reset procedure.  So, and you can also get some hints on the hardware, and from the developer's point of view,  well, if you want to go green, and you claim you want to go green,  well, the really good thing to do is to give some opportunity to people  to repair the device that you are giving them.  Okay.  So, I don't know, give good manuals, service manuals, that is really good.  Different parts, where to find and repair parts.  If you can't, well, maybe 3D designs of the parts that you would like,  that would be helpful to repair.  That's good.  Hacking, so how, now, let's suppose that you want to hack a new device after this.  Where should you start?  Well, it really depends what you are good at.  If you master the hardware part, go and start from there.  If you don't, and you rather are good at Android hacking and things like that, like me,  well, it's obviously rather in the Android parts that you should do some reverse engineering.  The other thing also, which I think is interesting to point out for developers,  is that hackers are not your enemies.  Hackers are not attackers all the time.  And especially in all the hacks that we've seen so far, well, they were all positive hacks.  I mean, I'm not breaking anything, okay?  I'm actually making the coffee machine more usable because it's now usable over the Wi-Fi,  and I can get my famous 90 milliliter cup.  Okay, it's maybe useless, but it's fun.  Okay.  But yeah, it's a good thing.  It's fun, okay?  But yeah, it's useful.  And we only hack things that we like, to be honest.  Otherwise, it's not, or that we find funny.  Otherwise, we wouldn't be doing it.  Now, this is a little bit more part of my job.  I thought of, well, is it possible to infect either of these devices?  Fortunately, in that case, it is not.  Because there is nothing where we can really substantially store a malware.  It doesn't need lots of space.  A malware, a few bytes, or at least one kilobyte would be sufficient.  But we don't even have that.  They are really limited there.  So this is good.  But if you are designing a connected device, which is connected to internet and has storage,  even a little bit of storage, really pay attention to this.  Because they might get compromised and serve to compromise other hosts afterwards.  So this, you need really to pay attention to.  And that's all.  Thank you very much for your attention.  Okay, so do we have questions?  We have a few minutes at the moment.  Coffees are being prepared in the main room.  And I think it's a good idea to keep you here, to not let you go to the coffee machines right there.  So let's start there.  Wait for the microphone.  I haven't sent it to Nespresso in that case.  Because it wasn't a vulnerability, right?  Okay, so I thought that they wouldn't really be interested.  However, if they want, for instance, to implement on their app the possibility to customize the  volume, well, they are more than capable to do it.  So it would be possible.  They can go and get it.  I mean, it's public also for them.  But yeah, so the answer is no, because I thought it was not a vulnerability.  Any other question?  Same for the jump rope, by the way.  I didn't disclose because, well, it's just using it another way.  But it's not really vulnerable.  Okay, thank you, Axel.


url: https://www.youtube.com/watch?v=x5IyXJthNo0
title: The Latest Startups In Cybersecurity & How To Become A Cyber Entrepreneur? by Trust Valley Startups
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=x5IyXJthNo0",
    "title": "The Latest Startups In Cybersecurity & How To Become A Cyber Entrepreneur? by Trust Valley Startups",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 3245,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Ladies and gentlemen, we are very pleased to be with you today.  I'm Lénique Pedron, the director of the Trust Valley, and I am with Olivier Crochat, the  executive director of the C4DT, come from EPFL.  We are very honored to be with you with two parts of this slot with you.  The first part will be a pitch of our start-up, and the second part will be a discussion how  to become a cyber entrepreneur, and we will have three start-ups with us, three entrepreneurs,  and one serial entrepreneur too, and they will speak about how you can find a way to  create your own company in cyber.  First, some words about the Trust Valley, and I just want to say to you that we are  not alone.  You have seen we have some people here.  It's because we have the Jury des Assises de Monaco, the start-up.  They are with us since this morning, and they will follow the pitch of our start-up.  The Trust Valley is a private-public partnership for digital trust and cybersecurity on mission  to foster trust, innovation, and collaboration in the economy.  We were founded by the state of the Republic of Geneva and the state of Vaud.  We work a lot with the NCS, so the Confederation, and all the part of some other governments,  so thank you to the Luxembourg to be with us, the government part of the Luxembourg.  Thank you to be with us today too.  We have as a funder six academics, such as EPFL is one of our funders.  Thank you for the support.  And also a lot of private sector, such as SMB, SME, that you know as ACRT, is a sponsor  of the Trust Valley too, but also is an expert solution on one to the other.  We have also Koudelski and all the names that you hear, I am sure you know.  The Trust Valley mission is really we do some referencing, promotion, network, hub, talent  is for that.  It's really important for us to be with you today also.  And we create some projects.  The first project program was created before the COVID.  It was, the name is Tech Fortress, this is a booster for startup.  So if you have a project, if you want to create your project because we have an idea, just  come to us and we can discuss to go to the market.  Because what we have seen in this region is that there is a lot of many, many very strong  and very good community with a lot of expertise, technical expertise, but sometimes they need  to have the go-to market.  So it's what we have done with our startup and we want to share that to you.  We work also with SMEs, so you will see some of our startup are now involved in our program  dedicated to SMB, SMEs.  So it's for that we open for them some possibility, some business opportunities to work with SMEs  and also with corporate.  Next, with KeyFuture of this huge program, it was really a pilot the first year.  We thought that it was very difficult to find 10 startup and we found 15 startup for the  first edition.  And now this is the fourth edition and we have more than 100 startup supported and it's  nearly 50% come from Switzerland, all the canton.  And Zurich, Bern, Vaud for sure, and Geneva.  And also we have now a lot of startup come from foreign country, it's 40% also.  More than 50 partners and more than 200 million raised by our portfolio.  So what we have seen since the beginning of the journey with the Tech Fortress, it's really,  at the beginning it was really difficult for a cyber funder to raise funds, to fund a fund,  to fund a good investor.  The market is really time-riding now, so I think it's really a huge opportunity for you  also to go in this cyber entrepreneurship.  The value offered by the program is nearly 100k on the budget.  Best-in-class cyber security startup, so we scout, all the year we scout with the help  of EPFL, but also with private sector, and also with the canton, and also with the army.  We work with armistice.  Some of you maybe know the cyber defense campus, they help us to have good scouting.  And we scout this kind of expertise, I will not read all the word, but I'm sure that you  have seen this kind of what we are looking for.  We opened this year two new vertical, relative to digital governance, and P-STEC.  Why?  Because we have now one incubator, just opened at the end of last year, in a new campus named  Unlimit Trust, dedicated to economy of trust and cyber security, just close to SIGPA company.  And we will open also a new trust village in the same mood, in Geneva, in April or June.  And we will scout about P-STEC, because we think that it's really a market to open with  that.  And also about canton.  At this time, what we have seen with the startup come from canton, it was, yes, I think we  can raise the number of the startup in canton.  In the field, we work a lot with space, smart cities, agri-tech, agri-food, health, and  the other.  So moderation with Olivier Crochat, and right now, I call Cognitech, our first startupper,  so Gilles Rosset, CIO at Cognitech.  Thank you, Lenny.  First security incidents have one thing in common, and I'm talking about intrusion, sabotage,  fraud, data leakage, and so on.  They were made possible because sometime in the past, something changed in the information  system, and the impact of this change was not assessed or completely understood.  A new service was exposed, but the configuration of your vulnerability scanner or IDS has not  been adapted.  A person moved within the organization and started accumulating toxic combination of  access rights.  A new version of the email client has been deployed on the workstations, and you don't  have the right controls on the DLP agent or the endpoint protection system.  Those things happen in real life.  Whatever your level of maturity in terms of cybersecurity, whatever the budget, the tools,  the people, the process is in place.  That's the real life.  So what can you do about it?  Can you perform a complete, in-depth risk assessment for every single change?  Obviously, it's not economically viable.  My name is Gilles Rosset, and I'm the CEO and founder of Cognitech, where we provide  a technological solution to this issue.  Our platform will monitor and watch and detect the pertinent changes in your information  system and assess its impact in terms of risk and compliance to your policies.  So that we immediately detect whenever you're in a situation where the risk is higher or  whenever there's a violation of one of your policies.  And as we are able to do that, we are also able to simulate the impact of a change that  you plan to do.  This is how we help our clients to achieve truly agile risk management and continuous  compliance without slowing down innovation.  Thank you.  Thank you.  Thank you.  Thank you so much, Gilles.  Do we have some questions coming from the Assis de Monaco?  No, not yet.  Oh, not yet?  Adieu.  Okay, so Gilles, what are your USPs?  Well, the USP is really the real-time aspect, because we are really monitoring all the information  continuously.  And the fact that we make it super user-friendly to the end user that we target.  We are not dedicated to technical engineers.  We are really targeting a population of risk managers, senior managers that want to use  and have a vision on the situation and be able to use it without having a training or  without having some complicated stuff to do or develop code or whatever.  And is it more for large companies, or is it depending on the level of security of data  that you need to have, or what?  It's from the SMEs to the biggest companies, because obviously, to have that kind of system  in place, you have to have a certain level of maturity in terms of data.  So that addresses SMEs and more.  So it could be also SMEs then?  Yeah.  Okay.  No question?  Okay, so thank you so much.  Thank you.  Thank you.  Okay.  Now, our next startupper, Stefano Zamuna, software developer and machine learning specialist  at ClearSky.  Thank you.  Can you hear me?  Yes.  Yes.  Have you ever considered how easy it is for hackers to clone your voice?  It takes them just a sample of three seconds to build your vocal avatar and make you say  whatever they want.  Now imagine what they can do by stealing hours of recordings from board meetings or medical  consultations.  Confidential conversations need more secure solutions, and this is where ClearSky comes  in.  Our product, ClearMind, will transform your conversations into digital and structured  documents, locally, without the need for an internet connection.  With ClearMind, you don't have to worry about taking notes anymore.  You can focus on the conversation you're having, and our technology will take care about extracting  and summarizing key information for you, saving you time and all this without compromising  your privacy.  We already tested our solution in several clinics around Switzerland.  Doctors are reporting an improved focus on their patients and up to 40% of their time  saved by using our technology.  But ClearMind is not just for doctors.  We are testing it in the legal domain, and our team will be more than happy to help you  augment and automatize your private conversations as well.  So if you are interested in this kind of solution, please meet us at our booth and sign up for  a demo.  I'm Stefan Zamonaris, CTO of ClearSky.  Thank you for your attention.  Thank you.  Thank you so much.  Just maybe one question.  I have the feeling that what you said is that it's processing conversation to extract  useful information.  Yes.  What's the link with the protecting the audio from fake redoing your voice?  So our solution is limiting the surface of attacks that you can have by being completely  isolated from the internet.  So if someone wants to steal your data, they have to have physical access to them.  But in any case, we are, of course, having encryption solutions on the device.  So this is our solution.  OK, thank you.  Some questions come from Monaco.  And so maybe while we're waiting for the questions from Monaco, you said that, of course, medical  information is interesting.  And you talk about the legal one.  Any other domains or sectors where it could be interesting?  So there is the law enforcement, where we have depositions, where people can go to the  law enforcement units.  Boot meetings is another segment we are investigating at the moment.  So this kind of solution.  Thank you.  OK.  Thank you so much.  Thank you.  OK.  Thank you.  Next startup, Dejan Milenovic, CIO of Autena.  Thank you.  Autena makes the world more connected, transparent, and authentic place by providing instantaneous  verifiable trust across multiple value chains.  Our technology at the moment is in more than 70 countries and used in different verticals  like pharma, food and beverage, luxury, and sport.  Contrafitting creates losses in the range of hundreds of billions of dollars per year  and impacts societies and individuals and companies in multiple ways, but most importantly,  it endangers human life.  And in the recent years, we have noticed a rapid increase in contrafitting, partially  due to the pandemic and the increase in online trade, and also with the emergence of digital  technologies, multiverse, and blockchain, we have the contrafitting appearing as well  and growing in the digital world.  My name is Dejan Milenovic, I'm CTO of Autena, and together with my colleagues in Autena,  we are trying to solve this, and we are working hard to solve this problem of contrafitted  products and traceability in the supply chain.  With more than 11 international patents combining IoT technology and blockchain, we provide  traceability and authenticity platform as a service, and this also infrastructure-free.  So our technology provides a possibility to track products on the single product level,  to collect interaction from end-users of the products, to make a bridge between physical  and digital products, and also to provide the real-time monitoring of location and environmental  conditions of monitored products.  And I am very proud to say that we are the first Swiss company who, this year on the  World Mobile Congress, won the Global Mobile Award for this technology that provides bridge  between physical and digital products.  Thank you.  I am at the Tech Trust booth later, if somebody is interested to meet and talk, I will be  there.  Thanks a lot.  So maybe one question concerning the, it seems quite a huge infrastructure you need  for that, so any proof of concept or already customers using the solution right now?  Yes, we have multiple customers, as I mentioned, in several industries, in pharmaceuticals,  in the luxury sector, perfumes, in food and beverage, wine production, and in sports as  well.  Okay, good.  Okay.  I have a question for you.  What solution are you projecting to focus on?  Like single-time usage?  A solution also that could weigh the life cycle of the product, the product that could  be stored for a very long time and then be sold to somebody else and not anyone?  Well, that's a very good question.  Thanks for that.  We have actually multiple, let's say, parts or devices which can do both, can follow,  let's say, the products with the fast life cycles, so to say, but also longer life cycle  products and also reusable traceability solutions.  When you talk about the life cycle management, this bridge between the physical and digital  products becomes interesting because then you can have these smart contracts in the  digital world which follow uniquely a physical product and can sort of facilitate management  of its transformation through the life cycle.  Okay, thank you.  Thank you very much.  Another question?  No?  It's okay?  Okay, thank you very much, Athena.  Okay, next one.  Arnaud Gardin, Director, Client Solutions and Partnerships, to Another Way, so Arnaud.  Let's imagine that you're a hacker.  You are in the dark side of cyber.  You do it for a living.  So you need to be efficient.  You need to be productive.  What will you do first to attack a company or an organization?  No idea?  If I am a hacker, the first thing I will do is I will look at the statistics.  80% of attacks will leverage human vulnerabilities right from the start of an attack.  These human vulnerabilities, what are they?  They are all the private information of collaborators, of VIPs, of a company, of an organization.  So you just have to have a look at the social networks, at the forum of hackers on the deep  and dark net, and you will find, you will be able to find a lot of information to create  social engineering, phishing attack, et cetera, et cetera.  What we do at Another Way is we change the game.  We want to prevent this initial step.  So we have created a dashboard in order to assess the risk for everyone in a specific  organization.  So we have an entry point, the email address, for instance, and we will gather a lot of  information about their risk so that we can have a scoring about their risk.  In a second step, for the people at risk, we will provide an individual web app for  anyone to have a look at his own exposure.  So with this web app, you will know exactly your exposure, your level of risk.  You will be able to add your personal data to know if you have a leak on your Gmail address  or if your phone number is exposed, and then you will be able to remediate that.  We will give you some advice.  We will give you some correction in order for you to remediate these vulnerabilities.  So basically, we change the way we approach cybersecurity prevention.  We address the human factor in a different way.  So we change this approach.  Thank you.  Thank you.  I'm Arnaud Gardin, and I'm happy to receive your questions.  You mentioned the market, or let's say the customer base.  Is it more companies, or it could be directly individuals interested in knowing more about  their attack surface?  So today, we work with enterprise, with companies, but we've seen that, for instance, in the  US and Canada, we are starting expansion there.  Whenever there is a leak in a company, the company, to avoid class actions, will propose  various tools, so antivirus and so on and so forth, and potentially an R application  for their employees.  So at a certain step, we will go to the B2C market.  Today, it's B2B, and we can work as well with B2Gov for certain specific environment  and protection.  We won the Forum Internationale de la Cybersecurité Prize this year, and we are starting to work  for the Jeux Olympiques 2024 in Paris with the Ministry of Interior.  Okay.  Thank you.  Thank you so much.  Thank you.  One question from Monaco.  Yes.  Jerome?  Yes?  Yes.  I agree.  I have a question about the situation of the factory environment, the internet.  Do you get your own information,  do you have to take it to a delivery company?  So good question.  So basically we supervise data leakage,  data leaks, for instance, on the dark web.  And whenever we have customers, we are GDPR compliant.  So we do this when we have customers.  We do look at their social networks on demand,  based on their action, on their own action.  So it's real time.  We gather information from the various leaks,  from the various social networks.  Okay, second question from Monaco, I think.  Is that right?  Yes.  Thierry?  Yes, sorry.  But in fact, I have my own solution.  So if you take your own data driver on the dark web,  I actually work for a company like that.  Indeed, yes.  Okay.  Okay, so thank you so much.  Thank you.  Thank you, and as always.  Thank you.  Thank you.  Thank you very much.  Thank you.  Thank you very much.  Thank you.  Okay.  Okay, next startup, Philippe Huguet,  CIO of Alchemia.  Welcome on stage.  Thank you.  Thank you.  Thank you.  One billion of events per day.  This is the average number of events  we are collecting for a mid-sized company  of, let's say, 1,000 workstations  to get a unified vision of cybersecurity and observability.  We speak about 12,000 events per second  to collect in real time, to ingest, to store,  and to transform into actionable insights.  Real-time data is becoming the fuel of cybersecurity,  but it's also becoming a main issue  because it's growing exponentially.  This is the main reason why  so many historical SIEM solutions  are no more able to do the job,  and also why the most powerful solutions  are becoming so crazy expensive.  This is exactly the reason why  a leader like CrowdStrike, two years ago,  decided to get rid of very famous solutions  to buy a company called Umeo,  because Umeo was one of the very few companies  that built its own data processing technology.  The good news is that  you don't need to buy a company anymore  because we are coming with a disruptive solution.  So Alchemia, we are a Swiss company,  and we are very proud to develop  the first AI-powered data factory  that is breaking the complexity  and the cost of real-time data analytics.  To do this, our platform is able to be connected  to any kind of data source,  and at the same time, in real time,  the data is prepared for an immediate usage.  What was so complex and so expensive  is done now, 10 times faster,  and with 10 times less resources.  I'm Philippe Huguet, CEO of Alchemia,  and I'm very happy to be able to make  your cyber data science dreams come true.  Thank you, Philippe.  So you talk about, let's say, data connectors.  So you talk about, let's say, data connectors.  So it's mainly for IoT or workstation,  or what type of devices?  When I said that we can be connected  to absolutely any kind of data source, it's the case.  Structured or unstructured data,  IoT, sensors, everything you want.  And you spoke about USP.  We are very proud about our universal connector  because it seems to be a first worldwide invention,  and the efficiency of our universal connector  is just amazing.  I'm sure.  Thank you.  Okay, maybe some questions.  Sorry.  Come from Monaco?  No question?  Okay, so we will go to the next part of...  Thank you very much.  And thank you so much, Philippe.  And just to let you know,  you have seen some different state of maturity of startups.  So some startup are at the very beginning  part of their journey.  So business concept, and some of them  are more like a trainer at a Serie A,  what we call Serie A.  So they've proceeded, they have two or three round of seed  to be in Serie A or Serie B.  Now I will call on stage.  It's my big pleasure to have on stage with us  to speak about how to become a cyber entrepreneur.  Three startup who come from our acceleration program.  The Tech Fortress, they are now alumni.  So they are the high brother of the startup  that we have in our cohort.  So I'm pleased to call Laurent Balmeli.  Laurent Balmeli come from Strong Network,  and I think we need to have some share.  Yeah, please.  We can help if it's needed.  And Laurent, you won last year the FIC.  The prize of the FIC, yes.  And I call also the team of Sapporo.  We have two founder of Sapporo with us today.  So, and you're two Serie A entrepreneur,  as you Laurent, we call that a Cyber,  Serie A Cyber Entrepreneur,  because it's not the first exit of this entrepreneur.  And I call the last one,  Aurelien come from Rumia.  Thank you, thank you very much for being with us.  So, Olivier, maybe we can begin with some question  for our startupper, yes?  So we have everybody on stage now?  Yeah.  Okay, perfect.  Thank you.  Yeah, we've heard about the, let's say the other startup,  or they presented themselves just before.  You've went through this stage.  So you were a few, let's say, steps further.  How does it feel?  Oh, you mean like the, sorry again, the next stage?  Yeah, the next stage.  It was like more doing the,  running through the accelerator program from Trust Valley,  and now you were, that is done.  Oh, okay, it's a follow up, yeah.  Okay, first of all, I'm really amazed  that there's so many people,  because thanks a lot for coming first.  I was not thinking that we were gonna have so many people.  So thanks a lot.  Don't go, because there are people actually leaving now.  Come a little closer.  Okay.  Yeah, I think, you know, it's been like,  I mean, like everybody who's doing a startup  knows it's a wild ride, right?  It's gonna be a lot of things.  I think being part of a program is essential.  For a startup, if you do a startup,  I think it perhaps is the best way to start.  You get yourself into a program,  get some coaches, mentors, get into the,  I mean, the network.  That's gonna give you some boost.  I mean, not all programs, obviously, are worth your time.  This is a good one.  But also, like, for instance,  like we are like a part of a program like in New York,  and after half the time, we decided,  ah, this is really a waste of time.  And also, it was something with NYU Sterns.  We think, oh, that may be good.  But then we're part of the one in the FinTech Lab  in Accenture in London, which is unbelievable.  So you have to pick your bottles,  not bottles.  And yeah, I think this is a good way to move forward, yeah.  Maybe a question for you, Philippe.  We are very pleased to have you on stage.  You are a serial entrepreneur, but also a papa,  because we don't have Olivier on stage,  but this is a startup at the beginning  of also Olivier Arias, your son.  And your two sons are involved, I think, in the startup.  Could you give you more information about that,  or how to become a serial entrepreneur?  Sure, sure.  Yeah, for me, I have created a lot of companies so far.  Nine, to be exact, in my life.  It's 35 years, so no merit, okay?  So, and the last one,  because I'm here to speak on behalf of Sapporo,  it's the most extraordinary for me,  because I did it with my two sons.  So you can imagine what that means.  So I'm very proud of that, for sure.  At the same time, I have educated my son  to become an entrepreneur one day or another.  And this is what was happening in reality,  not just for Sapporo, because for the two sons,  it's not their first one.  It's for the older one, the third,  and for the younger, the second.  So yes, it's something which is very important.  And how, because what we need to speak  is how to become a cyber entrepreneur.  So you can become a cyber entrepreneur  by family usage, with my example.  For example, I mean, and also by chance,  by opportunity, but whatever.  In order to succeed, you need to have step-by-step  an environment that will make you successful.  The first one is to have the good idea.  I heard the question from the audience.  What is your unique selling proposition?  It's not easy to respond to that question, right?  But it's based on an innovative idea first, for sure.  You need to consider what exists already,  what doesn't exist, why you can do better.  You need to be confident in yourself, but it's not enough.  After, you need to build the first prototype  and then build a little team, a small team,  at the early stage, with people you trust.  And then you need people like them around,  not just Tech Fortress, but also Innovo  and many other things that DataDovo can bring on the table.  Because this is where you can acquire the visibility.  If you consider Sapporo, for example,  we have been very proud to win the first prize last year.  For sure, that increased the visibility of the company  to be chosen as the best cybersecurity solution.  But then, it's not just enough.  And after, you need to have the funding to success.  I know that not all the companies here need funds,  but most of the time, you will need funding,  so you need to use the visibility  that brings Tech Fortress to get the right funding.  This is exactly what Sapporo did.  And after that, you need also to get customers,  which is the last thing and not the easiest thing to get.  So, that's just me.  Maybe, I just want to add,  you talked about customers, it's interesting,  and also about the fact that you've had  quite a lot of successful startups.  So, what is the difference, maybe,  I'm almost sure, over 35 years,  that the previous ones were not cyber startups.  So, do you see any difference between a traditional startup  or a cyber one, or what needs to be done there?  No, there is a big difference.  There is a big difference.  The cybersecurity segment is crowded.  Hundreds or thousands, I've not counted,  that exactly exist on the market.  So, you can hear every day, including today,  customers visiting you, they say,  we have so many, so many solutions.  So, the net is, because we don't have too much time,  and I don't want to keep the speech too much,  is, okay, if you want to acquire a new, innovative solution,  you need to keep out a solution  that you already bought in the past,  because that's the rule today for all the customers.  I don't buy if I don't stop the subscription of order,  or other...  Or it could be a new demon, no?  Yeah, but...  So, maybe, Aurelien, have you seen, also,  that type of, like, overcrowded potential customers market,  or with competition, or?  Yeah, I mean, it depends.  On your side, we are more on the data protection parts,  especially about regulation.  We work a lot with GDPR regulation  with European companies,  and in Switzerland, we work with the new LPD regulation,  and in Switzerland, we don't have so much competitors  on these specific regulations issues.  So, for me, it's a little bit different,  but in Europe, yeah,  there are a lot of companies doing that.  But, generally, in the tech and the cyber security,  we can see a lot of companies working on different subjects,  and, yeah, I mean,  I can understand it's quite hard  to be visible on the right way.  You talk about your product around GDPR,  or things like that,  so why Switzerland, and not being based in Europe?  So, what is more interesting?  Why is it more interesting to be around here?  Well, first of all, because I'm living here,  and just to explain a little bit about myself  and my background,  I was working in a company here in Switzerland,  near Geneva, in a startup,  but inside a big IT company,  and I left this company five years ago  to build my own startup.  Thanks to my clients, they pushed me in this way,  and when I found my company,  I already have clients,  so it was a big chance for us,  and that's why, I mean,  our market here is so important for us,  because we are already a network,  and the trust of our clients,  I mean, it's the most valuable thing in our company.  We can create tech, we can create program,  but at the end of the day,  what matters is the trust that your client gives to you.  Okay.  I know, Laurent, you don't like that I told about this story,  but I will do,  because we are in Antwerp-Nyack,  so I hack your slot.  And I just want to talk about how it's possible to find funds  and to find a good investor,  and could you tell more about your story with Wigman  and what happened with them?  Okay.  Yeah, obviously, finding money is the first thing, right?  And also, I think you need to take money  when you create a company,  because you're not, I mean, like startup,  because you're not creating like an SME.  You're creating a company that needs to be fast,  so that's why you need to raise money,  more money that you can make with customers  so you can grow faster.  And the main point for that is  because you're doing something innovative.  So if you wait too long,  and you're trying to grow like moms and pops,  or like nothing against SMEs,  but it's a different just business model.  So I think it's very important that you keep in mind  that the time to market is critical,  especially when you want to raise money.  So my experience is that I was fortunate enough  that it was my second startup,  and I sold my first startup to Snapchat in 2016.  So then I have an earn-out period.  And then-  But in Switzerland, in Iberdon.  Yeah, in Iberdon.  All places.  Well, actually, they asked us to,  oh, I guess you moved to LA.  I said, well, no way.  I have two kids, a wife, a house.  And I lived in the US for 10 years.  I lived in New York, and then I did Japan.  So I was like, okay, that's enough for me.  I want to raise my kids in Switzerland.  So I said like, okay.  So I'm gonna, and eventually, so they bought us,  and that was a good experience, obviously,  for the, you know, when you look for funding.  For the next time you go to CVCs,  if you have an exit, wow, that's kind of a gold card entry.  So obviously, it makes things way easier, right?  I need to be recognized that if I didn't have an exit,  I didn't have to go.  Because I basically went to see only one investor.  It was Ring of Adventure.  And so we raised 600,000, no customer,  just an MVP that I coded with my partner,  and a guy who left a snapshot to come with me.  And so we raised that money, and then we,  this is something else.  Don't expect yourself to pay much,  to pay yourself much, right?  Expect to live on a shoestring,  for the next two years, right?  We literally, I mean, I think if you do a startup,  if you want to have more than 5,000 a month,  it's not for you.  So this is kind of a rule of thumb.  Everybody's gonna be paid about 5,000 a month,  which is, I think, okay in Switzerland to live, right?  Obviously, you're not gonna go on vacation very often,  right, especially if you have two kids and a wife.  But this is just life, right?  But I think you're in for the adventure.  So you have to find also people that are minded,  that they agree on that.  It could be perceived as a sacrifice,  but to me, I just think it's a great experience,  because building this team is one of the crux  of creating a startup.  And then, so we lived on that shoestring  for about a year, and it's changed.  And then I could sell the platform to Broadcom,  which is a global customer in San Jose.  And then we raised, then we seen this investor,  and we raised 5.2 million last year.  But one thing that I learned,  because I didn't know this with my previous startup,  is that getting the VC is like,  every time you have a step,  is the brand that you put on your startup.  So it's really strategic.  I was not ever aware of this.  I say, well, money's money.  So, but actually, there's money  that is actually better than other money.  And you need to put kind of the bright stamp  of which VC, because if you want to go next  with the benchmark of the world,  or this kind of investors,  they need to have good VC.  So be very careful when you take money from people.  You have to be very careful where it comes from,  and also make sure that it's not something  that's gonna impede your growth.  It's really interesting, and just another question.  We talked about cyber entrepreneur,  and back also to the question.  Have you seen any change in the market  between your first startup  that was also about security and now different?  You've changed, in terms of money, right?  Yeah, you've changed, absolutely.  Like for instance, our pre-seed VCs,  they have a fund that is basically  just for EPFL student that have an idea,  which is fantastic, right?  They can get like 20K,  and they can just realize that idea,  and which didn't exist before, right?  And also like Wingman Venture, the pre-seed,  it's very new.  Pre-seed funding in Switzerland,  it's really something that for the last two, three years,  when I did my first startup, there was no such thing.  So if you need like half a million,  which seems to be a lot, right?  But when you put like a team, and you try to,  again, it's not gonna be a lot, right?  To create a product, especially if you do something  that is complex in infrastructure.  But money's there, and if you have a good idea,  if you're really motivated,  I mean, it's really possible to do that.  You ask 200K to Wingman,  and they say to you, no.  Yeah, we went with my partner, we said like,  okay, well, let's ask 200K,  because I think we have no customer,  we have no, and we have no product,  we just have the MVP.  And literally, we went to see these guys,  and they said like, well, actually,  we wanted that money in October, it was July.  And this guy said, well, no, you need the money now,  you need 600K.  And I said, oh, okay, for SIM dilution?  Yes, okay, then let's go for it.  So, but again, so I think what,  but the message is that there's money  to be allocated to good projects,  so you have a good idea, I mean, it's definitely possible.  And maybe about the Switzerland and the change in the market,  Sappo, is it, are you, were you based already in Switzerland  for the previous companies,  or are you based outside of Switzerland?  The two last ones before Sappo was Swiss-based.  Okay.  So, NexSync was the first one.  You said it changed a lot.  I don't agree that much, on my experience,  for example, for NexSync,  I remember we had no product, a prototype,  even if we can call that a prototype,  but I'm kind, so you call that a prototype.  And then we met Venture Incubator,  at the time, which was based in the PFL,  and then you go, that everybody knows, obviously,  and we discussed, and I said, we have nothing,  we have no people, we are just four people in the company,  two developers and two in charge of the business development,  and they say, yeah, I agree,  but do you have a customer interested?  I say, yes, we have one.  And is it really to pay something, whatever it is,  to work with you?  You say, yes, but it's a little,  a very few amount of money.  Say, that's fine, it's a reference.  So I say, yes, it's a reference,  and they say, okay, you can have 1.6 million,  which was for a pre-seed round,  you see?  So, yes, it changed, and at the same time,  you have also opportunities, at the same time that today,  there is big money on the market,  but you can cry for 600, but between us,  what you can do with 600?  Not that much, as you said, right?  So, it changed, and at the same time,  it's always the same story.  You say, you need to,  you need to choose the right one,  because a dollar is not a dollar.  I disagree on that.  I say, for me, a dollar is a dollar.  I met hundreds of VC in my life, in my nine companies.  Do I consider one better than another?  No.  What you can wait from VC, they say, they claim,  we'll help you, we'll help you on the sales side,  on the business development.  No.  So, there is some disagreement there.  On the other hand, you talked about having a customer,  or a potential customer helping.  Have you seen that, Aurelien?  You mentioned the fact that you were, let's say,  pushed to entrepreneurship by your clients,  or actual clients, so you had already  the potential customer when you started there.  Is it, does it make a difference?  Did it make a difference for you?  Yes, our client was really important  at the beginning of the company,  because they trust us, they can make the fact  that we can pay ourself, and because we also have family,  so, yeah, we need to be paid for the work,  and, I mean, money is a part, they pay for the service,  but also the network opportunities they open to us  was really important, so, on this point,  it's very important for us to rely on the clients,  and it's also really important to rely on specific organism,  like Trust Valley, for example, or Innosuisse, et cetera.  We are alumni for Tech Fortress season two,  and we gain a lot to be part of it, to be honest.  We learn a lot of things, we create a strong network.  And we also gain a large amount of credibility on the market,  and, yeah, I mean, all these points are really important.  Alone, it's not sufficient, it's not enough,  but when you put all this thing,  yeah, you can take some value from that.  Okay, one last question.  Please.  Oh, I don't know.  Yes, it's such a big pleasure for me to have you all here.  It's one hour share with you on the other startupper.  It's an extract of what we are doing in the Trust Valley.  We created this ecosystem in the region,  but we work also with other ecosystem  at international level.  We will go in RSA conference in San Francisco  next month, and yes, we work also with the north of Europe.  And maybe, do you have one advice,  one thing to do to someone  who want to become a cyber entrepreneur?  First, maybe you have the mic, so let's go.  Just go one step ahead, try it.  I mean, it's worth it, and it's not so complicated,  but don't be shy.  Talk with other entrepreneur.  Open doors, Trust Valley, Genium, Innovo, InnoSwiss.  You have a lot of opportunities to create,  but you have to create it by yourself.  Yeah.  Yeah, I think the only thing I can say  is that you need to be, I mean, like a team builder.  It's all about the team, right?  It's not gonna be you.  It's find the right people to work with.  I mean, this is the thing.  Also, when you go to VCs, they look at the team.  That's the first thing they look at.  They look at who's basically partnering, right?  One-man show never works.  I don't know any VC that invest in one-man shows.  Three, four people, sometimes it'd be more difficult,  because it's like, a couple is ideal.  So find a good partner,  find somebody who complements your skills.  I think this is the first step, really, to create a company.  Yeah.  Thank you, Laurent.  And Philippe?  I will be very short,  because I completely agree with Laurent.  Most important thing are people.  The people you are working with,  which include your customers,  that you need to build a trust.  Take for trust, the name is not for nothing.  A lot of trust.  Trust is the key of the cyber security startup.  The trust.  The trust between people inside,  and transmitting this trust outside.  So that's the most important thing, people.  Thank you very much.  Thank you, thank you to you all,  and see you for the next level of your startup,  and continue the adventure, the journey I wish you.  Thank you.


url: https://www.youtube.com/watch?v=MsLwY9XbB4o
title: How To Have Visibility And Security OF CICD Ecosystem by Pramod Rana
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=MsLwY9XbB4o",
    "title": "How To Have Visibility And Security OF CICD Ecosystem by Pramod Rana",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 1901,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Hello everyone and welcome to the talk.  Today I'm going to talk about how to have visibility and security of CI-CD ecosystem.  From the agenda perspective, first I'm going to set the context that why I'm having this  talk at the first place.  I'm going to touch upon the attack surface around the technology part and what could  be the possible methodology we can have to address the challenge.  And then I'm going to introduce an open source project, CI-CD Guard, around the similar solution.  And then we are going to deep dive into the architecture and the workflow, how the different  components of that solution works.  And we'll have a demo and then I'm going to close out with the future roadmap around the  talk.  A bit about myself, I'm Pramod Rana, working as an application security manager with the  NetScope.  For those who don't know us, please visit it.  We are at Insomniac.  And I'm primarily in two domains, security testing and DevSecOps.  I'm author of three open source projects, Omniscient, ViewPrioritizer, and SecDependent  Editor, which I have presented in different talks, BlackHat, DefCon, NullCon, last month  OS Global AppSec.  I'm also OSPune chapter lead and an OSCP.  First about the context.  So let me start with the oversimplified version of the CI-CD ecosystem.  So for any software in the world, we have a certain code base, that code base is stored  in a central location in terms of organization.  And then we have a solution which converts that code base into deployable entity, which  is again stored in a central location.  And then we have a solution which deploys that deployable entity into the different  infrastructure or the environment.  And that environment could be anything.  As a DevSecOps advocate, I highly recommend to have the security integration with each  phases of the SDLC, which we call it security in CI-CD, as we all know it.  It's a great topic, but this talk is not about that.  This talk is about securing the building blocks of the CI-CD ecosystem, which is security  of CI-CD.  In any kind of ecosystem, I'm using the word ecosystem very precisely here simply because  no component or no technology in the overall CI-CD platform is independent.  All of the things are related to each other.  Because end of the day, as a software provider, we are delivering a software to our customer.  And in any ecosystem, in nature as well, if we have a compromise of one component, it  eventually impacts the entire ecosystem.  And that is the need where we need to look at each component separately, but at the same  time building the overall relationship between them.  That is the part of problem.  The first is the visibility part.  And when I say visibility, what I mean by that is in a medium to large size of organization,  as a security professional, I might be aware I have, let's say, thousand repositories.  But do we have the visibility that how many third party GitHub actions we are using across  those thousand repositories?  And even in best case scenario, let's say we have that visibility, but are we aware  that which version of the third party GitHub actions we are using across the entire organization?  And that just one example of that.  Another example could be, I might be aware that I have, let's say, 50 Jenkins server  in my environment.  But do I know that how many jobs are running on those hundred Jenkins servers?  And if yes, that how many nodes I have across those are different Jenkins infrastructure.  So that comes the visibility part of the entire ecosystem.  The other part is the relationship.  Like I said, there is no independent entity when it comes to the CI-CD pipeline.  All of those things are related.  But how do we know the relationship between the different components which is flowing  from A to B at any given point of time?  And that we will touch upon the attack surface part as well.  So let's say we have a Jenkins server which is running a job, you know, building the binary  solution which we are deploying at our customer site.  And in that Jenkins server, let's say we have a very trivial vulnerability, default or weak  credentials.  So at first point, it might look like a very trivial vulnerability.  But if you look at the overall picture, and that's where the relationship part comes into  the overall system.  From a very trivial vulnerability, which is a default and weak credentials, we will be  impacting our binary, which we again is deploying into all of our customer infrastructure.  And if you look at it from the business perspective, that's a, I'll say one of the worst areas  we could be in, in terms of security.  Another area could be, let's say, in a GitHub action, we are running self-hosted runners.  And that self-hosted runners is running a vulnerable or malicious third-party action.  So what's going to happen is, I was looking at one of the talks where the presenter explained  that how the mining or the cryptocurrency solution runs from these kinds of scenarios  where they will be using the organizational self-hosted runner in order to run the malicious  third-party into the environment.  And I think that connects to the overall software supply chain security part.  Another example of could be, as we all know that in the organizational level, we run on  the SSO mode where the one user is presented across the different technology.  And if by any means the user is compromised in one of the technology, it's eventually  going to impact the other technologies as well.  And let's say our GitHub as an enterprise doesn't support, it doesn't impose the MFA  challenge.  And then another scenario could be that we were able, the attacker were able to compromise  the GitHub accounts with the social engineering.  And if the GitHub account is compromised of the developer, it can further propagate to  other scenarios as well.  So this is the attack surface when it comes to the overall CI-CD ecosystem of the solution.  And if we look at the methodology part, I think there are three parts to it when we  are building a methodology.  First is focusing on making the software secure and robust by default.  And what I mean by that is in any software, there are two phases.  The one is of the software provider, and the other one is the software consumer.  As a software provider, I think industry is doing a reasonably good job because of security  in CI-CD, again, looping back.  But I think everyone has a responsibility as a software consumer as well.  Whenever we are consuming a software, it's our kind of obligation to make sure that we  are doing a basic security checks on that software.  It could be open source software, let's say a very simple library you are using for a  very specific job in your software, or it could be an enterprise product, which is getting  used by all the employees in your organization.  And for that, what could be done is that having a vetting process, as simple as that, having  a vetting process on an organizational level that whenever you are using a certain software  component, which is not developed by you, are you making sure that you're looking at  from the security perspective?  At the same time, when we find something in someone else's software, are we making sure  that we are considering it on a whole community level, working proactively with the provider  to fix that part?  If we combine these two steps where we are working to making sure that we as a software  provider, we are doing our best job to provide the software.  But at the same time, as a consumer, we are sharing the responsibility of making that  software secure.  The second aspect or the second part of the methodology is how well we are implementing  it into our environment.  And that will vary as per the organization because no software is secure with misconfiguration.  Any software which is secure by default, if you implement it in a insecure way, it's  eventually going to be insecure software.  It could be as small as default settings disabled, MFA enabled, up-to-date plugins, apps, actions.  Any enterprise level software as of today supports customization one way or another.  For example, for Jenkins, it is plugins, for GitHub, it is actions.  If you are using those third party components within your organization, then you have to  make sure that the security of those components, those custom components is also considered.  Third part of it is the monitoring or the continuous monitoring part where first we  are monitoring whether anything bad happened, are we able to detect it, second, can we respond  effectively if something bad happens?  So these are the three aspects when we need to look at when we are building a methodology  for the CICD, securing of the CICD ecosystem in the organization.  First, making sure we are taking a share responsibility to make the software secure.  Second, when we are using it, we are using it with the, I'll say, adequate security controls.  Third is, we are monitoring continuously and have the ability to respond to anything  bad happens.  Now, this is where the open source software, the open source project comes to the picture  CICDguard.  It does, first, it represents all the components into the graph forms.  And what I mean by that is that all the different components of the technology will be breakdown  into the node level and the relationship, the edges between the nodes will show the  relationship how the different component is connected.  What it helps is, it helps to get the visibility part correct.  For example, it will just not show that you have 10 Jenkins server, it will even break  down to the level of the jobs, it will say you have five jobs, so basically you will  have five nodes and then in which node those jobs are running.  So you will have a relationship between the node of type job to the node of the type node.  So that's how the overall graph picture is built.  Why I used graph?  Because personally, I think it's more intuitive when building the relationship database, relationship  schema for the different technologies.  And second thing is, it goes to the granular level of breaking down the technology.  Second thing it does, the security aspect, obviously, it tries to identify the misconfiguration  into the different technologies, whatever it is finding at that moment, and provides  the possible recommendation for that.  Third thing, which is most important in my opinion, it tries to identify the relationship  between the different components.  Like I said, one of the challenges is finding the visibility and the relationship.  So it handles that part by building the relationship and that is the primary reason of using the  graph theory because graph theory is more intuitive for the relationship part.  For example, if there is a certain change in a certain repository, how eventually it  is going to trigger the certain build process in a different technology.  So from the visualization perspective, how it's going to work out is that you have a  node of type repository and there is a change, certain commit, it eventually will go to the  ascertain Jenkins job and that job will eventually create a certain binary in a different artifactory.  So all of that relationship is going to flow through the graph in the solution.  And another aspect could be like I touched upon for the GitHub action part, for example,  in the organization as per the process, we might say that whenever we are using a third  party GitHub action, we are going to have a security review of that.  And depending on the security review, we are going to, you know, approve a certain version  of the third party library, which we will say at that point of time that it is the most  secure to be used in a security professional opinion.  What it will help to identify is that in the organization, in the overall organization,  what are the different version of any particular third party GitHub actions you are using?  And then we can map it to the back to the approved version and we can identify any deviation  we might have.  So, for example, at any given point of time for the GitHub action A, we are saying use  the version one, but in the organization, we are identifying the deviation of version  one, two, three, then from these project, from the solution, we can identify, OK, these  are the deviations, let's action on them.  And do we have common users between the different technologies, so on and so forth.  So first, the visibility part converts everything into the graph with the node and the edge  will represent the relationship, then identifies the industry security misconfiguration in  the technologies.  And on top of that, it identifies the relationship between the different components.  This is the node database schema.  As you can see, I have break it down into the granular level possible, for example,  for the GitHub action, it would be workflow, job, step, command, runner, action, so on  and so forth.  And interesting part, this I identified after building the solution is that once you have  a node of if you have a node with a similar schema already, then rather than creating  a separate node, it eventually will make back a circular relationship to the node.  So what happens with that is that, for example, if you have five runners in your organization,  you can find the reverse relationship as well that how many jobs are running in my each  of the runners.  So for example, if at any point of time you feel that this particular runner is having  too much load, then this tool can help you to identify that thing as well.  So this is what the overall architecture looks like.  It has, I'll say four parts.  First is the scan engine part, which runs independently.  What this scan engine is, it's a collection of independent scripts in Python and each  script is designed to perform the security scan on a particular technology.  At this point of time, it supports four technology and you can use it independently.  But at the same time, you can use it in a collaboration with the relationship as well.  That is the scan engine part.  The next part is the analysis engine, in which it tries to identify the relationship  between the scanned technology.  How it's going to work is, for example, you might run the script of Jenkins and then you  might run the script for GitHub.  If you run the analysis engine on top of that, it's going to scan all the nodes for those  two technology and try to identify the relationship.  The more technology you are going to scan, the more comprehensive relationship analysis  is going to be.  And you can just keep going on that process again and again.  From the output perspective, to build the analysis, all the database, all the information  gets feeded back to the Neo4j, Neo4j is the database.  And you also have a JSON format, in which case you want to, let's say, feed it back  to the other technology, for example, Elasticsearch and all.  In that case, what you can do is you can simply run the script, feed it back the JSON output  into your choice of analysis engine you want.  It also has a very basic web UI in order to visualize all the data and put some custom  filtering on that.  And all of this can be accessed by the user at any different point of time.  In order to run the scan engine, there are two ways you can provide the inputs.  The one is the environmental variables.  You just set it there if you don't want to pass it into the command line, because all  of this information will be secrets.  And then other option is obviously the command line.  And from the, what kind of input it needs is the authentication detail to the respective  technology you want to target.  And obviously it will vary technology to technology, which kind of authentication information  you will be providing.  For example, in case of GitHub, you need the personal access token and all that.  Depending on the privileges you are providing, it will be able to read more and more information.  In generally, since we will be accessing every, the script will be accessing everything, you  will need to provide the admin access personal token in that.  Any question before we go to the demo?  I recorded demo for two, for one very specific purposes, because in this demo, we have some  information which I simply cannot show.  So I have redacted it.  That's why I have recorded this demo, but our tool is, so as you can see, there are  four technologies in a certain directory and you can run it independently.  For the demo purposes, I'm using the environmental variable in order to provide the authentication  detail and no further information, no further input is required for in case of action.  You can simply run it.  Once it starts running, it provides the basic information in the command line about the  running and all.  So this you can run independent of the tool.  You can simply go to the GitHub, do the clone and start running.  It's as simple as that and every vulnerability, every security misconfiguration identified  by the tool will have a certain identifier and depending on the technology, as you can  see, all of the output is in the JSON so that it is readable by other analysis tools as  well.  This I ran for the GitHub action.  So this is what the feeding part of the solution is, where you are running independent scripts  again.  Now we are going to run the Jenkins, same process, you need to provide the authentication  detail.  It will build the connection.  We'll try to fetch the information.  It takes time, sometime depending on the network access and all.  So as you can see, for example, JNK 003, it's a identifier for the vulnerability, it identified  at that point of time for that.  So all the information displayed in a square bracket is the rejected one, when you will  be providing this information in the actual life, it will be displayed in that way.  So as I told, it goes to the level of job and then in the job, it identifies the node.  It also identifies the plugins, what is the version of the plugins you are using, how  those plugins are connected to the other Jenkins, other technology, it identifies the users,  it identifies the groups, so on and so forth.  I did not want to fast forward it intentionally because I wanted to give the actual feel of  how the script is going to run out when in the actual life, again, all the output is  in JSON format in the command line and then you can change it as per your need.  So this is what the UI part looks like.  You know, like I said, it's a very lightweight web UI at this point of time, we have different  node colors in order to identify for the different technology.  And as you can see, there are relationship, there are there are edges between the different  technologies as well if you so because I have in my demo, I have scanned almost four, all  four are technology supported by the scripts.  And because of that, there are a lot of data processed by that, that's the reason I have  a filter where you can simply select the plugins part and in the in the UI, it will display  the details about the UI, the red represents that the security vulnerabilities has been  identified for that particular node, the relationship of the filter is OR, so basically it will  says that select the node with the type plugin or type build, you can add and remove.  One important part I wanted to make a visibility point here is that so this this light bluish  color is the Jenkins build node, and it is getting connected to the repository within  the GitHub environment.  As you can see, this node is the type repository, and this node is of type build, what it implies  that is this particular build is getting triggered by this particular repository.  And if there is any change in the repository, it eventually is going to impact that build.  So this is what I meant when I said the relationship between the different technologies, and it  identified two different variations of that when I ran the scan in the in the demo environment.  So this is the GitHub repositories, and this is what the Jenkins build is built.  So if we are able to work on the so as as part of the next step, I am working on building  a overall path at this point of time, it's a one-to-one relationship between the repositories  and the build, for example, but from a visualization perspective, if we make the filter correctly,  what we can do is we can make a connection back to the let's say user A made this commit  on repository B and repository B eventually triggered the build C and that build C like  I said goes back to the artifactory artifact A. So that's how we can build the relationship  at this point of time from a filtering perspective, it just displays the one particular path.  So going forward, obviously, the first part is the expansion on the technologies more.  Like I said, the more technology solution will cover the better relationship it will  be able to build.  These are the few I have in pipeline.  If you have any feedback, feel free to open up an issue or the pull request into the into  the repository and then we can take it from there.  I think but my personal focus is on the analysis part.  The more technology we build, the more type of nodes we will have.  And what I mean by that is that more analysis we have to build.  The primary reason of making this project was to build on the analysis engine more,  which means that parsing of the of the different components more and try to identify the relationship  between them as well.  For example, it could be if we consider any software based organization, let's go with  the microservice architecture where multiple repositories are responsible for building  one service.  Can we find that relationship that service S is built by five different repositories?  So if we are able to build that kind of relationship, we will eventually be able to connect that  which users change triggered, which change in the service in the microservice architecture.  Can we build a relation on the on the contributing to a particular microservice and all and second  part is obviously the next part is the is the build the intuitive visualization which  include making the search engine more effective.  For example, all the metadata can be make a search engine on the basis of the all metadata.  So these are the parts on the on the going forward way.  Like I said, first of all, thank you for being here.  And if you want to know more about the Netscope and the product in general, please feel free  to reach out.  So thank you for the talk.  Any questions?  Yeah.  Hey, thanks for the for the talk.  So you said the project is open source, but the repository is actually empty right now.  Yeah.  Yeah.  I am going to put the code after that.  OK, cool.  And so my question is like, how many or how different or what kind of detections do you  have there?  Like that's probably the main, main, main point of the tool, right?  What do you mean?  The technologies?  No.  Like what kind of vulnerabilities do you detect there?  Oh, OK.  So in terms of, so in terms of category of vulnerability, like there are different components.  The first I'm trying to identify whether there are any basic and secure configuration, for  example, default credentials, HTTPS enabled or not, what kind of users are there in the  system.  And it will vary from technologies to technology as well.  So, for example, in case of GitHub Action, one of the findings is what are you using  any well-known vulnerable version of the third party software?  In case of Jenkins, for example, it could be like, are you using vulnerable version  of plugins or outdated version of plugins?  In case of GitHub, it will be, for example, do you have MF enabled or not?  So because and so that is the library of the vulnerabilities I have in terms of each technologies.  And with my tool, I'm going to also publish, you know, kind of knowledge base that which  kind of vulnerability I'm detecting in our tool, irrespective whether it got detected  or not.  Make sense?  OK, thanks.  Any other question?  Was it that good or that bad?  You were that good.  Oh, thanks.  Good.  But I have a question.  What I really didn't get is where do you get the information?  Are you looking at config files that are local or are you a super user who has access to  all these tools?  This solution is super user who has access to all the information.  So basically it's an API call to the target technologies.  So before that, we had individual components talking to each other, like in a limited environment.  And now we're getting a super user who has access to everything.  No.  So in the architecture, I had the breakdown into, let's say, broadly two parts.  The one is the scan engine part.  The second part is the analysis.  Scan engine is again, can be used independently.  So how it's going to work out in practical life is that you identify which technology  you are using in your environment from the supported technology in the solution.  For example, you might say, I'm using GitHub and I'm using Jenkins.  I'm not using, let's say, JFrog at all.  So you are going to configure those two scanners with the super user access for both.  And then what it is going to do is it going to scan the independent technology.  It's going to fetch all the information.  And then the analysis engine is going to make the relationship from the database, from the  local database of the solution.  Make sense?  Yeah.  Makes sense.  Other questions?  Okay.  Perfect.  Thank you for the talk first.  Is it possible to push those data into RDF database and not just graph?  I'm sorry.  I did not get the question.  Is it possible to put it into ontologies and not just Neo4j graph database?  In terms of database, it's going to put in Neo4j.  What customization you can do is since in the command line, I have all the output in  the JSON, you can redirect that JSON output into your choice of our technology.  But on the fly, it's not going to it's it doesn't support anything else at this moment.  Thank you.  Other questions?  Okay.  So thank you again for the talk.  Thank you.  Thank you, everyone.  Have a nice day.  Thank you.


url: https://www.youtube.com/watch?v=PosGarCGXRo
title: Which Models For Secure ICS Network Architectures To Adapt To New Usages? by Alexandrine Torrents
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=PosGarCGXRo",
    "title": "Which Models For Secure ICS Network Architectures To Adapt To New Usages? by Alexandrine Torrents",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2870,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Well, good afternoon, everyone.  So today I will talk about secure ICS network architectures, and especially how they can  be adapted to new usages such as cloud, IoT, or machine learning.  But maybe a question to start with, how many of you have already worked in industrial control  systems securely?  OK, not a lot.  And how many of you maybe know about the Purdue model?  OK, not a lot.  So I'm going to start with a small introduction about ICS, and so industrial control system.  So first, where do we find industrial control systems?  Well, pretty much in a lot of different industries and sectors, such as transport, aeronautics,  car, automobile, military, defense, also utilities.  But what is an industrial control system?  So basically, it will have an interconnection with the physical world.  So you will have sensors and actuators, which represents the actual physical world, and  they will be interconnected with what we call the production network, and especially PLC,  which stands for programmable logic controller.  So they interact with the sensors and actuators, and they send command to open a valve, turn  a motor, or something like that.  Then the PLC would be connected to the supervision network, or the SCADA network.  So basically here, you have the Windows world, because you have Windows workstations, Windows  servers with a supervision application.  So you have different consoles to supervise what you have on the plant, and you also find  maintenance laptops to go and program the PLCs on the field, for example.  And so this is a combination of these two networks, the supervision network on one hand,  and the production network on the other hand, that we call the ICS, the industrial control  system network.  As you may know, the ICS would be interconnected most of the time to other networks, and starting  with the corporate network of the company, and probably also be connected to the one  of the company and have interconnections with the internet, or the cloud, or external partners.  So that's it about the introduction, and let's deep dive in the presentation.  So I will tell a story about two very different secure ICS architecture, but what is a secure  architecture?  Well, here, an introduction about the Purdue model.  So basically, it's a conceptual model where we place the different components I've just  presented.  So different levels.  Basically, at level zero, you have the sensors and the actuators.  At level one, you will find the PLCs.  At level two, you will have the Windows world, the supervision network with your SCADA servers,  your engineering workstations, and your operator consoles.  At level three, actually, it does not exist at each plant, but it's the kind of orchestrator  of your system.  You can find that in manufacturing plants, for example, when you have different production  lines and you need to orchestrate a different production network.  Then usually, depending on the Purdue model you are using, that can be a level 3.5, which  is the BMZ, and then you have the enterprise network at level four.  So basically, everything that is below level three is considered part of the industrial  control system.  So this is the Purdue model, and this is actually what we call a secure ICS architecture.  And actually, in 2019, in a conference dedicated to industrial control system, there was a  panel called, is the Purdue model dead?  Well, actually, some people thought it was still accurate today, and others thought it  was not relevant anymore, especially when considering cloud.  So traditionally, there has been a rigidity to what a secure architecture is.  And here is an example of rigidity, the DMZ.  So imagine you need an interconnection with your industrial control system, and so your  OT network.  Well, it's simple.  You can put a proxy server in the DMZ and only allow incoming communication to the DMZ.  So it used to work, but does it still make sense today?  Well, maybe not in all cases.  So let's see how we can think about the future of ICS network architecture, having in mind  a specific motto, no limits.  And so let's take an example.  So I've been working for various companies that have a large variety of control systems,  historical businesses such as power plants, so nuclear, chemical, or refineries, but also  new businesses such as solar and wind farms.  And now, these various businesses can be found within the same company.  So for these companies, the existing ICS cybersecurity policy needs to be adapted to the new usages  and businesses.  But how can we define cybersecurity requirements and rules that would apply to the same company?  So in this presentation, we will compare and contrast the requirements and corresponding  ICS network architecture of two different businesses within the same company.  But first, an assumption.  So in this presentation, I will only discuss about common and control system, because usually  when we talk about ICS, we have three different kinds of, let's say, systems, monitoring systems,  common and control systems, and safety systems.  So to make my presentation easier, I will only talk here about common and control systems.  So let's present in more details our two use cases.  So first, the historical business, the power plants or refinery.  So here, we usually have large plants that are on a single geographical location with  many people working on sites.  These systems are designed to operate locally, so on a single physical location, and autonomously.  There are only a few interconnections, and usually they are not essentials to the industrial  process itself.  You have usually a high volume of assets on the network, and they are pretty standard  assets like I just presented before, so PLCs, sensors, actuators, and Windows workstations  and servers.  And here, the industrial process is usually complex with many different common and control  requests.  Then we have our new business, the solar and wind farm.  So here, we usually have a lot of very distributed industrial sites that are communicated through  the internet.  So these are really small sites without any human presence most of the time, and only  a few assets on the network, mainly data loggers or inverters.  And these systems are usually operated from the cloud.  So concerning common and control, you will only have a few requests, and mainly start  and stop requests remotely.  And these systems are also mainly about energy management and optimization.  So would you have the same architecture and the same cybersecurity requirements for both  cases?  Well, probably not.  So let's start with the historical business and secure architecture.  So here, for the power plant or refinery, we will have standard ICS network architecture,  so following the Purdue model I presented earlier.  So we have an industrial site on a single geographical location, and we have our OT  network, which is a dedicated OT network, with the different assets I've already presented.  So the sensors, actuators, PLCs, some HMIs, the SCADA servers, and the different workstations.  You can also have segmentation within the ICS network, and actually it's recommended,  but actually not always implemented on the field.  And this OT network will need to have interconnections with the IT network.  And so how do we do that?  With the DMZ between the two networks, and we have two firewalls, one between the OT  network and the IT network, and one, and the DMZ, sorry, and one between the DMZ and the  IT network.  And in this DMZ, what do we have?  Well, for example, rebound server for remote access, an update server, an antivirus server,  and maybe also some file exchange server or other application servers used as proxy.  Then this industrial site is usually connected to the one, so the wide area network of the  company, and connected to the data center of the company.  And in this data center, we can find central services DMZ, and also an internet DMZ, and  actually, most of the time, it's the main or even the only way to access the internet.  So actually, the remote access will go through this architecture.  So going through the data center of the company, then go on site through the DMZ and access  the OT network.  So what are the ICS cybersecurity requirements for this architecture?  Well, pretty standard DMZ between the IT and the OT network, protected by firewalls.  So one firewall between OT and DMZ, and one firewall between DMZ and IT.  We have no direct communication between the IT and the OT networks.  We also have protocol break in the DMZ, so we use relay servers, for example.  And lastly, we have no local internet access on the OT network.  So the internet access goes through the IT network.  So would this architecture work for the solar and wind farm case?  So let's try to apply the same architecture principle for this use case.  So what do we have here?  We have our main operator sites with our OT network, but here on this network, we only  have workstations, and the rest of the industrial process is actually elsewhere.  And I will go back on that.  But then you have actually the same interconnection with the network data center of the company  and the same remote access solution.  But where is the rest of the industrial network?  Well, it's geographically distributed, and you have several remote industrial sites.  And maybe here, a constraint before we go further.  So actually, to interconnect those distant sites, we wanted to implement MPLS, pretty  standard.  But we met with telecom operators, and as I said, the MPLS was not technically possible  for 20% of the sites.  So actually here, we had to use the internet to interconnect our sites.  So what do we have?  Remember, in this example, we have small sites with only a couple of assets on the network.  But if we follow the same principle as previously, we will have a DMZ to interconnect with the  rest of the network, a firewall between the OT network and the DMZ, another firewall and  internet gateway between the DMZ and the internet.  We will have probably VPN IP sectionals connected to the data center of the company because  it's the only way to reach the main operator site.  And since we cannot allow direct communication, we will have relays in the DMZ.  And actually, here we miss the SCADA servers.  So imagine here, the SCADA servers are hosted in the cloud.  So here are similar constraints, a DMZ, a first firewall, second firewall, IP sectional,  and a relay.  Well, does this really work?  Let's consider maybe one of the main communication in this architecture.  Obviously, the main operator site needs to communicate with the industrial sites.  And the cloud with the SCADA server needs to communicate with the OT network.  And they will probably use a Modbus communication.  Modbus, I don't know if you know this protocol, but it's a well-known industrial protocol,  but without any security, no authentication, no encryption.  So this communication will have to go through all the IT network of the company.  And it will have to go through also some DMZs.  But can we really have a DMZ and implement a protocol breaker with a Modbus communication?  And do we really need to use the IT network to make two industrial sites communicate with  each other?  Maybe not.  And also, in this scenario, you may have noticed we have two different firewalls for each of  the small sites.  Well, maybe if we have only a couple of sites, it could be feasible.  But imagine you would need to interconnect 300 small sites like this.  Well, you see, it does not scale.  So actually, let's try a blank page and see how we can think about another architecture  that could be secure.  So what do we have here?  Our OT network geographically distributed.  So several remote sites without any human presence.  The main work sites with only workstations.  And the SCADA servers hosted in the cloud.  So remember, internet is used as a transport mean to make the assets communicate with each  other.  So one secure architecture solution would be to virtually create one, leveraging SD-WAN  technology.  So remember our meeting with the telecom operators, well, it was them who said that we could implement  SD-WAN.  But what is SD-WAN?  Software Defined Wide Area Network.  So you will virtually create your one through a network of VPN tunnels, mostly VPN IPsec  tunnels, over any physical network.  So you can have very different physical networks, internet, radio, satellites, different operators  network, and still build virtually and logically your wide area network with this network of  VPN IPsec tunnels.  So with that in mind, we will have some SD-WAN edges at each location.  So the sites, the remote sites, and also the cloud, which is the infrastructure as a service.  So different VPN IPsec tunnels.  And here, so you can make the main operator sites talk with the remote sites.  The cloud talk with the remote industrial sites.  But the remote sites are not supposed to talk with each other.  So there won't be any direct VPN IPsec tunnel in this architecture.  And then inside the VPN tunnels, of course, you can implement network filtering and only  allow legitimate communication, such as Modbus flow I talked about earlier.  And so with this SD-WAN edges, of course, you have the firewall embedded in these devices.  And you can also implement detection by activating the IDS functionality on the firewall, for  example.  Then what do we have next on this architecture?  We have a DMZ, hosted probably in the cloud.  And you have different zones in this DMZ protected by different firewalls.  And here, it's a DMZ directly between the OT network and the internet.  So the remote access will go through this connection as well.  And so if we take a look at the central OT DMZ, we will see the central services where  we can find, as previously, the bastion server, update, and antivirus server.  And actually here, for the updates and antivirus servers, they can be connected directly to  the internet, to the official websites of the vendor, probably by implementing a URL  or a site listing with a proxy.  And you could also have here and consider interconnections with external partners.  And so you could add additional flow analysis and the restrictions in the central DMZ with,  for example, relay of proxies for standard communications and protocols, such as HTTPS  or SFTP.  And if you need to interconnect with a partner and use industrial protocols, you can have  a network probe for industrial protocol analysis.  But where is the IT network in this architecture?  Because we still need an interconnection with the IT network, but it won't be done on the  main operator site.  Here, the interconnection will be directly in the cloud with a dedicated firewall between  the DMZ and the IT network.  And you probably will have another dedicated network for the IT network.  So basically, what are the main differences with this architecture with the previous one?  We have the OT communications between the sites directly, and we do not go through the  IT network anymore.  We have a DMZ between the OT network and the internet directly.  And we have only one global DMZ for the whole OT network.  So let's sum up the key requirements.  So we have our VPN IP sectors between the industrial sites that are communicating through  the internet, so using our SD-WAN network.  We have a global DMZ between the OT network and the internet, and we do not need to go  through the IT network anymore.  We have firewalls with restricted firewall rules at each location.  So the main sites, the different remote sites, as well as the cloud.  And we have a network probe in the DMZ for flow analysis, especially for industrial protocols,  which cannot be used with relay or proxies generally.  So to sum up for the solar and wind farm architecture, we have a multi-connectivity using the internet.  We are leveraging the SD-WAN technology to create a fully distributed industrial network  over the internet with a large cloud strategy.  And here we adapted the Purdue model, and we placed the components based on their functionality  and not where they are physically.  Because I don't know if you noticed earlier, but the internet tends to be represented as  a level five in the Purdue model.  However, be careful because this architecture is riskier than the previous one, and it will  be important to maintain a good security level, but it's difficult and drifts can be observed  over time, especially when you consider the SD-WAN edges.  You could have a misconfiguration and have your site directly exposed on the internet.  So you will need several requirements that need to be respected.  So first, end-to-end control of the communication between the different industrial assets.  And also you need to secure your communications based on the level and the business need.  So do you need the VPN tunnel?  Do you need network filtering and our fine grain filtering rules within your tunnel?  Do you need relays?  Do you need encryption for the communication?  Do you need to add detection?  But rigor is key in this architecture, and the cybersecurity basics will need to be respected  finally for industrial control system.  So to come back to our example, so we needed to have specific cybersecurity requirements  for our company and apply to all architectures.  So we've seen that this architecture can be considered as a secure one for the solar  and wind farm.  However, it might be too risky for our historical business of the power plants.  And earlier we said that the other architecture was a bit too much for the solar and wind  farm use case.  So could we build something around risks to build our strategy?  And so let's try to build an ICS classification methodology.  So here the goal would be to classify an industrial control system and not especially a site,  because you may have different systems on a single site.  So we will put each industrial control system on a risk matrix and try to differentiate  their criticality.  So we use a standard risk-based approach.  And actually we took the ANSI, which is the French cybersecurity agency, ICS classification  methodology as a base, and we adapted it to our context.  So we have the impact and the likelihood.  So regarding the impact, here we use the standard HEC impact scale of the company that is adapted  to all businesses.  And we have several types of consequences, such as human, environment, image, or financial.  And we will use the global impact.  The global impact will be the maximum of each of the type of consequence.  Then we have the likelihood, and here we will have different factors to consider.  First the attacker's level.  So are we talking about a non-targeted attacker, a private organization, a state-sponsored  organization?  We will also consider the functionality.  So are we talking about a monitoring system, a command and control system, a safety system?  We will also consider the connectivity.  So are we on a single geographical location?  Are we using a distributed network, using a private network such as MPLS, or are we  using public networks?  And we will also consider the level of access control, so the level of identification and  authentication.  So for each of these factors, we will get a number, and then we have a formula to calculate  the likelihood.  And then we will have our risk metrics, and we will place the industrial control system  on the metrics, and it will give us the classification.  And in our example, we have four classes of classification.  And it's important when you build such methodology to consider also regulations to have maybe  some minimum classification depending on your systems.  So let's try the classification on our two system examples.  So first, the impacts for the power plant and the refinery here.  We have, for example, a Seveso site with high HEC risks.  So we have high impact, so let's say three.  And for the solar and wind farm here, we have no HEC risks, and actually not a lot of risks.  The highest impact would be a financial loss due to a production stop, for example.  So maybe here, the impact will be only two.  Then regarding the likelihood, so to ease the case, we will consider we have the same  attacker levels, the same access level, and the same functionality, so it's the connectivity  which will make the difference.  And so regarding the connectivity on the power plant and refinery, we have a low connectivity  because we have an industrial network on a single geographical location and only a few  interconnections with the IT network.  So with the formula, we will get a likelihood of two.  And for the solar and wind farm, as you saw, we have a high connectivity because we have  a geographically distributed industrial control system, and we are using a public network.  So with the formula, we will get a likelihood of three.  So with that, we can place our industrial control system on the matrix, and we get a  class three system for the power plant and the refinery, and a class two system for the  solar and wind farm.  So you see, we end up with two different classifications for our systems.  And so we may consider different requirements depending on the class of the system.  So for example, for a class three system, we could forbid the use of cloud.  We could have only a private network used.  And for class two network, we could allow, under certain circumstances, cloud communications,  SD-WAN technology with a stronger VPN and network filtering with detection, et cetera.  But can it be then simple?  Unfortunately, no.  But let's take a step back on our example.  What was the main decision factor for the secure architecture?  It was connectivity and impact.  Because for the power plant and the refinery, we had a high HEC risk, so interconnections  were limited, no cloud, no distributed network, and no public network.  And for the solar and wind farm, we had low risk and high distributed network.  But is there any additional factor that could be considered to help with the classification  and our requirements?  Well, we could consider, for example, multiple expositions.  Because in my example, I only talked about the cloud.  But we could also consider interconnections with applications from the corporate network.  And the systems need to be considered as a whole.  And for example, since we are talking about the same company, you've seen that in the  two scenarios, we have a global central services DMZ.  Well, could we mutualize this DMZ for the whole company?  Or is maybe the risk of compromising the power plant refinery through the solar and wind  farm maybe too high?  And we can also consider regulations, physical access, device access control, and data confidentiality  as well.  But in the end, be pragmatic and do not stick to a formula.  You should consider key factors and make your classification accordingly.  And also, another interesting thing would be to build architecture patterns.  So for your company, you could identify several use cases, build reference architecture based  on the risk analysis.  And these architectures patterns will need to be regularly updated.  Because business needs and technical capabilities evolve regularly.  So you could have some global cybersecurity requirements to respect depending on your  ICS classification, but then have different architecture patterns for each of your new  use cases with some specific requirements.  And so let's go further on that and with the architecture patterns.  And let's build an OT use case catalog for the company with adapted cybersecurity frameworks.  So use case catalog, why and how?  So why do we need a catalog first?  So I've already talked about it a bit, but let's deep dive here.  So with this use case catalog, it would be more concrete than a simple cybersecurity policy.  So I'm not saying it will replace entirely the cybersecurity policy.  But actually, it will be concrete and answers business operational questions and provide  operational guidelines directly to the industrial sites.  And it's also important to provide ready to use tools to local teams, because usually  they have limited time, sorry, resources, and also a few cybersecurity skills.  And it will allow you also to have consistent architectures and cybersecurity solutions  across your company.  So it will avoid local initiatives and maybe build non-secure architectures.  And then so how?  So you will need to list first the different use cases for your company and build deep  dives for each of the use case.  And so you could have three different parts for each of the use case.  First a description of the use case, then a network architecture diagram, and finally  some technical guidelines to respect.  So let's take a few examples.  So four here in my presentation.  So first, let's consider remote control of industrial applications.  So a bit like my previous example, let's imagine a geographically distributed industrial control  system with different sites communicating through the internet with a central supervision  site.  A second use case here where you can have IoT sensors on your industrial network connected  to an application in the cloud for monitoring and predictive maintenance, for example.  A third case when you could have remote maintenance operations, so an external partner responsible  for the maintenance and operations of your sites having to connect remotely to your industrial  sites to perform some administration actions.  And a fourth example here with maybe more machine learning with a cloud solution for  energy optimization, for example.  And so this application is hosted on the cloud and is directly connected to your industrial  control system.  But here not only for monitoring, well, first information that are gathered from the industrial  site, but with the application from the cloud it analyses the data and is also capable to  send command and control requests to your industrial control system.  So today we will focus on the first one and the fourth one, and I will present you what  it could look like in the use case catalogue.  So first example for the remote control of industrial installations.  So a brief description.  So we have geographically distributed industrial sites, and we have command and control which  is managed from a central IoT site.  So here we can consider that it's an extended IoT network.  And a few technical characteristics.  So here the sites communicate through the Internet, and we have OT to OT communications,  so mostly industrial communications.  I mentioned earlier Modbus, but we could find also OPC UA or any other industrial protocols  between the central sites and the PLCs on the remote sites.  And we have no local IT network on the remote sites.  It's just a small network with only industrial assets.  So then we could have our network diagrams.  So here a bit like my SD-WAN example as previously, but a bit smaller with just a central site  with their assets and only a couple of sites, but we still have a DMZ and VPN IPsec tunnels.  And so then we could have some technical guidelines like this.  So I won't read everything, but you get an example.  So we need a DMZ between the OT and the Internet.  We will implement a network filtering over the different tunnels and only authorize a  whitelist of data.  We will have also IDS sensors and give some specific guidelines about the filtering that  we are allowing between the sites.  Then a second example, so with the energy optimization solution.  So here, again, it's a cloud solution using machine learning to automatically send command  and control requests to the SCADA server.  And in terms of technical characteristics, so we have the application hosted on a partner cloud.  It's not the company who has this application.  It's an external partner.  With this solution, we need to install somewhere in the company network a device that will  be directly communicated to the OT network and actually communicate directly with the  PLCs using, for example, Modbus protocol.  And this partner device will also be connected to the partner cloud using a standard HTTPS  communication.  So again, network diagram with the device.  So here you see that we decided in this example to have the partner device in the DMZ between  the partner cloud and the OT network.  We have an HTTPS proxy and some firewalls in the architecture.  But then if we want to have the technical guidelines, we can have specific sites and  requirements.  So here we specify that the partner device needs to be installed in a DMZ between the  industrial network and the internet.  It states that we need a protocol break in the DMZ.  And we need to filter the different communications using a firewall.  So here we have HTTPS with the cloud and Modbus with industrial sites.  So we consider that we have a protocol break with this partner device.  Again, here, since we are talking about command and control, it's pretty dangerous.  You might think to allow an application hosted in the cloud and especially an external partner  application to send command and control requests to your industrial control system and actually  directly to the PLC.  So here you could have additional requirements to make sure that you cannot do anything too  harmful to the industrial control system.  And maybe here implement filtering at the application level by putting a dedicated firewall  after your partner device before the communication with the OT site.  And so if we take Modbus as an example, we could, at the application level, make sure  that, for example, no PLC programmation would be possible by blocking communication with  the specific administration function.  We could allow read requests on the all PLC address range.  And regarding the write request, we could authorize only some specific addresses of  the PLC to be written and also have some specific information about the data that can be written  and have some specific thresholds for the data to be written.  And then it's pretty basic encrypting communication with the internet and maybe again some detection  mechanisms.  So that was for the example, but what are the key success factors for such a catalogue?  Well, three steps, in my opinion.  First, the fact that it's really important to co-construct the catalogue with the business.  It's also very important to communicate the catalogue and promote it at all levels within  the company and make sure that people on site know about this catalogue.  And of course, keep this catalogue updated regularly and add new use case if you have  new use cases.  Another important thing about such a catalogue, it's really important to have technical solutions  to be provided.  It's good to have a catalogue, but we need to go from theory to practice and actually  provide technical solutions to industrial sites, because like I said previously, they  do not have always the resources and the skills.  And these technical solutions need to be anticipated.  So when you build such a catalogue, it's important that you have all stakeholders involved,  and especially the architects, to make sure that it's feasible to implement such solutions.  Otherwise, you will probably have to start everything from scratch.  Then, how could we manage the different architecture patterns in our company, and especially which  central infrastructures?  Because many companies have chosen to centralise their resources and especially their OT solutions.  And so as a centralised OT DMZ, it can be a different level, the entire company or sometimes  it's a regional DMZ.  So what do we have here in such central infrastructures?  Like you've seen in the previous network diagrams, we can have antivirus, update servers, remote  access solution, maybe an active directory as well to manage identities, proxies, etc.  And the benefits of such centralisation is better knowledge and control of the industrial  assets, and also the uniformity of the designs and solutions across the company.  Then maybe a question about mutualisation, because when we talk about centralisation,  it implies asking the questions of the mutualisation of the infrastructures.  So going back to what I said earlier with our two examples, I've mentioned two different  options.  One option where the company would decide to have only one global central infrastructure  for the whole company.  And option B with two different zones depending on the site's criticality.  Well, here we go back to our risk-based approach, because here you need maybe to build a decision  tree for your company based on the different industrial sites and businesses you may have.  So how many different zones you will need and how you would classify the different sites  and decide which zone would be used for which industrial control system.  So final takeaways for the presentation.  So we've seen that control systems can be very different and just security rules and  architectures can be different.  So the historical ICS secure architecture is not specifically applicable to new usages  and the Purdue model needs to be adapted.  And so here are some key factors to have in mind for an architecture decision.  First, what does the control system do and what are the business needs?  Then what would be the impact and especially in terms of HEC if there was any attack on  this system?  And maybe a third key factor, which is my level of exposition.  So in terms of transport means, for example, but also in terms of applications and other  systems connected to this application.  So it would be really important to document your use case for your company because it  will help your classification and architecture decisions.  And so I think it's good for companies to consider launching a task force to support  project and industrial sites and build secure architectures for new usages because they  will happen whether you're here or not.  And maybe a final thought, how can we find the right balance?  Because having different secure architectures for each of your use cases within the company  is good, but only up to a certain level of manageability because you will have to maintain  all these architectures and solutions.  So unfortunately, you cannot have as many architectures as control systems.  Thank you.  Will.  Do we have any questions?  Hello.  Hey, thank you for the presentation.  It was very interesting.  I really liked it.  I have two concerns about your model with one central DMZ.  Imagine a company that has multiple sites all over the world, like U.S., South America,  China, Europe, you name it.  Have you considered if having one central DMZ doesn't mean a lot of latency in communication  with that?  Wouldn't a model with, I don't know, one DMZ per continent be a better idea in here?  Plus, I see one advantage of traditional Purdue model over your model, because if you have  sites all over the world and you have one DMZ per site, then if there is a connection  breakdown, then there is a chance the site can still operate.  In your model, it can't.  So actually, in my presentation, I'm not saying that I don't like the Purdue model.  I'm saying that there can be very different architectures, depending on the industry,  for example, because here I mentioned solar and wind farm, but we have also other kind  of distributed ICS in utilities, for example.  And maybe it's not the same risk, and so you won't allow what I've just presented for other  kind of industry.  And maybe to answer your first question as well, so yes, of course, it depends on the  company to have either one big central DMZ or several spread across different continents.  But also what's important here to have in mind is that usually what you have in the  DMZ is not essential to the production.  So if you lose the DMZ, it's not supposed to block your production.  And so that's why also in my design with the solar and wind farm case, I really wanted  to have the OT sites directly in communication with each other without going through a big  architecture.  So if sites need to communicate with each other, they will have a direct tunnel between  the two to avoid what you just said.  Yeah.  I have a question.  I'm more on the left-hand side, oil and gas companies, which I'm not working for oil and  gas, but my organization has lots and lots of control systems.  And I see more and more demands that even your engineering stations, your operator stations  are provisioned like with standard IT.  We see that we're running control system in docker containers.  We see that we're running virtual machines for control systems.  We see that we program PLCs from Git repositories and so on.  So we're using machine learning for predictive maintenance and so on.  So how does this fit into your model?  It does not fit in the Purdue model because it's no more or less bridging all layers.  How does it fit in yours?  Yeah, it can fit as well.  And for example, if you take soft PLCs where you do not have the hardware device anymore,  but it's virtualized using a codesis, for example, it will still be put in my model  at the level one of the Purdue model.  It will just have a different device.  So you need to adapt the Purdue model with the new solutions that exist on the market.  But in the end, it does the same thing.  Your protective means don't work anymore.  If I'm talking about docker containers, nobody in my organization will rewrite a docker container  from scratch.  They will come from outside.  So they downloaded from docker maybe, or the virtual machines come from outside.  So how does that fit in?  Yeah, so actually here, if you are using IT solutions, you can also use IT cybersecurity  good practices also for OT.  It will do the same thing.  Because people tend to think that OT cybersecurity is really different from IT security, but  not that much, in my opinion.  However, you can have very automation solution to prevent an attack.  For example, having controls directly on PLC and make sure that even if someone is  in the network, you cannot directly reprogram the PLC and having good practices developing  the PLC.  But for the rest, I mean, most of the protocols are still unencrypted and unauthenticated.  So one of the best way to protect industrial control system is by the network.  But if you change all the devices and use more IT systems, maybe you will get rid of  the old industrial protocols that are unsecured by design, and you won't have these issues  anymore.  I'm not offering other questions because we don't have much time left.  So thank you very much, Alexandrine.


url: https://www.youtube.com/watch?v=Jdhg1Tx8CjQ
title: Permissionless Android Universal Overlays by Dimitrios Valsamaras
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=Jdhg1Tx8CjQ",
    "title": "Permissionless Android Universal Overlays by Dimitrios Valsamaras",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2988,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   So hi, everyone. And thank you for joining. My name is Dimitrios. I'm from Greece. And  here are a few things about me. So I'm engaged in computer security since 2002. I was actually  a member of one of the first reverse engineering groups back in Greece. And I started my career  as a network security engineer. Then I moved into developing for about five years. And  the last five years, I focused mainly on security. Before I joined Microsoft's threat  intelligence team as a senior security researcher, I was leading a team which was conducting  malware reviews for the Google Play Store. And besides that, I'm a father of two. Boy  and a girl. My free time, I play music, guitar, piano. I also sing. Although there is a debate  with my wife regarding this one. So I didn't put it here. All right. So before we start,  I just want to address a question which I get quite often when I do my talks. And this  is how come a Microsoft security engineer talks about Android, you know, this kind of  stuff, how these things are connected. So as I said, I'm, let's say, I'm following up  with security, computer security for quite a long time. And I guess you would also agree  with the fact that today's threats need a more holistic approach, right? So a breach  in your mobile might affect even your corporate network right now. And I strongly believe  that companies should, let's say, follow, I mean, improve their security solutions in  order to protect their clients across all platforms. So I'm very proud of being a part  of, let's say, such an initiative. And with that being said, we can jump right to the  outline of this briefing, which consists of the following topics. So first of all, we're  going to talk about the Android user interface, just a brief overview of the main components  and things that we're going to use during our presentation. And then we're going to go  to, let's say, first main part, which is going confusion attacks. What is the story so far?  We're going to see quite a lot of, let's say, techniques which have been presented during  the last years when it comes to Android operating system. And then we're going to discuss  about the behavior out of which this attack was, let's say, inspired. Okay, then universal  overlays addressed by the specific CVE. Actually, the title is permissionless, universal  overlays, but it's quite far. I couldn't add it here. And yeah, we're not going to use  any kind of permission. This is the difference, actually, with the attacks that have been  presented so far. And finally, we're going to see some defensive takeaways, how we can  protect Android apps from these or even similar type of attacks. Okay, so let's start with,  let's say, the Android graphics architecture, focusing on the components that we said we're  going to discuss. And I'm not sure how many of you have created an Android app so far,  but we may all agree on the fact that one of its most important features is the ability  to interact with the user, right? So that being said, almost every modern development  environment facilitates this process by providing tools to make this process easier, right?  So this way, Android developer with just a few clicks can add or remove buttons, views,  images, and so on without need to dive deep into their implementation details. Now, system  wise, when an app is created, a window is going to be attached to it, which is actually  a container for what we call view objects that are backed up by surface objects. And  since we may have more than one app running at the same time in an Android device, what  comes next is the surface flinger, which will gather all these surfaces and try to composite  them on the display. After talking with the hardware composer, which is a hardware  abstraction layer, we will gather all these surfaces and do the final composition display.  Now, what I intentionally didn't mention so far is the role of the window manager, so  for whom, let's say, is to decide the order, the focus, the position of the windows in  Android display. And this is the window manager, where the window manager comes into play,  which will gather all this info, will send them to the surface flinger, and will do the  final composition, as we said before. Now, when it comes to window manager, it's an Android  system service, which is, let's say, responsible for the look, the behavior, but also the  behavior of the windows, and also the transition, the animation of them when we open a  window, when we close one, or we're simply rotating something. Although, despite the  rich functionality of this system service, third-party apps don't have access to their  own IDL, and they can actually, let's say, access specific properties using some classes  like the window, window manager, or the Fugue configuration class. And here I have an  example of, let's say, how you can acquire an instance of the window manager, then access  this property, as I said before. Now, another important aspect, which is related to our  research, is what we call Z-order, and refers to the order across an imaginary axis, which  starts from the bottom of the screen up to what the user sees on top of the screen, right?  And the position of a window in this axis depends on its type, and every Android app can  request a window type, any window type, by just creating a window manager instance,  acquiring window manager instance, using the layout parameters, and then just setting the  window type that it wants, right? Finally, you can use that view in order to add the  view to the newly created window. What is now strange here is that, let's say, privileged  window types, and by privileged, I mean the ones which are on the top of this imaginary  axis, come with special, let's say, with high price. Let's put it this way. So in order  to get approved such a window, for example, the type alert window, you need the system  window permission, so the user has to go to a specific menu, enable this, let's say,  permission for your app in order to get this permission approved. Now, what happens here  is that before Android 23, this permission was approved by default, sorry, SDK 23 was  approved by default, and what is even more interesting is the fact that if an app targets  an SDK which is lower than 23, gets permission approved by default even in newest Android  versions, and this brings me to the figure which I have here on the right side where  you can see the various window types and their position across this axis that I talked to  you about, and despite the fact that most of these window types have been deprecated  or aggregated under a single window type, they can still be used by apps which are targeting,  let's say, these are versions up to Android 8, okay? All right, so we talked about the  shape of a window, the shape and all these things, but there is also another interesting,  let's say, aspect when it comes to windows, and this is the behavior of a window, and  what I mean by that is how it will, let's say, react on various events that take place  on an Android screen, so the common, let's say, behavior in that case is that the window  will consume the specific event, so what this event can be is, let's say, a user click or  a user touch, a swipe, so what will happen usually is that the window will consume this  event, will perform some kind of functionality, and that's it, but you can change that using  various flags like the one, the first one that I have here, which is the flag not touchable,  so what you can do with that, you can simply let your window dispatch the touch to the  window which is below, right, so we give this way click through capability to our window,  that's so simple, and to use this flag, you don't need any kind of permission, right, just  to make clear. All right, so we said about the look, we said about the behavior, and there  is also another interesting, let's say, feature when it comes to these windows, which we'll  call them free-floating windows, so they depend solely on the process that they belong to,  so what that means is that even if you have created your window within your activity,  an activity, and you dismiss this activity, this window will remain there as long as the  process is still active, and the other way around, and this is actually something which a  lot of malware families are using in various ways, for example, around somewhere, they're  using this type of windows to cover the screen so the user loses access to the actual user  interface, and like I said, this is just one way to abuse this type of feature when it  comes to this type of windows. All right, so let's make a pause here and try to identify  what is the main issue, right, so we said that actually, yeah, the Android operating  system where more than one app can run at the same time, right, in the background, and  we said that each time, only one app will be the one that will be interacting with the  user. We have a couple of protections when it comes to the origin of an APK, we have the  signature, which can be used to authenticate an app and, you know, ensure that it comes  from the same developer, and we have also what we call the trusted sources, which can  ensure that an app, let's say, meets some specific criteria, although there is no  explicit information showing to the user about the user interface that interacts with  and the application that it belongs to, so this is the main problem, and this way, any  app can imitate the user interface of another app and claim its identity or claim  its privacy, so in most cases, the victims of this, let's say, type of behavior are  banking apps or apps in more general which handle some kind of financial data, private  info and so on, all right? Okay, so this brings me to the main, let's say, to the first  main topic when it comes to this type of attack, and we are going to start from the  main issues, a GUI confusion attack needs some user interaction, which needs sometimes  social engineering, and in general, attacks which depend on this type of, let's say,  vulnerabilities, they are considered as low-hanging fruits when they are compared with  attacks which depend on memory corruption types and so on, but this is kind of unfair if  you think about it, almost every modern malware campaign like, let's say,  Flubot, Cerberus, all this, let's say, modern, in a way, families are using this type  of attacks in order to achieve their targets, right? For example, the ones that I  mentioned, they're using overlays in order to perform phishing or something. So  despite the fact that many, let's say, techniques have been presented quite the last few  years when it comes to GUI confusion attacks, we may, let's say, classify them in three  main categories. So we have the first one, which we're talking about attacks that  they are using overlays, and then we have the ones they are using task hijacking, and  finally we have the ones which are using what we call activity switching. So starting  with the first one, the main idea is to conceal a part or all of the message which is  communicated to the user via a graphical user interface in order to alter the message,  to alter the meaning of this message, and trick the user to take an action that  wouldn't normally take. For example, imagine that we have a processor which offers a  service, offers a product, and sends a request to the user, a top-up, let's say,  pops up from a banking app. The user sees the amount which might be very large,  extra large, and the user will reject because the amount was, let's say, insane.  If the same attack will be performed from a malware which can't create overlays,  then the amount can be simply concealed so the user can be tricked and, let's say,  approve the request. So as you understand from what I've said so far, they're all  the malware should, must be able to control the position of a window in this imaginary  access that I talked to you about in the beginning of this briefing. And one way of  doing that is using what we call a type toast window. This is an old attack,  old type attack, and it uses this type of a window, which window by, let's say,  construction was created in order to be on top of other apps. Why? Because it has  to send a message to the user to take a quick action or something is happening,  some kind of an event, so the user has somehow to take an action. So this type  of a window, as I said before, should be on top of others. And this is something  that this attack, let's say, abuses. Again, create a window manager instance,  layout parameters, and this time just use a type toast window, click through  capability, change transparency, position, and finally perform the final overlay.  The same thing, the same result, different type of window. This actually was used  by the clock and anger, let's say, technique. Use a type system alert window  or the newest version of it, which is the type application overlay, although,  again, the user has to navigate to this specific menu and enable it in order for  an app to be able to do that. Yeah, this is this. Another attack, which is not  that widely known, it was actually my first zero day, this one, so this is why  I mention that. So it was first found in the Flav99 adware, and what this adware  was doing was just loading a library, a native library, and was giving a couple  of constants, which was in a function which was implemented in the native layer.  So these constants were found to be, to represent window types. The one was  the type presentation, the other one was the type toast. The type toast I talked  to you about, but the type presentation was, let's say, something like an  overlooked type of a window. Someone didn't notice something, so I don't know.  And it could create overlays without any kind of permission. So it was giving  these values in, let's say, some native implementation of it, and then it was  creating, again, a window manager instance, checking if the SDK version was  lower or equal to 24 in order to create a type toast window or a type  presentation. So that was it, how it was using that. So in Android 10, there was  a restriction which says that an app can't start an activity from the  background if it doesn't have some specific, let's say, if some specific  conditions apply. One of these conditions was if the app has a visible window  in the foreground, then it can start an activity. So this one was using  exactly for this way, it was using this, let's say, window type. So it was  creating a window which was invisible, all right? So it was not visible to the  user, but it was visible for the system. And it was using this window in  order to start spamming the user with advertisement. So that was the main,  let's say, way of using that. And you can understand by using just zero day  in order to spam the user for what kind of revenue we're talking about when  it comes to this type of malware. All right. Next one is task hijacking.  And in computing, when we're talking about multitasking, we refer to a state  where more than one process can run at the same time, right? Although when it  comes to Android operating system, a task has a slightly different meaning.  So a task is not an app, it's not a process. It's a set of activities that  the user interacts with in order to do some kind of a job, right? That's the  meaning of it. Now, these activities may belong to different apps, and  activities may belong to different tasks. So that's the idea. And these,  let's say, attack abuses state transition conditions like task affinity and  allow task reparenting in order to do that. So how it does that, imagine we  have the victim app, which is a secure app. So the malware, whatever, will  create an activity which will set the task affinity to the package name of  the app. It will create, it will set actually the flag of this activity,  allow task reparenting to true, and then it will try to, let's say, inject  itself to the task that the user interacts with when it comes to the  specific app, right? That was the idea about this one. And the last one,  which is very interesting, although it's very, very simple, abuses APIs  which are used in order to bring an activity on top on the foreground,  right? So the idea is, again, simple, observe the foreground. If the  activity which is currently on top belongs to our target list, then start  our own activity and hijack the user session. That's it. We have a couple  of exceptions, sorry, a couple of restrictions when it comes to this,  let's say, attack. So we don't have visibility of the activity which is  on top, right? We have the sandbox. We have a lot of things when it  comes to Android. So we don't have visibility regarding that. And we  can't start an activity from the background, as I said before.  Exceptions, accessibility service, the powerful accessibility service  which can be used actually to get your app opt out from almost any kind  of UI restriction. We have the user stats when it comes to the first  one, the system alert, for which I talked to you about. And we have  the full screen intent, which never works. I don't know why. But I  added here just for the sake of completeness. Now, we are going to  see the first demo. I have quite a few because we're talking about  UI. So I created the ROG APK, which performs this task. So what  it does, it will observe the foreground. If the app in the  foreground belongs to a very, very well-known, let's say,  banking app, it will start its own activity. So I hope it will  play. Yeah. That was it. Anyway. So not much. Just a few things  about the context here. So first of all, as you may notice, there  is a small window here. Yeah. On the left side, which is a free  floating window, which is used exactly for the reason that I  talked to you about. It's a foothold. So it uses this  foothold, observes the activity which is on top, and if the  activity belongs to the banking app, it will start its own  activity. So the user will start, let's say, interacting  with the malware instead of the banking app. That's the idea  behind this one. All right. So we said that we can use a start  activity method in order to start an activity, obviously,  and this can start another activity, the new activity can  start another one, and so on. But the question here is how  these activities are arranged on the screen? And the answer is  that they are using what we call a back stack. So imagine  something like a last-in, first-out stack where the user  can simply add or remove activities from the top of this,  let's say, stack by simply interacting with the user  interface. Now, what is interesting here is the fact  that when an activity is pushed in this stack, it will retain  its graphical user interface. And what is even more  interesting is the fact that if the user starts another task,  let's call it task B, task A will go in the background, and  the back stack will remain intact. So when the user removes  task B, task A will get again the foreground, and the back  stack will be restored. So what I just described can be  exceptionally visualized by using a transparent activity.  And how we can create one, we just create a theme which has,  sorry, a transparent window, the background is the color.  Actually, it is also transparent. We don't want the  shadowing title. A window is floating means that the window  is not anchored, so it can be moved freely. And finally, we  have the background theme enabled set to false in order  not to blur the activity which is below. That's the only thing  that this flag is doing. The next thing was just to choose  an app which has some kind of emotion, right? We wanted to  understand the level of intactness, what they mean by  intactness. Will the app still keep playing the video, for  example? That was the question. All right. And this was the  result of the second, I guess. Anyone notice something? Yeah.  Yeah. Actually, the result was so good that I myself had to  add some kind of a mark in order to understand with which app I  was interacting. Was it the YouTube app or was it my app? I  mean, so I added this one, and then my next, let's say, thought  was to do something a little bit more, let's say, malicious.  And I did this one.  So if you desperately wanted, let's say, a YouTube premium  account, would you click on this one? This is a question  here. I don't know. Any feedback? Yeah. Anyway, yeah, I  don't think that you like a YouTube premium account. But in  any case, I think that the main idea here is that you can  integrate the user interface of the activity which is on top  with the activity which is below. And by adding, let's say,  some specific, let's say, views or effects or something, you can  even alter the user interface of the activity which is below.  So that's the main idea behind, let's say, this attack. But  there are, okay, there are a lot of restrictions again, right?  We don't have visibility. We talked about that. We can't  start activities. We talked about that. And we don't have  click-through capability. Of course, we can bypass all these  things. To put it better, we can get our app opt out from these  restrictions by using permissions. But our attack  wouldn't be permissionless if we had permissions. All right.  So before I explain how we managed to amplify what we had  so far in order to get a practical, let's say, create a  practical attack and get some security impact regarding this  attack, let me first describe our target. So we're targeting  critical important screens which can be used in order to request  from the user to take some kind of critical decision. So when  it comes to third-party apps, we're talking about apps which  can be used in order to approve a payment request, a remote  login, or some kind of an authorization or something. When  it comes to system screens, which is the most interesting in  this case, we're talking about the screens which can be used in  order to approve permissions, dangerous or no, system  services, privileged access to system, privileged services, or  change some kind of a setting. And we may classify those  screens in two main categories. So the first category is the  single-step decision screens. Simply said, a window will pop  up. The user will click on the window, and a decision will be  made. And we have the multi-step decision screens where the user  has to follow, let's say, some steps and some wizard in the  Windows OS in order to get to the final, let's say, screen and  click something in order to get the final decision made, right?  So let's start with the first one, which is the first line of  defense of the Android operating system when it comes to private  user info. And this is the permission screens. And when I  say about permission screens, we are talking about the ones  which control access to user private info like SMS calls,  call logs, you name it, the contacts, anything. Or even  devices like the microphone, camera, location, right? A lot,  a lot of things. So this is the main idea. That was the main  idea behind the first, let's say, the single-step decision  dialogues. These dialogues before Android 11, Android 10  belonged to this package here. And they moved to an Apex as  many more. They moved to an Apex in Android 11. Although OEMs  can customize this user interface, these dialogues using  a runtime resource overlays. But what we are most interested in  that case is what type of window this permission dialogue is  using. And let's say it was surprised to see that it was  using a simple base application window, but it had some very  interesting flags. One flag is the dim behind, which can be  used in order to blur the window which is below this one. And  the other one was the high known system overlay windows. And  this one is a little bit, let's say, interesting, and I'm going  to elaborate a little bit more. So it can be used in order to  protect an app from type alert or system alert window type.  Okay? And that's the good news. The bad news, up to Android 12  at least, it was that in order to use the flag, the specific  flag, you need the high known system overlay windows  permission, which is a signature privilege, so it can be used  only by system apps. And then this was moved to the high  overlay windows, and now you can use also from third-party apps.  Okay. But if you think about it, if you think about the  activity that I show you, the transparent activity that I show  you, it doesn't use any kind of special window, right? Special  type or something. We use a humble base application window.  So the next step was embarrassingly simple. It was  just to add a click-through capability, no rocket science  here. You get a handle of the window, set the flags to the  not touchable, arrange the view in some way that you can cover  the parts that you are interested about, and you have  the following result. So here you have the permission dialog  on the left side, and on the right side you have the  permissionless overlay. So that was the idea, and that was how  it worked. To give you some context, our app starts with  zero permissions approved.  Yeah, and it ends up with all the permissions approved. All  right. So that was the, let's say, the main points out of it.  I guess a good viewer may notice the short delay when it comes to  the overlay and the permission dialog, but this can be adjusted.  This actually belongs to a loop. We just use the loop in order to  ask the permissions, but you can adjust the time that you request  the permission so you can put your overlay on the right time.  All right. So I guess permissions dialogs are cool.  They can be used in order to get any kind of info when it has  private user information, but can we do something better?  And the next, let's say, challenge was the multistep  decision dialogs, which can be used in order to approve access  to very interesting services like the accessibility service  or give you access to the files of the device, the external  directory after the introduction of the scoped, let's say,  storage. Then you can get access to,  you can get your app as a device administrator.  You can get the system alert window, notification access,  premium SMS, and, of course, to install unknown apps.  So all these things are, as you understand, quite privileged  when it comes to Android. All right.  So the first challenge when it comes to this type of, let's say,  dialogs was to minimize the steps that the user has to take  in order to approve access, to give access, right?  So we have to minimize the steps to get to this button there and  make the user to click on this button.  But there is a convenient way of doing that.  You can just create an intent, set the actual action to the  corresponding menu that you are interested about, and you can  start the activity in order to navigate the user to the menu  that you want. For example, you want to get  the user to the manage overlay display on top.  You can just create the first one, accessibility service the  second one, and so on. All right.  So that was easy. But we still have two steps.  The first step, the user has to choose our app between a list,  actually, with apps which request the same type of access.  And the second step is, of course, to trick the user to  click on this button there. But if you notice the first  list, the activities, actually, the packages there are arranged  in an alphabetical way, right? They are ordered alphabetically.  So the only thing that you have to do is just to name your app,  I guess, with some A's like we did here, AA, so that explains  the name, in order to predict the position of our app in this  specific list because it's very important, right?  So the next step was to create a ROG APK, which will simply  start the first menu, this one that you see here, and then  start an activity which will cover the parts that we're  interested about. So we can just focus the user  only on our own app. So that was the first step.  And then use a trampoline activity.  I will explain why I named it like this.  In order to start another overlay which will cover, again,  the parts of the dialogue, of the second dialogue that can be  used in order to, let's say, communicate to the user that,  you know, you are approving something which might be bad.  All right. So this was the result.  I told you we're going to see quite a lot of short clips.  And this is to get the system alert window.  Yeah. Our app starts again with zero.  I mean, with no permission approved.  So the message is totally, of course, you can change the  message, but this is something which is far from the actual  message. Yeah.  And we have this permission approved.  Right? So simple.  Okay. All right.  So how we did that, let's go to the technical part.  All right. Which, like I said, is pretty  much simple. So we're starting with our main  activity with our create method where we're creating an intent.  We're just adding this action here that I talked to you about  in the previous slides. And the first thing is to start  the display on top. Right?  Which is going to trigger the Android settings app and start  the display on top access menu. That's the first step.  Then we're starting immediately another activity which we call  trampoline and will make sense after you see this.  Which will, again, in the create method, will start the  second instance of display on top access menu.  So what this will do is to bring our trampoline activity in the  on pose state. So it will just try to remove  our activity from the top of the back stack and we'll try to set  it on the on pose state. But instead of staying there,  we are going to start another activity which we'll call  overlay trampoline that will do the following.  So in the first step, it will modify user interface in order  to cover the first menu dialog. So the user will click.  So this will trigger the second step.  But bring our own activity in the on pose state.  So we can now modify our user interface.  Then, again, cover the second part of the dialog.  And when the user clicks again, we can navigate the user  somewhere else. So why we did that, why we are  using that instead of something else?  We are using that because, as I said before, we don't have our  app doesn't get notified about the touch, the user's touch.  So we can't know, there's no way to know if the user clicked on  this menu. So we identify that by the life  cycle of the activity. We can see that when the  activity goes on the on pose state, this means that the user  clicked on the menu. So our activity went on the on  pose state. And we can just, let's say,  change and do all these things that we did before.  So what I didn't cover so far is how we identify the current  step that we are currently with in, sorry.  So we're just using an intent, an extra.  We name it step. And then a simple switch case  just to check in which step we are.  So then we just modifying the message that we are showing to  the user. We are modifying some parameters  like the XY parameter that I showed you in the beginning.  And we are creating the overlay. So this is the idea.  Get the intent. Get the window manager instance.  As you see, we are not using any kind of special window type.  We're just using a type application window.  No permissions, nothing here. We just modify the settings like  XY with this kind of stuff. And we are covering the parts of  the dialogue that we are interested about.  This is for the first step. And then we go to the on pose  state. We just increase our step one,  let's say, like one step more. And we're going to the second  one, which we are covering the other parts, right?  Like we saw in the demo. All right.  So that was the main idea of the attack.  But what we managed to take out of it, which screens were  vulnerable. So we managed to get all the  dangerous permissions like i talked to you about, like SMS,  call logs, everything. Then we managed to get all file  access. We managed to set our app as a  device admin. As you understand, i couldn't  bring a demo for each one of them.  But, yeah, we managed to get the device admin access, display on  top of other apps, modify system settings, install unknown apps  and get users access. So as you understand, when it  comes to Android operating system, this thing is quite  powerful. If you manage to get all these  permissions for your app, then you have something which is, i  would say, something like malware and steroids.  So it's quite big. What we didn't manage to get in  this case was notification access and accessibility  service. That would be wonderful, but we didn't.  Anyway. So, okay.  Let's summarize what we have. So we said that the main idea,  i mean, the design issue here is that the user can identify  with which app, let's say, interacts with.  Right? That's the first issue.  And the other one was when the activity is pushed in this  back stack, it will retain the graphical user interface.  The main idea was to integrate the user interface of the  activity which is on top with the user interface of the  activity which is below and add click-through capability in order  to hijack single-step decision dialogues, multi-step decision  dialogues and also third-party apps.  All right. So that's how we can protect  apps from this type of attacks. And the only way to protect an  app from this type of attack, and this is actually what was  the mitigation regarding the system dialogues, is to check  if the motion event which creates a click is partially or  fully obscured. That's the only way to do that.  So you get this flag. You see if this flag is,  let's say, set, and if it is partially obscured or if it's  obscured, then you can just reject the specific click or  touch. There is another way, but  no, it can't protect you from this type of attack, but it can  protect you from system alert window which is the hide overlay  windows that I talked to you about, and it was imported in  Android 12. So you can use this one and  use the set hide overlay windows methods to protect your, let's  say, activity from these kinds of attacks, but again with  special type of windows. And with that being said, that was  the last one. Thank you very much for  viewing this. If you have any questions, I will be happy to  answer. Thank you.  Thank you.  Okay. Thank you. Any questions?  Yeah.  If you can go to the second to last slide, what does it mean  if it's obscured? Obscured means that it's  discovered from another window. Okay. So there is a flag for  this. Yeah. It's a flag. It's not used normally then.  What do you mean it's not used? It's a property of the motion  event which identifies if this motion event, let's say, comes  from, it comes using a dispatch, to put it this way. So you are  dispatching. It was dispatched. Okay. So that's what it means,  simply said. Thank you.  Here, your top right.  So thanks for the presentation. Very nice.  This mitigation would imply that every single developer needs to  do on every single touch event this kind of mitigation.  When it comes, yeah, of course, when it comes to, like I said,  to critical decision screens, not everywhere, right?  Yeah. But still, this would not really protect you against the  type of vulnerabilities that you showed which were at the OS  level for approving permissions, right?  When it comes to approving permissions, this thing has  already mitigated, right? There is a fix. It has been applied.  So there's no, I mean, if you try to run the same thing on the  newest Android versions, it won't work. But when it comes to  third-party apps, yeah, there is still an issue with that. You  can use that in order, let's say, to create this kind of  permissions. Although, I mean, you need again to bypass some  restrictions. So you have to get your app, let's say, some kind  of permissions in order to do that. But, yeah, it still works.  I mean, if your app doesn't have this flag set, yeah, it works.  So I was wondering, given that Google fixed this in the OS  itself, are they planning to also fix it for third-party  applications?  I don't think so from the point that, I mean, they can't make  you use these flags, right? It's something which is not, it  doesn't stand from this point. This is actually something which  I have been discussing within my company. There are, let's say,  some cases where you can't apply these flags because it breaks a  lot, a lot of things, right? You know, when you're developing  something and you're just changing a small flag which was  used for something else, then it can break a chain of things,  and this can be a disaster. So like I said, you can't use these  flags when you have really important decision screens.  Really, you can add them in your view, let's say, your button,  your tangle, or whatever, in order to protect it from this  type of attack. That's the only thing you can do, I guess.  Yeah, but maybe the inverse should be applied. Maybe these  flags should be the default, and then if you have a name...  Yeah, I don't know. I mean, that's, you have to, you know  the triangle, right? You have functionality, you have, yeah,  but...  Convenience.  Yeah, so, yeah, I mean, it's something that, I guess, they  leave it up to the developer to decide how they, I mean, how  they can arrange that thing there.  Yeah, okay, thanks.  All right. Thank you.  Any other questions? Yeah, there.  Hi.  Hello.  I wonder how could you make an application, a phishing  application, that uses the Heavy Lantern presented in the  first slides, the Heavy Lantern mechanism without the user  noticing the app while navigating between apps?  The first one, I mean, the task switching, right?  Yeah.  Yeah, so this attack leverages the fact that the human eye  can't, let's say, perceive the transition state from one  activity to another due to the short transition time.  So there's a very short transition time in order to  identify, to see this. I mean, so the human eye can't  perceive that. If we go back and go very, very slowly, you can  see the transition, actually. But, no, when it normally works,  no, there's no way. So this is what this attack actually  leverages. And, actually, this is something which is used by a  lot of malware families in order to do such a thing.  They're using this switch, activity switch, in order to do  that. So it is something which is  valid. That's what I mean.  Because while you showed the video about the  evidence mechanism, we could see the malicious app in the  background while navigating between apps. So I wonder...  Yeah, if you push it in the background.  Yeah.  Yeah, that's a way to do that. But how many times you do that?  I mean, you have your banking app, right?  You're just clicking on your banking app.  I don't know. Yeah, maybe.  I don't know. If you are sometimes, let's say,  very security-focused, yeah, I agree with you.  We will do that. But, honestly, I prefer not  to install something. That's my first rule when it  comes to security. But, yeah, when you push the  app back in the back stack, you can see which, actually, in  which app it belongs to. But, like I said, you don't see  that.  But I wonder, is there a mechanism to  phantomize, maybe, to...  There are a lot of things that have been, let's say,  introduced in order to show the user that you are  interacting with this app. There are some papers about  it. But, you know, when it comes to this stuff, I think  that, I mean, I think so. I'm not sure. But I think that  Google has to, let's say, put a balance between usability.  They don't want to interrupt the user experience with...  Because, okay, you can... There are some cases.  There are some papers. They're showing some things,  like, you know, we can add a bar here which says that you  are interacting with this app. Like we have in Windows, for  example, right? You know with which app you are  interacting with. But, no, here, I mean,  there's no nothing. At least for now, nothing.  As far as I know. Yeah.  Thank you. Thank you very much.  I still have one question here.  Hi. Hello. Thanks for the presentation.  It was very interesting. So, the last slide, I mean,  not the last, but the one presenting speaks about  mitigation. Yeah.  What about common users mitigation or protection  apart from good IGN and not installing everything on  Google App, on Google Play?  Yeah. Unfortunately, that's something,  yeah, that has to do with... When it comes to Android,  I mean, there are some specific, let's say, steps that you have  to follow when it comes to security.  Never, of course, the first one, the first rule,  never trust an app which is off market.  We never install an app from any source.  You never know what... You know why.  I mean, when it comes to Play Store, at least they have some  rules. You can't upload your app and  request accessibility service without have some kind of,  you know, let's say, reasoning about it, right?  When it comes to off market, you can do whatever you want.  There's no... Although there are mitigations.  I mean, in Android 13, you can't access the... You can't  request accessibility service when you are off market.  Anyway, but what I want to say is that make sure that the  sources from which you are installing your apps are,  first of all, trusted, and then what kind of permissions you  are approving. For example, the system alert  window, for me, it's powerful, right?  It can bypass a lot of restrictions.  And people, you know, just, yeah, approve it.  There's nothing... Yeah, because they don't know about it.  So just approve this permission. It can, you know, it can give a  lot of privilege to an app, right?  And it can do all this kind of stuff, all this magic with the  user interface. So, yeah, you have to engage.  You have to be careful with that.  You have to check your sources.  Yeah, that's the only thing you can do, I guess.  All right? Thank you.  Other questions?  Oh, okay. Still another one.  Yeah, I was wondering, first of all, thanks for the great talk.  Thank you.  I was wondering if there are any actual use cases for overlays  that you know about or...  Like I said, I mean, when it comes to overlays, when it comes  to great confusion attacks in general, like I said, most  modern malware families are using this kind of stuff.  For example, you have Cerberus, right, which is very well-known.  It just starts screeching.  When it comes to this attack, no.  So far, no.  The one that I talked to you about, no.  There's no, I mean, evidence, at least, that uses this type of  attack, right?  The ones that I showed you.  My question was not about attacks, but more legitimate  apps having actual use cases for being overlaid.  Overlays.  Yeah, I mean, of course.  I think that, not I think, actually, you know, the bubbles  that you see in your device, like the messengers and stuff,  they are using this alert type system, alert window, in order  to do that.  Actually, there are two ways in order to do that.  It's picture-in-picture, which creates a small window like the  maps.  You use a maps app.  You just minimize it so it will go.  This is picture-in-picture.  And the other one is using a system alert, which is a  legitimate way, yeah.  That's for the legitimate way to use it, to be on top of other  apps.  Yeah.  So it's useless.  It's useless.  Anyway, yeah.  Other questions?  Okay.  Perfect.  So thank you again for your presentation.  Thank you very much.  Thank you.  Thank you.


url: https://www.youtube.com/watch?v=88dIdx3PXFQ
title: Attacking And Defending GraphQL: The Ultimate Guide by Leo Juszkiewicz
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=88dIdx3PXFQ",
    "title": "Attacking And Defending GraphQL: The Ultimate Guide by Leo Juszkiewicz",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2959,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Okay, so first of all, as usual, I want to thank Insomniac, ICRT, basically everyone  that organized this great event, I'm really excited to be here, this is my first time  in Switzerland, you have a great country, specifically here in Lausanne, right, France  as well, I guess.  So let's start with this, we have attacking and defending GraphQL, the ultimate guide,  my name is Leo Joskowicz, so let's start.  First of all, you don't know me, so let's start with a quick who am I, so I'm originally  from Mexico, yeah, I can prove that, basically because I love chili, I love spicy, if you  see me somewhere around just pouring some chili on my soup, don't worry, I was born  like that, also other hobbies that I have as well, Swiss chocolate, not because I'm  here, I'm telling you, I always love the Swiss chocolate, soccer or football, whatever  you call it.  I used to get certified, I wasn't sure if I was supposed to say that or not, but I have  all these OSCP, OSCE, CPPT, EMAP, EWPT, PTX, so on, but not anymore.  I work as an application security architect in Dario Health, which is, as its name implies,  it's a healthcare company based in New York, I do a lot of stuff, you know, like design  reviews and making sure the code and processes, everything is as secure as possible, I used  to be in my previous jobs, security researcher, but mainly in the web security area.  And also, when I have time, I'm pursuing my MSc, my master's, in cybersecurity from the  University of London, and basically that's all about me for now.  So the agenda for today is going to be just a quick overview about what is GraphQL, maybe  some of you are familiar with, maybe not, so we'll just give a quick recap and we'll  start gradually moving on to more topics, more operations, directives, and more less  common stuff, actually.  We're going to see also some terminology, because we need to understand that in order  to understand attacks and how to defend ourselves.  We'll do also a comparison with other APIs, so the RESTful API, which is the most widely  known technology, and we will see also real exploit scenarios, so we can see how things  go in real life, but also we will see other attack vectors, other places where we can  be hacked or attacked if we are not aware or we don't care enough.  And lastly, of course, we're going to see some remediations or ways to mitigate those,  how we can defend ourselves, how we can make sure that if we adopt or if we adopted already  this technology, so we are safe.  So let's start with a quick overview, but before that I would like just to clarify,  I don't know, just somebody saw me downstairs and he was like, oh, you're a hacker, so you're  probably on drugs.  I'm like, no, I'm not, dude, I just have red eyes, I just went to the doctor, so I'm not  on drugs.  Okay, so API basics.  So you already know what an API is, or if not, it just allows you to exchange data or  information with different applications.  Usually you follow some rules, some header, some token, key, password that you need to  share with the service provider or the service provider actually provides you.  Let's say we want to query the weather information for today, so we set a set of rules, a few  fields that you need to provide in order to get the full weather or just one piece.  But APIs became really crucial just last year because they bring a lot of benefits.  This is the way of exchanging data between my app and the rest of the applications, okay?  We see them basically all over.  If you know YouTube, if you know Facebook, basically almost every single application  in the world, mostly the public ones, they share some kind of information or API for  you to reuse and query their data.  If you want to get, let's say, your video and you don't want to go and click on your  video link every time you want to get the viewers or you want to get some other information,  you usually do this through an API provided by the service provider, but as well if you  want your service to be used by other users in the world, other services, so you need  to provide that also as well.  So almost 70% expect to rely more, even more, on APIs on 2023.  That's according to statefulstateoffpis.com, but that's just a number, okay?  It could be, you know, millions of users and millions of applications as well.  So we used to have something called the traditional REST API or RESTful APIs, and that used to  be the standard.  We know we have several methods, HTTP post or put to create or modify data, delete if  you want to remove some items, something on the server, get if you want just to retrieve  data or you want to read data from the server, and we used to have many endpoints, okay?  We'll talk about this later.  And also the way of interacting with the server, it was by using JSON or XML.  XML may be less common, but if you know Google Cloud or one of these services, so they still  use kind of like an XML API where you can actually use XML as part of the, I mean, to  call the API service.  But we used to have many endpoints, like if you want to query for orders, you want to  query for users, history, logs, every service or every component of the application is just  another slash something, sometimes a few slashes.  That was just basically the RESTful or the old or the traditional method that we know.  So the economy just to reinforce a little bit more about this, they said, I think it's  in 2017, I'm not affiliated with them, okay?  So they said that the world's most valuable resource is no longer oil, is data, okay?  And when we talk about data is the API, because this is the way of exchanging the data between  you and the application, okay?  So if you want to invest, maybe this is your opportunity.  I'm not sure, yeah, if REST actually stands for Relaxation REST, RESTful APIs.  So let's see a few GraphQL fundamentals now.  What is GraphQL?  So GraphQL is an open source data query and manipulation technology that is used for APIs.  It was mainly created by Facebook or Meta back in, I think it was in 2012, and they  released this to the public in 2015.  Why they did it or what's so great about GraphQL?  So first of all, it's flexible, okay?  You can change pieces in amount of just seconds or minutes.  You don't need to change your whole architecture in the front end or in other places.  And it's very efficient, okay?  Because we will see later where, how you can just query only or basically send only one  request with many queries instead of sending dozens of queries for that.  Also one of the problems, we'll see that by comparing them.  So one of the problems with REST APIs is that you get everything, you query for orders,  you get all the orders.  Okay, you can query for the ID, but you get sometimes all the details, not really necessarily  at this moment, but you get everything in the same packet.  With GraphQL, you specify what exactly you want, okay?  So in many cases where you are, you need compliance, HIPAA, GDPR or whatever, and any other regulation,  and you are requested not to, I mean, everyone basically, but specifically these companies,  much more.  So they reduce drastically with GraphQL, just with the disclosure of PII or PHI, personal  identifiable information, or PHI, which is the same acronym just for health information,  like diagnostics and stuff like that.  So when you query the API, you get the exact information.  You get the name, because that's what you requested.  You get also the phone, if that's what you requested, but you don't get the phone name,  address, and also different information that you didn't even ask for.  Another advantage here is that it's a strongly typed language, otherwise errors will be  thrown.  That means that, as opposed to, I mean, you could do it also in RESTful APIs, but you  need to have some work done in the backend.  What you need to do is just to query specifically for that type of data, whether it's an int,  a string, there are also some scalar types or built-in types that are called scalar types,  we will see it shortly, which is like an ID.  And that's what you request.  If there is an error, so you won't get anything, which is differently with RESTful APIs.  Now regarding the HTTP status codes.  So in RESTful APIs, usually we need to deal with, you know, the 200, and then in the body  you put some other HTTP status codes, 405, 404, 401, whatever it is.  Here, mainly, we don't care about errors, I mean, we always get 200, and that also makes  it a little bit harder for an attacker to realize whether this is an error or not.  Of course, if there is an error, so there will be like a short field, JSON field, called  error with the message specifying what went wrong.  But we don't need to get, I mean, not with any other status codes.  So let's just jump about some more terminology about GraphQL.  So first of all, we need something called a schema.  The schema is what actually defines what we want to query.  It's kind of like defining our database, how it's going to look like, what fields we're  going to have, what type of queries we're going to have, okay?  Because we have something called STL, which is the schema definition language, it's just  defined by, I mean, actually, it was originally by Facebook, now it's by the GraphQL Foundation,  which is, we'll see something similar to, has some similarities to JSON.  So the schema is just like, let's say, the big picture, like the database.  Now on top of that, we have something called the object.  So the object is kind of like the type of operation that we want to retrieve, we want  to deliver to the user.  And inside each object, we have the field.  Now the field is what specifies the values for an object.  So here we have a very, very easy example here.  So the schema is of type user.  Now we have an ID, the ID is the field of type ID, ID is a built-in type of GraphQL,  but also we have the name.  And the name is, as usual, a string.  And all this makes the object.  Now we have another object, which is the type order, orders.  And here is kind of like a table if you want to assimilate this to like a SQL database.  And you have also a user ID.  Now a user ID here in this case is of a type user.  Now user is a type that we created.  So this is called basically an edge, or it's just a relationship, we can create relationships  in the GraphQL.  Because at the end, if you remember, what we want to do is we want to query once and  get all the necessary information that we want.  So in this case, we could do, we could get orders, and we could get also the user that  order that.  We could do it even more complex and create a bidirectional relationship between the orders  and users, and we can query either to get the rest.  But this just gets more complicated.  It's one possibility, but this is just a very simple example of a GraphQL schema.  Now we mentioned about the schema.  We have this information that can be queried.  So what does that mean?  What can we do with that?  So there are three main operations in GraphQL.  One of them, or probably the first one, is the query.  Query is just a read-only, it's just like a GET request, okay?  What we do here is just read-only information about the server, about some endpoint.  I want to get all the users that recently signed up to my application.  I want to get all the last 10 orders that were ordered in my application.  Nothing else.  So if you try by a query, if you try to write data, if you try to change data, that's not  going to work.  And it doesn't matter if you are the developer, it's not going to work.  Now another one is the mutation.  Now the mutation is where things start to get a little bit fun because mutation means  that you're going to change data, okay?  This is like if we compare back again to REST.  So the mutation is kind of write, which means create, add, change data, or even delete data,  but also at the same time we can read data from the server.  And lastly, we have a third operation, which is the subscription.  Now the subscription is kind of, if you are familiar with WebSockets, so it's basically  kind of push notifications with the client.  It could be only directional from the server to the client or vice versa, or it could be  bidirectional between both.  Let's say we're waiting for the user to upload a file, so once we get a file, then the server  gets some sort of notification, and so then the server will send an email.  I'm saying it's commonly with WebSockets, but it could work with different technologies.  Now here, what we do is we first of all define the schema, so the schema says I want to query.  So the query is, in this case, just a user.  It means if you want to read data based on my schema, so you can do it as of this example  only to the user's object, okay?  If I try to read, let's say, to the orders by using this example, so nobody will be able  to do so because there is no permission, actually there is no indication that a user can actually  read the object until we put it inside here.  So GraphQL is very cool.  Oh, my bad.  Okay.  So let's just dive a little bit deeper into this, what exactly or how we can do a query.  So if we want to get a user's name, okay?  So we do this syntax, which I don't know if you are a fan of Python or maybe not.  If you like JavaScript, JSON, Java, you will like this as well.  So we have a query here, okay, which is like the main operation in this case, and then  we have what is called a top-level field, which is users.  It's kind of the name of the endpoint, let's say, comparing this to RESTful, and the field  that we want to get, okay?  A user could have a name, it could have an age, email, ID, many other information.  So in this case, we want to get only the name.  So this is on the left side, we write our request.  On the right side, we have our response, okay?  So the name here, I hope I pronounce it well, is Alain Berset, right?  Swiss president.  This is not by coincidence.  And this is just a very simple query, okay?  From here, you could just put more and more fields, okay?  I mean, there's nothing from the client perspective that avoids or prevents me as a user to  put more and more fields, okay?  So we'll see that later.  This is maybe an attack surface for GraphQL.  Now what about the mutation?  So the mutation, first of all, as you can see here, we need to add that to the schema.  We need to say, hey, I want to use, because at the end, we can have in a complex environment  like, you know, big companies, you might have different schemas, which is very powerful  in GraphQL.  You might have a schema for development.  You might have a schema for different applications.  So for this schema, I want to say, hey, yeah, here I want a mutation, okay?  Let's say if we go back to the weather example.  So I don't want any user to change the weather, right?  Because you're going to say now in Switzerland, it's really hot.  No, here it's not Dubai.  So I want users to only query, to only read the data from my server.  So in this case, because I need to explicitly do that and put the mutation, and it's just  very simple mutation, colon mutation.  And then at the bottom, we can see the mutation itself.  So in this case, it looks a little bit daunty.  Basically, these are arguments that we put on just like with any function there.  So we have our create user function with the ID.  The ID is provided by the front end.  In this case, it's number one.  So what we want to do here is we want to replace some fields or the name of a user.  So here we have the password.  The password, I just made it up, is swissinbase64.  You can check it out.  And with the name of Victor Rossi.  I don't want to kill the president, so don't worry.  And what we want to do is just specify the three fields, the ID, the password, and the  name, okay?  Just in case the ID was something completely different.  So the response on the right, we just get this, which means that it was updated, okay?  So usually what you request is what you see on the response, okay?  So these are the two main operations that we mostly be playing with, the query for read  and the mutation for changing, deleting, or adding more data.  Now there's another thing, because GraphQL is a full language here that was created.  There is something called directives, okay?  If you come from Python and you know, like, decorators, it's something similar here.  So what if you want, you know, you have your BigQuery.  But by using this kind of directives, you can change actually the whole behavior or  how the response is going to look like.  Why?  Because in some cases you want to ignore data.  You want to say, hey, but give me this space just in case this is not true.  So by this example, what we see is we have the list of users and we want to get the ID.  We want to get the name as well.  But we want to say, hey, if the basics only checkmark is true, okay, which can be retrieved  from the front end, let's say the user wants to see how many users are in their database.  So just skip the URL, okay?  Skip the link from that response.  Because they all want to get just the ID and the name, nothing more, okay?  So there's a few directives that we can use.  Skip, include.  And just a few others.  I think there are like five or seven, maybe, we can refer to the RFC for that.  You will see later on why this is important, again, because in this case this is skip.  But if you have include, so you might include the password in some queries as well.  Also, we have something called fragments.  I have no idea why they use this word.  I don't know.  Fragments for me, I don't know.  I come from Android.  So something completely different.  So fragments is the way of reusing the same piece of code, or in this case the same field  for different queries.  Let's say you have a query, again, for retrieving the user, the username.  You don't want to type 30 times user, right?  Because there is some principle called DRY, or dry, don't repeat yourself.  So what we do is just we put these three dots, which is called a spread operator.  We define just some name.  In this case, it's called same fields.  And we do fragment.  We say, OK, what the same fields or the common names that you want to include in every query.  So we do ID, username, email.  So every query that includes this spread operator dot, dot, dot, same fields.  So automatically, it's going to include these fields.  So in this case, again, this is just very simple.  We have just three fields.  But imagine if you had 12, and you were doing 15 queries.  So that will really save us a lot of time.  OK, and we have one more thing here.  There's something called introspection, OK?  What is introspection?  So by introspection, we can query the server and discover, we can find out about the underlying  schema types, operations.  If there's a query, mutations, subscription, directives, everything, basically, OK?  It's mainly for debugging purposes.  I mean, I wouldn't recommend this in a production environment.  But the problem is that it's enabled by default, OK, all over, OK?  You can use no matter what kind of implementation.  And it's going to be enabled by default.  The problem is even worse with some implementations, specifically in Java and Go, because you cannot  even disable it.  What do you do?  There are some workarounds there.  So just in case you are using Java and Go, make sure you disable this.  But what exactly is the introspection?  So introspection is defining the query.  And we have our magic field here, underscore, underscore, schema.  In this case, what we want to get is the whole schema, namely, the whole database.  And we want to get, specifically, the names, the name field here.  Now, what we get, I mean, this is just an example.  But we get a full schema here on the right.  We get a query.  We get user, which is the name of the field.  And we see, at the bottom, we see the password field, OK?  So if we manipulate this a little bit more, we'll see later that we can even query and  get the password for different users, of course, if there is not the proper configuration in  the back end.  But this is just their part of GraphQL.  So it's OK.  That was probably a lot of information.  So don't stress.  This is just art.  Because there is something called GraphQL Voyager.  This is kind of a UML, like kind of a graph mode of your whole schema types and everything.  It actually draws all the relationships between the different objects as well.  This is a little bit complex.  That's what it looks like.  But it's just to reinforce that if, for any reason, we have a database, I mean, either  we are defending or attacking.  So we have a way of visualize that in a much more convenient way, OK?  And it's not just, you know, kind of having all text.  It could be much easier.  Of course, we'll need to manually look at all this and find the relationships between  the dangerous objects.  And this is free, actually.  You can just download it from GitHub.  A few endpoints, a few ways where we can find GraphQL is, of course, on the slash,  on the root path, just because.  But there are a few more.  We can see this, of course, on the slash GraphQL.  There's a slightly different version, GraphQL.  We have the v1, you know, version 1, version 2, version 3, slash GraphQL.  We have slash API, GraphQL, slash API GraphQL, slash console, OK?  I have no idea why they made it up this way, but it works.  Slash playground.  Yeah, that sounds very cool.  Slash GQL, slash query.  And it's not really for only queries, OK?  This is the GraphQL endpoint.  Or simply index.php and question mark GraphQL.  This means that, again, if we are trying to defend ourselves, just make sure that only  the right people, or from the right sources, they have access to your endpoint, OK?  And for any reason you don't have any app, debugging app, IDE, or something else running  in the background.  So now we saw everything about GraphQL.  We need to compare now GraphQL and see more advantages versus the REST API.  So as we mentioned earlier, we have the ability of just query one single endpoint in GraphQL.  Just name any, slash GraphQL.  And by REST APIs, you probably have many of them, OK?  If we just Google quickly for the weather forecast app, AccuWeather, YouTube, you probably  have dozens, if not hundreds, of them.  And each one with different specifications.  So this makes it a little bit harder because, first of all, maintaining all of this.  You forgot this is internal, this is not.  Who has access to this one?  How many fields if you're required to have authorization?  If it's just SSO, if not.  So this makes things a little bit more complicated.  And if we talk about, let's say, GraphQL, so it's just much simpler.  I mean, for sure we can have more than one endpoint, but usually it's enough with one.  Second of all, as we mentioned earlier, with GraphQL we use only POST methods.  There is a way actually to use GET methods, but it's not recommended because that will  lead to some CSRF stacks.  But technically you can, but you are using usually POST methods.  But by using REST, again, you need to deal with DELETE, PUT, PATCH, HEAD, GET, OPTIONS.  Just too many HTTP methods there.  Another advantage of GraphQL is it's called over- or under-fetching, which means either  you get more information that you requested or you get less information.  So you don't get the exact information in RESTful APIs.  So by GraphQL, you get exactly what you need.  You ask for the user, you get the user.  You ask for the name only, so you get only the name.  You don't get the full description or the user with all the details as well.  And the frontend, yeah, it's on a crown here.  So the frontend must match exactly of the changes that you do with the backend.  And in GraphQL, probably you have your PM, you have your customers.  They want to do some changes specifically to the API.  They don't want to be called ORDERS.  They want to be called ALL.  So what do you do now?  You need to change everything in the frontend.  You need to change everything in the backend as well.  It's just time-consuming.  In GraphQL, it's just going to be the same endpoint, GraphQL.  And only you change specifically in the backend, or maybe just in the frontend, about what  your customer, your PM, wanted to change.  If it's just a few fields, okay, just remove them, add them, and just play around with  that.  But it's much more cost-effective also by using GraphQL.  Another advantage here is that we mentioned that it's strongly typed.  You cannot mess around with different types.  If the user put number one as a string, where it should be an integer, or if the user, you  know, because that could also lead to some attacks.  If on the phone number, the user put the email, not because they made a mistake, but because  they wanted to enumerate or try to attack your server, so that could be directly rejected  by the server by GraphQL, because you asked specifically for a type.  And the rest, yeah, you could do that.  You could still, of course, in the backend, you know, compare, you know, PHP, Java, whatever,  JavaScript.  You could use the three equal signs to compare both the type and the value, but, you know,  you would need to do that for every single value.  And here, it's just made by, you know, the schema.  It says you get only that type, and that's all.  Besides that, in GraphQL, you also have the ability to create your own type, okay?  You create your user type like we did before.  You create kind of like your class with all your fields, with all your different values  that you request, so it's much more granular than just REST API.  But there's one thing, at least here, that REST APIs are still good.  I mean, we need to still consider if we really do some complex and very, very, you know,  nested queries, nested APIs with GraphQL, it's a little bit different here.  Because with, you know, imagine like you nest, nest, nest more, that could lead to adding  null of service or simply crash the GraphQL endpoint if you don't do it properly.  Or even if you do it and some attacker plays around with your API.  And in just the common, the traditional RESTful API, that will be just easier.  And also, by caching responses, so RESTful API, it will be better because, you know,  the API will always return the same response.  But in GraphQL, it's enough that you change one field on the same endpoint, the same operation,  and you're going to get a completely different response.  So it's still possible, but it's just a little bit more complicated to cache your responses.  So it means that if the response, let's say, last 10 users, that a couple of users are  trying to query to your server, so it's going to take a little bit more because the server  will need to, again, process that and retrieve back to the user.  So only for this reason, I would recommend to, or I mean, at the end, you could work  with both.  You could combine GraphQL and APIs.  So specifically for that, for those complex queries, so you can use better RESTful APIs.  So this is a very interesting example here, just to illustrate what GraphQL can do here.  So at the top, you can see the RESTful API.  You have your api.com slash burger.  You get everything.  Okay.  You get the bun, you get the bread, you get the patty, you get everything you get.  There is no way to specify, I want just this and that field, or in this case, pieces.  I mean, of course you can filter by in the backend, you could apply some limits, but  it's harder.  I mean, it's not by design.  And here in GraphQL, just specify what you want.  You said bun, patty, bun, lettuce, lettuce at the bottom.  So this is what you get.  Okay.  As you can see, there's no cheese here.  Okay.  And this is a GraphQL versus REST API.  Now let's see some usage statistics.  Who uses that?  Why do you do that?  So GraphQL is everywhere.  Okay.  Sometimes we don't realize about that, but it's actually there.  So this graph was taken from a wonder graph.  It just illustrates the popularity of GraphQL.  This is the amount, this is until actually two years ago, but it reflects here the amount  of there's most 4 million of repositories, 4 millions that were created just with a word  or with some tool regarding GraphQL.  Okay.  And again, this is just GitHub.  We could even have more data about GitLab, Bitback and other technologies or platforms.  But as you can see also, there are big technology, big companies, just like Facebook, GitHub,  Pinterest, Coursera, Shopify.  And there's just many, many, many companies that adopted already this technology.  And they're even contributing to the advance of this great technology here.  And again, this is just an example taken from graphql.org.  There are just millions, probably other websites that are using this technology as well.  And the reason, you know, because it's just much more flexible as we talked earlier.  Now let's go to the fun parts.  Let's see a real exploit scenario of how we can take advantage of GraphQL.  I mean, it's great, but everything comes with their part on the side.  So not a long time ago, there was an attack in Shopify.  Shopify, I guess you are familiar with.  It's a website, it's an e-commerce that you can mount, you can use and sell your stuff.  You can kind of use their service for that.  What's more fun about this is that Shopify, they actually, as we mentioned, they contribute  and they develop tools for GraphQL.  So they had a vulnerability in their website and the way of exploiting it was to first  enumerate, to first discover what's going on, analyzing the endpoints, analyzing the  fields that can be sent to Shopify.  Of course, it's, you know, it takes, it sounds maybe easy, but it takes a lot of effort here.  And once that, the endpoint that was actually lacking authorization, it was found, then  the email, basically what happened is that you could send a mutation to an endpoint and  there was no authorization.  It means you could update any email just by changing your email.  Okay.  You just found the endpoint changing your customer's email.  So then you just change that.  You simply change the endpoint or the host where your victim is, and you could change  their, every single customer's email as well.  So after manipulating the mutation, we can just simply send that, you know, with any  proxy, Zap, Burp, whatever, Fiddler, just manually with the URL.  And that was enough just to exploit that.  So let's see this in a more technical way.  We have here the mutation that was in, um, in, in Shopify.  So email sender configuration update, nothing really that tells us a lot, but here we can  see that the, uh, the ID that was sent is basically the email.  Okay.  We could figure it out that there is no really, uh, authorization of this from this, uh, on  this side.  We don't send any token.  We don't send any, uh, API key or any password here, uh, to the endpoint.  So that could be one way of identifying that there is a vulnerability here.  Then we could just play around with the different fields.  We could add more fields.  We could just, you know, uh, delete or add some arguments there.  And this is just a screenshot of, um, how it looks like in the, in, uh, this is in Postman.  And lastly, this is how we can change the customer's email here.  Again, now this is just one example.  There could be many, many other examples that we can see shortly.  So, um, there are many vectors, many ways of attacking or many ways that we can defend  ourselves from attackers here.  So one of them is injections, just like with any other technology.  So there was an alternate attack in Nuri, uh, I think Nuri, uh, there was a, a blockchain  bank or something, a financial institution.  And they were, uh, um, they, they had an injection through WebSockets there that affected  their service.  Uh, but also there was an SQL injection.  Why not SQL injection just by, you know, they're putting the, um, the apostrophe and doing  the query.  You could just do whatever you want, job the table, add users, manipulate the database.  And that was in HackerOne, HackerOne just, you know, it's a, a platform used by hackers.  So hack the hacker.  Uh, there was also a denial of service, denial of service, uh, by, uh, recursively putting  more and more fields.  You could just nest more and more, uh, levels, you know, eight, 10, 13 levels of, um, uh,  sub, uh, sub, uh, uh, objects there and putting more and more fields.  Uh, we could just do the same with fragments, just putting the dot, dot, dot, and naming  the same function 30 times with different names.  Okay.  So basically we are kind of doing 30 different operations, but at the end it's just the same  with different names and the same thing with a directive.  So that happened in Magento that I mentioned before, which is the directive is the, uh,  include or some, um, uh, component that changes the behavior of the response.  So if it's a skip and you do include, so you can include some other information that wasn't  unintended.  Uh, there was, um, SRF also is another attack vector.  I didn't hear about any attack in that attack surface, but it doesn't mean it didn't happen.  You know, if you don't hear it means it didn't reach out to the news yet.  Okay.  Uh, we have also CSRF or a CSWSH, which is the same thing as cross, uh, uh, WebSocket  hijacking.  And, uh, it just basically happens if you use, uh, GraphQL over get method because there's  no authentication there.  So we should be careful about that as well.  Uh, authorization, authentication bypass.  Okay.  This is also another issue in Git, um, in GraphQL.  It happened in GitLab.  It happened in Shopify again, uh, also privilege escalation simply by changing the ID, changing  their, uh, role from regular user to admin.  Also, uh, hacker one was, um, vulnerable, uh, other attack vectors include less, uh,  or low vulnerabilities, which is enumerating the field suggestions.  Usually, um, GraphQL tells you something like, you know, if you, uh, if you were wrong in  writing a field, uh, do you, you know, like just Google, they suggest you another field  similar, uh, with, with a similar name.  And they tell you, uh, the response says, did you, uh, um, refer to maybe this title?  Did you refer to that?  So basically you are enumerating this schema, you're enumerating the GraphQL endpoint.  And lastly, when we are mishandling errors, as usual, when we send errors, we don't need  to send the whole stack trace or the whole database, uh, error.  We need to just send exactly what we, um, need.  So these are the attack vectors.  Now how we can remediate those, how we can defend ourselves from these, um, attacks,  we're using a great technology.  So first of all, yeah, disable introspection.  Of course, if you're doing, again, if you're using Java and Go, so you need to find a work  But, uh, don't expose this, at least not in a production environment.  Don't expose your schema.  Don't let users query your, uh, schema or types or any other, I'm sorry, any other piece  of information about your GraphQL endpoint.  Uh, also some developers, they like to preload some queries in JavaScript libraries.  They do it because of performance.  So try not to do that because that gives a hint to attackers.  Uh, also use only POST requests.  And again, because by using GET requests, you could be automatically, um, vulnerable  to CSRF.  Uh, next set the query def limits and timeouts.  To avoid denial of service, just, you have like a, a way of limiting the fields and limiting  the time of how every query should last.  If the query lasts for more than three, four seconds, that's too much.  Just reject that.  Uh, also calculate the field's height.  If you have only eight fields, that's all you're going to get.  If an attacker puts, uh, 11, so that's enough to reject the, the, the request.  Uh, return generic errors, just, you know, kind of something went wrong.  But if you, uh, you have, uh, an error in your SQL syntax in line 92.  And lastly, as a general rule is sanitize and validate all the fields.  Every single field needs to be validated because if you request again, a phone number, don't  expect the user to send all the numbers.  Okay.  Uh, even that you have your front end, uh, you know, JavaScript is, uh, actually even  HTML is only letting users to put, um, all the numbers.  Don't expect that because that could be easily changed by proxies, by many, many other tools.  And if you expect that and a user sends something else, you could be in trouble, but not only  that, every single piece of data that you ask for the user, every input, every search,  every field that has a text box and, or even any piece of data that, you know, input hidden,  uh, that the user can send back to the, um, to the server.  So that needs to be validated and sanitized.  Sanitize mean, you know, uh, to simply remove the special characters, those characters that  you're not expecting, like an apostrophe may be expected if you are in America for, you  know, McDonald's for a name, but that's not expected for an email.  Okay.  So if you have invalid or Unicode, um, uh, letters or characters in emails, that's not  also expected.  So for that specific, try to sanitize.  And there are just many best practices around the internet for that as well.  Okay.  So that was all.  You are awesome.  And thank you so much.  Hope you enjoyed.  Okay.  Okay.  You know, the drill, any questions?  My site is based on movement, so I should don't move.  I don't see it.  Yes.  You talked about hiding field names by not having a suggestion.  Shouldn't it make more sense to have authorization on which field can, which fields can be carried  by which user?  Yeah, yeah.  You're right.  I mean, you should, every operation, let's say the type user, it should be always, uh,  uh, checked against authorization and authentication.  That's first of all.  I mean, you have a schema.  You have a schema that, uh, only specifies, let's say the ID name, username age, and that  will be only, uh, stick to, let's say the user that the ID matches to, let's say the  cookie.  That will be really the, the, the idea.  Of course you could have another schema for admins that they can query, let's say support,  technical support.  They can actually query and even mutate the password with the right, uh, permissions as  well.  Yeah.  Yes.  Hi.  Uh, thanks so much for, for your talk.  Very interesting.  Um, when you do an enumeration of the, the, the service GraphQL, do you have access to  the schema or you need to use some brute force technique?  Um, by default, yeah, by default, the, the introspection is enabled.  Yes.  But even if you don't do it, I mean, there are other ways of enumerating.  You could simply, um, just, you know, throw your own field name and if you don't get an  error, so it means that the field exists.  So it doesn't, I mean, yeah, it's not implied that the introspection is disabled.  You could still have some other ways, but that's still enough to, you know, I mean like  again, you could have rate limiting, you could have a WAF, which also help mitigate those  attacks as well.  Yeah.  Great.  Final question.  Okay.  So suppose I have an app that I want to pentest that uses GraphQL, like are there any tools  that are available to like fuzz the APIs that use GraphQL or anything?  You mean tools to defend?  No, to attack.  Tools to attack.  There are a lot.  You could use simply, uh, if you know burp, burp suite.  Yeah.  an extension called InQL, I think, so it's just available in the pro provisional version.  You have a graph wolf, uh, I think I show it, uh, graph wolf to enumerate the endpoints  just automatically.  You have the WFuzz.  You could use also SecList for check, you know, discover, uh, different fields, endpoints  are just huge, uh, word lists there.  Um, besides that, uh, I think that would be enough.  That would just, yeah.  Okay.  Thank you, Leo.  Thank you so much.


url: https://www.youtube.com/watch?v=bRyghlND7kQ
title: Open Sésame! Example Of Modern Electronic Lockpicking by Thomas Bygodt
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=bRyghlND7kQ",
    "title": "Open Se\u0301same! Example Of Modern Electronic Lockpicking by Thomas Bygodt",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 2582,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20240223"
  }

  This text was transcribed using whisper model: large-v2

   Thank you very much, thanks to be here, for the little anecdote, it's my first talk in  my life, so just enjoy it, please.  We will talk about some modern electronic lockpicking, it's quite pretentious, I agree  with you, but you will see, it will be really fun.  We will talk about some physical design vulnerability, of course I have confirmed it with another  device, and after we have a big part about Bluetooth Low Energy, because it's my favorite  color of money, and you will see why.  So of course, let's go, I'm a senior security editor for OneCyberDefense since 2017, I work  in Rennes, in France, I like IoT and especially hardware and reverse things since 2-3 years  ago.  I'm an ex-CTF player, sorry I'm quite old now, I can't bypass a full night, I'm quite  old.  So before to discuss about some smart locks, let's go back several thousand years, little  history.  According to the historians, trace of the first lock, as we know, dates back to the  ancient Egypt, the design is really easy, just only three pins, the material is easy  to break, of course, just wood, but this design, it's currently already used, but of course  with more pins, more secure material, like steel and other things.  In 1951, there was a great lock controversy, a famous lock manufacturer from United States,  Mr. Hobbs, picked Chubb's lock, which is an unbreakable lock for 50, 60 years, during  the great exposition at London, so of course, at this point, it was, he breaks the unbreakable  lock, and the same year, he breaks the Braham lock, which is another unbreakable lock.  Of course, in the last 30 years, many technologies are evolving, for example, we have Bluetooth  low energy in 2009, of course, we have ZigBee, we have Wi-Fi, and everything.  So all of it creates a lot of hacking possibilities for us, so yes, there are already some hacking  stories about smart locks in DEF CON or Black Hat conference, but I think we can find some  other conferences like Insomniac too.  So, the physical vulnerability, obviously a lock must protect the access from unwanted  people.  You can always use a brute force attack to break the door and enter to the house or to  the room, but we will not do that in this talk, we want to be like James Bond, maybe  we can have some tools just open the door for us, yes, let's see.  So of course, when we talk about physical, we have to find a physical entree to attack  the hardware.  And once you are in the hardware, you have to understand how the lock works, how many  boards inside the lock, how boards communicate with them, both together.  And obviously, if we can get the hardware, we will try to reverse the framework if we  can get it, to find a password, hidden functionality, backdoor, vulnerability like a buffer overflow  or everything.  So this is the lock, so sorry, but I will not disclose any name of company during this  talk due to some respect.  You will see why before.  Not for the lock manufacturer, because for the lock manufacturer, sorry, but I have no  pity for them, but for the BLE creator, it was really great, so just for them, I will  not disclose any name on this talk.  So we have this lock, which is quite simple.  We have three parts, two big parts, one outside of the house.  The outside has the main board, has the battery, of course, outside.  If the power is off, you can change the battery easily.  And inside the cylinder, inside the door, you can find a motor board in this talk.  So of course, let's dig in a little on this board.  So first, the main board has a Nordic processor ARM Cortex M4 32-bit.  We can find some other motor controller on this board.  Of course, we have a connector, because of course, the main board has to communicate  with the motor board, so we have to communicate with them, and that shows a wire connection.  And we can find some pins on this board, so I have already soldered them, because first,  I don't think that just my work will bring me here, just in front of you.  So on the motor board connector, we can find the old pin about debug, so we will use them  a little bit later.  Same thing for the motor board, we have a microcontroller, of course, it's an STM8.  We have another motor controller.  We have the motherboard connector, of course.  And some other debug port, we can find a UART connector.  So the thing is that the TX is working, RX doesn't work.  The debug connector is used, but I can't find anything on this pin.  For this board, they have to do the right thing.  So of course, we have to find a physical entry point.  So when you are in front of the lock, once you remove the stainless protector, you have  a little pellet.  You can really easily remove it, just drill it, and you remove it, and we have access  to the motor connector, really easy.  So that's it.  We can have access to the connector between the main board and the motor board.  Of course, they forget to remove read protection on the processor of the main board.  So we can connect to it with OpenOCD, and we can extract the firmware, and we can put  the firmware that we retrieve.  We can use nrefident, which is an open source program, to identify the Nordic SDK version.  Obviously, you can connect GDB.  It's more easy to use GDB to extract some part of memory, like RAM, like pin configuration,  and everything.  So first, they don't hide any information about the hardware.  So thanks for that.  It's easy for us to retrieve datasheets on the web.  Electronic board is not difficult, it's really easy to access to it.  Debug port is not deactivated.  And weak protection of the processor is not set.  OK, thank you very much.  So of course, I said that we have the motor connection access.  So let's use a logical analyzer to see what's going on on the wire.  I don't connect the red wire, because red wire is only a power.  So well, we run our logical analyzer.  We have this signal, let's dig it.  We have three parts.  The first in blue is probably just a wake-up signal to the motor board.  We have two other big parts, probably the request and the response from the motor board.  So let's zoom on the first one.  OK, here we can see that we don't have many symbols.  We can see that we have only two symbols on the signal.  So let's do an exception.  OK, we have a 0, we have a 1.  Because for me, I don't like play with it.  Personally, I prefer string, so I prefer hexadecimal.  It will be easier for me if I can treat the data with hexadecimal string.  And once you have the language, the hexadecimal conversion, to analyze the communication,  I take sample at different action, of course, during the initialization.  So initialization is when you power on the lock.  So you remove the battery, and you put the battery back.  It's the initialization.  And the opening is, of course, when you enter the white code or you use your phone, the  lock is open.  So this is the function.  I take two different controllers, C1, C2, and obviously, at two different times, the  dash 1, dash 2.  So of course, we can say that we don't have any time issue, any time token.  So we can probably do a replay attack of that, obviously.  So let's go deeper.  We have some few bytes we never change.  So OK, the first one is maybe some headers.  The other is some maybe separator.  We have a byte we change only during the function.  So for initialization, we have, in ping part, we have three.  And during opening, we have one.  So this is the common byte.  And of course, we have a big part in middle, in orange, which is maybe, I know, is that  the ID of the motherboard, but it's maybe some un-ID.  And the first, it's just a checksum.  If you don't trust me, you can check it just with the command, because you can see on the  first time that you have 87 with three commands.  And on the opening function, you have 95, and you have 1 in command.  So it's maybe a checksum.  So of course, communication is unencrypted, is not signed.  They don't have any protection against triple attack.  And of course, yes, they use, the same use, a sensitive data without authentication, because  when you open, when you put the battery back, so we, but this is not an authentication.  Yes, you tried, OK.  OK, so this is the easy part.  Let's go deeper on the frameworks.  First of all, before I attack the framework, I have to extract, obviously, all the part  of the processor.  With the datasheet, you have, we have all address that we want, so we can extract the  pin configuration, we can extract the RAM memory, and everything.  Of course, the first thing you do when you have a binary, is just do a string.  It's a basic.  We have some string on the result.  Some of them are, can be interesting, dynamic password, yes, why not.  We have some string which looks like some identifier, or some token, maybe.  And obviously, we have to some file path, and github command, github URL, of course.  Thanks for that.  Thank you, developers.  First of all, I will focus on the EF40 and the KV40, because for me, it's quite strange.  They came really a lot, so it's maybe some magic number.  So I look for EasyFlash.  EasyFlash, it's an open source project to manage memory on bare metal firmware.  So let's go on the source code of EasyFlash, thanks to github.  We have some, obviously, we have some structure, we have some function, so let's go find this  function and structure inside our firmware.  Okay, so we have the createEnvBlob, once we have the function to manage the blob, you  can follow all the call stack to find the memory which is modified, read, written, and  we find a memory like that.  So we find the KV40, we find some probably CRC32, we find the lens, name lens, and everything,  and we can find the name here.  It's lots of settings.  Okay, well, I love Gidra, but I'm really bad to create some plugin on Gidra, so I prefer  to take my pattern script.  So I write a pattern script to search for me.  All of the data which follows the structure of the EasyFlash project.  I found 60 structures, and some of them are really interesting, like log setting, of course,  and hard ID.  Yes, because my first log is obviously, I have put a very strong password on it, which  is 123456.  Very strong.  Don't use it, please.  So the password is really in plain text.  We use it, we can use it, we can find it really easily.  So I don't speak about it, but we have a master password which never change.  You can reset the log, but the master password doesn't change.  It's like a joker.  If you forget your code, you can reset the log.  Maybe you can think that the master password is random.  Well, no.  Why use random when you can just increment it?  It's more easier to increment than do random.  So you can read some of them, and if you know the time when your target bot is locked,  you probably can guess which is the brute-forcing part of the master password.  So obviously, passwords are not hashed, master passwords are not random.  Okay, thanks for that, too.  So let's go deeper into the framework.  Of course, here we have found the password.  We have to find the command implementation.  So to do that, I use the ID, because as I have extracted the RAM memory, I can search  in the RAM memory for the ID.  Obviously, the ID must come from somewhere.  So we have just followed the call stack and the external reference to the memory address.  The first of all is obviously the write.  So the ID comes from a FICR register, so it's a full random 8-byte identifier for each Nordic  processor.  It's set in factory, you can't modify it, and it's fully random.  Well, okay, this is quite good.  We have only one place that the data is read.  Okay, let's go.  So we have our function, launch motor command.  Obviously, I have renamed it.  And we have three positions in the code where we call this function.  You have it here.  So obviously, we have the open command, we have the initialization command, and we have  the last one, but I can't say anything on it, because I don't have success to trigger it.  Maybe I have tried.  But maybe some one-shot command to initialize the motor board with the identifier of the  main board when the lock is in factory.  So obviously, here we have firmware, we have the communication language, we have everything  that we know, everything that we have to do to create an attack card.  But I don't want to create an attack card, because even if I like Raspberry Pi or Arduino,  I want to save the planet, and I just want to reuse my main board tested card.  So I take the firmware, and I put my code inside the firmware.  Why I do that?  Because you can say, well, you have the debug port, you can flash all the firmware.  Well, I don't reverse everything in that firmware, because reversing a bare metal firmware, it's  quite complicated for me.  And it's quite time-consuming a lot.  So I don't want to waste too much time on the initialization reverse.  So like that, I can use all the initialization of the firmware of the constructor.  Okay, perfect.  So I put just my command, my code, inside the firmware.  Because I have the size to do it, because the firmware doesn't take the full memory  of the processor.  So of course, you can find here some of my attack code.  So we have to intercept the ID.  So we transform, we switch our card like, obviously, a logical analyzer.  And once we have the identifier, we are just to send the open command to the lock.  And obviously, I have built a door lock, I have built a little door, to show my work.  Ah, demo effect.  So let's go.  So we have, this attack can be done on the real door, of course.  It's absolutely not mandatory to be in laboratory.  So we pull back the battery.  We wait for the initialization command.  Here I have read the identifier, and here I have opened the door, in less than 8 seconds.  So yes, of course, you can hear it, because I disabled the sound, but we can hear the  little door, the little motor inside the door.  So in 8 seconds, I can open your door.  Okay, that is for one lock.  But this design is used in many other types of lock.  So I take another one lock of the manufacturer, obviously not the same lock.  Okay, so I took this one, with a fingerprinting captor, and NFC possibility to open the door.  The connector is easily accessible, it's just turned by 90 degrees, but you can use it,  you can always use it.  We can find, obviously, debug port.  So let's go analyze the communication between the motor and the mainboard.  So we are only one wire to data.  And here, they don't implement any specific constructor communication, that is the protocol,  they just use UART classical, but they use in one wire.  So they switch the RX and TX, the receive and transmission, on the wire, between request and answer.  Okay, so it's best for me, because I don't have to write, to return a specific plugin  to extract the data.  Okay, we find the same structure, command, ID, okay, perfect.  Let's go with opening, because of course this is for initialization, so just when you pull  back the battery.  And for opening, this is the same, same for that, we have the same design.  So I have to check, of course, the weight protection.  Well, they set it.  Ah, bad luck.  But no, thanks to include security in Cortex-M0, there is a vulnerability, which affects all  of Nordic NRF-51, because yes, the board doesn't have the same processor of the first lock.  And thanks to that, we can read register, and we can set register.  But obviously, in the few steps of the initialization, a processor just read one address of the memory.  So we have just to put the address of what we want to read, and just step one, and obviously  we have the result in the register.  This is for the vulnerability.  So thanks to that, you can extract the firmware, you can dump the firmware in 20 minutes.  For 2,056 kilobytes, so it's quite fast.  So I will not, I have reversed the firmware too, but yes, I just want to confirm our command  I implemented.  So of course, we have the same problem.  Communication is unencrypted, no protection against replay attack, and they use sensitive  data without authentication.  Thanks.  For it, I don't have made a specific attack board.  The most easy part is just to hard-code the identifier inside the firmware.  And you just put all commands, like initialization, open, everything.  You hard-code the fact that all commands are just opening functions.  So you just have to put your attack card, and it opens the door.  Of course, there are NFCs, so I must, I have to check it.  First of all, without any administrator, any NFC card can open the door.  Thanks for that.  Obviously, the documentation of the lock says you have to set an administrator.  But I'm sure that we can find some lock without administrator in the wild.  And with administrator, maybe it's better?  Absolutely not, because in the memory, there are just the UID of NFC tag inside the memory,  so of course, they don't use a secure, if NFC can be secured, behavior.  Thanks for that.  Please, don't use UID to authenticate people with NFC card, please.  Okay, so here I have done the full physical vulnerability.  We will talk about Bluetooth Low Energy.  So for the first lock, they use SDK provided by a specialized company in the Internet of  Things world.  They have cloud integration, it's a major actor in IoT world.  They don't use any encryption protocol, protocol encryption, it's a full plaintext Bluetooth  Low Energy communication.  But they have implemented some encryption on the software side.  They just use Bluetooth like a whole wire.  Okay, so we can find maybe ZIV, and we have a packet, but only for 20 bytes length.  So we have a counter to say the packet is the fourth packet, the fifth packet, okay.  Let's go do some 3D hooking with Objection open source program.  Well, you hook on the IES function, so as you can find the key, you can find the initialization  for the vector, and everything.  Okay, you can print the stack trace too, it's easier for us to get the call trace, to do  reverse.  So of course, I have done two trace, and I compare the key.  The first key are always the same, always.  But the other change, okay, so maybe they have to exchange some random token or something  to change the key, okay, why not?  But the most interesting part is that the key is always the same, okay, keep that in  mind.  Obviously, even if I like Frida, when developers put a log inside their code, and give us the  possibility to put the switcher, the log back, yes, just use it.  So there are two functions which is called CircuitKey4 and CircuitKey5.  So obviously, it's quite, it's not really easy to read, so just focus on the green and  the orange packet boxes, it's much easier like that.  So the first key is just MD5 checksum of the login key, and the second key is MD5 checksum  from the concatenation of the login key plus S1, okay?  Thanks to Logcat, we have the size of the login key, we have the S1, and here, we have  the first critical problem, the login key is only six additional characters, thanks  for that, because obviously, six characters in the decimal is really easy to crack.  So we will just focus on the first packet, so the first and the second packet between  the mobile and the device.  So on the device, so the first request doesn't have any specific strings, but the device  responds to us with many information.  First, we have the hotkey, we have a device ID, and we have the S1.  So we don't have to brute force the S1.  The second request, it's more interesting from the mobile part, on the device, it just  maybe, okay, you just pad.  So on the mobile part, we have the device ID, we have the login key, and here, we have  the UUID.  Well, but I don't speak for UUID, okay, just let's find where is the UUID.  Each Bluetooth device has some advertising communication, which broadcasts every time,  once it's powered on, it broadcasts some data.  In the data of the lock, we can find the UUID, which is encrypted by AES, CBC, with a key.  The key is given to us with the advertisement data, okay, so just do that.  But where comes from the AES key?  It just comes from here, and same for them, it's the AES key, the alpha of the AES key,  is the UUID encrypted by login key and UUID.  But you know UUID, you just have to guess the login key.  You know the plaintext, you know the ciphertext, you know a part of the key, you just have  to brute force six hexadecimal characters.  Thanks.  No, so obviously, they don't use any Bluetooth low-energy encryption, they can be used.  So we, but no, even if you use MD5 checksum, your AES key is not 60-byte length, the charset  of the key is not large at all, and obviously don't use sensible data to generate public  data in a secure way.  So here, maybe I can do something with that.  So we have a SDK, obviously the mandatory part is that an inbound device should not  be able to communicate with the device.  If you bond your phone, only your phone on your account, on the SDK cloud integration,  can communicate with the lock of the device.  But we have two vulnerabilities, we have a six-character string, we have the same string  used to create sensible, accessible data, okay, so we can have a decryption of all communication  on the fly or offline, as you want, and obviously we can interact with a device without any  user or cloud interaction.  Thank you for that.  So of course, I have done some responsible declosure, but just look, just go to two steps  to weaponize it.  So the first is optimize the brute-force algorithm, thanks Ashcat.  Find some Bluetooth parameter, analyze an open uncheck, or whatever, or the request  that you want implemented in your client, and obviously, open Sesame.  I will not release the script, but I will show you.  So, I'm quite late, so I will advance a lot, so we have to pair our phone with the lock,  so thanks to that, okay, we can open, and when we open the door with the application,  we have a log inside the application, okay?  So let's go the attack.  So here, I have found the login key, I brute-force the login key, of course, I have found it,  and once you found it, you have just to, you have everything, every string, because lock  sent to them, so you, sent to you, so you can use it to open the door.  So in less than 20 seconds, I can open the lock, only with that.  And obviously, no log at all inside the application.  I have confirmed the vulnerability with another device, so it's just a little drawer, it's  the same vulnerability, and in a few seconds, I can open it.  So the vulnerability doesn't affect only one device, it affects all devices with the  Bluetooth SDK.  Okay, so I know my talk is long, sorry about that.  So of course, I have tried to do a responsible disclosure for the physical vulnerability,  so they don't really take me in consideration, you will say, yes, of course, it's a Chinese  company, yes, okay, okay.  So I came back in September about Bluetooth vulnerability, and they said to me, go to  the police station, to, okay, I just want to say that you have a vulnerability, I don't  want the police station, okay.  The most fun part on the manufacturer is that you have, they have a blog, obviously, where  they talk about security of connected lock, so things, but we can do some Bluetooth attack,  we can do replay attack, and physical attack, it's possible, on your lock.  Thanks for that.  I quite finish.  So for the BLE SDK creator, I have failed to found the above multi-platform on the SACMail,  the customer support doesn't trust me in September, but thanks for me and for them, it was much  better in February, so you can have, you have the timeline on the screen.  So there was really great, I want to say thank you to them, because they authorized me to  give the talk, despite of the critical vulnerability, and they paid me the reward, and I have, I  have the maximum reward of the Ubuntu platform, so really thanks, it was a very great exchange.  So for manufacturer, of course, please use Backpack Ties, listen security researcher,  and for you, so we, I don't have any solution, perfect solution, if you want to choose some  smart object, well, do your own research, do it for reputation, or anything, I don't  have a perfect solution for that, sorry.  Thanks for your listening.  Okay, we have a little bit more than three minutes for questions.  Any raised hands?  Thank you for the talk.  On the first part, how much time do you need to drill the hole, and do all the necessary  steps to plug your attack card, or plug your stuff to opponent?  To drill the, the planet?  Sorry?  To drill the planet?  Yes, to connect your, well, it wasn't an attack card.  In two minutes, I think, on the door.  So two minutes plus the time, like, was, like, I don't know, five, ten seconds?  And three, three minutes, you're in, okay, awesome.  Of course, the pallet, you have to replace it, so you just buy the same lock on your  e-commerce website, and just put glue and replace your, a new pallet, of course, because  if you make a hole, you can see the hole.  No more questions?  Okay, thank you, Thomas, very good presentation.  Thank you.  Thank you all.  A round of applause for you.


url: https://www.youtube.com/watch?v=yg_ix5NEErk
title: A COMPLETE Offlane Guide for Beginners and Advanced Dota 2 Players - Early Game
type: video
author: BalloonDota
ingestion_date: 2024-09-13
transcription_model: medium
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=yg_ix5NEErk",
    "title": "A COMPLETE Offlane Guide for Beginners and Advanced Dota 2 Players - Early Game",
    "description": "Immortal Dota 2 coach breaks down a complete Offlane guide on how to dominate the early game phase as an Offlaner using a specially created Offlane cheat sheet with a 5-point grading scale. \n\nGet CRACKED on Offlane today!\n\n-------------------------------------------------------------------------------\nBALLOONDOTA COACHING RATES \n-------------------------------------------------------------------------------\n(Short term coaching)\n50$ for 1 hour\n120$ for 3 hours (25% discount, 40$/hr)\n\n(Long term coaching) \n(recommended for cheaper rates)\n350$ for 10 hours (30% discount, 35$/hr)\n650$ for 20 hours (35% discount, 32.5$/hr)\n850$ for 30 hours (45% discount, 28$/hr)\n\n-------------------------------------------------------------------------------\nDOTA COACHING BY BALLOONDOTA\n-------------------------------------------------------------------------------\nFiverr coaching link: https://www.fiverr.com/yongy146/help-you-improve-in-dota-2-with-7400-mmr-coaching\nDiscord: BaLLooN#5243 \nDiscord Server: https://discord.com/invite/w4PWyXDV4n\nPaypal: siahcheonyisiahcheonyi@gmail.com\nPatreon: patreon.com/BalloonDota\n-------------------------------------------------------------------------------\n\n00:00 - Introduction\n00:58 - Won Lane Subsection\n6:54 - Dota2ProTracker\n7:12 - Lost Lane Subsection\n10:43 - Conclusion\n\n-------------------------------------------------------------------------------\n\nDocument link: https://docs.google.com/document/d/12Vj_aOIJopll2lKLuLjx05wiaICaRwhu/edit?usp=sharing&ouid=106671014916816226730&rtpof=true&sd=true\n\n-------------------------------------------------------------------------------\n\nDota2ProTracker\nhttps://dota2protracker.com/\n\n-------------------------------------------------------------------------------\n\n\u266a Memories (Prod. by Lukrembo)\nLink : https://www.youtube.com/watch?v=jbnMSWrLuMs\n\n\u266a Cloud (Prod. by Lukrembo)\nLink : https://www.youtube.com/watch?v=v1XgHCIdDc8\n\nMusic: High Tide by Hotham is licensed under a Creative Commons License.\nhttps://creativecommons.org/licenses/...\nStream: https://linktr.ee/hothammusic\nFree Download: https://hypeddit.com/hotham/hightide\nSupport by RFM - NCM: https://bit.ly/3U7XiHI\n\nMusic: Don't Go - tubebackr & Scandinavianz \u200bis licensed under a Creative Commons License.\nhttps://creativecommons.org/licenses/...\nhttps://soundcloud.com/tubebackr%C3%A2%C2%80%C2%8B | https://links.fanlink.to/tubebackr\nSupport by RFM - NCM: https://bit.ly/2xGHypM\n\nMusic from #Uppbeat (free for Creators!):\nhttps://uppbeat.io/t/fass/furious\nLicense code: JNBUADJFRTJIFFRA",
    "channel_url": "https://www.youtube.com/channel/UCYldE7tGQHjNwIVHQ7bDNoA",
    "duration": 745,
    "channel": "BalloonDota",
    "uploader": "BalloonDota",
    "upload_date": "20240528"
  }

  This text was transcribed using whisper model: medium

   Hey guys, so what I have here is the Dota Phases step-by-step process assessment sheet for the  offlane early game phase. For those of you that have watched my carry DPSP cheat sheet, this will  be similar to that. The only difference is we are now looking at the offlane okay and specifically  the early game phase. I also have the complete DPSP sheet for the offlane role but the laning  phase and the mid game phase will be exactly the same as the carry cheat sheet so you can get it  from that video instead. Alright, the biggest difference will be the early game phase, how it's  played. If you like my content, please consider clicking on the like, comment and subscribe  button. Also, if you're interested in getting coached by me, do check the description box down  below. So let's dive right into it. For this cheat sheet, I've separated it into two subsections.  The first subsection will be where you win the lane okay so we are trying to push the advantage  in this phase and the second subsection will be where you lose the lane so you're gonna recover  and play like a post one carry. Alright, so the offlanes early game phase will normally begin  when you manage to break the enemy's safe lane tower. So this will happen around the 8, 9 or 10  minutes. Of course, if you are more proficient in playing the lane, you can dominate the lane earlier  so typically 6, 7, 8 minutes is possible as well. Some even going as early as 5 minutes but the  moment you break the safe lane tower, we're gonna go towards the focus on what you want to do in the  early game phase. Okay, so when you manage to break the tower, the first thing you want to look at is  you want to ensure the enemy's safe lane is always pushed out, right? You want to make the enemy  safe laner get kicked out of lane because if they go into lane, they're gonna have to go across you.  Okay, so the prioritization of pushing out the safe lane is so important because it applies pressure  and when you apply pressure, the enemies have to keep coming to retaliate against what you're  doing in the lane. So what tends to go wrong is people most of the time will get interrupted so  they start looking at fights that are not purposeful and they start wasting a lot of time around the  map. So make sure you are always pushing the lane, right? And you only leave to the other lane if  there's like a clean-up fight or a tp into an important fight. Otherwise, do not leave the  enemy's safe lane area. Okay, next we go into the warding around the enemy safe and enemy jungle.  One of the most easily overlooked thing that cores do not do in low MMR, I would highly suggest that  you do it because a lot of times if you are always reliant on your supports to plant the wards and  stuff, if the supports are not around or they have not bought the wards, now you have essentially  given up control of what could have been if you just warded it up yourself. So once you manage to  break the tower, first thing that goes to mind, buy your wards. Every time you open the shop,  you buy tps, you buy clarities, right? You buy your observers and buy however many sentries you  buy as your observers. So you're gonna have to protect your wards. So if you have vision,  you're going to ensure your safety around the enemy safe lane and you can keep farming around  the area. Okay, now we move to invading the enemy jungle. This goes hand in hand with the earlier  point. So you want to ward the enemy jungle. In order to do so, you can invade the enemy jungle  as well. Okay, so you want to walk into the enemy jungle to establish control and you want to hunt  the enemies with or without your teammates. Of course, you have to factor in how much information  you have on the map. So map awareness needs to come into play. Okay, make sure you are always  going into the enemy jungle, taking away the safe lane carry's farm from the enemy side,  kicking them out of the entire area and establishing your control there. Okay, ensure you don't die as  well. Now we go into the fourth point. So all of this, you will notice that it happens after you  break the tower and after you invade the jungle. Establish your control around their jungle,  ensure the safe lane, enemy safe lane is always pushed in. So you want to take away the resources  from the enemy carry and their teammates. So once you break the tower, normally you're the strongest  hero in the game because you will already have your ultimate most of the time, right? You will  have a lot more net worth than the opposition and you'll have a lot of vision set up yourself.  So you'll deplete the enemy's farm and always select the correct jungle camps, meaning you want  to move forwards into the enemy's jungle camps where you can, instead of farming backwards,  right? You want to lead to the jungle camp that's closest to the lane rather than the jungle camps  that are far from the lane. So that always ensures that you proceed forwards, push the lane in,  farm the jungle camp and you repeatedly do that over and over again until the play happens at  another lane where you TP to or you manage to see a kill with the vision you have set up yourself.  Okay, so we go into protecting your wards. Alright, so once you plant wards in the enemy's jungle,  there are cleaves, right? Plant on their cleaves, someone is on the cleaves. So you want to protect  those wards with your own sentries, with your presence and you want to call for supports for  backup from your side to come and invade the jungle with you as well. So if you manage to  always protect, it's going to be ensured that your wards will never be de-ordered because with  the advantage you have with the enemy safe lane constantly pushed in, with your control and  presence around the entire area, the enemy can never return and take over the lane back again.  Okay, now we go into connecting the dots. So connecting the dots will refer to how well you  connect from waves to camps back to waves and camps again. So if you want to get a 5, you want  to make sure that you are not pausing in between. So you go from waves to camps, always pre-planning  your route beforehand. Next we go to maintaining control over enemy safe lane and enemy jungle.  Okay, so this again is relatable to taking away resources, relatable to the three pointers here.  Enemy jungle warded, invading enemy jungle, keeping enemy safe lane pushed out. You'll then  maintain control, meaning once you have done all of this, you don't want to leave, right? The moment  you leave, what's going to happen is the enemy safe lane will come back into the game. Okay,  so you need to maintain the control you have over and you do not give back the control you have  established earlier on. Alright, threat identification. When you're invading the  jungle and controlling their enemy safe lane, of course in turn will come threats. So I have a lot  of students that when I tell them, how come you're not pushing forwards, right? And their typical  answer will be, oh but it's on the enemy side, I don't see any vision on the map. And then immediately  five seconds ago, we have just seen like one hero show top, three heroes show mid. These players do  not see that what happened five seconds ago is the information they need to decide on what happens  now, on what they do now. That is the threat identification we want for these players to  understand. So your farming path selection, if you can go forwards, always pick forwards. If you can't  go forwards, then you'll pick backwards. So you'll base this off map information, vision, awareness,  the words you plant, control, lead, your levels, a lot of factors, right? So make sure you understand  what will kill you and what cannot kill you. Then play around that, push your limits as far as you  can. Lastly, usage of scan for a winning lane. So when you push forwards, let's say you're playing  to an area that you have no vision, you want to walk up to your high ground to plant a ward on the  cliff. You want to push a wave without knowing what's behind and the map is black. Then you'll  abuse the scan behind the wave. So the scan will tell you if the wave is dangerous or not. Okay,  these are all like global criteria for every role. How fast you kill creeps, how well you identify  whether you die or not and how often you use scan. Before we continue with this video, I would like  to quickly introduce to you Dota 2 Pro Tracker, the top Dota 2 website to get your resources from  about up-to-date meta builds and hero picks. If you are not already using Dota 2 Pro Tracker to  learn more about the game, be sure to check it out. With that said, let's get back to the video.  Okay, now we go into the losing lane. So when you lose your lane, on the other hand, we are looking  at ways for you to recover, right? So instead of pushing your advantage earlier, early on when you  break the tower, now you're playing from a scenario where you fail to break the tower. So  these cases will happen when your support goes missing. When your support is like doing something  else somewhere else and now you're left with a 1v2 scenario in the lane that you cannot win.  In cases like this, you will fall into recovery and you'll play very similar to your post-1 carry.  Okay, so what I mean by this is, first we are looking at how well you select your farming route.  When you lose the lane and you can't push forwards because forwards will mean death,  now we are looking at farming backwards. So we are looking at the ancient camp,  we are looking at the triangle and we are looking at safe farm near our tower. Okay,  and we're also looking at pulling the big camp for the wave to push back to your tower.  So ensuring that you pick the right farming route, say you're a tight hunter, you go smash ancient  creeps instead of big camps. If you are X, you also pick ancient camps, right? If you're playing  like say death prophet and you can't play ancient camps, you're gonna play big camps. So how well  you select your farming route, forwards, backwards, ancient speed camps, reading the timer for the  ways to push back to your site, very important factors. Okay, now we go to connecting the dots.  So same thing as before, whether there are pauses or not, whether you're maximizing time,  right, or you're wasting time. Normally you want to prepare your movements like five seconds ahead,  three seconds ahead, based on what you see on the map. If you prepare on spot, if you try and execute  things on spot, you're gonna be slow. Example, I push a wave, now I'm thinking about what camps to  go. Essentially, you're gonna be wasting a few seconds there. However, if before you even pushed  out the wave, you know, okay, after this wave, we see a camp, we see a camp there, we see another  camp, we see the next wave coming. So this, all this will go together to make up the bigger picture  of not wasting time. All right, so amount of interruptions present, say you're like recovering,  if you proceed to like go help your team and you die and turn, or you show to a fight that's not  good and you just wasted time, you have essentially interrupted yourself from recovering, so you're  too slow. All right, so no chasing for kills, don't trade if there's no point in trading,  just push wave and farm, push wave and farm. So time taken to kill creeps, same as before,  using our spells, right, how well, how fast you kill creeps and all that. Clarity and TP's, same  thing. Ability to identify open lanes, same thing. So two TP's, two Clarity's, mana always running,  all right. Open lanes, so we're always gonna be TPing to these lanes, we're not gonna be walking,  if the lane is too far, just TP. Because right now the plan is to recover, when you're recovering,  you gotta speed up your farm. Okay, cleanups, as mentioned, show up to cleanups, don't show up to  not cleanups, right, show up to good fights, pick the right fights, don't show up to fights that are  like with intent to help and you die in turn, or don't show up to fights that are like a waste of  time when you can be recovering with your farm. Track amplification, make sure you're not dying  when you farm, usage of scan, you gotta ensure you're always safe when you push waves, when you  hit camps, when you go high ground, when you push into your jungle, right. And finally, from both  of this winning and losing, you're gonna go into how fast you take to hit your item timing. So  normally the item timing for an offlaner will be something like a BKB, a blink dagger, but if the  game pacing is very fast, then your item timing will change, your item timing will go from like  a BKB to a blink dagger, it depends on how fast the game is progressing. What is the key item  that tells you to start fighting? In a slow game, there will be a BKB, in a fast game, there will  be a blink dagger. So how fast you relate to the game pacing will determine what items you will  buy as your item timing. So that means you start like grouping and all that stuff. One key note I  want you guys to understand is, even if you have lost the lane, you can still go back into a winning  lane, meaning this criteria, all of this farming recovery route can become a winning lane again,  can go back to this state, even if it's slower. Let's say you lost the lane, suddenly you get  ganks from your teammates to win the lane for you, and you manage to break the tower by like 13  minutes, 12 minutes, you will still go into the winning lane state. So do not assume that I've  lost the lane, I have to lose the lane forever. No, a losing lane can become a winning lane.  Subsequently, a winning lane can become a losing lane. Okay, so let's say you try and you broke  their tower and you try and push forwards, but they retaliate and now you die, or you can no  longer push forwards because there's too many threats, and now you're forced to play backwards.  Then you'll farm your jungle camps instead, and you're gonna go into the losing lane state.  Normally, if you do it right, you're gonna mostly win the lane and you're gonna stay with the  winning criteria instead. Okay, so I hope this video makes sense. There's also a total score  for you in case you win lane or lose lane or both, and you can summarize your win in the end.  Okay, any questions, you guys can feel free to leave them in the comment box below. I try my  best to answer to every comment that's being posted. This DPSP cheat sheet will be in the  description box down below. Thank you for supporting my channel. I'll see you guys again. Peace.


url: https://www.youtube.com/watch?v=QruSCKPuUgI
title: Gain MMR With These Concepts: Increasing Leads, Progressing Game, & Highground
type: video
author: Carbonyl DotA
ingestion_date: 2024-09-13
transcription_model: medium
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=QruSCKPuUgI",
    "title": "Gain MMR With These Concepts: Increasing Leads, Progressing Game, & Highground",
    "description": "I'm Carbonyl_DotA and I'm a 7k MMR coach. I make educational DotA YouTube content. If you're interested in my paid coaching, please join my discord linked below.\n\nPart 1 in this Series: https://youtu.be/rxFWNPpB7gw\nThe Box video: https://www.youtube.com/watch?v=WVnzQN1u-o8\n\nCoaching Discord: https://discord.gg/fhdXsaEsas\nYouTube Channel: https://www.youtube.com/channel/UC8Rv6PXWZ5ERqoLlUsIyQ8w\nEmail for business opportunities or requests for coaching: carbonyl.dota@gmail.com\n\n#Carbonyl_Dota #Dota2\ndota coaching,dota coach,immortal dota,carry coach,carry coaching,support coach,support coaching",
    "channel_url": "https://www.youtube.com/channel/UC8Rv6PXWZ5ERqoLlUsIyQ8w",
    "duration": 498,
    "channel": "Carbonyl DotA",
    "uploader": "Carbonyl DotA",
    "upload_date": "20231229"
  }

  This text was transcribed using whisper model: medium

   Hey guys, today we're bringing you part two in the series of what you need to know to improve at Dota 2,  talking about increasing a lead, progressing the game, and going high ground.  Progressing the game is taking objectives for your side. Objectives are towers and Roshan.  Alternatively, you can progress the game not by taking an objective, but by setting up the map,  gaining map control, such that you can then increase your lead.  Increasing your lead is accruing more gold and XP than your opponent over a period of time.  Sounds pretty simple.  The thing with taking objectives is it permanently increases your map control,  or in a sense, permanently lessens their map control, their area of control, the areas they can easily be in.  If you win a fight and you take a tower, that's like permanent map control, or at least lack of map control for their side in that area.  If you win a fight and then you go farm at your side of the map, and you jungle or whatever, and you don't take objectives,  then the game just continues as is. You haven't really gained anything. You haven't really progressed the game.  They could always come back later. Stuff happens all the time.  So if you're not progressing the game when you're ahead or you want to fight,  then you're not really going to win consistently, I guess.  Things are just going to become more random because the games are going to get longer looking at you low MMR players.  So we've talked about how these things are linked.  The best play after winning a fight is to take an objective.  If you can't because your lanes are bad, then what you need to do after winning a fight is immediately fix your lanes.  This sets up the map such that the next fight you take, you can take an objective,  or just sets up the map such that it gives you the information you need to then know if you can safely take an objective even if they respawn.  Now, let's talk a lot more about how we set up the map and what playing from ahead looks like and how you can try and play from behind.  This is called what I call the box. I have a full video on this.  I highly recommend you check it out. If you haven't seen it already, I'll link it in the description.  But we're going to cover the basics here because it's so important and it kind of ties into these other concepts anyway.  And just to define the box, the box is the losing team's area of control.  So, for example, just in the thumbnail portrait here, you can see that the dire team is winning and the losing team is what's within this red line here.  This is the losing team's area of control. The dire team obviously has a bigger advantage here.  So just keep that in mind. The dire is trying to shrink that box smaller, take objectives, make it smaller.  And the radiant wants to push that out. The box comes down to a couple fundamentals.  So a team at the lead cannot control the entire map.  And by the entire map, I mean all three lanes and all the jungle area.  You just can't. It's too big. You don't have enough heroes.  When ahead, the team that's ahead wants to fight the enemy with their already superior level and item advantage.  And when you're behind, you want to dodge them because the enemy has a superior level and item advantage.  Obviously, things like cooldowns of high impact spells or items can affect whether you want to fight in that exact second or not.  But that's the general idea.  And then the map control and information gained from the lanes being pushed in for either side, really.  Like it's good if you're losing, because it's good if you're winning.  The more you can get the lanes in, the more information you have to dodge bad fights if you're losing or to choose good fights.  And when you have the lanes pushed in, it forces a response from the enemy because they want to get that golden XP or it forces an obvious non-response.  If you're pushing in a tower and creeps are dying under that tower and nobody on their team's farming it,  that's kind of a key indicator that they might be doing something important somewhere else,  because otherwise they wouldn't be letting those creeps die for free.  So we want to tie in progressing the game here with this box idea.  When you've got the lane shoved in and you're trying to reduce the enemy's area of control, that allows progressing the game to happen much easier.  You're applying the pressure, you're controlling where the enemy goes.  When you're ahead, you want to corral the enemy into the area behind their existing still standing towers.  Once you've done this, objectives will fall easier because you'll have good information for where they are.  And a lot of times things like Roshan can be free because you've contained them.  They're in a small area and you can take Roshan whenever you want and they either have to like try and smoke  or it'll be really obvious that they're coming to stop you and it'll set a good play for your side.  Another key, while you're doing this box concept and keeping the box in, you want to kill heroes that leave their box.  So if you look again just at this thumbnail picture that is on the right here.  From the Dyr's perspective, this Tusk walking into the triangle or this Drow walking into her jungle is not allowed.  It's outside the Radiance area of control and you can just kill them.  So just real quickly on how to do that, and I go into a lot more detail in that video,  but having good wards when you're ahead, scouts when the enemy is trying to leave their box,  and then you just need to have the means and the discipline to catch and kill those heroes when they leave their area of control.  People do this all the time, especially at low MMRs.  The thing is at lower MMRs, the winning team or the team that's ahead doesn't really capitalize.  The higher MMR you get, the more often you're capitalizing on these mistakes that your opponents are making.  The losing team should be trying to spread out and they do want to increase their area of control,  but they want to do it away from wherever the opponent is.  And remember, the opponent cannot control the entire map.  Even if you're ahead, they can't control the entire map.  So if you see them all in one area, you can move out the other way.  If they split up too much, you can kill the people that try and split up.  And you want to shove these lanes out away from the opponent.  And in pubs, this should really be you, because your teammates just won't do it well a lot of the time.  So that's progressing the game, and we know how that ties into taking the lead.  We want to progress the game by taking objectives when possible.  We want to use the box to get map control and control where the enemy can go.  We want to have good vision up.  Eventually, this is going to lead into trying to go high ground.  How do you go high ground? Well, it's dangerous.  Everybody complains about it on Reddit and some heroes it feels impossible against.  So really, it should only be done with a significant advantage.  So you're up in hero number and or you have the Aegis.  Of course, if you're like 50k ahead, it doesn't really matter.  But in general, you want to have a significant advantage.  You also really need to be aware of the possible buybacks and what your plan is if they buy back.  It doesn't need to be elaborate.  If they buy back, do we back right away? Yes or no?  And it can depend on the hero.  So like in this screen cap below, if the Tusk buys back, maybe not a big deal.  We can keep going high ground.  If the Spectre buys back, that probably is a big deal,  but we still have Aegis, so maybe we're still okay with it.  It's just something you have to think about,  and it'll just depend in your game and the heroes as to what those buybacks mean.  It's just really important to know and not throw, to respect the buybacks a lot of time.  Usually the best play is to respect the buyback.  Push high ground if they buy back, back off, farm it up a little bit, and look for the next good play.  And the last thing is don't push into those key high ground heroes like Tinker and Sniper.  Those heroes are just impossible to push high ground against.  So just play the box, play the map and control it.  If they leave the box, if they leave their box, which a lot of times will be their base  if you're really far ahead because you've shrunk them all the way down,  if they leave their base, that's when you fight them.  Any fight outside the base against these high ground defensive heroes like Tinker and Sniper is usually good,  versus trying to push into their base is where they have supreme advantage.  That is the end of the video, guys. Thanks for checking it out.  I will hit you with part three, which is going to be on making good plays pretty soon, and I'll catch you later.  Thanks for watching. If you liked the video, give it a thumbs up.  If you haven't already, sub to the channel.  And if you want to be coached by me, check the link in the video description.  You can join my Discord there, and there's all the information there on how to sign up.


url: https://www.youtube.com/watch?v=sjsnuirLyKM
title: Rust stole C++'s best features
type: video
author: Let's Get Rusty
ingestion_date: 2024-09-13
transcription_model: medium
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=sjsnuirLyKM",
    "title": "Rust stole C++'s best features",
    "description": "In this video, we dive deep into the best feature Rust stole from C+.+ I'll break down exactly what these features are and show you how the creators of Rust have innovated on top of them. Stick around till the end where I'll discuss the biggest challenge Rust faces in its quest to compete with and potentially replace C++. \n\nFree Rust training: https://letsgetrusty.com/bootcamp\n\nChapter:\n0:00 Intro\n0:18 1st feature\n3:27 2nd feature\n5:33 3rd feature\n7:27 Rust major limitation",
    "channel_url": "https://www.youtube.com/channel/UCSp-OaMpsO8K0KkOqyBl7_w",
    "duration": 527,
    "channel": "Let's Get Rusty",
    "uploader": "Let's Get Rusty",
    "upload_date": "20240912"
  }

  This text was transcribed using whisper model: medium

   Rust stole C++'s 3 best features.  In this video, I'll cover exactly what these features are, and more importantly, how the  Rust creators innovated on top of these features.  At the end, I'll also explain the biggest limitation Rust has to overcome in order to  truly compete and potentially replace C++.  The first feature Rust stole from C++ is, ironically, the resource management model.  When C++ was first introduced, the creator, Bjorn Strashtrup, came up with an extremely  useful design pattern called RAII, which stands for Resource Acquisition is Initialization.  The idea is that resources like heap-allocated memory, database connections, and file handles  should be tied to the lifecycle of objects.  When an object is created, it should acquire the resources it needs.  This is done in the object's constructor function.  And when the object is destroyed, the resource should be released.  This is done in the object's destructor function.  This design pattern leads to reliable resource management, cleaner code, and, most importantly,  it reduces the risk of resource leaks.  That's why it's used throughout the C++ standard library.  In fact, OFstream already implements RAII internally, so we can use it directly to manipulate files.  To automatically clean up heap-allocated memory, we can use the unique smart pointer from the  standard library.  And to automatically manage database connections, we can use third-party libraries.  RAII is so useful that Rust took this design pattern and made it a core part of the language.  Similar to C++, the Rust standard library extensively uses RAII.  We can manipulate files and the handle will automatically be released.  The box smart pointer is used to automatically clean up heap-allocated memory.  And we can manage database connections using third-party libraries.  But Rust doesn't stop there.  It provides two major improvements on top of the traditional RAII pattern in C++.  First, unlike C++, Rust prevents you from accidentally shooting yourself in the foot.  In C++, you can bypass the RAII pattern and allocate memory manually using the new and  delete operators.  This can lead to mistakes like use after free errors if you attempt to access a pointer  after calling delete, double free errors if you accidentally call delete twice, and resource  leaks if you forget to call delete.  These bugs can and do compromise the stability, security, and performance of software.  Microsoft famously reported that 70% of vulnerabilities found in their products were caused by memory  safety bugs.  Rust avoids these pitfalls because it doesn't have operators like new and delete.  It only allows you to allocate resources using RAII constructs.  The second major improvement Rust provides on top of the traditional RAII pattern is  automatically managing references to data.  In Rust, the compiler enforces the validity of references.  When a value is deallocated, the compiler will prevent any references to that deallocated  value from being used again by performing compile-time checks.  This means references are guaranteed to point to valid memory.  So you don't have to worry about infamous bugs like null pointer dereferences, use after  free errors, and data races.  The RAII pattern in Rust is called the ownership model, and the extra compile-time checks that  ensure the validity of references is called the borrowing model.  Together, they ensure that resources are automatically cleaned up and references are always valid,  eliminating an entire class of memory safety bugs.  The second feature Rust stole from C++ is the principle of zero-cost abstractions.  This principle can be summarized with the following phrase, what you don't use, you  don't pay for, and what you do use, you couldn't have hand-coded any better.  This means that high-level abstractions like generics and collections should not impose  any runtime overhead or performance penalties compared to code using low-level abstractions  like loops and counters.  This leads to a great developer experience while preserving lightning-fast performance.  In this C++ example, we create a vector of integers and then use a for loop to find the  greatest element in the vector.  This code includes loop initialization, condition checking, and element comparison, making it  less readable and more prone to errors.  By using the iterator abstraction in C++, this code becomes a lot simpler.  Now, we just have to call the maxElement function in the standard library.  The iterator abstraction encapsulates iteration and comparison logic, making the code cleaner,  more concise, and less error-prone without sacrificing performance.  Here's how we would write the same code in Rust.  First we turn a vector into an iterator by calling the iter method, and then we find  the greatest element by calling the max method.  In this example, we're actually using a few zero-cost abstractions.  The first one being the iterator abstraction.  The second one is the option enum, and the third is pattern matching.  The beautiful thing about Rust is that it builds on top of the zero-cost abstraction  principle by further emphasizing memory safety and thread safety.  For example, if we go back to the C++ example and call the maxElement function with an empty  it would lead to undefined behavior, because we would get back an object that is not safe  to dereference, but in the next line we are attempting to dereference it.  In Rust on the other hand, the max method returns an option type, so if we call it on  an empty vector, it would simply return the none variant.  The option type forces us to check whether the return type is the sum variant or the  none variant, which makes our code a lot more robust while preserving blazingly fast performance.  The third feature Rust stole from C++ is generic programming.  In C++, generic programming is implemented through templates.  Templates allow you to write code that works with any data type, providing flexibility  and reusability.  This template function called print takes a single parameter of generic type T. The  generic is also constrained by the printable concept.  Concepts in C++ define requirements that a type must satisfy.  In this case, for a type to be considered printable, it must be able to output to standard  and the operation must return a reference to Ostream.  By using this concept as a constraint on the generic type T, the print function ensures  that it will only be instantiated for types that can actually be printed.  Rust took the idea of generics and modernized it.  In Rust, we have generics which are inspired by C++ templates, but with two key improvements.  First, notice the clean and concise syntax.  Rust generics are more intuitive and easier to read.  Second, Rust integrates generics tightly with its trait system.  In this example, we're explicitly stating that the generic T must implement the display  trait.  This is similar to C++ concepts, but it's been a part of Rust from the very beginning.  Because generics and traits are tightly integrated in Rust, you'll get clear error messages  when you use a type that doesn't meet the requirements, which has been a historic pain  point with C++ templates.  Rust's approach to generics also maintains the zero-cost abstraction principle we discussed  earlier.  The compiled code is just as efficient as if you had written separate functions for  each concrete type, because this is actually what Rust does automatically for you at compile  time.  Moreover, Rust's ownership system applies to generic code as well, ensuring that even  generic functions are memory safe and thread safe.  By refining C++'s template system, Rust has made generic programming more accessible  while maintaining its power and performance benefits.  Now while Rust has made significant strides improving on C++'s features, it still faces  a major limitation, ecosystem and compatibility.  C++ has been around for decades and has built up a vast ecosystem and wide-ranging industry  adoption.  C++ also has near seamless compatibility with C, meaning you can run your application on  virtually any operating system or hardware platform.  Rust, being a newer language, is still building its ecosystem.  And while industry adoption is rapidly growing, it's still in the early stages.  And Rust's compatibility with C while improving isn't as seamless as C++'s.  This ecosystem gap means that for many existing large-scale projects, or specialized industries,  C++ remains the go-to choice despite Rust's safety advantages.  For Rust to truly compete with C++, it needs to continue growing its ecosystem and improving  its compatibility with existing codebases.  Despite these challenges, I'm very optimistic about Rust's future.  As the ecosystem grows and compatibility improves, I think the rate of adoption will only increase.  If you need help becoming a Rust developer or are just curious about the opportunities,  make sure to get your free Rust training at letsgetrusty.com slash bootcamp.  Hope you've enjoyed the video and remember to stay Rusty.


