What makes for excellence in heart care? It starts with one of the most amazing teams of heart surgeons and cardiologists that I've seen assembled under one roof and the region's leading technology in a new $40 million facility. This is the nationally recognized Heart and Vascular Institute of Eastern Kentucky at Pikeville Medical Center. County Public Library is hosting a Sims 3 friendly magic show. We are gonna be doing for autism month Cody Clark magic sensory friendly spectacular. Essentially, I'm on the autism spectrum have been diagnosed since I was 15 months. So the show will use magic, comedy and storytelling to share that coming of age journey, but also it will be what's called sensory friendly and it will remove loud noises, bright lights and being that I'm disabled myself like a lot of the intended audience. I can further just things in real time as I get a sense of the audience's needs. Clark knows firsthand how sensory sensitivities can get in the way of enjoying a program. You'll get to see some pretty engaging stuff with props but in a more intimate place than like a 1000 seat theater. He's taking his expertise and using it to share a new kind of magic show. It still works as a family friendly magic show but now it's accessible to people who might not normally feel comfortable attending a public event at a big library. The magic show will begin at 5.30 PM on Tuesday, April 4th at the Pot County Public Library on Lee Avenue. My goal is if you wanna come to just enjoy a magic show with your family, you will be happy. And if you wanna learn more about what it's like to live with autism what exactly sensory friendly accommodations are you'll be happy there as well. It is free to attend and no registration is required. Reporting from Mountain Tom News, I'm Ethan Miller.


Oh, right. I see slides. I see things. I see a very quiet group this morning, more or less. So we'll just go ahead and get started. We've got quite a few things to be able to wander through today. So we've got our standard agenda. We've got some notes coming in from KubeCon. We've got our SIG updates, and we'll be having some presentations from Chubeau and Operator Hub. I am now playing the role today of Liz Rice, who is currently out. Yeah, some notes from KubeCon. Wanted to be able to highlight that we had 11,000 attendees here today. And big, big important thing, as Chris has noted over in chat, December 4th, that's the deadline for our Amsterdam pieces. Chris, anything on that? No, CFP closes tomorrow. And just opening to people to make any comments, thoughts, suggestions on how to improve KubeCon next year. So we're kind of open to suggestions here. There's also a survey that we asked people to fill out, but we could use a few minutes on this call for some feedback. Yeah, I'll also be watching chat to see if there's anything in there. And that survey is also linked into these slides. So happy to be able to have people look at those from there. We can move on. Coming up, we've got our KubeCon that you've seen. And for those that are in re-invent, we want to be able to let you know that we do have a networking details over on the Twitter account, as well as the slides here. Please RSVP so we know you're coming. The last pieces in here, the Kubernetes forums, they are coming very, very soon. And one note, we do still have India sponsorships available as well as the opportunity to be able to do co-located days for the India events as well. So please reach out if that's something you're interested in. All right. Other pieces in here as far as housekeeping, we have current votes on the table. We've got a Falco vote. We've got a SIG network vote and the tough graduation vote. So these are all currently open. If you want to be able to add both binding votes from TOC or show a support votes, non-binding votes, please go ahead and drop those in the mailing list. All right. All right. So, hey, update from SIG app delivery here. First, we had our first two sessions at KubeCon on an introductory session and a detailed session on the app delivery model, which we have been working on. This was very well received to the feedback from the community. It was very good to have that structured approach and we got some additional questions around it. Very notably, we also asked the audience what they would be mostly interested in learning more about. One key aspect really was here about Kubernetes for air gap environments as we got some feedback out of the telecommunication industry. So the main question is basically how can I run my Kubernetes environment and which also obviously ties into the whole application packaging topic if I have an environment that has no access to the internet. Tomorrow we will have a presentation from Microsoft and from the CNAP folks on best practices there. But this was something that came up several times during KubeCon how these situations can be handled. And what the problems is, which is I think something we should follow up further on and develop as practice out of giving them with some work there. Operator definition. This is still work in progress. So we were asked by the TUC to come up with a definition around operators and what we want to do there. This has been started already, but we will have a first discussion tomorrow and then get back to TUC with the work in progress. On the project evaluation, so we have a couple of evaluations that are pending from CICF delivery right now. This is just a friendly reminder that we would like to have some input on evaluation guidance and due diligence documents which we could use as templates here. I think that's where we kind of stuck somehow is what is the ideal format to present this back to the TUC. This is where CICF delivery is still looking for guidance on how we should best handle this. So everything that the TUC can share with us is highly appreciated here. So whether it's also past evaluations, whatever is available. During our KubeCon meeting, it was mentioned that there is now a template that has been or isn't the process of being created. So please, please share this with us so we can use it also here. I got your message. Sorry. Yes, I've been away out of office for a while, but I'll send you all of that material that you requested. Yeah, thank you. I was assuming that given the Thanksgiving holidays, you might be out. We expect almost a feedback once you have these documents that can provide more just on some projects we have that have been that have presented some feedback here. We would also have a more detailed discussion with the TUC about the Argo project, which is currently under review. The question here is, or the challenge here is that looking at Argo, you look, looking at Argo CD, Argo events, Argo workflow and those projects. It's actually not a single project submission. It's a submission of multiple projects and also these different projects have also different maturity and community adoption. So this was more than intended. I was interested to see an open discussion how to handle situations like this where somebody not just proposed like a single project, but a bunch of them all together. The operator framework is actually a nice coincidence that we have later on the discussion about the operator hub. There was just a question whether we should split up the operator framework as a project from the operator hub discussion simply because the operator framework obviously is this project to build operators. The operator hub is coming with its own infrastructure requirements. There's more around that the hub itself, like whether it's accepting other operators, how to handle these things, and also the cost obviously of running it. But as we have a presentation on operator hub today, I would defer here for presentation later on. And regarding the command operator in this case is that the Kubernetes operator, not the person who's operating. And the question on kudo, I think regarding kudo that he will see is already engaging with the kudo folks. There's no way to write down the feedback from the gap delivery. But that is one of the projects that need to go through SIGAP delivery as part of their proposal to the TOC and the CNCF correct. That's a delivery project. Yes, it is. But we also talked to the TOC and the TOC also already provided feedback so the TOC should already have everything that's needed or that's then I think they already reengaged with the kudo project. I'm also going to talk a little bit about that later on when we get to the operator framework. Okay, that's it from SIGAP delivery for now. Thank you. All right, I think we can move on to Alex. So SIG storage was quite busy at KubeCon. We had a well attended session with a lot of the leads and co-chairs were present. And it was really good to have a number of people after the session to show interest in working with us and contributing both to use cases and some of the white papers that we're building, which I'll talk about in a second. We also had a co-located event, the Climbing Storage Day, which wasn't technically a SIG storage event but had a number of SIG storage members contributing and working on this event, which had sponsorship from a number of different organizations, but also a lot of inputs from a lot of end users of storage projects and products. So we're kind of now going to potentially discuss seeing if this should come under the auspices of the SIG storage team and maybe help turn it into more of an official CNCF SIG storage event. But it's only the most earliest of those discussions, so we need to discuss this on our next call. And finally, thanks to Amy and some of the marketing guys at the CNCF, we now have a logo, which we're probably more excited about than we should be, but it is kind of cool. Can we move on to the next slide? So I've put a list of work in progress that we've been working on over the last couple of months and things that we need to close off over the next few months. There is an addition, a database addition to the Landscape Point paper. The database section of the original Landscape Point paper was the scope due to time, so we now have a few people working on that. We're also working on a performance and benchmarking white paper, which kind of covers some of the grotches, but also defines terminology and also some of the tools that you can use to benchmark and test performance for things like volumes and databases. And we've also started putting together a storage use case library, which basically pulls on the information that we have put together in the original white paper, the Landscape White Paper, and kind of covers the ideas we're going to build a library of examples of sort of best practices for different use cases. And also during KubeCon, we had a good discussion between some members of the talk and the SIG members discussing some of the processes and workflows. So I've put in a link for some of the discussions we've been having in the SIG, in our source SIG, and we'll be looking to integrate that into a document that Liz is putting together. Next slide. I noticed you're also having the Chihuahua FIS presentation later on, so I put this in just for informational purposes. It's the details of the SIG review of the Chihuahua FIS project, which we did in the summer, and some of the information will be gathered. So as I said, we're happy to move forward with that, and hopefully that information is useful for the TOC and their vanity. And that's it for SIG storage. Hello, this is Sarah from SIG Security. We have the kind of the main activity that we've been doing over the last few months is organizing ourselves so that the growth in our membership doesn't take all of our attention and want to highlight the roles that members have been taking on. We have meeting facilitators, project leads, and new security reviewers. And so you can check out that link if you want to see how we're helping the group self organize. One of the outcomes of the in-todo security assessment, which was our first assessment, is the supply chain security compromise catalog. So there's a PR that where in-todo Santiago Torres, the leader of the in-todo project, has contributed their collection of supply chain compromises. And then the next step, we already have a PR out for categorizing them. We want to learn from these and help educate ourselves and the community about the threat, the different classes of threats of supply chain compromises. We also had Schwag. Our group also is very excited about our logo. We have a Raccoon secret agent spirit animal for SIG Security. So Amy, thank you for putting together stickers, which were available to the members and people interested in SIG Security. And then we decided to bestow hoodies on the members who had taken on roles. So that's Brendan Lum and myself before the intro session, supporting our hoodies. Next slide. So we had Cloud Native Security Day, which was sold out with 175 people. We had lots of contributed talks with the board there was a open spaces session, which allowed for a lot of discussion. And we got a lot of positive feedback about the interaction between the people who were attending that. We had an intro session and a deep dive. And you can see in the bottom right that a lot of the active members and new members got together for a dinner social. Next slide. I wanted to highlight a recent thing that we've done, which it which was in preparation for KubeCon where we added templates for issues. And this was, we had some of them already, but particularly we added a presentation template. So this allows anyone to contribute an issue that automatically gets tagged. And this really helps streamline setting up a cloud custodian is going to come present to us on December 11th. And I also wanted to announce that December 4th, tomorrow, Melanie Riesnik, I hope I'm pronouncing that right from Radical Radically Open Security will be giving a talk to the group. And Radically Open Security is a not-for-profit computer security consultancy that recently did open source audit of Mozilla through their MOS program. And so they're going to talk to us about how they do open security. So really excited to have Melanie read back there. And anybody is welcome to come attend. 10 a.m. Pacific tomorrow. All right. For SIG network, we had an intro and a deep dive at the same time at KubeCon. Yeah, as part of that, Ken and Matt and myself were present to help introduce the mission and goals of the SIG and provide clarification around that. And for my part, I was rather, well, both had some anxiety invoked. I think it also encouraged that there was a full room of people interested in the set of topics that are stated inside of the charter. For my part, it was particularly heartwarming to hear some network engineers or some non-developers raising their hands. They were actively interested in the topics at hand and wanting to ensure that they were, that they should be participating, that it was going to be, that the set of discussions were going to be inclusive of non-developers, if you will. That's network engineers or developers now, Lee. Come on. Yeah, that's right. Be nice to us, man. That's right. Just take some Python. That's all you just said. So, so on that, there was an article written up by Sean Michael Kerner that Kerner that was appreciated that describes some of the discussions there. I think both, you know, given reinvent this week and the pending final binding vote for the SIG, our upcoming first Thursday of the month meeting will probably be postponed this week. Pending those, those two items. Ken and Matt, anything that I missed from our discussions at Gucca? No, sounds good to me. I was just going to add that there's definitely a lot of interest in the SIG. And so I was, I was really encouraged to see that as well as you, Lee. So I think it's a good sign that, you know, the deaf is moving in the right path by, by making this a SIG. And there's going to be a lot of, there are a lot of non like network only type of questions being asked, like how to, how do we kind of integrate this with the experience of cloud native. And so I think it's definitely the right timing and a lot of interest. So it's good to see that. Thanks for putting it on, Matt and Lee. On to presentations with Chuba. Go on in. Hello everyone. Hey. Yeah, today I want to present Chuba FS. Chuba FS is a, is a distributed file system designed for cloud native vacations. It targets containerized and stateful services who need persistent and reliable storage that can be accessible like a local file system. And it's a production ready, which means that it's already been used to support more than 160 application services running on JD's collective platform. Yeah, Chuba FS has several kind of key features that we think that that are important for to support cloud native applications. The first one is the high performance. We try to optimize those five operations whenever possible to provide a user experience like the opening doors are like a local file systems. It supports money tendency, which means that the different application services can share the same online storage infrastructure. It's it has a general public storage engine, which can be used to store both large and small files. It also supports like different file access patterns such as sequential and random accesses. The fastest to be self is highly scalable because we employed a separate metadata cluster to store the file metadata. It provides policy compliant APIs, which comply with policy semantics. By the end of December. The next factor will be is that three combined API as well, which is another picture for us. Next. Yeah, so here is a is a general architecture of the file system on the upper portion is the content platform. The different colors are to present different application services running on the content platform. The second option is the shot online storage infrastructure, which has like three components, the data subsystem, the metadata subsystem and the recent manager. The data subsystem is the place where the file contents can be stored. The metadata subsystem is the place where the file metadata can be stored. And we have a resource manager to to manage resources and performs the orchestration. We also provide a separate repo for it. We also provide a docked compose to create and started the subsystems and the resource manager with a single command. That is that is the easy, easy way to to try the two bypass on the laptop. We also provide the integration with Helm recently on our release be wonderful. Also in a separate repo. So here is a is a brief history of for the project. We launched the project on on generally 2017 and open source. This project on March 2019. We three months later we we did a presentation to stories see on June 12 of this year and short of that we got our first external user over on July 4 we we present our industry paper on March 2019 and right after that we got we got our first maintain outside JD. On middle of August we released our support to set a driver we went to zero and two weeks later we we submit our proposal to C7 sandbox just recently we released the support to help to answer. So so the project itself sees on the GitHub under the Apache 2000 license. It received more than a little bit more than 400 get up stars. It has like 77 GitHub folks and we we currently have 14 maintainers from three different companies. So, so next I want to talk about the production adapters. So how to bypass has been used in JD. So the first example the first use case I want to talk about is the machine learning area. So in JD we have our in house machine learning platform. On this platform data I use to store on just on the local disk. But as our business grows, we got a lot of like training data and the training data the size is is always is mostly like on the TV level, and the content of data keeps changing. So this is the use case that well to about FS can be a good fit because it provides those opposite API's. So the migration from the lock this the solution to survive fast can just require minimum minimum engineering efforts. And on the other hand, because of this kind of migration, we we eliminates those that the show, how can I say, the limitations of the local disk space. So the first example is, is the Mexico database backup. So on the official Mexico documents, when doing the backup usually requires an OSS SDK, or REST APIs, but this kind of increasing the operation cost for us. And the backup files are processed by multiple layers of services which kind of hurts the performance. So it's kind of trouble some to to do the troubleshooting to do the debugging. So, so this another use case that we we switch to to to to bypass, because by doing so we firstly we just the backup files like we're doing on local disk. So we have the the paid cash and right cash to to greatly improve the performance. And by by checking those lock files provided by trial fast or can easily check if anything failed, and doing during the troubleshooting. So there are more like, like use cases than than just the two that I just mentioned, we can find it online from from our documents. Next. The first one has two external users. The first one is the record Nova. It's a company in China that provides visual perception solutions that use the case is more like a using to offer us to store those are large number of small inch files. And the second one is the function which I which is in commerce vendor of industry, industrial supplies that to use the case is for them. Why is the engine lock storage for for as cause a settlement, and the other one is the product image storage similar to recommend. Next please. I want to, then I want to talk about the scope of two of us the ordinates and as well as how it compares to to existing since our projects. The one from from the distributed file system area so one of the famous one is the system and it's the successors, the classes, which is Google's in house solution, working together with work from the public cloud side we have AWS EFS and many others. We also have a self FS, a glass FS. Those kind of public open source source story solutions. We have a very comprehensive comparison from the performance and stability side. We use with those open source solutions in our paper. Next. How to buy fast relates to other since that projects. The first one is the most important is a quality is because we use to buy fast to support our content platform in internally in JD. It's really large scale. We also do this, the home support as the patch manager. We use the promise us as a default monitoring system in the file system. So we plan to to you to integrate with Rook as our story on straighter for for collectives. Next. So here is a list of the current system storage projects. We have it is the open EBS Rook type TV, we test and not home the new member of the sandbox. We see there's still a missing piece of, of the district five system there. And we think that that's why we think that a true FS can be, can be a good candidate. So we actually present, we did a more technical presentation to the story see on June 12 of this year. There are lots of discussions and feedbacks on doing the presentation, but at least point there's no outstanding questions related to the project. But besides those are like the technical questions and feedbacks that you feedbacks with variable feedbacks that we want to bring out to table. The first one is, is the, the score below to buy fast. So the 12 s is, is, is designed to for the photo services and applications where most of the rights as potential. So although we support the random rights, but in our case in our use case in internally in JD, most of the cases are still like special. And the fastest in itself is not designed for the case where restrict restricted meta data consistency and the optimistically are required such as direct L, which means that the user just bypass those OS level caches and just talk directly to to the faster in itself. This kind of personal performance and it's not recommended recommended. The second thing want to bring up is, is the access integration being being asked to do in the doing the presentation. The, the setting says I integration needs to be up to date. So, so before those suggestions and feedbacks we remove the CSI comment or components, and we create a loop, a separate repo for it for the for the updates of the set the driver. We also submitted our PR PR to the to to the community for the reviews. Next. So, the, the, the last slide I want to talk about why is why, why CSI sandbox. So there's three reasons. The first one is the neutral home. And the second reason is that by finally the sandbox we have a clear like governance and it's a safe place to explore those collaborations with with others. And the second, second reason is the alarming with with since admission on based on our companies to try to strategy we want to get a better public visibility. We want to make a cloud native computing ubiquitous. And the third reason is the project itself. The two by five project has a strong relationship with, with other since that projects because JD is completely ecosystem in production. So we, as an end user, we have the experience of all for the five system itself, and how to put it into production and what kind of like for requirements needs to be used to look, be looked like, in order to support those cloud applications. So that's another strong point for us to join the sandbox project. And yeah, that's it. Next. Yeah, that's it. Thank you. Any questions, we can move on. Hi everyone. We're going to talk about the operator framework today. I know that we specifically had mentioned operator hub earlier. It's kind of bundled in its current formats I'm going to talk about all of them. I have some ski. I come from core West was one of the very early employees there. So I'm presenting on behalf of red hat but really we built this community for several years now starting core West. So the operator framework is really about a gap that we see in the cube ecosystem around the next wave of running applications these you know really advanced distributed systems that need active care and life cycle management. This is why we bootstrap this operator concept, and it's been proliferating all over which is great. Next. So we really see a gap in building these things, running them as well as discovering capabilities about them. And the framework has a number of projects, some projects to address these needs you can all find them on GitHub. Probably heard of most of these. So and I'll mention that these slides I'm going to go through really quickly I mostly want to have a discussion today but they're included so if you want to reference them later on. Next. So quick history of the concepts. We invented this pretty early in the cube ecosystem in 2016 with a few bootstrapped operators from core West. Next, and then we rapidly progressed into a ton of operator community building, along with red hat and others that are unlocking kind of stateful workloads on Kubernetes. We have an operator sick started under the open shift Commons banner and would love to bring that into the GNCF. We're also involved in a lot of the add on discussions for Kubernetes and various six cluster life cycle I think that's since migrated to a different sick. So we're we're kind of discussing things all over the place. Next. And then most recently, we made a big launch with operator hub.io. This is a place to discover these operators, most importantly, addressing the gap where it's not just popularity but it's what are the capabilities of these how mature these operators and what exactly do they bring to the table. You know some of them are going to vary in maturity and that's really important for production workloads. And where we are today is we've got a ton of mind share and adoption. You know, I've got a stat slide but you know we've got 1000 plus forks of our SDK so folks are using our tools to build these operators. We have a number of commercial products that are delivered via operator number of CNCF open source projects that are delivered via operator. And this is kind of seen as the way to bring this next generation of workloads on to Kubernetes. Next, I mentioned this just because I know there was some talk in chat of the definition of an operator. This is kind of our definition. And I would like to continue to see that evolving over time and we'll work with that SIG, but it's really embracing Kubernetes extensions in a domain specific way that domain specific way is really the gap that we see. You know every database is different every application is different and the experts can bake that knowledge into an operator. Next. So why use the operator framework we've really broken this down into a number of different personas. We think that are all equally important. We've got developers that are want to build an operator and you know don't want to do all this repetitive scaffolding. We can do all that for you and bacon some best practices. We've got facilities for cluster admins to control which operators can be installed on clusters, you know operators have fairly high permissions depending on what they're doing. That's why they're so powerful, but there need to be some guardrails in place, or else you know your cluster can run a muck. And we think you know production use cases really need those guardrails. The users of your clusters why we're all here while we're providing Kubernetes out to our end users. They need a cohesive set of tools to discover what services are on those clusters. If they want to wire front end to a caching layer to a database. All powered by operators, knowing how to do that is really important to our life cycle. So the main tools that we have for building these operators we think it's really important to address the entire spectrum of skills that folks have and we want to meet them and their model of the world. So to do that we have kind of a no code operator if you will which is building a helm chart into an operator. And this is a way to get kind of the human out of the loop and have a programmatic kube native interface to helm without using a CLI. We have ansible tools so if you're more of an operations focused team and you know how to write ansible or have an existing investment in ansible playbooks you can build those into an operator and do a whole ton of different really cool things. Then we've got our go SDK which builds on kube builder and some other CNCF projects. And that's really the power that you get from all of client go and all that associated tooling and all for all three of these framework which we think is really important. This is another gap that we have where we need to up level these operators that they are trusted by the community and we think testing and validation is really key to that and so we've got that built into our SDK as well. Next. Another framework is the life cycle manager. This is a huge gap that we see in the ecosystem so far, which is, you know, not just installing an operator but managing it over time. CRDs are cluster wide currently and so you need to not have conflicts with those and if you have operators that are dependent on other CRDs being installed on cluster, the life cycle manager has a ton of dependency tooling involved to get that done. So if you install like what we call you know like a top level operator that might install you know the front end the caching layer in the database for example all in one go and map those dependencies down. We think this is really key for having a really wide ecosystem of operators that work together and talk together. Next. And lastly I mentioned this earlier we've got operator hub.io. This goes more past kind of just popularity into actually looking at those dependencies that we were talking about looking at the maturity and the capability model that we have that I shared in chat earlier. It's a recognition that we want these operators to be trusted and you know when they're running your storage and your production databases. And your important ecommerce applications, they need to be really bulletproof and so operator hub has some automated testing as well as some PR based review process to ensure quality. And we think that's really, really important and that's a gap that we don't see addressed anywhere today in the ecosystem. Next. Here's some stats really quick like I said the 10,000 SDK clones I think you know shows a ton of people are using this. We've got you know 600 folks on our SIG mailing list. And so that that shows you that there's a gap in knowledge here and so we've got a community that's built up sharing best practices, talking about the next operator frameworks that we want for like a Java SDK for example so we've got a ton of engagement here. We've got 207 combined contributors to all of our sub projects and a ton of different unique organizations contributing as well. So we think this is a really vibrant healthy ecosystem. Next. Here's just a quick sampling of tweets. You know these come in all the time but folks are seeing that the SDK is a really easy way to jump into this. Other projects that come afterwards like the life cycle manager and operator hub speak against, you know the different steps that you're going to have after you start building an operator. And so we've got folks like I said building commercial products. We've got really healthy open source ecosystems using these as well as just you know, regular end users build a prototype and things like that. Next. I think the most powerful kind of endorsement of an operator we've seen is, you know, handle these quotes I just pulled off one of them from coupon EU earlier this year.  The advice is really you have to build an operator to do this. You need something actively looking after something rebalancing data reacting to monitoring alerts, doing anomaly detection. These things that kind of live at one level above where our cube resources are today, you know, a staple set isn't going to get you all the way there. And so we think this is that's the huge gap that operators fulfilled in our ecosystem. Next.  A bunch of these are CNCF projects, as well as open source communities, commercial entities. We've got the logos on the bottom of this slide are companies that are building internal operators. These are the ones that at least a public we talked about that we know that there's a lot more doing it. And I think that's the power of you know they're building internal applications to talk to these open source operators and really fostering that ecosystem and all the interconnections there. And as we build up more and more of this, I think we're going to see this start to explode even more than it has today. Next. So this is the meat of it that I really want to talk about. So we've got a lot of overlap and engagement on sick app delivery. I'm not going to walk through all of these but we're we have a lot of things that we can bring to the table to address some of the gaps we see in this ecosystem. And I think we're very well aligned in that regard around some of the different things a lot in the life cycle manager in the SDK that we can bring to the table there. Next. And so I wanted to address some of as we presented to say gap delivery, I forget when it was about a month or two ago. And here's a quick highlight of some of the feedback that we got via some emails and the chat during the discussion. Unfortunately, we ran out of time in that meeting so there wasn't a lot of kind of live voice to voice chat. But this is a summary of some of our PR conversations and stuff around community governance. So we got a ton of feedback on that. So we have opened some PRs and some docs about our community involvement in some of those regularly scheduled meetings. It'll, you know, very much looks like any other CNC project. We got one, a lot of stuff around packaging formats like do we need a new packaging format. Basically are the short of this is we're not super opinionated under this, you know, there was like, oh, is, is helmet packaging format. We think the life cycle manager and some of the stuff that's included in that specification go beyond just packaging it's all about, you know, reacting in dynamic dynamic environments registering the CRDs and dependency model and how do I an up valid upgrade past between operators that are way more powerful than just like you know the packaging format. There's still some discussion to go there, but I think we bring a lot to the table, like, you know, late binding of operators as they're installed and said that I'm managing CRDs was another topic, you know, question can helm do this. The, the important part is not just, you know, the, here's the CRD YAML go throw it into the cluster, it's the dependency management, it's the recognition that these are cluster wide and they need to be, you know, it's a privileged operation to install one of those. And so it's, it's a really key thing that we think the framework does well in the life cycle manager that's not addressed currently today. And as of now, I think the helm three community is saying that CRD management is currently out of scope doesn't mean it won't be in scope later on. So just wanted to summarize that discussion you can follow those links for more. And then last, I know there was some mention of Kudo and other SDKs. And so we've been had a great QCon discussion with the Kudo team I think there's a path forward it seems like it makes a lot of sense for Kudo to come in under the operator framework as a fourth type of operator. And so I think we've got alignment on both sides for that so we're really excited about that. And like I said we've been discussing kind of all over the place in different SIGs and hope to continue to do that as well. I think that is all that I had on this if you can go to the next slide I think it would just say questions. Oh, never mind one more slide. So here's a big list of some of the other CNC projects that we've got operators for. And things like that, like I said we're driving stuff with Kudo and the helm folks I saw Matt has some comments in chat if you want to just chime in really quick that would be great. So I think we can start the discussion. That's all the slides I wanted to get through. Matt, what was I wrong. Okay, so, so there's a few things about how one is with CRD management and this actually gets complicated I know that the operator lifecycle manager makes a number of assumptions. But as I poke around the Kubernetes community, there is no one way to do CRDs and so Helm wants to provide a bunch of the features. But the problem has to do with coming up with what are the right ways and the right patterns and I know the operator lifecycle manager makes a number of assumptions and that shuts out other cases, and it becomes a problem of aligning around CRDs. And that's really something that the Kubernetes community needs to do and so Helm wants to and has certain features around CRD management. In fact, many people do install operators with Helm today. And CRDs and everything at all. And so I think this is something that the Kubernetes community probably needs to come together around, but it's not the case that Helm doesn't want to. It's the case that Helm isn't trying to shut out certain assumptions and cases and so we're conservative in what we do with CRDs until we're able to solve for many of the cases out there and I understand the operator lifecycle manager makes more assumptions, even those beyond what the Kubernetes community is doing right now. And I think that's kind of the difference. But during the Helm 3 lifecycle, we will be adding more CRD features and there are CRD features in Helm to manage it. People do deploy operators with Helm. And so that even gets into some of the operator hub stuff. I know there's the testing framework. And I think that requires the operator lifecycle manager, is that right? Operator hub? Yes. So it does require the lifecycle manager to, like I said, go beyond installation so it's upgrading CRDs if they need to be upgraded, providing that path, providing the dependency resolution. But doesn't that make the operator lifecycle manager a hard dependency on an operator being listed in the operator hub? So somebody could go maybe write one in Rust and deliver it with a Helm chart, but it couldn't be listed in the operator hub in the current flow because it wouldn't fit with the current testing framework and dependencies. Is that right? Yeah, today that is correct. Is there any roadmap around opening it up to operators written and deployed and managed in other methodologies? The roadmap has kind of been contingent on some of these discussions. I think we're very much open to that. And we've got some changes underneath the hood, what we call our bundle format, which is a little probably too low level for this discussion. But that would open up, you know, being able to package things as Helm charts and coming, getting rid of some of those dependencies. But I think it's basically up to you. We kind of want to know what the future is before we commit to that stuff, but we very much are open to quite. The other thing that I noticed in here, and since I've got you want to ask about is if you go back to your slide on the operator lifecycle manager. There was trying to find it myself here. There was talk about subscriptions, if I remember right. One slide back from this. Yes, subscription for your operator. This kind of puts the operators using operator lifecycle manager into kind of a a SAS model or service catalog type model that works great for things like my SQL as a service or postgres as a service in a cluster that's kind of added on as a cluster extension. But there are many cases where people are using operators in an entirely different way that is maybe my one bespoke application and it's not a SAS within a cluster and the subscription model and those ideas don't fit. How does that fit within the operator lifecycle manager and the operator hub. Yes, you can think of the subscription as a kind of combination of some lower level olem features and so what you could do is basically just do what I'll call like a one off install basically do a manual install of one of these versions and then just, you know, have it be a subscription installed in health check to be a olem but then not actually upgraded or you know you don't have that subscription idea. So we can address both of those it's like, do you want to be high level in the SAS experience like you mentioned or do you want to be lower level and just kind of install this and Okay, but most of this is centered on the use of the operator lifecycle manager right and it's kind of the bridge piece between all the things. I mean, I think there's a huge thing before that of, you know, building these operators and building them correctly and all the best practice and knowledge there but olem is a really big piece of this yes. Okay, thank you. Appreciate the questions Matt I think it's important that you know we're completely transparent and that's what we want out of this process and you know we definitely want to be able to support. You know as many formats as we can but to have a way that we can properly test it as well so I mean hence that's the reason for the framework, I think you can appreciate that. So, you know feedback is definitely welcomed. Yes I do. And that's one of the things we do with helm charts is we do lots of testing around those things as well, because you know I appreciate it because we do that ourselves over on the helm project. And that we also had doing this discussion is because you also want eventually to have CNCF host the operator hub is what the actual cost would be for hosting something like operator hub. Yeah, honestly, the it runs on a open shift cluster today and it's actually a fairly small one and there's not a ton of resource requirements there. I think I've got some you know Jenkins jobs that are kicked off. I don't know exactly what the cost of that is today but I, it's not astronomical by any means. Yeah, it will be great to get this because obviously eventually if it's doubted by the CNCF the CNCF should be able then to run this the hub as well. And you mentioned it's running on open shift so does it have a hard dependency and open shift or would it work on any Kubernetes cluster. There's no dependency on open shift. It's just, you know, I think it's like, I want to say it's 20 pods. I think the cluster has like three or five nodes on it, you know, nothing crazy. And so, these are all great questions where should we capture those, given the differentiation of the, the SIG versus the TOC, can we just add this to the PR and address those accordingly, as either we need to be reconciled or future items. I'm not sure how we want to the project proposal, GitHub PR would actually be best. Perfect. And so any follow up discussion should happen in that PR or thank you. Okay, perfect. Thank you. Other questions. Good. Since there are so many, would it be worthwhile to have a follow up actual discussion in the SIG rather than just try to barf it all up into this PR. I mean, I think we're pretty open to whatever seems like the best avenue for discussion. PR seems easy. All right, we'll follow up there. Thank you. Appreciate it. Thank you. All right, that wraps up our agenda and we have four minutes to go today. Any more questions, anything else that people want to be able to surface in this meeting. One item, SIG runtime. I think we decided two odd weeks ago that we were going to put that up for both to the TOC, the charter is done. We have chairs and SIG leads. I think the PR probably needs to be slightly updated, but should we do that in the next two weeks? Yes, if you can do that, that would be super. Thank you. I understood you were going to call the boat. Maybe there was a miscommunication. If you can update the PR, I will be working with the TOC to be able to call the boat. Okay, cool. Thank you. Thank you. I had one little announcement. I just sent a note out to the TOC list. I, Brendan did a great flow chart earlier this summer about project process. There's been a lot of questions and confusions about that. So I made a barked out version of that, which is PR321. I said not on the mailing list, would love some feedback. I'm just, we're trying to scribe what is the intended process. So have no attachment to the boxes and arrows there. Just want to help drive it to documentation. Anything else? Okay, good to see everyone. I will be posting this up on YouTube as soon as I have the recording and we'll see you all next time. Thank you. Thanks. Thank you.


Hello, how are you guys today? Most people are unaware of the effects of EMF radiation on our bodies. Electric and magnetic fields, basically most of modern technology, whether it's a power line, a cell phone, or an internet router. I was too, until I started researching after experiencing health issues when I was younger. And it turns out sleeping next to an internet router isn't the best idea. Now a lot of people go their entire lives and just disregard it because they're healthy or normal and think they're functioning optimally. However, all it takes is one negative dietary or lifestyle catalyst. And you're suddenly going to doctor's appointments every week without knowing what's wrong. When in reality, you could be experiencing low level radiation poisoning. And if you're getting poisoned, you don't add something to fix it. You don't try to neutralize the poison. You remove the poison, which isn't what doctors are trained to do because it's not that profitable. Starting with number one, insomnia. This also includes poor sleep, fading in and out of sleep, suddenly waking up at night and fatigue despite sleeping with many hours, all types of different sleep disturbances. For me, in most cases, I couldn't fall asleep at all.  Maybe your neighbor's got a smart meter. Your parents got a Netflix device. The new router got upgraded. It's stronger. I had a client whose brother set up a computer room above them and then they just started having insomnia. Another person I knew had a neighbor who used the microwave super early at like 6 AM every morning, which was waking him up like clockwork. And you should feel good and rested upon getting out of bed in the morning.  But if you're not sleeping in a low EMF environment, if you don't have shielding canopies or tents or you're turning your devices off, then you should really figure that out because the sleeping portion is the most significant out of EMF recovery. Even if you're in a super high radiation work environment all day, at least when you go home, when you go to bed, your body is able to recover in a lower radiation environment. Number two, we have headaches. And this greatly depends on the person's metabolic health. People who have higher liver function, overall metabolism can handle stress from radiation more without as many negative side effects. You can have one person living in New York City wearing air pods, frying their brain all day, seem fine, of course they're going to age quicker and stuff. But then a person who makes a five minute phone call could get a headache later. Very, very subjective. And every time I drive upstate to look at farms or properties, since they have all these new five grams towers aimed at the drivers on the highway, I always get headaches unless I wear head protection while in the car. And when you sleep, there's cerebral fluid that washes over the brain, kind of like wiping it clean of oxidative stress. Very important for healing. So usually sleeping in a low EMF environment can be the only way to cure some headaches. Next up, we have stomach aches or stomach pain. And the radiation will impair your digestive organ function, again subjectively depending on the person. So your liver is not producing as many enzymes or processing nutrients, your pancreas isn't doing the same thing, not enough insulin, not enough enzymes. The small intestine isn't contracting properly, food's not moving, gut motility comes to a halt, Candida can start to overgrow and penetrate the gut lining.  I noticed so many changes in my digestion when I used to work in the city just from going back and forth, like really, really strange. But when I started wearing protective clothing, the stomach aches stopped. I would still get headaches on occasion, but not nearly as frequently so even though my head wasn't shielded just my body, my liver and all of my other organs functioning optimally allowed me to heal some of the oxidative stress from the brain because you know the blood's flowing throughout the entire body down back to the brain so really makes a big difference. Forgetfulness, brain fog, losing your train of thought. And this is pretty simple. You were talking to someone, having a conversation, trying to think of something and it just poof, vanishes, completely gone. And this is more evident in really high radiation environments because it will occur more frequently. You'll constantly lose that train of thought throughout the day. It's not a once a week thing. This can happen multiple times an hour, very easily, greatly dependent on how high that radiation is. Wrapping up with nausea, dizziness, just like generally feeling unwell and kind of out of it. More severe symptom where you've been exposed to radiation at moderate to high levels for some amount of time and you have low level radiation poisoning. Usually for me I'm not in a high radiation environment for long enough to have side effects for days after, but if you do feel nauseous or dizzy that can mean you've had a five grams tower on you for a long period of time. When I moved in here there was a five grams antenna on one of these street posts and it was pointed right up my head so I was waking up nauseous, dizzy, out of it. As soon as I shielded everything that kind of went away. There's pretty different feelings that can be hard to tell depending on how in tune you are with your body but once you experience a low radiation environment versus a high radiation environment like going out and camping or sleeping in an EMF tent versus being in the city or next to a microwave at work then it's very, very, very easy to tell. It's why I always wear my Wi-Fi shielding protection clothing throughout the day all day, winter, summer, doesn't matter whatever I'm wearing I always have the protective clothing on as much of my body as possible and then I'll also try to shield my head throughout the day but especially at night or when I'm working on my computer I have several bed canopies set up to reduce the radiation as much as possible and this is as much of a health factor, something you want to do as diet, as exercise, as grounding. Reducing the EMF can be more important than all of those on its own. Which is why I created Wi-FiShielding.com guys for affordable and unique anti-radiation products. There's so many videos on EMF. If you guys want to learn the mechanisms and how it's actually damaging your body I've spoken about it. Anything you need to know it's on that EMF playlist. So as always thank you guys for joining me today. If you can please drop a like on the video, leave a comment down below, subscribe so that YouTube can unsubscribe you next week and be sure to check that notification bell so they don't notify you of my videos. As I just said guys Wi-FiShielding.com which you can also see on Frank-Founder.com if you would like to support me further. I'll see you guys soon.


And I just feel like I've grown up like being taught that it's like an abomination like it says in the Bible and... The Bible has 36,000 verses in it. I can cherry pick anything out of here that I want. On the surface, this may seem loving and compassionate, but in truth it's a cowardly display to preserve one's own reputation and garner praise from the world. Jesus never did this. He spoke the hard truth that we need to repent all of us. Jesus has come to redeem sinners. If we are good just as we are, Jesus' sacrifice serves no purpose. But the Bible says that we were born in sin and it is only Jesus who can give us a new nature, a new identity. As Christians, we need to make a choice. Will we compromise the word of God in order to satisfy the wisdom of the world? Or will we hold to the truth in faith that regardless of what comes, God will be with us?


This talk is about my search for a good UPnP hacking tool. So what we're gonna go over today is just some introductions to tell you who I am. First, I'll start talking about what is UPnP and why should you care about UPnP? Why was I looking for a tool to hack UPnP in the first place? I'll talk about some of the tools that are out there right now and what I found to be their shortcomings and why I thought that they weren't quite sufficient. I will show you a new, an updated tool that I put a lot of updates into and I'll talk about the features of that and throughout we'll do some demos of that functionality and about UPnP in general. Q&A was gonna be in the Discord chat but I know Discord is down at the moment or there's some issues with it. So if that still happens, we'll probably just keep the Q&A here in the Twitch channel. All right, so who am I? Real name is Trevor Stavato. I've been in offensive security for over 10 years, different positions, mostly in web app and network pen testing. A couple of years ago, I founded this cool little company called LabMath Security. Before I was in hacking, I was a software developer and I did that for a number of years and then realized all the mistakes I was making once I became a hacker. I tried to be an active member of the security community. As Sam said, I help do some IoT village stuff in Canada. I help sometimes in the US as well. I like to dabble a little bit in RFID. So we do an RFID village here in Canada and I do some red teaming for the pros versus Joe's CTF which unfortunately didn't happen this year because of all this COVID stuff. Maybe one of my proudest achievements so far is the DEF CON 26 Black Badge win at the IoT CTF. All right, so let's talk about what UPnP is. UPnP is universal plug and play. And it's a protocol defined, I think back in 2008 was the original publication of this protocol, allowing for devices on network to discover and interact with each other based around a principle called zero configuration networking. Really what they wanted to be able to do was to have a device that just plugged into a network, found other devices and was able to talk to and communicate with the other devices and have them configure themselves according to their needs without anybody having any actual input and hands-on keyboard configuration. Sounds like a great idea to me. So UPnP is a protocol that uses pretty standard services like HTTP, XML and SOAP. And it defines a way for services to describe their functionality and as they interact with other devices. A lot of the common uses for this are for network services. So small office, home office, routers we'll use this for configuring port forwarding. There's data sharing services for network storage, media streaming, for example, Chromecast or some of the original versions of Chromecast use UPnP to initiate the streams. And it's also used commonly in smart home control which will be one of the demos that we're doing later on today. So in the spec UPnP talks about kind of six capabilities or six things that are required for proper UPnP functioning. The first one is addressing. It's not as important for the tool because we can't really talk to it unless it has a device but the device needs a way to get an IP address. And this is typically done through DHCP. The second one, more interesting to us is discovery protocol. So the devices need to be able to advertise their presence on the network or other devices need to be able to search for other UPnP devices on the network. So there's a protocol called simple service discovery protocol SSDP that is used to do this advertisement. And I'll show one of those requests later and show how that works. Once you know what devices are on the networks you need to know what those devices can do. And then there's a device description XML file that gives this detail. And when the devices broadcast their presence or another device searches for them the URL to that XML file is part of the response that comes back. The next part is control. So once you know what it can do you need to know how to control that device. You need to know what endpoint to send the request to, what parameters you need to include in the request. Once you have this information now that's enough information to start interacting with that device. There are still a couple of other parts to UPnP. The fifth one is event notifications. So you can subscribe to specific state variables on a device. And if that state variable changes it'll send a notification to you. And then the last part of UPnP protocol is a presentation. For the topic of this talk that's not as important because that just gets into sort of regular web app hacking less UPnP hacking. So we're gonna focus on two to five with this talk. So I'm gonna show you just a brief view of a device description and what that kind of looks like. So over here, I'm gonna run a search and you'll see the discovery message and I'll make this bigger because this might not be easy for people to see. So there's a discovery message that uses a custom HTTP verb called Msearch. It posts to a broadcast address and this is just a fixed, this is the same on every network. It's got a message saying trying SSTP discover and a service type in this case is SSTP all which basically says all devices respond to me. And you can see the responses come back here from all the different devices showing you here is the location of my service or my device description and it'll also give you some information about what kind of device it is. So you can see on my network, there are a couple of devices that have a lot of different services because we said SSTP all, all of the services are responding separately. So now I'm gonna, we're gonna take a look at one of these and we'll show you what a device description looks like and let's make this bigger. So this here, you can see my setup here on the other screen, I have an ASUS router, I have a WiIMO switch and that is, there's a little lamp plugged into that WiIMO switch. So the device description we're seeing here is for the ASUS router. It shows you the model number, the version numbers, serial numbers, a lot of information about it. When we get down into this section, the service list, this is where we see the different services, the UPNP services that it supports. So it'll show you the URL that you need to send control requests to, the URL to send event requests to, and it'll also have, not in this one, but in some of them, it'll have the, oh yeah, no, here it is, the SSTP, so the service controlled descriptions, so the service description. So if we copy this and we put this on here, we'll now put a double fax bar, there we go. Now we'll see all the actions that this service supports, action name and all the arguments. So we can collapse all this and you can see there's gonna be a bunch of actions for this service and then we get into this service state table that talks about all the state variables and some of these won't send events, so the send events is no, but some of these do. And those are the ones that we can subscribe to, so physical link status is a variable that we can subscribe to and get notifications when that status changes. So you can see how this can be used by devices to monitor what's happening in the network and be able to control it. So that's the overview of how these, the sort of service descriptions and device descriptions work and what they look like. So one thing that's missing from this spec is that there's no authentication, even on the control endpoints when you're sending a control message, they are unauthenticated. It's a very old protocol, as I said, 2008, so they probably didn't think about that part of it. There have been some updates, some other optional pieces that you can tack on to add some authentication and some security to it, but those really, from my experience, I haven't seen any devices that use those. So most of this is just fully done unauthenticated. So why does this relate to IoT? Why is it in IoT Village? A lot of IoT devices are using UPNP. It makes them very simple for setup and control. A lot of consumer devices, they just wanna make it simple. You take it home, you plug it in and it works. So that's why UPNP is helpful for that. But as a hacker, we can look at what can we do with that so we can do things like turning smart home devices on and off and we'll do a demo later of the WiIMO switch turning that on and off. One of the other things that UPNP has gotten the news a lot for is the ability to update the router's configuration and open ports on the router so that you can forward from the WAN side, the internet side into the internal network. And then, as I said, you can also control media devices. So I thought IoT has already so many vulnerabilities. There's gotta be some UPNP vulnerabilities, right? So that's why I wanted to look at UPNP as sort of an attack path. As I said, there's been a couple of notable exploits in the news. Back in 2017, Akamai released a paper talking about UPN proxy, UPN proxy. Basically, a lot of devices were configured to expose the UPNP interface on the WAN side. So you could send control events, things like port forwarding from the WAN side. So somebody on the internet could control your router and could set port forwarding to get internal access to your network. And even some of the rules, the way that they were doing the port forwarding, they're not validating the fields. So you could port forward a port on the WAN side and forward it to a completely different URL somewhere else on the internet. So people were using this as a proxy, as their UPN proxy, to hide where they're coming from and sort of disguise their attacks. Back in 2019, there was a pretty famous attack from HackerDraft where they used basically that same functionality, routers that were allowing configuration on their WAN side to port forward to the Chromecast device. And then from there, they could control the Chromecast device because it used UPNP as a way to stream a video to it. So they could control the Chromecast device and put a video of their choosing on. And they decided to put up an advertisement to subscribe to PewDiePie. So that got a lot of news headlines. One of the more recent ones that I've come across is this vulnerability called Call Stranger. And it's a 2020 vulnerability. It's really interesting when you look at this because basically what he did is he looked at the UPNP spec and just noticed that there's some bad design in the spec. So I talked about the event subscription part of this. There's a callback of the event's description. So you tell it where to call back when something changes. But there's no validation at this point done on that callback. So you can have that be some other address on the internet. You can use it to, you can add query strings on it so you could use it for data exfiltration if you wanted to get stuff out of a network kind of sneakily. There's also some amplifications type ramifications to this because you send a very small request and the request that comes back or gets forwarded to that notification server is much larger in size. So you can potentially do some sort of denial of service using that amplification. So we'll look at that and show you how that's done. So when I went looking for the UPNP tool, there's basic things that I would want a UPNP tool to do. First, I wanted to discover all the devices on my network. I don't want to have to go out there and look forward. I want this tool to be able to find them. Once it finds them, it should be able to parse the description, find the services and actions and events. It smells pretty straightforward and easy to parse. So that should be straightforward. And then to be able to build and manipulate the UPNP requests, that needs to be something simple that I can easily do and potentially ideally fuzz that interface. So let's look at some of the tools that are out there and how I found that they worked. Now, this isn't an exhaustive presentation of what's out there. These are just the more common ones that I've come across. The first one is Miranda and it's available in Cali out of the box. It has a nice command line syntax if you like that kind of thing. But on the cotton side of things, I found it doesn't always work. In the case, I just ran it yesterday on my home network. It can find the devices by doing an M search, but it seems to have trouble parsing some of the service description files. So it comes back with an empty list of services and you can't do any sort of control of the actions. Also, command line syntax, in my opinion, isn't as nice for interacting with these requests and I just don't find it as nice to use. The next tool that I looked at, and I was actually really excited about this tool was the Burp UPNP B Hunter. It's available in the Burp app store. Because UPNP is HTTP based, XML soap, all that kind of stuff works really well in Burp and it works really well in Burp's other tools like intruder and repeater. So I thought this was a great place to have that kind of functionality. But when I started using it, there were some major problems that I had where it wouldn't detect all the devices on the network. Some of the devices that I knew were there, it wasn't picking them up. And sometimes the parsing wasn't working. It wasn't able to parse the service descriptions and get access to all the different control points. Lastly, I found the interface just wasn't so easy. My home network, I do have a lot of IoT devices plugged in and when I do a UPNP scan, I get back five or six devices. Each of them have many service descriptions and lots of control endpoints. And the version that's in the app store right now basically has very little fine green control over what requests you send to intruder or repeater. And sometimes even you don't have control over where you send it to. It's either one or the other. But I was ending up with, you know, 100 repeater tabs of requests and trying to dig through 100 tabs to find the one request that I wanted to fuzz or test. It's just not very user-friendly in my opinion.  As I said, there's other tools. There are things like UFuzz. That's based on Miranda. So it's going to have the same sort of shortcomings that Miranda has. There's some .NET tools, but I don't really work on a Windows laptop very much. So .NET is not that conducive for me. So, you know, I was kind of looking at a few different options. I keep looking to see if there's other tools out there. I build a new tool from scratch or I modify an existing tool that's already out there. So being Canadian, I turned to my good friend and my neighbor Drake and I said, what should I do? He told me, don't build a new tool from scratch. You got to modify something that's already existing out there. So that brings me to my version of Burp UPNP Hunter. I thought that it had the best sort of, you know, potential for a tool because of its integration into Burp and some of the other tools that you can use with Burp. But first we had to get through some of the bugs that it was facing right now. So the first one, the fact that it didn't detect all the UPNP devices on the network, I found that this comes down to some devices that just don't follow the spec very well. It was sending the M search using an SSDP all, which I showed earlier, and all devices are supposed to respond to that, but some devices they just don't. So I added a different M search. So it does two M searches, one using SSDP all and one using another tag called root device. And that only the root device is supposed to respond to that, not all the different services. Pardon me, that seemed to work a little bit better for some of the devices that were on my network. So I was able to find all the devices on my network at that point. I still had some issues though with parsing in this tool. There was an interesting unsigned integer conversion error. So Burp is written in Java and Java byte arrays go from negative 127 to positive 127, but Python, which this tool is written in, has byte arrays go from 0 to 256. So in most characters, that doesn't really matter because you're still in the 0, 127 range. But when you get into special characters and you get an assigned byte array from Java going into Python, things don't work so well. So I had to do some tricks to convert that back to an unsigned byte array. So that, you know, no matter what we got in the service description, special characters or not, it wasn't gonna work on me. I also found that the control URLs, the way that it was parsing the control URLs from the service, from the device description, it didn't account for the fact that some devices add query strings to the control URLs. So they have a generic control URL, but they have a query parameter that it uses to determine what service you're trying to talk to. And without that, it just gave me back bad requests. So I had to modify the tool to actually use the query string that was part of the control URL. Lastly, there were still other issues with the parsing. It wasn't actually doing XML parsing in the first version. It was using a Regex to try to search through the XML document to pull out the pieces that it needed. And if you had an XML document that wasn't structured the way it was expected, then it wouldn't work. So I switched it to use actual XML parsing because, you know, that just makes sense. I also changed the UI for the tool. Because I didn't want to have to dig through 100 tabs in Repeater, I added some combo boxes where you can now select the IP, the service, and the action. So you can drill in on the specific request that you want to look at and play with. I added a full request viewer and editor. So you can look at that and maybe change things before you send it to Repeater. And you have the option to send it to either. You're not sort of tied into one or the other like you were in the first version. And lastly, I added a couple new features to the tool. So I added the ability to subscribe to event notifications. So it parses that service description, looks for state variables that have events turned on. And then it will build a request for you that you can generate a subscribe request to subscribe to those state variables. I also added an option to specify the single device description. So instead of searching your network, you can specify a remote service description. Searching only works on your local network because you're broadcasting to an address within your local network. So only devices within that local network are going to work. But if you go on Shodan, there's a lot of UMP devices on Shodan that are exposed to the internet. If you want to play with those, now you can because you can paste that service description into there directly and load that and get all the actions. I also added some little buttons so you can view, pull up the service description and SEDP files directly from the tool. That was kind of more of a convenience for me as I was debugging and trying to figure out why things weren't working, to easily get to the device description and those files made it a little bit easier to see what I'm looking at. And now it's demo time. So we'll go through that tool and show you what it actually does. So UPNP Hunter 2.0. Right now, it is not available in the verb app store. I do plan to push it to the verb app store at some point later. I first wanted to wait and give the original author a chance to pull in some of the changes that I pushed and maybe update the tool from there. He doesn't seem to have the interest to do that so I will push this as a separate standalone version. So this is the tool. This is what it looks like in the verb tab. And I'm just going to go ahead and start a discovery on my network. And this will take a few minutes because as I said, it's running the M search, reading back all the responses and then parsing out. So on this network, I have two devices that are running UPNP. This is the Asus router as we saw before. This one is the Belkin WiIMO device. And this is the list of all the service endpoints that it understands. And if you look at the different actions, these are all the actions within that service endpoint. You can see the SCDP here for a second. And so you can see action to get device information. That should be in here somewhere. Yeah, get device information. And then once you select it, it pulls up the request, it builds out the request in this field here. So you can view it, see what different parameters it takes, and then you can send that straight to repeater or to intruder. And we'll see that repeater picked it up. Now it's here and I can send this request and get device information from that request, from that device. So that's very, very basically that's how it works. So let's show you why this is cool and what we can do with this. So one of the things that's very easy to do with the Belkin WiIMO device is controlling its on and off state. It's called binary state. So we are going to find the request that's set binary state. And we can see there's a few different parameters here and the parameter values are just filled with fuzz here. It could tell you where you can actually put input. And we'll send that to repeater. We'll take all this fuzz here stuff out and the only one that really is needed for most basic operation is the binary state. So I'm going to set the binary state to 1 which should be on. And as you see over here the light flips on and I get a response that now the binary state is on and some other information. Now I can set the binary state back to 0 and the light goes off. So very simple, easy control of the device state through UPNP. Let's talk a little bit about event subscription. So in here you will see a subscribe request and it again uses a custom HTTP verb subscribe. This is the path pulled out of the device description and then again there's a bunch of places where you can fuzz. Here in this section is where you put the parameters where you want the callback to come to. You can set a timeout for how long you want to get notified of of those event changes and then this is a comma separated list of all the different parameters that this device will give event notifications for. So I already have one of these queued up over here. Let's see. So if everything is still working the way it should I will get a device description or sorry event notification here saying the that is not what I expected. Hang on a second. Property change property state is zero. Okay. Sorry that is what I expected. Now if I go back to the basic event request and I change the state to one now I get another notification coming in on that callback with the binary state is one. So we see the notifications and how they come back. What's interesting about notifications and what this call stranger vulnerability sort of talks about is you can specify multiple endpoints that this calls back to one of the neat sort of features of this is that if the first request doesn't if the first URL doesn't you can't reach it doesn't get a response from it then it will try the next request IP. So you can actually make use of this to do some internal port scanning of things on the network if you can access this on the WAN side for example you can use this feature specify a host in a port and then specify a host and port that you know it can reach and if you get the callback coming to to your IP address you know that it wasn't able to connect to the previous one. So that's kind of a fun little thing you can do with the subscribe feature but really that's I guess sort of the end of my demonstration of this tool I think it can be really powerful especially being able to send stuff to intruder and do some fuzzing with this and I can also show you here that if we just take this device description paste it in here then we get just that device descriptions services we don't get all the other so you can use that as well to sort of narrow down or look at remote ones like I said and I think that is it so the repository for this is in our GitLab link is here as I said I do plan on pushing this to the verb app store at some point in the future but it's just not there right now.