 Hello, and thank you all for joining my session. This is one of my favorite talks because, well, we get to do a whole bunch of really fun demos. But anyway, we'll get into that. Before I get underway, I would like to acknowledge and pay my respects to the traditional owners on the lands on which we meet today, including the Wagonja people, who are the traditional owners here in Narrowmine, where I'm presenting from. And Narrowmine, for those that don't know, is a little country town in country new suburbs. For those that I don't know yet, hello. My name is developer Steve. I'm one of the senior developer advocates at Sneak. I'm previously, well, I've been a developer advocate or a developer evangelist for many, many years now for companies like PayPal, Braintree, Vazero, Telstra, and IBM. And well, one of the things I love the most about being an advocate or an evangelist is I get to come and geek out with amazing communities like this one. And in particular, I mean, we all learn and grow and share knowledge together, which is always great. And I mean, that's pretty much the main core of open source as a whole as well. So massive open source fan and contributor. And so I've been literally coding since the age of eight, back in the days of QBasic, for those that remember it, there wasn't a whole lot of like open source libraries and dependencies back in those days, or indeed wasn't a whole lot in the form of like open source communities. There's a little bit, but through what I call my developer origin story, if you will, one of the things I've always loved doing as a technology adopter and technology enthusiast is just building application that changes someone's lives in so many different ways. And indeed spending time through digital agency and even being a CTO, building an application that just changes someone's life in that tiny little way from being able to order food or a car service or entertainment or just be able to connect to each other. So if you think of like an iceberg and how usually you've got a small amount of an iceberg sitting in the water and then underneath you've got the majority of the iceberg, we can apply a software development lifecycle, LSL, SDLC in the same type of approach when it comes to deploying, building and maintaining applications. Something I've always been mindful of through my developer origin story is just what else is being deployed in that stack that I'm releasing my code along with. So if you think of like open source platforms like WordPress, Drupal for example, or indeed some of the NPM ecosystem components, so many times like as devs, as technology people, we deploy these applications which sometimes have some things hiding in them that we're not even aware of. Indeed through my developer origin story history, there's been so many times where I've had to go back and clean up an application because there was that one component which lets something into my stack or let a malicious attack again control of my stack, which subsequently had some unwarranted things happen inside the stack from data integrity right through to running applications, root kits or whatever else inside my application. And again, if you think like from that whole user first approach, there's times where we will as developers at the code front level, literally just NPM install a particular thing or composer install a particular library with little regard to the security aspects of what we're utilizing and what we're doing. This is where encouraging development and developer teams to do that due diligence piece of understanding the components that they're using, but also the subsequent indirect dependencies which they're also utilizing as well. And special mention here too, and like I've been here, usually it's at like 2 a.m. where you're looking for a particular fix for this problem that you're having in the code and you find that thing on Stack Overflow or Reddit, that snippet of code, which you're not entirely sure what it does, but hey, things seem to work and now finally you can do that commit and go to bed. So many times where I've often then subsequently wondered, I wonder what that's actually doing inside my infrastructure. And this is where taking the time to do some due diligence sort of really pays off. Again, to protect those end users that we build these apps for, which is really, really important because those end users put their trust in us and their faith in the systems that we're building out that we keep them nice, safe and secure. We keep their data secure and fundamentally that you don't end up with that really big bill at the end of the cycle because something's using your cloud infrastructure for all sorts of reasons. I've totally been there before. But one of the things I love the most about the open source ecosystems is just the exponential growth that we see year on year. Like quite often there'll be that one library functionality that splits off and becomes a dependency that gets used across the holistic ecosystem, which is really cool because I mean, that's what open source is about, right? And as a product of the open source world like the learning, the sharing of knowledge and the community spirit, that is totally one of the things I love the most. One of the things we do see across ecosystems though is also the rise in vulnerabilities being discovered in these very open source packages. And again, if you think back to that iceberg view your open source code there or the open source code you're using for your code which sits above the water or on the surface of the internet, if you will, which is then the second level down in our iceberg view because your code is using open source libraries and dependencies to be able to do the amazing things that it does. Even platforms like Drupal and I'm not singling Drupal out in any way. In fact, the Drupal security program shout out to the Drupal security program folks because they do amazing work and are very fast in patching anything as a community, they will literally all come together and be able to identify a security researcher findings, be able to identify and validate and then quickly move to push out a patch in a release. But this is one of the platforms, open source platforms I've used in the past where one of the libraries or dependencies in the ecosystem has inadvertently let something into my infrastructure which then means going back and identifying, cleaning up and yet pushing out a release and well, essentially cleaning things up but this is something we see across a number of different platforms. And again, shout out to the Drupal security folks because they do do amazing work. This is a reoccurring issue now being looked at by governments all over the world. Indeed, through last year and this year we've seen the likes of the American government and even here in Australia, the Australian government look at ways to mitigate open source supply chain risks and security. So an example of that locally, and I love IoT things but the Australian government is now looking at ways to bring in some mandatory rules around open source and firmware on IoT devices. If you think like this isn't just commercial devices that govern and help things like agri-tech and logistics tracking, mining for example, this is also consumer ready devices. So those Wi-Fi light bulbs that you buy for like $5 or $10 now, they're so cheap and they change to so many colors but the firmware on those which I mean fundamentally basically have access to your Wi-Fi network. So this is becoming a potential attack vector for malicious attackers or malicious vectors to be able to get into your home Wi-Fi and do all have, well, essentially cause all sorts of mischief. And while that may just be a simple broker connection, IAC security whole of a topic. These, the guidelines the federal government is looking to adopt in regards to IoT devices is what's known as the ETSI standard which the UK government recently adopted as well. So this is one to totally check out. Actually, I also run the Oz IoT, a US IoT meetup group and we've got a security panel in a few weeks with somebody from the UK government will be on the panel who's also worked closely with the ETSI standard. So if you wanna find out more about this one total plug here, but if you wanna find out more, yeah, please come and join the session we'll be a little fun and also super interesting to see what the standard means, how it's been adopted in the UK and just, I mean, what it means to IoTists of all different levels, consumer, commercial, et cetera. Anyway, whole other thing, totally tangenting. But open source supply chains security is something we see through the open source world that comes in through the likes of and there's loads of examples on this but it comes in through the likes of like as a indirect dependency through event stream which introduced flat map stream in 2018, for example. So this was a library that got introduced into the NPM ecosystem through a social engineering hack called event stream. Now event stream was downloaded millions of times a week before it was eventually stopped but this basically created a gateway or doorway into so many iceberg stacks all over the internet. But it didn't stop there because we saw Electron Native very similar type situation but we saw Electron Native notify in 2020 which basically added a dependency to a library and three weeks later we saw the same thing again and three weeks after that we saw the same thing again. Each time the community would come together, identify the risk, do a release candidate we'd see the same injection or same type of injection then occurring for a multiple of weeks. This actually reached a point where the NPM organization or NPM group themselves put out an alert to say if you've got this installed you need to check your infrastructure pretty quick. So this has been a reoccurring problem and has so many flow on effects to well kind of everything around us from utility companies, even on the supply chain side of things, everything from utility companies to food distribution networks like so much downstream of this which is why I mean governments are taking that move to try and protect this infrastructure from becoming vulnerable. I want to do a shout out here too because I'm a big open source enthusiast you probably guessed that I may have mentioned it but one thing here is to recognize like the work that these open source community groups do and largely their passionate open source enthusiast volunteers that will contribute what time they can to the work that these groups do. So patching security bugs, for example there's sometimes a delay in the security researcher raising a vulnerability with that community group the group then coming together identifying the risk putting a strategy together and like how they're going to mitigate it push out a release candidate which then needs to go through testing there sometimes can be a delay from sometimes a few days up to sometimes a few years before before the security vulnerability is acknowledged and then a fix goes into place. So always remember, and I know you will do this I just like to highlight it but always remember to contribute back where you can particularly if you're using a particular library or dependency or just the work that somebody's done in the community, contribute back where you can just to add to the project and be awesome. I know you will do, it's like to mention it. And one of the ways we do that it's sneak it's through a program called sneak advisor. So basically this allows developers to be able to do some due diligence or technology adopters to be able to do some due diligence on the components that they're using. And in this report, you can actually see for a particular open source group you can see all the metrics around numbers contributors like security things being patched which gives you an overall package health score as you can see on the screen here. So this is a good way to understand the components that you're using. And likewise, this also gives the community an idea on how they're tracking as far as keeping on top of vulnerabilities coming in the number of contributors. And then if needed, the community can come together and sort of patch a whole bunch of stuff or put more effort or do a call out to be able to get more people involved. So actually if you are looking to get involved in some projects, this is a good way to work out which ones to get involved in and totally contribute back where you can even if it's just updating a read me or indeed just checking of release candidate fix that might be fixing a security vulnerability. Also shout out to the security researchers that contribute to the Node.js ecosystem vulnerability disclosure program that we also help manage as well because I mean fundamentally this keeps everyone nice and safe. Anyway, let's have a look at some apps. You ready to hack some apps? I have two that we're gonna be looking at today. So fingers crossed they both work. No, they both will work, they both will work. Anyway, this first one we're gonna look at is one for it's an NPM app demo app that we have on the Sneak GitHub. So as you can see here, you can try this yourself at home. Just please remember to don't take this to the production because it does have 61 node vulnerabilities in there. Now this is totally intentional. Again, not for production. Please try this at home. But these are intentional because fundamentally as developers, technology people if we understand the vulnerability at its core most base level, we're able to, well, we're able to not only mitigate that particular vulnerability type but we can spot them easier in the future because well, we know what to look for, we know how they work. So in the repository folder, exploits folder, you'll see here, there's a whole bunch of exploits to try on this particular demo. This particular one demo app is a to-do app. So really basic to-do app which you can run in Docker container, you can run on infrastructure. Although again, not really recommended, don't take this to production. And I'm gonna show you why. Actually, I'm gonna show you why I'm both ones but in particular this one. So the vulnerability we're looking at today on this demo is the marked package which basically, well, it's a cross-site scripting attack but inside the user input, it basically enables markdown to appear inside, well, the user entry, so the user data. So as an entry, I can basically go, this is a bold statement. And yes, it is. Actually, it's a partially bold statement. But anyway, the thing that I can do with this as an end user is, well, I can basically use markdown to create to-do list item entries which is kind of cool, kind of fun. And you can do a few things with markdown. The library that we're using, so all the library version that we're using is 0.3.5 which you can see here in the package manifest. The wrong window. The safe ones to use is 0.3.1 and anything below 0.3.6 as you can see here. So we're using 0.3.5 because I like to live dangerously. So one of the things you can do with markdown of course is links which look something like that. And essentially that's going to behave exactly as intended because well, as an input user or as a developer for this particular application, I want users to be able to enter links. And if I hover over it, like it's gonna take me to the intended destination, nothing untoward there. What's actually happening as part of the markdown library is it's trying to do some user input sanitization which you can see here inside the application. So I can set sanitize true, well sanitize to true as part of the call for the library which is as a developer, I mean, we always should be sanitizing input. So I mean, this kind of should be set by default to true. It probably is inside the documentation. Actually, I think it is. But what is actually happening is as part of the sanitize functionality is it's doing a whole bunch of character set matching to try and identify any untoward user input that we don't wanna see inside our application which is pretty important, not only for output input, then output that's gonna appear in the user's browser. But also if you were storing this inside a database, you don't want certain types of things to be injected into that database. So like SQL injection, for example. So in the case of this particular example, what it's doing is doing some regex and then also trying to match certain character types that we do not want in the user database. Of course, one of the attack vectors we see particular to a cross-site scripting attack is then using that same link functionality to try and inject some JavaScript which is a classic like a wasp attack vector method. You can see there, like trying to inject JavaScript inside a markdown link creation, it's not able to do it. So it literally creates a blank line as part of the user input. The other way to get around this particular attack vector is by URL encoding characters as part of the JavaScript injection attempt. So as you can see there, I'm using the same type of input or same type of attack vector approach, but I've got some URL encoded character sets as part of the user input, which of course the library sanitize functions able to detect that and it's able to filter that out. This particular vulnerability though is using or the way to get around it is to use an object type as part of the user input. So in JavaScript using this for example, as part of the with URL encoding as part of the input type is one way to get around well that's basically how this particular vulnerability works. So if I enter that now, you can see that's actually worked and that now becomes clickable and is able to call a JavaScript function like an alert box. So if I click that now, you can see it comes up with this alert box is a loading inside of a alert box. And yes, it is. Now there's a number of ways that a malicious actor would be able to use this particular function in particular with a browser input like this, like loading in stealing session information or loading in a key log for example, redirecting to a malicious website to do a whole bunch more damage inside the user's browser. There's a number of different ways that this particular function can be used to do all sorts of mischief. Anyway, let's have a look at another one. This time using Java. Any Java fans in the room? Woo, Java. So again, this is another demo app that we have on the Sneak Good Hub and please you can try this at home. There's full instructions on how to get this up and running in your environment. Just like before, we also have an exploits folder. So you can see there, there's a whole bunch of different exploit types that you can play around with as part of this demo application. So this time we're running inside Heroku. And what we're doing is using the zip slip vulnerability as part of the zip slip zip util library. And we've got a really good write up on this on the Sneak blog, which talks about how this particular vulnerability works and how it basically gets executed. So again, the zip file that we're going to upload is sitting in the exploits folder inside the Java group app on the GitHub. But essentially what this is, and I'm just gonna sign in, there's a few really good demo screen. I think it should have worked. Let me switch back, sign in. There we go. That should work now. Send me live demos, what can go wrong? So just like before, this is a basic to-do app. Of course, the slight difference to the other one is there's a login with a couple of vulnerability types in there too that you can play with. So what I'm gonna do is create a to-do list item entry. So demo to-do. I'm gonna set the date to random date, which is 1970s date. Ooh, 1970s. You can see there, it's just added to the to-do list, the demo to-do entry that I literally just created. So one of the things I can do with this application is upload files. As you can see in the upload files section, what we're going to do is grab that zip, slip, zip. Such a tongue twister. And basically upload that and inside here is where my attack essentially, well, here's where it starts to get interesting. Because inside that zip file, we've got a good.text file, which, I mean, sounds good. That's relatively good. But also you'll see the second file is a massive file traversal. And essentially we're going to inside the app replace the native to ASCII function inside the application. So you can see the native to ASCII function here as part of the application. And what that does is that user that to-do input that we just did, we're basically going to hijack that with something a little malicious. So if I choose that zip file, like so, then click upload, you'll see inside my files now I have the good.text file as anticipated. Now if I go and try and create another to-do list, entry item, so if I go testing. Just do testing again, there we go. And you create, you'll see now, instead of testing again, it's come up with more ha ha ha gotcha, which it totally did. And so that's this particular vulnerability for the zip util library or what we're leveraging in the zip util library is to basically hijack base functionality inside the application and do some malicious things. Of course, all that we were doing was hijacking the user input in this example, but there's a number of ways you can use a file traversal to edit files, take control of infrastructure. Indeed, I've seen file traversals before in the wild where whole infrastructure or applications have been hijacked and all sorts of root kits and malicious activity was going on. Again, this is something like you want to avoid because well, you've got to protect those users, but also it's going to send your cloud usage through the roof, which I mean, nobody wants. Nobody wants to be on the end of that particular bill. Switch back to the demo. So again, this is about protecting, taking the time to do some due diligence to protect those end users and protect your infrastructure. Like end users put so much trust in the applications you're building out and supporting. We need to take the time as technology folks supporting these applications, earning their trust, earning those end users trust to make sure they've got a nice, secure and safe experience. Of course in the cloud native world, like your application is way more than your code. And one of the things I love most about the cloud native world as a dev, as a dev ops, as a dev sec ops, is I can deploy applications super, super fast using very few lines of YAML for example. So if we look at Docker and containerization, there's been over 242 billion downloads of base Docker container images to date from Docker hub. And this forms the next part of our iceberg is the containerization piece of our SDLC iceberg view. And if you think about it, like there's so many vulnerabilities that we now see appear in the top 10 Docker base images consistently year on year, which kind of makes sense given what we just looked at with open source components, how vulnerabilities can surface in them. It kind of makes sense that we also see the same vulnerabilities appear in base Docker container images. The way to get around this with the base Docker container images, not only ongoingly scanning those base images, but also starting with the base possible minimal image and building up the components that you need or that your application needs as part of your deployment. Again, we need to keep those end users safe and keep that infrastructure nice and safe. The way I like to think about this is with great containerization comes great responsibility. I do love that meme. And the final piece of our iceberg is infrastructure as code, which, well, it enables me as a dev to be able to build out some really quick and fast infrastructure as I need it to appear as I need it to appear to run my application. But of course, one of the ways that we see vulnerabilities appear in things like IAC is misconfiguration being the number one cloud vulnerability type, which kind of makes sense when you think like all the ways that you can set permissions and control different aspects of the infrastructure. But we missed a really important piece to our whole iceberg view. And it's probably one of the most scary. Well, I'm gonna say that as a developer, as a long-time developer, is development environments are now also prone to the same vulnerabilities that we've literally just been talking about. Now, I won't go into that in this one, but we have seen the likes of, for those that are familiar with it, Homebrew, we're now seeing the same vulnerabilities appear in the Homebrew ecosystem, which again, kind of makes sense given that a lot of the components Homebrew uses for its extensions and indeed its core infrastructure are built from the same open source components that we see time and time again, vulnerabilities appear in. Something we did release, and there's a full write up on the link on the slide here, but we did release also for the VS Code or Visual Studio Code ecosystem extensions that we're now seeing vulnerabilities appear in as well. Now, this gets kind of scary because there was four extensions in particular that we identified. Now, important to note, the maintainers of these repositories have already patched the security findings that we've released because we raised a security issue, researchers raised security issues on the repositories. So thumbs up to the maintainers. But Latex Workshop opened a default browser, Instant Markdown, and I hadn't used this last one, but I swear it's real, RainbowFart, just some of the VS Code extensions that we've seen vulnerabilities appear in. So there's full write ups on the blog there. And if you check out my GitHub repo, I actually have a demo for Instant Markdown, which is probably one of the most scary out of that list. Essentially, the Instant Markdown vulnerability in the previous version allows someone to do a file traversal remotely on a developer environment. Anyway, I'm not going into that one now. So just in closings and takeaways, remember to always be scanning source code containers, infrastructure. Make sure you're scanning at that code front level, even if you have a nice IDE extension that you get installed or that your devs decide to use so that you can understand the risks on the code that you're not only deploying, but also just be identified ongoingly of stuff that's coming up that you beyond deployment. Because super important to be alerted when new things are identified. Just finally, I'm just going to do a shout out for the Sneak Ambassador program we recently launched, looking for more people to get involved with that. It's free to apply to and we can help you with speaker training or resources or whatever you need to be able to go out and basically build awareness for keeping everyone nice and safe, like end users, developers, et cetera. So if you want to find out more about that, hit up the link on the screen or reach out. Yeah, you can reach out to me on socials. I'm developer Steve, pretty much everywhere. And just finally, please remember to use your tech superpowers for good and remember to be excellent to each other. Thank you very much.