So good morning, everyone. My name is Arne, and today I'll be hoping to entertain you a bit with some GPG usability issues. So thanks for being here this early in the morning. I know some of you have had a short night. In short, for the impatient ones, why is GNU PG damn near unusable? Well, actually, I don't know. So more research is needed, as always, because it's not like using a thermometer. We're doing something between social science and security. But I will present some interesting perspectives, or at least what I hope you will find interesting perspectives. This talk is about some possible explanations that usable security research can offer to the question. Now, some context, something about myself. So you have a bit of an idea about where I'm coming from and what colored glasses I have on. So pretty much my background is in mathematics, computer science, and strangely enough, international relations. So my professional background is that I've been doing embedded system security evaluations and training, and I've also been a PhD student studying the usability of security. Currently, I teach the new generation, hoping to bring some new blood into the security world. So I want to do some expectation setting. I want to say what this talk is not about. I will also give some helpful pointers for those of you that are interested in these other areas. So I will not go into too much detail about the issue of truth in security science. Here are some links to some interesting papers that cover this in a lot of detail. Neither will I be giving a security primer. There are some nice links to books on the slide. I will also not be giving a cryptography primer or a history lesson. Neither will I be giving an introduction to PGP. And interestingly enough, even though the talk is titled why is GPG damn near unusable, I will not really be doing much PGP bashing. I think it's quite actually a wonderful effort, and other people have already done the PGP and GNU PG bashing for me. And as I've already mentioned, I will not be giving any definite answers, and a lot of it depends. But then you might ask, it depends. Well, what does it depend on? Well, for one, what users? You're looking at which goals they have in mind, and in what environment, what context they're doing these things.  I want to offer you a new view on the security environment. And I will also give you some concrete exercises that you can try out at home or at the office. And some do's and don'ts and pointers for further exploration. So this is a short overview of the talk. I'll start with the background story to why I'm giving this talk. Then an overview of the usable security, research area, some principles and methods for usability, some case studies, then some open questions remaining. So the story. Well, it all started with this book. When I was reading about the Snowden revelations, I read how Snowden tried to contact Glenn Greenwald. So on December 1st, I sent an email saying, writing to Glenn, if you don't use PGP, some people will never be able to contact you. So please install this helpful tool. And if you need any help, please request so. So three days later, Glenn Greenwald says, OK, well, sorry. I don't know how to do that, but I'll look into it. And Snowden writes back, OK, well, sure. And again, if you need any help, I can facilitate contact. Now, a mere seven weeks later, Glenn's like, OK, well, I'll do it within the next days or so. OK, sure. Snowden's like, OK, my sincerest thanks. But actually, in the meantime, Snowden was growing a bit impatient. Because, OK, why are you not encrypting? So he sends an email to Michael Lee saying, OK, well, hello, I'm a friend. Can you help me get in contact with Laura Poitras? In addition to that, he made a 10-minute video for Glenn Greenwald, describing how to use GPG. And actually, I'll have quite a lot of screenshots of that video, and it's quite entertaining. Because of course, Snowden was getting increasingly bothered by the whole situation. Now, this is the video that Snowden made, GPG for Journalists, for Windows. I'll just click through it. Because I think the slides speak for themselves. Take note of all the usability issues you can identify. So just click through the wizard, generate a new key, but we need to enable expert settings, because we want 3,000 bits of keys. We want a very long password, et cetera. And now, of course, we also want to go and find keys on the key server. And we need to make sure that we shouldn't write our draft messages in Gmail, or Thunderbird and Enigmail for that matter, although that issue has been solved. So I think you can start seeing why Glenn Greenwald, even if he did open this video, was like, OK, well, I'm not going to bother. And Snowden is so kind to say, after 12 minutes, if you have any remaining questions, please contact me. So at this year's Hope conference, Snowden actually did a call for ARMS. And he said, OK, we need people to evaluate our security systems. We need people to go and do Red Team. But in addition to that, we also need to look at the user experience issue. So this is a transcript of his kind of manifesto. And he says, well, GPG is really damn near unusable, because, well, of course, you might know command line. And then, OK, you might be OK.  And he also notes that, OK, we're part of a technical elite. And he calls on us to work on the technical literacy of people, because what he explicitly warns against is a high priesthood of technology. So OK, that's a nice call to ARMS. But are we actually up for a new dawn? Well, I want to go into the background of usable security. And I want to show you that we've actually been in a pretty dark time. So back in 1999, there was this paper, why Johnny counting crypts, which described mostly the same broken interface. So if you go back to the video of which I showed some screenshots, then, well, if you look at these screenshots from 1999, well, is there a lot of difference? Well, not really. Nothing much has changed. There's still the same conceptual barriers and same crappy defaults. And most astonishingly, in the paper, there's a description of a user study where users were given 90 minutes to encrypt an email, and most were unable to do so. So I think that pretty much describes damn near unusable. So a timeline from, well, before 1999 to now of the usable security research. So quite a lot has happened, although it's still a grown field. It started the idea of usable security. It was explicitly defined first in 1957. But it was only until, only in 1998, that the first usability tests were carried out. And only in 1969, that the concept of user-centered security was described. An interesting paper also from 1999 shows how, contrary to the general description of users as lazy and basically as the weakest chain in security, this paper describes users as pretty rational beings who see security as an overhead and where they don't understand the usefulness of what they're doing. So the study of PGP 5.0, I've talked about that already. And there was also a study of the CASA network in 2002. And it was found out that a lot of users were accidentally sharing files from personal pictures. Well, who knows? Maybe credit card details, you never know, right? In 2002, a lot of the knowledge of usable security design was concretized in 10 key principles. And if you're interested, I do recommend you to look at the paper. So a solution to the PGP problem was proposed in 2004, or actually it was proposed early, but it was tested in 2005. And it was found that actually if we automate encryption and automate key exchange, then, well, things are pretty workable, except that users still fall for phishing attacks, of course. But last year, another research identified that making security transparent is all nice and well. But it's also dangerous, because users no longer are less likely to trust the system and are also less likely to understand what's really happening. So a paper this year also identified another issue. Users generally have very bad understanding of the email architecture. And email goes from point A to point B. And what happens in between is a no. So before I go on to general usability principles that form the founding pillar of the usable security field, I want to give some examples of usability failures. So you might be familiar with Project Venona. This was an effort by the US intelligence agencies to try and decrypt Soviet communication. And they actually were pretty successful. They uncovered a lot of spying. And well, how did they do this? The Soviets were using one-time pads. And if you reuse a one-time pad, then you leak a lot of information about the plain text. What we also see happening a lot is low password entropy. We have people choosing password, 123456, et cetera. And what I just described, the study looking into the mental models of users of the email architecture and how it works. Well, at the top, we have still a pretty simplified description of how things work. And at the bottom, we have an actual drawing of a research participant when asked, can you draw how an email goes from point A to point B? And it's like, well, it goes from one place to the other. OK. So this died. So these are two screenshots of an email. Well, if I wouldn't have marked them as the plain text and the encrypted email that will be sent, you probably wouldn't have spotted which was which. So this is a pretty big failure in the visibility of the system. You don't see anything. Ah, that's the point. Yes. So on the left, we have a screenshot of a GPG. And as I've already described, command line people. Well, we like command line, but normal people don't. And what we also see is a lot of the jargon that's currently being used even in GUI applications. So on the right, there is a PGP 10.0. Now, I want to close these examples with, oh, you might be wondering, what is this? Well, this is actually an example of a security device from, I think it's around 4,000 years ago. Now, people could use this. Like, why can't we get it right today? So something that you should, this is a little homework exercise. Take a laptop to your grandma, show her PGP. Can she use it, yes or no? Probably not. But who knows? So now, I want to go into the usability cornerstones of usable security. I want to start with heuristics. Some people call them rules of thumb. Other people call them the 10 holy commandments. For example, there's the 10 Commandments of Dieter Rams. There's 10 Commandments of Jacob Nielsen of Don Norman. And it really depends on who you believe in, et cetera. But at the cornerstone of all of these is that design is made for people. And well, actually, Google says it quite well in their guiding mission, is focus on the user and all else will follow. Or as a usability maxim, thou shall test with thy user. Don't just give them the thing. But there is one problem with these heuristics and with this advice, go and test with your user. Because it's pretty abstract advice. So what do you do?  You start observing people. So one nice exercise to try is go to a vending machine. For example, the ones at the S-Bahn. Just stand next to it and observe people buying tickets. It's quite entertaining, actually. And something you can also do is to search for usability failure. So this is what you already do when you're observing people. But even just Google for usability failure, gooey fail, et cetera. And you will find lots of entertaining stuff. So those were some heuristics. But what about the principles that lie behind those? So usability or interaction design, it's a cycle between the user and the system, between the user and the world. The user acts on the world and gets feedback. And they interpret that. So one important concept is for things to be visible, for the underlying system state to be visible, and to get appropriate feedback from the system. So these are Don Norman's Gulfs of Evaluation and Execution, sort of Ying and Yang. And there's two concrete problems to illustrate. For example, the button problem is like, how do you know what happens when you push a button? And how do you know how to push it? So I unfortunately don't have a picture of it. But at Oxford Station, the taps in the bathrooms, they say push, and you need to turr. Then there's the toilet door problem. The problem of how do you know what state the system is in? How do you know whether an email will be encrypted? So this is a picture. I'm sure how well it displays. But basically, there's two locks. One is actually broken. And when pushing the button that's on the door handle, you usually lock the door. But, well, it broke. So that must have been an entertaining accident. Another, as I've already described, another important concept is that of mental models. It's a question of what idea does the user have of the system by interacting with it? How do they acquire knowledge? For example, how do we achieve discoverability of the system? And how do we ensure that while a user is discovering the system that they are less likely to make mistakes? So this is also the concept of Pokeyoke. And here's an example. You also see it with floppy disks, with USB sticks, et cetera. It's engineered such that users are less likely to make a mistake. Then there's also the idea of enabling knowledge transfer. So how can we do this? One thing is metaphors. And I'm not sure how many of you recognize this, but this is Microsoft Bulb. So traditionally, PC systems have been built on the desktop metaphor. But of course, you shouldn't take metaphors too far. Microsoft Bulb had a little too much. To enable knowledge transfer, you can also standardize systems. And one important tool for this is design languages. So if you're designing for iOS, go look at the design language, the human interface guidelines of iOS. The same for Windows. Go look at the metro design guidelines. And for Android, look at material design. Because another interesting exercise to try out relating to design languages. And also to get familiar with how designers try to communicate with users is to look at an interface and try and decode what the designer is trying to say to the user. And another interesting exercise is to look at not usability, but unusability. So there's this pretty interesting book called Evil by Design. And it goes into all the various techniques that designers use to fool users to get them to buy an extra hotel, car, et cetera. And Ryanair is pretty much the worst offender. So a good example to study. So what if you want to go out into the world and apply these principles, these heuristics? So the first thing to know is that design tends to be a process, whereby the first part is actually defining your problem. So your first brainstorm, then you try and narrow down to come to concrete requirements, after which you go and try out the various approaches and test these. So what materials do usability experts actually use? Of course, there is expensive tools, actor, pro, et cetera. But I think one of the most used materials is still the post-it notes, just paper and pens. And OK, where do you want to go and test? Well, actually, go out into the field and go to the ticket machine of the S-Bahn. But also, go and test it in the lab so that you have a controlled environment. And then you ask, yeah, how do I test? Well, the first thing is go and get some real people. Of course, it can be difficult to actually get people into the lab, but it's not impossible. So once you have people in the lab, here are some methods. There are so many usability evaluation methods that I'm not going to list them all. And I encourage you to go and look them up yourself, because it's also very personal what works for you and what works in your situation. When using these methods, you want to evaluate how well a solution works. So you go and look at some metrics so that at the end of your evaluation, you can say, OK, we've gone down a good job. This can go better. OK, maybe we can remove that. So these are the standardized ones. So how effective are people, et cetera, you can read. For a quick start guide on how to perform usability studies, this is quite a nice one. And the most important thing to remember is that preparation is half the work. First thing is to check that everything's working. Make sure that you have everyone you need in the room, et cetera. And maybe most importantly, usability and usable security is still a growing field. But usability is a very large field. And most likely, all the problems that you are going to face, or at least a large percentage, other people have faced before. So this book describes a lot of the stories of user experience professionals and the things that they've come up against. So a homework exercise, if you feel like it, is looking at basically analyzing who is your user and where are they going to use the application. And also something to think about is how might you involve your user, not just during the usability testing, but also afterwards. Now I want to go into some case studies of encryption systems. Now there's quite a lot, and this is not all. This is just a small selection. But I want to focus on three. I want to focus on the OpenPGP standard on Cryptocast and on TechSecure. So OpenPGP, well, email is now almost 50 years old. We have an encryption standard, Asmai. It's widely used. Well, it's widely usable, but it's not widely used. And well, GnuPG is used widely, but it's not installed by default. And when usability teaches us one thing, it's that default rule, because users don't change defaults. Now you might ask, OK, PGP is not installed by default. So is there actually still a future for OpenPGP? Well, I would argue, yes. We have browser plugins which make it easier for users. And you might say, OK, JavaScript, crypto. I'll come back to that later. But when we look at Milvolo, we see, well, the EFF scorecard has a pretty decent rating, actually compared to that of native BGP implementations. And also, Google has announced and has been working for quite some time on their own plugin for end-to-end encryption. And Yahoo is also involved in that. And after the Snowden revelations, there has been a widespread surge in the interest in encrypted communications. And this is one website where a lot of these are listed. And one project that I especially would like to emphasize is Milpile, because I think it looks at a very interesting approach whereby the question is, can we use OpenPGP as a stepping stone? OpenPGP is not perfect. Metadata is not protected. Header is not protected, et cetera. But maybe when we get people into the ecosystem, we can try and gradually move them to more secure options. Now, what about CryptoCats? So CryptoCats online chat platform that, yes, uses JavaScript. And of course, JavaScript Crypto is bad, but it can be made better. And I think JavaScript Crypto is not the worst problem. CryptoCat had a pretty disastrous problem whereby all messages that were sent were pretty easily decryptable. But actually, this is just history repeating itself, because PGP 1.0 used something called Basomatic, the Basomatic Cypher, which is also pretty weak. And CryptoCat is improving, which is the important thing. There's now a browser plugin. And of course, there's an app for that. And actually CryptoCat is doing really, really well in the EFF benchmarks. And CryptoCat is asking the one question that a lot of other applications are not asking is how can we actually make Crypto fun? When you start CryptoCat, there's jelly noises, and there's interesting facts about cats. It depends on whether you like cats, but still, it keeps you busy. Now, the last case, TechSecure, also has pretty good markings. And actually, just like CryptoCat, the App Store distribution model is something that I think is a valuable one for usability. It makes it easier to install. And something that TechSecure is also looking at is synchronization options for your address book. And I think the most interesting development is on the one side, the Cyanogen Mod integration, so that people will have encryption enabled by default. Because as I mentioned, people don't change defaults. And this one is a bit more controversial, but there's also the WhatsApp partnership. And of course, people are saying, yeah, it's not secure. We know, we know, EFF knows. But at least it's more secure than nothing at all, because doesn't every little bit help? Well, I'd say yes. And at least it's one stepping stone. And all of these are open source. So you can think for yourself, how can I improve these? Now, there's still some open questions remaining in the usable security field and in the wider security field as well. I won't go into all of these. I want to focus on the issues that developers have, issues of end user understanding, and of identity management. Because the development environment, there's the crypto plumbing problem, as some people call it. How do we standardize on a cryptographic algorithm? How do we make everyone use the same system? Because, again, it's history repeating itself. With PGP, we had RSA changed for DSA, because of patent issues, IDEA changed for CASTS, because of patent issues. And now we have something similar. Because for PGP, the question is, which curve do we choose? Because this is from Bernstein, who's got a whole list of all the curves, but a large selection of the curves, analyzing the security. But how do you make, well, pretty much the whole world agree on a single standard? And also, can we move towards safer languages? And I've been talking about the usability of encryption systems for users. But what about for developers? So API usability. And as I've mentioned, language usability. And on top of that, it's not just a technical issue. Because, of course, we want to secure microchips. But we also want to secure social systems. Because, in principle, we live in an open system, in an open society. And a system cannot audit itself. So OK, what do we do? I don't know. I mean, that's why it's an open question. Because how do we ensure the authenticity of my Intel processor in my laptop? How do I know that the random number generator isn't borked? Well, I know it's borked. But then there's the issue of identity management related to key management. And who has the keys to the kingdom? One approach, as I've already mentioned, is key continuity management. Whereby we automate both key exchange and whereby we automate encryption. So one principle is trust on first use. Whereby, well, one approach would be attach your key to any email you send out. And anyone who receives that email just assumes it's the proper key. Of course, it's not fully secure, but at least it's something. And this is really, I think, the major question in interoperability. How do you ensure that you can access your email from multiple devices? Now, of course, there's metadata leakage. PGP doesn't protect metadata.  So what do we do? We do anonymous routing. We send it over tour. But how do we roll that out? And I think the approach that Milpile is trying to do is interesting and, of course, still an open question, but interesting research nonetheless. Then there's the introduction problem of how I meet someone here after the talk.  But either I get their card, which is nice, or they say what their name is. But they're not going to spell out their fingerprints. So the idea of ZUKUS Triangle is that identifiers are either human-meaningful, secure, or decentralized. Pick two. So here are some examples of identifiers. So for Bitcoin, lots of random garbage. For OpenPGP, lots of random garbage. For Miniloc, lots of random garbage. So I think an interesting research problem is can we actually make these things memorable? I can memorize email addresses. I can memorize phone numbers. I cannot memorize these. I can try. Then the last open question I want to focus on is that of end user understanding. So, of course, we all know that all devices are monitored. But does the average user, do they know what worms can do? Have they read these books? Do they know where GSEQ is? Do they know that Cupertino has pretty much the same powers? Do they know they're living in a panopticon? Do they know that people are killed based on metadata? Well, I think not. And actually, this is a poster from the university where I did my master's. And interestingly enough, it was founded by a guy who made a fortune selling sugar pills. Now, snake oil. We also have this in crypto. And how is a user to know whether something is secure or not? Now, of course, we have the secure messaging scorecard. But can users find these? I think there's three aspects to end user understanding, which are knowledge acquisition, knowledge transfer, and the verification updating of this knowledge. So as I've already mentioned, we can do dummy proofing. And we can create transparent systems. For knowledge transfer, we can look at appropriate metaphors and design languages. And for verification, we can try and approach truth and advertising. And last but not least, we can do user testing. Because all these open questions that I've described and all this research that's been done, I think it's missing one key issue, which is that the security people and the usability people tend not to really talk to one another. The open source developers and the users, are they talking enough? And I think that's something, if we want a new dawn, that's something that I think we should approach. Yeah, so from my side, that's it. I'm open for any questions. Arnie, thank you very much for your brilliant talk. Now, if you have any questions to ask, would you please line up at the microphones in the ails? The others who would like to leave now, I'd ask you kindly to please leave very quietly so we can hear what the people asking questions will tell us. And those at the microphones, if you could talk slowly, then those translating have no problems in translating what has been asked. Thank you very much. And I think we'll start with microphone number four on the left-hand side. Yes, so if you've been to any successful crypto party lately, you know that crypto parties very quickly turn into not about discussing software or how to use software, but into a thread model discussion and to actually get users to think about what they're trying to protect themselves for. And if a certain messaging app is secure, that still means nothing because there's lots of other stuff that's going on. Can you talk a little bit about that and how that blends into this model about how we need to educate users and what we're actually educating them about and what they actually need to be using? Well, I think that's an interesting point. And I think one issue, one big issue is, OK, sure, we can throw lots of crypto parties, but we're never going to be able to throw enough parties. With one party, you're very lucky you're going to educate 100 people. Just imagine how many parties you need to throw. It's going to be a heck of a party, but yeah. And I think, secondly, the question of threat modeling, I think, sure, that's helpful to do, but I think users do first need an understanding of, for example, the email architecture because how can they do threat modeling when they think that an email magically pops from one computer to the next? I think that's pretty much impossible. I hope that. Thank you very much. So microphone number three, please. Arne, thank you very much for your talk. There's one aspect that I didn't see in your slides, and that's the aspect of the language that we use to describe concepts in PGP and GPT, for that matter. And I know that there was a paper last year about why King George can't encrypt, that tried to propose a new language. Do you think that such initiatives are worthwhile, or are we stuck with this language and should we make as good use of it as we can? I think that's a good point. And actually the question of, OK, what metaphors do we want to use? I think we're pretty much stuck with the language that we're using for the moment, but I think it does make sense to go and look into the future at alternative models. Yeah, so I actually wrote a paper that also goes into that bit looking at the metaphor of handshakes to exchange keys. So for example, you could have an embedded device on your, as a ring or a wristband.  Could you use that shaking of hands to build trust relationships? And I mean, that might be a better metaphor than key signing, webs of trust, et cetera. Because I think that is horribly broken for the concept, trying to explain that to users. Thank you. And at the back in the middle. Thanks. A question from the internet. Mold from the internet wants to know, if you are aware of the PEP project, the Pretty Easy Privacy, any opinions on that? And another question is, how important is the trust level of the crypto to you? Yeah, so actually, there's a screenshot of the PEP project in the slides in the why WhatsApp is horribly insecure. And of course, I agree. And yeah, I've looked at the PEP project for a bit. And I think, yeah, I think it's an interesting approach. But yeah, I still have to read up on it a bit more. Then for the second question, how important is the trust in the crypto? I think that's an important one, especially the question of how do we build, how do we create social systems to ensure reliable cryptography? So one example is the advanced encryption standard competition. Everyone was free to send in entries. The design principles were open. And this is in complete contrast to the data encryption standard, which I think the design principles are still top secrets. So yeah, I think the crypto is something we need to build on. But actually, the crypto is, again, built on other systems where the trust in those systems is even more important. OK, thank you. Now microphone number two, please. Yes, Arne, thank you very much for your excellent talk. I wonder how about what to do with feedback for unusability in open source software. So you published something on GitHub, and you're with a group of people who don't know each other, and one publishes something, and the other publishes something. And then how do we know this software is usable? In commercial software, there's all kind of hooks on the website, on the app that send feedback to the commercial vendor. But in open source software, how do you gather this information? How do you use it? Is there any way to do this in an anonymized way? I haven't seen anything related to this. Is this one of the reasons why open source software is maybe less usable than commercial software? It might be. It might be. But regarding your question, how do you know where the commercial software is usable? Well, one way is looking at what kind of statistics do you get back?  So the best approach is to design usability in from the start, the same with security. And I think that is also so even if you want privacy for end users, I think it's still possible to get people into the lab and look at, OK, how are they using the systems? What things can we improve? And what things are working well? So you're saying you should only publish open source software for users if you also test it in a lab? Well, I think this is a bit the discussion of, do we just allow people to build houses however they want to? Or do we have building codes? And I think actually this proposal of holding software developers responsible for what they produce if it's commercial software. I mean, that proposal has been made a long time ago. And the question is, OK, how would that work in an open source software community? And well, actually I don't have an answer to that, but I think it is an interesting question. Thank you. Thank you very much. Number one, please. You said that every little bit helps so we can have systems that don't provide a lot of almost any security. That provide just a bit of security and there's still better than no security. My question is, isn't that actually worse because this promotes a false sense of security and that makes people just use the insecure broken systems which will go and say we have some security with us? I completely agree, but I think that currently people, when you think, OK, an email goes from one system to the other directly and from the studies and interviews that I've done, I've met quite some people who still think an email is secure. So of course, you might give them a false sense of security when you give them a more secure program, but at least it's more secure than email, right? Thank you. Thank you. There's another question on the internet. Yes, thank you. A question from the internet. Bot Crypto, would you finally recommend your grandma to use? Well, unfortunately, my grandma has already passed away, so I mean, her secrets will be safe. Well, actually, I think something like where crypto is enabled by default, say, iMessage, I mean, of course, there's backdoors, et cetera, but at least it's more secure than plain SMS. So I would advise my grandma to use, well, to look at, OK, well, actually, I would first analyze what does she have available, and then I would look at, OK, which is the most secure and still usable. Thank you very much. So microphone number three, please. So just wondering. You told that there is a problem with the missing default installation of GPG on operating systems. But I think this is more of a problem which operating system you choose, because at least I don't know any Linux system which doesn't have GPG installed today by default if you use, at least if you use the normal workstation setup. Yes, I think you've answered your own question, Linux. I mean, unfortunately, Linux is not yet widely default. I mean, I would love it to be, but yeah. But if I send an email to, well, let's say, Microsoft and say, well, install GPG by default, they're not going to listen to me. And I think for all of us, we should do a lot more of that, even with Microsoft. Even if Microsoft is the devil for most of us. Thank you. For that. We should be doing more of what? Making more demands to integrate GPG by default in Microsoft products, for example. Yes, I completely agree. I mean, what you already see happening, well, I mean, it's not very high profile yet. But for example, I mean, I refer to the EFF scorecard a couple of times. But that is some pressure to encourage developers to include security by default. But as I think I've also mentioned, one of the big problems is users at the moment. Developers can say, OK, my system is secure. I mean, what does that mean? And do we hold developers and commercial entities? Do we hold them to, well, truthful advertising standards or not? I mean, I would say, let's go and look at what are companies claiming and do they actually stand up to that? And if not, can we actually sue them? Can we make them tell the truth about what is happening and what is not? So we've got about two more minutes left. So it's maximum two more questions. Number two, please. Yeah, so every security system fails. And I'm interested in what sort of work has been done on how do users recover from failures of this way? How do users recover from failures? Everything will get subverted. Keys will be your best friend will sneak your key off your computer. Something will go wrong with that. Your kids will grab it. And just is there, in general, has somebody looked at these sorts of issues? Why, I think. Is there research on it? Of various aspects of the problem. But as far as I'm aware, not for the general issue and not any field studies specifically looking at, OK, what happens with key compromise, et cetera. But we do have certain cases of things happening, but nothing structured, no structured studies, as far as I'm aware. OK, thank you. Thank you. Number three? Yeah. You mentioned mail pile as a stepping stone for people to start using GNU PG and stuff.  Shouldn't we actually talk about how to make encryption transparent for the users? Why should they actually care about these things? Shouldn't it be embedded in the protocols? Shouldn't we actually talk about embedding it in the protocols? Stop using unsecured protocols. And having all of these, you talked a little about it as putting it in the defaults. But shouldn't we emphasize that a lot more? Yeah, I think we should certainly be working towards, OK, how do we get security by default? But I think I've mentioned it shortly, that making things transparent also has a danger. I mean, this whole, it's a bit like a system should be transparent is a bit like marketing speak. Because actually, we don't want systems to be completely transparent. Because we also want to be able to engage with the systems, look at our systems working as they should be.  But yeah, something that you achieve through usability studies, security analysis, et cetera. Thanks. All right, Arne, thank you very much for giving us your very inspiring talk. Thank you for sharing your information with us. Let's give him a round of applause. Thank you very much.


Without further ado, uh, this is Elvis Callado. He's going to be presenting on some really cool, uh, research that he manipulated. Yeah, sure. Yeah, sure. Alright, awesome. Thank you so much for joining us and here we go. Tossed. Is that good? Alright. Thank you everyone and welcome for coming. This is my talk called Green Waves. Alright, let's get started. So this device up here that you see is called the Green Wave G1100. It was distributed by Verizon FiOS and Frontier. They're an ISP up in the northeast and we have Verizon for the file service which is not available in my area but this is what they gave you. So if we look a little there we got our FCCID. So what do we do with our FCCID? We go online and we find the internal photos and then we find the processor and we look it up. There's no data sheet for that unfortunately but we see the shield is on cover, we see two memory modules and if you see something like over here you may be going, hey, what's going on over here? Well, you have every reason right to be because this over here is JTAG. Awesome. So I just grabbed my, I think it was like JTAGulator or my Arduino. It's 33 Logic so it doesn't really matter. Uh, got the pinouts. So this in the middle, open up the device, this thing right here. In the middle we have four pins and what do you think it is? You are, right? So we have ground, receive, transmit, 33. Unfortunately when we turn on the device, standard in is blocked so all we get is standard out so receive is, you know, we can't type anything. Crap. We cannot do anything whatsoever. We just see standard out, we just see print logs but we're not seeing it, we can't do anything. That's, that's boring. So after some thinking because I want to keep everything software based I don't want to touch hardware like yeah there's a NAND flash, we can remove it. That's the last thing I want to do. Like I'd rather go with the software route because it's ripping crap out and I mess up, I got to buy a new one and I just forget all that. So I just solder some, so it takes like a hot glue gun. Uh, you know, find an area on the board that has no copper exposed, put a little bit of hot glue on there, take some header pins, just stick it on there, wait for it to dry and then I take some wires and I just, you know, solder it on and it's not the prettiest thing in the world. Uh, but you know and then I just attach some wires, put it on my FTDI base breakout board over here, turn on open OCD with my configuration on my FTDI board and we see automatically, boom, we do have a JTAG interface, we have the ID, we see the manufacturer ID is ARM base, woo hoo. So then we open up our own target configuration, so we set the reset config, we have test reset, we have system reset, it's a push pull situation, uh, we have a new like tab with the ID at the very end of it and then we create a Cortex-A, uh, target that's little Indian and then after that we run it again with our two configurations, the board and the target and look, oh, also we have six break points, four watch points and you know, I can just tell it into open OCD, like always and give it commands or attach GDB to it and start analyzing memory once I halt the processor. So before we get on to the next slide, so the first thing I started doing once I had JTAG was I don't have a data sheet for this chip whatsoever, so I'm dumping memory addresses, if something is not, you know, unaccessible, I just write that out. So I'm dumping, dumping, dumping, halting the, uh, the boot up process in different stages, I'm trying to find the kernel boot arguments. So after about an hour or two, I think about two or three hours, it was kind of a while, I finally found it and I set a watch point to the very last character that kernel argument, kernel boot argument, uh, so that when it's done writing for a watch point, I can set a break point, well, it'll, you know, break and uh, I can overwrite it. So instead of a knit calling slash a knit, um, I can set, no, instead of calling this upon initialization because I don't have view boot access, like yeah, I could ground clock on the, uh, on the NAND or so or, you know, whatever and make it fail and maybe I can, you know, do a second retry and get into it, but again, I don't want to touch hardware. So, um, I'm able to overwrite the kernel boot parameters, set a knit to BNSH. All right, awesome.   So great. So this gives us access to rip the firmware off and get debug capabilities, right? So the very first thing I do is I go through all the RCS initialization scripts, I get everything running and I look for all the running daemons. I don't care if it's WAN base, LAN base, everything's open scope in my eyes. So I'm looking at anything that's listed on all interfaces zero to zero or, uh, you know, an internal interface. Uh, IP tables can maybe come into play later, but we'll get into that later. So very first thing, I'm looking for low hanging fruit and someone please script me out. UDP 1900 is. Yes, awesome. It is known as SSDP.  But anyways, we have three binaries here. We have three different SSDP servers. WPS monitor. Front tier four is about a 32 megabyte C++ file. Have fun with that. It's kind of fun to look at. Fun. Uh, we have mini UP and PD, which probably is vulnerable to the readout of bounds volume that I posted earlier this year. So anyways, today we're going to be talking about WPS monitor. So before I even start ripping things out, I need to know my environment. Um, because I need to know like, you know, do I need info leak? Uh, do we have an extra keyboard stacked? Do we have an extra keyboard? Well, what the hell am I looking at? Right? So very first things I do is I look at all, you know, there's a Lib UPP library. You can see like, oh, I'll Lib UPP. It's nothing until one. So remove all like assumptions out of your head. Uh, and also we have ASLR on the imported libraries. Surprise. We look at a stack in the heap. We have depth. Awesome. Uh, we also look at the heap over and over again, you know, and we see that ASLR does impact the heap based headers in the stack. Cool. Uh, the only thing that we see here is that this WPS monitor, the main binary itself is not ASLR, uh, whatsoever. So we do have a static binary. We have a gadget. The problem is we have null bytes in this 32 bit address. So if we have a string based overflow or anything like that, we can't use this because of limitations of a string. You know. So, after that, this device does have USB devices. So I plugged in the FAT32 device in and then just DD, uh, you know, look at mount, see where the file says to be mounted from, DD down to, uh, the USB drive. And then after that, one, two, three, bada-bing, bada-boom. We use bin walk, like always, and we extract the file system. So now we're going to get more into the nitty gritty, happier stuff. Vuln hunting.  Like some people have all, you know, super dope scripts.  And that sucks, right? It's like, oh, I looked at strings from the vuln. And that's exactly what I do first. I'm looking for low hanging fruit, least path of resistance. So I'm looking for a percent S, right? Because what are the destinations for a format string? We have a buffer or some sort of file descriptor in Linux, right? We have syslog, uh, or we print the standard out, or we're gonna, you know, save it something to a buffer and do whatever, right? So I see this very first response. HP11 OK blah, blah, blah. I see percent S here. See percent S there. Percent S here. Over here is a percent S. And over there, there's a percent S as well. And that's very interesting to me. So I'm like, all right, what is, what is this response? Right? Like what function is using this? So I see this immediately. Looked at x refs. And I'm like, oh, that's nice. Sprint F. But, you know, remember, Sprint F is there copying all those like vulnerable C functions can be used in non-vulnerable way, right? So just because it's printed out doesn't mean it's vulnerable. So we look up, what is R0? The destination buffer coming from. So we look at, it's from R5 going to R7, you know, then adding some more to R7 and putting it on the R0. So this right here seems to me that we're accessing some sort of member and a structure, right? Or, you know, an object, but still a structure, a C. So we're accessing something.  Like, you know, we get an address from Malik. We save it there. Uh, maybe it's calculating the length beforehand and, you know, maybe it's not vulnerable. Like I said, who knows? Or maybe this is a character buffer, um, inside the structure that has a fixed size. Who knows? So we need to do more research. So the next thing I do is I'm looking at the UPNP, um, uh, specifications going, what is this, uh, message for? And we see that we have something called a SID, which is a unique identifier. And we have this timeout second dash and this is actual subscription time. Something in R, we probably have second dash and some integer, right? So I'm like, well, what's causing this response? And we see this. It's called a subscribe. Subscribe, publish your path. And I'll, I'll show that. What's that afterwards? We have something called a callback. Host and user agent are optional. So that's why they're not bold. Callback is, uh, mandatory. It is wrapped around, uh, angle brackets or less and greater than whatever. Uh, we have NT set to UPNP event, which is static, has to be that. And then we have timeout second dash and then it requests, uh, duration. Second dash, um, again, probably an integer. Second dash 20. Second dash 900. Whatever. So, uh, what is this for? Like, what part is this? What is a publisher path?  But everyone talks about the control URL, the soap actions. And that's not what we're talking about today. We're talking about this, the event URL, which is called the GINA stat. I forgot what it stands for. Tell them ahead, but just trust me. It's called GINA. Um, so the very first things we do is we launch up some notepad editor, VIM, whatever, but this is not VIM. I think it's Zed or something like that. Uh, so we use, you know, requests. We're gonna send a request that, come on. Uh, we do second dash and then a string instead of like an integer. Because I just want to see first hand if this percent S that I'm seeing in the response is even worth looking at. Uh, this is, you know, maybe pass it to a toy first.  Like that's not exploitable or anything worth looking at. So I need to dig deeper. So we just send it and awesome. I sent a string, I get a string back. That's awesome. So okay, this seems kind of interesting now. So that percent S is what we control. So okay. So next things we can do is we have two things we can do.  Um, I mean like, yeah, we can chase down the structure and like, you know, we can find CSI functions and find where arguments, you know, it's being passed to you. We know that, you know, like a stir copies a character buffer of character pointer. So this is a character pointer or whatever. Or maybe if we look up certain strings online like on get duck duck go, uh, Google, whatever, maybe we find the structure that we're clobbering potentially and we find everything, but this is supposed to be confidential. So I didn't have all this at the time. So screw it. We'll just black box it. Kobe. So next thing. So I set up a for loop that same as that code just in a for loop. I'm incrementing now by one byte at a time, that second dash. And I have GDB attached. It's going to keep going and going and going and going and going and going. Any kind of reset sets to me just try again and keep going. Right? Just keep going. And I get a segmentation fault. I'm like, oh my god. There's poly static sizes. This is awesome. Oh my god. I got to call my dad. But hold on. Let's not call my dad. Because this is just loading and compare. We're not writing anything. We're just loading and compare. That's not anything useful. And we go in IDA and we look around and yeah, alright, comparing it to R1, which I don't know the value of. It's an unknown. But you know, we have this compare. It's looking at zero and it's going to branch out and return. Ah. So alright. So I'm kind of messing around at this point because I'm thinking we have this UPNP server. What kind of states can we put this in? Kind of request can I send to this thing? We have an HP stack. We have a SOAP stack, SSP stack. We have this GINA stack. So I start thinking, I'm like, well what kind of other states can I do this in? And I find this. And I'm not going to read this wallet text to you. Basically what this says is that once you subscribe, you get a SID.  Right? So from there, is this that you subscribe for 20 seconds? And then you change your mind. No, no, no, I meant to subscribe for like 100 seconds. Well, you send a second subscription with your SID and with a new timeout value. I was like, ah, maybe we can like hit some new code with this type of thing. So we subscribe first, save the SID, and then we cause the overflow and see what happens, right? So I do the thing again. And we get a different site fault. I'm like, oh. Better be something good, right? So I start looking and I'm like, oh, we see this load. You know, offset 24 to R3. We do a compare branch on zero. So if it's null, we don't call it. You're not going to call null. And then it jumps to it with the uh, with the exchange. So we can jump modes in thumb mode, arm mode, whatever, right? And I'm looking at this, I'm like, what's R3? I'm like, oh, that's the value I control. That's my name. That's awesome. So, okay. So we have, so I got lucky, right? I got super lucky, but I don't care. That's my luck. So going on, I kind of have a way to obtain PC control. We're one pointer away, right? We're almost there. Still can't use WPS monitors a gadget because we're still bounded by the limitations of a string. Can have a null byte because that's the terminator. Uh, ASLR and import libraries that don't have an infleek. So whatever, right? So now to the exploit development of this. So we're thinking, we're thinking, I have one pointer away. I have ASLR. I have depth on a heap and stack. One pointer away.  You know what this reminds me of actually?  I don't care. Anyone? Yes, awesome. Cool. So that's exactly what it reminds me of. I'm like, okay, new tactic. Screw the infleek. Let's find a way to spray the heap. Let's figure out to do some, you know, some David Blaine magic stuff. And then, you know, maybe we can trigger the overflowing code exact, right? And speaking of which. Oh, whoops. I need to start this. So you're about to witness the world's slowest exploit. My exploit takes about 20, 28 minutes and 30 seconds to run. So we're, we're going to start it. Just want to make sure it's running before I go back to my slides. Alright. One second please. This is slow. Alright. There we go. Alright, cool. So let's go back. Alright. So this says spray the heap, do some magic, trigger overflow, get code exact. So we look at the heap. So I need, I need information now. What is the base address of this heap, like loading it every single time? So I need a target address to maybe grow this heap towards, right? So look at it once, maybe twice. Look at it again, and again, and again, and again, and again, and again, and again, and again. That's okay. You know, we can do that later, right? We need more off-screen. That's, that's boring. So, um, also I need to know how much memory do I have?  Yeah, my age is showing, right? Or, you know, at least a gig. So spraying the heap is not really that much, you know, not much, you don't have to worry about it, and running out of memory and stuff like that. But we have 117 megabytes free. Or, you know, I don't want to be, you know, taking up everything. So let's just call it 100. 100 megs. So theoretically, if the heap always loads at zero, just think about that. The maximum size I can grow the heap to is 0 6, 0 6, 0 6, 0 6, or whatever, right? So awesome. I can grow the heap to a very large size potentially, if I find a primitive to allow me to. So after doing all that stuff and putting everything to like an array, oh that's an array, into a spreadsheet, and seeing like the top and bottom and see, like what's, what's going on here? Like what's the, you know, like what's the highest address the heap actually loads on to and stuff like that? So I actually saw that it loads under 0 303 all the time. We see like an 0210, but it always loads under 0 303, so I'm like, all right, cool. So I start looking at the description functionality. Like how does this work? I need to find primitives. I need to fill the heap. I need to do memory leak. Not info leak and memory leak. I need to fill up the heap. So I start looking at this. So I start looking at Stirling and it goes to a calic. And I find out that that pointer there is the starting, it's the URL portion of the callback. So after the IP colon port slash, and then the end of it, that's, that's where we're at. So that's where that pointer is to. That's slash, and then maybe like ABCD, right? The closing bracket is null terminated at this point. So we're just going to add some sort of size to it. So it's going to be size of some structure, right? So we have some structure. And where the last element is some character buffer array. And then we call calic. If you're not sure what calic does, it takes the values of R1 and R0, multiplies them, checks for overflow condition. This is a very high level. And then it calls malloc, gets a pointer back, mem sets it and returns it back to you. So everything's going to be initialized to 0.  So we go into GDB, we set some break points, and you know, we get the length and we get to turn edges because I need to learn how to, you know, I need to start spraying this stuff. So I set up a for loop to subscribe over and over and over and over and over again.  All right, I'm getting the same pointer over and over again. Just so in my head, I'm like, all right, so it's being freed, alec'd again, freed, alec'd again, freed, alec'd again.  So step back. If I were to develop this, if I were, you know, on some team where I'm stressed out to get something delivered by the end of the week, I'm like, well, having one block for subscriptions for multiple devices makes no sense, right? If I'm just using the same block, we're free one block with two devices, that's almost like a used out the free situation, or only I support one device at a time. So I go, well, let's change something in my subscription. They can change IP address maybe, change the port number, change the URL. So for simplicity, I just do like a four I and range or two, whatever, and use the I to add it to my port range.  I can now spray blocks of 4k. Awesome. I have a way to fill the heap. So in theory, this is what I'm doing. Subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe, subscribe.  Okay, cool. Let's cool. You can fill the heap. We can spray the heap, but we still need to do some dope David Blaine magic, all right?  So I start reading the manual some more. We go back to the architect, you know, the specifications, and I see this request now, unsubscribe with the publisher path with your SID. I'm like, all right, let's go back to the code. And I find this function called delete subscriber. I wonder what it does. And I see this little wrapper of free here, which literally just takes a pointer passes to free. So I set a break point there. I go, well, what is this pointer? Right? Like we have runtime capabilities. Like, I don't feel like spending all the time reversing all the things. Don't limit yourself to just one way. Use the easiest ways. So I'm like, oh, so if I subscribe, and I reverse the array of all the cities that I saved, and I set them to unsubscribe, they're, they're freed. These are my blocks. I'm using the awesome. So I have an ability to spray the heap, and I have the ability to free blocks at will. And I can make holes in the heap if I want to or whatever, right? So back to monkey in a round. Because this is the heap spray portion, but I'm like, okay, I'm still bounded by the limitations of a string. I can't do anything yet. I can fill up the heap. That's, that's fine. But, you know, I can't use WPS monitor as a gadget yet. So I started talking to a colleague who works on different products but also has experiences with heap stuff. I'm just bouncing ideas back and forth with my colleague. It's kind of like rubber ducking. And so I sent him my IDB. And I'm like, hey man, I'm looking at this. You know, this is my limitations, this is what I can do so far. You know, you can look at all the, you know, references to malloc, calic.  But we start going back and forth and he asked me a question. He goes, hey, this function here about base 64 decoding uses malloc. What is that all about? Like a UPMP, base 64.  Awesome. So we go back to soap. The thing I did not want to talk about whatsoever. And I started looking for an action with one argument because I don't want to deal with multiple arguments and it's just, it gets kind of messy. And I find this, this delete AP settings. Sure, whatever. What kind of type is this new AP settings argument? Go all the way down to the bottom of XML. We see it's a base 64 type. So we can send a soap request to this action and inside the XML, inside the text, we just, you know, base 64 encoded string. I can base 64 encode nulls. Okay. So what I do next is like, all right. So when I send the soap action, I set a break point. I look at the heap block and it's actually the decoded data that I sent to it. It's not the base 64 string. Awesome. I can now write nulls and I can probably use WPS as some sort of gadget if I can figure out the way to spray my fake object into the heap. So I try this out. So we do it. We unsubscribe. We call the soap action. We unsubscribe. We call the soap action unsubscribe. And then I look at this. This is early development of my structure. That's why we see like 0202, 0303, just lining everything up. The very first one is my first gadget. So whatever. But I'm trying to set things up. So I'm doing everything by hand at first and I'll, you know, make it nice and pretty later. So, okay, we can spray the heap now. We're kind of almost there of doing some magic. But wait, roadblock. All right. I do my spray and do my technique and I'm like, all right, let's look at this address and it's not there anymore. Shit. All right. Well, what's going on? So to think about the layman's terms, like super simplistic, you can't build a house without a roof, right? That seems silly. So my technique right now, I'm like, you know, I got all these subscriptions. I unsubscribe. Do your soap action. I unsubscribe. Do your soap action. Unsubscribe. So, you know, blah, blah, blah, blah. And we're going down the line and, you know, and then the rest, right? But then the Linux kernel is like usually an application. You got all this free space in Melik. You don't need this anymore. So it eats it all the way and revokes it from me and gives it to another application or anything else that needs the memory, right? So that's what's going on. So I'm like thinking, I'm like, well, instead of freeing everything, what if I leave the last allocation there? Because in the seconds, there's actually an option to do infinite, where you'll never, ever run out of time for your subscription. It's forever until the application, no, until like reboots or something. But either way. So now I fill up the heap. I pop the last allocation off of my array, reverse it. Now I do a unsubscribe on the second to last and I go from there, right? So this is awesome. So this is working fine until... Come on. Until this happens. So my way to do the base 64 thing is right into the same block over and over again. I'm no longer putting something on top of the free list, occupying it, getting freeed again, free something else, put on top. It's not, it's something else just racing to it. Something else is causing some issues.  So I'm going to set just a simple break point on free. If it's null, just keep going. I don't care about null being passive freed. So we just keep going and we're just going to wait. And actually it does some stuff every 60 seconds because there's also other imported libraries and you know, we've got to see if they're doing something or the main binary is doing something. Because if there's a race condition, this makes the exploit that we're trying to do much less reliable and it's not really worth going for anymore. So I look at it and I'm like, all right, let me set an M search request. Because if you use Google Chrome for example, when you open up your browser, go to YouTube, your browser sends an M search request on multicast because it's looking for something called a dial server, which is a layer of UPMP developed by Netflix. You can find the GitHub, find the code. You can also look at the Chromium code branch and find the dial code. But anyways, we send an M search request. We see that there's port and it's being freed. Okay. We find the sizes by looking at the heap header manual and stuff like that. So every 60 seconds, this device sends out a notify request on multicast. Sends it out and says to everyone, hey, you know, I'm here. Here's Maximil. Go and chat. That's cool.   This is what it looks like. So I'm going over all these different instances as to like what can get in there, what kind of requests and the sizes so that I set up my heap a little bit differently. So now I have two arenas. So I have one arena where I have spaces for these objects to fit in too perfectly. And they can jump in there all they want because I'm making holes. It'll never get like condensed or whatever. It may get trimmed. It doesn't matter. Then I have my other arena where I have that last allocation being set and I do the whole thing. So now we shift gears. So now what I'm doing is a free, replace, free, replace, free, replace, blah, blah, blah.  So we resubscribe and we come back down. And also what we're doing is between every single iteration is that we have a UDP socket listening on multicast. We select it upon every single iteration. There's something to read. We slurp it up. And we also maybe do some more subscriptions and replacing just to unfoo bar anything at the top of the free list because we don't want anything else to race there. So next we can spray the heap. We can do some magic now. We can now use WPS monitor. We can write nulls to the heap and stuff like that. I guess base64 decoded. That's awesome. But we don't have an exploit chain yet. So I'm thinking, I'm like, all right, let's cause the crash and we look at what do we control? Right? I don't use like, sometimes I use like, point of bug and stuff like that. But if you use an open OCD and you have point of bug running, you have a lot of issues that may occur. So I just haven't commented out my gdb init. But anyways, the only register that we have control of really is R4. R4 points to our overflow string. And yeah, the first pointer is going to point to something in the heap, blah, blah, but let's just assume the very first one is just 41, 41, 41, 41. So I have a pointer that points to my data. That's all I have. So I start looking online. I'm like, all right, let's think back about Internet Explorer days.  Oh, we did a stack pivot, right? We have like one shot. So we do a stack pivot.  We, if we have depth, we have a bunch of returns. So, you know, we shift the stack to the heap and then we return, return, return. Then we have our drop gadget to call virtual protect and we X2 shellcode, but it being but a boom. So I start looking online and I see this. So this was from 2012, a rock scone talk about exploiting stuff on R and blah, blah. And it has this load multiple decrement before instruction. And what does it do really?  I'm like, oh, man, God. So I open up Redair and I look for this load multiple, load multiple deduct before with R4 and I see some instructions. So I plug it in, very first thing and illegal instruction. Well, what the hell? Like what? Why? So we look at the ARM manual and we see this restriction on the second line. The register destination list cannot contain SP. The destination list that I had before has SP to second to last one. This is now an illegal instruction. I can't use this technique on this device. So all right, back to the drawing board. So what I do next is I develop a rejects for IDA. I'm looking for load where the last, the last register, you know, second operand or whatever of that opcode is R4 being dereft. That's all, that's what I want. So I set up a rejects to do that. I find a bunch of them, I go through them by hand and I find this gadget here. And then it says like dereft R4 and R3. We add all these offsets and we get R2 and we have R1 and R0. I'm spraying 4K blocks here. Hex 1000 is 4K. So we're just going to jump into another block that I'm in control of with my data. So this right here gives me the primitive of calling a function with two arguments. Okay, cool. But the problem is though once, once this function, like once what I call returns, it's going to use the stack now and it's going to pop PC and I no longer have control. So I only have a one shot situation. So I'm thinking, I'm thinking, like what can I do? I'm like, alright, so let's look at functions that write, like that write to memory that are not bounded by character limitations. So I started looking at mem copies. This thing has tons of them. So you know, I'll put on my music or whatever and I start grinding through this. And I find this mem copy here and you don't have to read all this. I know it's probably hard in the back and I apologize. I'll sum it up. So this right here, if you look at the second to last instruction, r0, the destination, is a stack based buffer. Even though the stack frame is kind of large at like 2k, you know, hex 800, we still have a destination buffer that's a stack. And r0 and r1 are in our control now because that was the last gadget that gave us control. And r1 is in r4, r0 is in r5. We look in, r4 is n, r5 is the source.   I control n.  So that's what I do. And we look at the bottom of this thing so we adjust the stack frame so we have to be careful now. This is a large adjustment, 2k. So we're not going to jump back and do stuff. We're now just incrementing the stack. We have to be careful not to run out of stack space and cause us, you know, like an interrupt to happen or a signal to happen and kill the program. So now we have control of r4 to r7. Now we brought the heap to the stack. So now, next gadget. R7 is going to contain a pointer to the IAT table entry, uh, inside WPSMarkz where it's not ASLard, uh, uh, start to unsign long. But with a pointer of minus 4 and this next slide you'll see why. So then after that we pop from the stack r3 to r7pc. Next thing. We deref r0 now, which is now going to take the IAT table plus 4 and it's going to, it's going to deref that pointer from the IAT table. Now we have a libc function, a pointer. Now we're inside libc. I start to unsign long. We don't need to leak it anymore. Pop from the stack. Next one. We add r3 because, look, we have r3 to r7. r3, uh, it's going to be an offset. Now we're going to add it. Well, r3 and r0 are going to be added together and we're going to save it to r0. So now it takes start to unsign long. I take an offset and I add it and I get to, since the system wasn't working, I didn't want to debug it, p open.  So then from there in gadget 6, this looks really large, but we can pick another allocation that's like maybe a megabyte away. You don't care. We're gonna write to the heap now. We have a pointer to p open and all these gadgets I found by hand. If I try to use some wrapper thing and try to automate it, I would not have found these gadgets. Rapper and everything's gonna say, hey man, there's a mem copy with R0 and R1, well R1 and R2 and R0 is being stacked. It's not gonna tell me that. So anyways, this right here I'm gonna write to the heap. I'm gonna write the p open, uh, pointer that I just calculated into the heap now. Keep going. We're almost kind of towards the end of the stack limitations here. So now I invoke gadget 1 again, which is our last gadget, gadget 7. So this one, remember, I can call something with two arguments.  So let's put it all together. So we spray the heap, we save all the subscription IDs, we don't free the last description ID, that's our roof. We free and replace the blocks with unsubscribe and we replace everything with the soap action with base 64 encoded fake structure, our rob chain, and ending with a command. Everything is aligned to 256, or actually it's, yeah, so everything is 256 by the line, whatever. So we free five, I'll be very occupied by five, free them again, go to the next five. If anything comes in multicast, fix up the heap if needed by doing resinscriptions and freeze again. Trigger vol, maybe we win. So we sue everything and we see this, right? So let's, let's check out this guy. Why is it 11 percent? No, it is at 11 percent. Why is it 11 percent? All right, so I guess I'm not doing the exploit live anymore.   Oh no, why? It's on. All right, I'm sorry, I guess I'm not doing this live. But it is reliable. I can demo it later if you guys want to see it. But uh, sorry, so we're stuck at 11 percent. But what we were doing though was the free and replace of everything that we were doing. We create two arenas and we're going all the way down. It should have been around 60 percent by now or so. So that's, that's all right. Man, let's see down here. But anyways, if, if this was working properly and didn't want to just foobar out of nowhere, we would be in the context of reading all that stuff. But the funny part about this as well, just to look up, is that there's actually one process, uh, let's see here. One process ran by nobody. It's another UPNP server. So whoever actually made the process, you know, the, the, uh, the process run under nobody, like that guy deserves a high five. So anyways, let's go back to everything. Um, uh, man, I really wanted to show that shell. Oh well, it's actually still going. It's just going really slow. Anyways, so we do have a shell and I wanted to just show you guys some bonus stuff as well. So besides the shell and all that stuff. Um, so before I remember I was saying that, you know, I was looking at daemons that were running on a particular, you know, uh, all interfaces, already just a LAN and I found one of 5916 who was being filtered by IP tables. So I started thinking, I'm like, huh, what if we use that genus stack to pivot like a server-side request forgery, right? So we set the callback address to 120 local hosts 5916 with this URL. And so we attached S trace to that daemon to see if anything's coming in. We send the request and yes, we do get that. So if you are trying to hit something that's maybe token based, so it's a TCP based connection and maybe it's like, oh, it's doing like stir-chir, they start to be getting up something or stir, like a stir-stir, like some sort of substrain that's token based. You can use this to maybe hit that part of the code and maybe change configuration or something like that. So it's a way to pivot. So last but not least, I also wanted to give a buzzing demo, but I'm not sure if it's uh, if it's going to cooperate with me, but um, I mean, after all this, so finding the bone and all that stuff taught me something valuable. So uh, I was doing this by hand and I was like, you know what, I've been finding a lot of the same kind of programming issues with this protocol and stuff like that. I have a background in network engineering, I also have a background in QA. So I was like, let me start making a fuzzer. And I encourage everyone else to do this as well because what do we have? We just have HP, we have XML. If you could just make something to just send out an M search request, get the, you know, get the, the XML file back and just parse that, make the XML parser, go through everything, save everything, make your own fuzzer. Like you'll save so much time. So instead of a few days like it took me by hand to find this volume, it would have taken me 30 seconds. So actually, let's see, now it's going, it's going now. All right, so maybe if we have time towards the end, I'll check up on it and see for uh, for all good. So anyways, oh man, everything going wrong is, that's awesome. So anyways, so if an ISP asks you, and this is going to be super cheesy, but whatever, I'm going to do it. If an ISP asks you, could you, would you install this router in your house? You must say, no, I do not, would not install this in my house. I do not want it here or there. I do not want it anywhere. I wouldn't want it for free. I wouldn't want it if it could download up to 10 GB. But anyways, that's enough of that stuff. This is who I am. So I go by Blackout Online. Someone had the real name Blackout, so I changed the L21, 020, cool, Elite Sauce, what up. I'm a zero-day researcher at Exodus Intelligence. I do embedded devices, both SOHO, I do enterprise network solutions, firewalls, virtual appliances, whatever, I don't care. If I can get it, I'm going to audit it. Smart devices or anything else that catches my eye. We're also hiring at Exodus Intelligence.  But that's about it. So again, that's who I am. Thank you for coming to my talk, Label Greenways and Ham. Take care.


Eating? Yeah.  Japanese or Korean? Oh, I'm Korean. Yeah, you're Korean. Kim Jong-un's boyfriend, huh? You're Kim Jong-un's boyfriend? Anyway, do you can try? Yes. Some people are saying he should have called the police. He did the right thing because you don't know nowadays this guy could have had a gun. Other people are coming more from the other side being like, I don't like what that guy said, but he shouldn't have went to jail.


You should never abandon yourself to be someone else's friend. And if you're willing to abandon yourself to be their friend, ask yourself, why are you willing to do that?


To the coaches corner, I'm Joe Wamba, joined now with Ed Hoddle, head coach of the 20th ranked football team. And coach, let's talk a little bit about the effort on Saturday against FDU form, putting up some big numbers offensively, and Dan Williams having six passing touchdowns. Sure. Any time you can get six touchdowns, it's a big day offensively. To be able to throw six was outstanding. I mentioned it post game. Dan and those guys are going to continue to get better, continue to grow together. Incredibly hardworking group. And having a secondary of the caliber that we have certainly helps them improve. And the competition that's fostered in practice is quite remarkable to watch. And you heard Devin post game talk about that, that he thinks the offense has the edge. If Faust and her ability was up here, they'd tell you the opposite. So it's a good, strong, healthy competition that both groups are benefiting from. Absolutely. And you talked about that secondary. Again, three takeaways, intercepting the ball. The streak stays alive. We can call it a streak. Talk a little bit about how the defense was able to hold the team to 15 points. Like I said, post game, they did a nice job scheming us up. And I think that was something that they did some things that we hadn't done in practice and that we hadn't seen on film. And to their credit, they did a nice job. Once we got into the locker room, we were able to make the adjustments on the run side. It forced them a little bit to go back to what we thought they were going to do originally. And our guys are pretty opportunistic back there. We've got some special players back there. Again, and they love the challenge of the interception. It's really ingrained into them and who they are as a group of players. And it's exciting to watch. And those guys are so pumped when it happens. And obviously, it's a big play in a ball game. But I think even more so, the culture of that group is what's really exciting to watch. And now looking forward into this week, you guys travel up to Misericordia. What is it you guys are going to have to do internally to keep that success rolling? I think, again, it's focusing on what we can control. It's a long trip. The weather is predicted to not be great. But those are things that we can't control. We've got to be focused on what we can control. The quality of our play, the focus on fundamentals, our ability to continue to make plays and clean up some of the things that we did last week. We've got to be able to run the ball effectively, more consistently. We've got to continue to tackle better. We've got to continue to do some things that we've identified as areas that need extra attention in practice. And we've got to continue to strive to be great every Saturday in knowing that the effort we put in in practice is going to dictate how we play Saturdays. And coach, as always, thank you for your time. This has been the Coach's Corner. I'm Joe Wamba, and he's Ed Hoddle.