 So, if you're in here for the Skata strange love talk, that's not happening. Last week they substituted me in as the replacement speaker. So it's still a Skata talk, but it's a very different one. We're talking about HMI vulnerabilities. We're talking about some very easy ways of breaking things. So the cool thing is instead of going home and hacking a nuclear power plant, you can actually set up a VM with this stuff and break it and not draw too much attention. So if the panel members here would introduce themselves, we'll start at that end because you're paying attention. My name's Amanda. I graduated from Mississippi State undergrad and went to University of Maryland for grad and this is a good guy. The security consultant now, first time at DEFCON, having a good time. Hi. I'm Kendall Blaylock. I literally share an office with Wes, so five days a week I have to watch him and it's not pleasant. Does he have the DEFCON hacker smell? I'm Thomas, a long-term student at Mississippi State, undergraduate, graduate and gone for the Ph.D. Long-term student. I like that. Shane Fry graduated in 2010. You break things down now. It's about time for me to get started. This talk is Skate HMI and Microsoft Bob. We're looking at modern vulnerabilities that are very reminiscent of things that we saw in the 90s. My name is Wesley McGrew. I'm a research associate. My title is Mississippi State University by where a few hats there and you see tons of different affiliations. Basically, they're all part of our computer security and computer forensics research that we do there. I also see some of my personal contact stuff there. My Twitter accounts are McGrew Security and my personal website McGrewSecurity.com. So if you're asking what is it that I do, who am I, my primary job is to train law enforcement on digital forensics. Law enforcement and wounded veterans coming back from Afghanistan and Iraq to give them the ability to get jobs in digital forensics. Primarily these people are not tracking hackers, so you don't have to worry about that too much. It's mostly a child pornography thing, although we do mess around with hackers, so we also do some control system security research as part of the critical infrastructure protection center. With that, we have guys that look at the vulnerabilities and PLCs, the networking protocols, encryption being used on SCADA networks. My research in that area is on SCADA HMI, the user interfaces. Personally, my interests are in breaking things, figuring out how they broke and figuring out how people broke into things, some reverse engineering, and asking me about social media data mining sometime. My personal contact information there, email address, all that good stuff. So for this talk, we're going to be describing some HMI products. We're going to talk about which of these products actually provides any kind of security functionality in there. Some of them do, some of them don't, some of them advertise it, some of them don't. And then I'm actually going to tie it to that Microsoft Bob thing. I'm not just throwing that in there for the hell of it or anything. We're going to look at some vulnerabilities in Microsoft Bob and in SCADA HMI products. And we're going to have a couple of demonstrations of those. So there's a cartoon dog that's going to help us break Microsoft Bob. We're going to bring them back in for one of the HMI products. But we're also going to show you how some of these products really do a bad job of very basic security principle things like password storage. A couple weeks ago, we had the problem of LinkedIn not hashing their passwords correctly. They didn't use a salt. We're going to look at some products here who store passwords in a much more insecure way. We're going to tie it all together with some lessons learned and what you can take home from this, what you can play with, and then we'll have Q&A. So you know about me. Now, for you, what you're going to get out of this talk, why you shouldn't be walking out now, if you're a vulnerability geek, if you're like me, you always look and see what's coming up on exploit DB. You always are looking to see what news is being posted and what modules are new in Metasploit. If you're an exploit spotter, essentially, you can pick up some really neat and easy tricks, especially if you're new to this, because a lot of these vulnerabilities are not crazy, you know, heap overflow type things or anything like that. It's very easy to exploit, very easy to find these kinds of vulnerabilities, so you can find your own O-Day in this way. If you're experienced at this, if you are the kind who's constantly finding remote code execution type stuff and wrecking shit, then you can just gasp in horror or slash glee that it's this easy. If you're a pen tester and you're going after any kind of control system network, any kind of critical infrastructure, you may be able to take away some stuff from this on how to escalate and leverage access to Skate HMI, especially with the password disclosure vulnerabilities. Even if your target isn't the HMI, there's a good chance that they're reusing those passwords elsewhere. If you're a Skatans or a control system stakeholder, chances are you're not a DEF kind. But if you are, then you'll see this and you're like, well, the box said that it provides authentication and security, but after this you'll realize that that might not be the case and you might want to start layering defenses around this. It's not necessarily, the checklist of security features isn't necessarily what you should be going by. If you're an HMI developer, then you're going to be composing a nasty email to me, especially since this talk was a substitute talk. The ODES particularly fresh here. The vendors found out about this a couple of weeks ago. So basically what you'll learn from this is how to develop secure HMI systems or what not to do at the very least and what sort of principles you might want to follow. So a lot of Skater Talks, a lot of Control System Talks basically waste a whole lot of time on the alphabet soup of Control Systems. I'm not going to go too deep into this or anything. I'm going to assume that you have been to a Skater Talk before because they've been pretty prevalent at conferences for the past few years, but the idea here is the part that we're most interested in here is the HMI, the human-machine interface. So we have systems that have PLCs out in the field and anything that are doing stuff and communicating back and things like that. What we're concerned with is that control panel interface. If you watch the Simpsons, you remember that Homer Simpson works at a nuclear power plant. He's always got his feet kicked up on the control panel, eating a doughnut and everything and there's switches and gauges and dials and things like that. And that's sort of an old school human-machine interface for a critical infrastructure system or any kind of control system. The photo that you see there is from Three Mile Island back in the day and anything. You have actual physical switches and dials and gauges. You may have some of this now and everything, but it's probably being fed data a little bit differently than this is, a little more indirectly. Now, you're much more likely to see LCD panels, touch screens, work stations set up with graphical interfaces for the control systems that you're manipulating. The one at the bottom there is actually from a demo system that's a cookie factory. I like that one. That's definitely critical infrastructure. The interfaces for these, if you've been around for a while that you probably realize these look very much like visual basic style interfaces. These look very much like programmer art, as you would call it, where the skills of a graphical artist have not been consulted. But the idea with this sort of interfaces and this sort of software really is that there's no cookie factory HMI product that you can buy, pop into your system, and it automatically start making cookies for you. There's no drop-in software for controlling a nuclear power plant. These things have to be kind of custom written per client, per stakeholder. So there are companies out there that are basically solutions providers that buy the HMI software, code up all of the interface, code up all of the background code that runs behind that, and deploys it out to the end users. An interesting aspect of that is when you find a vulnerability in HMI software, the vendors don't necessarily know who their end users are. They know who their solutions providers that are buying the products are, but they don't know who the end users are. Because what you're doing is you're buying essentially an IDE that lets you develop these sorts of interfaces. Another cool thing about that is that if you want to play around with this sort of software, they are very generous, most vendors are very generous about giving out demonstration versions that you can use. And those demonstration versions typically have very, very loose restrictions on them, because they want you to learn how to use their software to develop solutions. They want you to get tied into that and then recommend that to clients. HMI is part of the attack surface for a control system. These sorts of systems, there's increased connectivity and control systems for billing and process improvement type purposes. There are HMI products for cell phones and tablets and things like that now. There's a famously, I've seen, an ad from a control systems magazine that shows an engineer sitting on a mountain top of their laptop remotely accessing whatever water treatment plant there is. It was supposed to be an advertisement with junior. You can be on vacation and still manage all the critical stuff that you're responsible for, but in reality it's just terrifying. I put insider threats here because most of the stuff that I'm going to show you today, it's not remotely exploitable necessarily. Some of it in some situations could be, but what you're mainly looking at here is the insider threat. So if you look at the Stuxnet attacks and anything, those, that Stuxnet moved around by USB and so you could have insiders that are moving those USBs around intentionally or unintentionally and basically hopping air gaps. These air gaps, oftentimes the air gap isn't really there and even when it is there, it's not something that's insurmountable. So and a lot of times the end user, the end client doesn't even know basically that there is, whether or not there is an air gap or not. They think there's an air gap, but as it turns out, well you ask them, so what happens when the system breaks? Well, we call our solutions provider and they fix it. Well, do they come on site to fix it? No, they do it remotely. So if we look at HMI security features, some of these products don't advertise any sort of security features. It's a control panel software, it runs locally, you use it locally and it talks out to whatever devices it's going to talk out to and that's it. And I don't really pick on that because it's not claiming to do anything. But there are a lot of these packages that claim some security functionality. Primarily the security functionality that's advertised by these products is the identification and authentication of users. There's usually some very good complex systems for having multiple layers of access, different access levels. Everybody from the Homer Simpson guy sitting at the power plant and anything at the control panels, all the way up to the engineers that can actually change code on things and modify the HMI. The idea behind this is to protect the integrity of the HMI project, the project being the entirety of the user interface and code around it. Preventing modification of the HMI software itself and locking in the users into a captive kiosk interface. On a previous vulnerability I asked one of the developers, or I was talking to one of the developers about the security features that the product provided and he told me that the security features that were there were originally put in place to keep the operators from playing pong on the operator workstations. This is a product that evolved from Microsoft DOS days back in the 80s using a lot of the same code. So Wes are you saying that pong is more of a threat than Internet Explorer? No. So there's some difficulty here in having HMI systems protect themselves. So if an HMI system is advertising it has some security functionality then it has to protect itself in some way. So the idea is the way this happened originally in if you had DOS HMI packages is you had your hardware level, you had your very thin layer of operating system of DOS, single user, single tasking and the HMI itself would handle everything as far as users and authentication, access control and things like that. If you're the only thing running on the system you don't have a whole lot to worry about as long as you can keep somebody captive in there. As long as you don't allow anybody to run any extra code or anything like that. As long as you can kind of protect the boot up process and things like that. As long as you're the only thing running you don't have to worry about anything undermining your homegrown security. And so you implement a lot of your own security controls because DOS really didn't do that sort of thing for you. And so if you can manage to keep something as a straight up kiosk then you're pretty good with that. But now you've got multi-user, multi-tasking operating systems or the default. Most of these packages run on Windows XP and above 2000 NT. Pretty much everything you should see on it's going to be running multi-user and multi-tasking. But the HMI systems are still implementing their own user authentication and their own access control. So you've got a problem here. As you know if you have multi-users and multi-tasking you've got several different users, several different processes. And the idea with this sort of thing is that the operating system and the chipset and everything tries to help you out with preventing one user's process from monkeying around with another user's process. But there's nothing to keep one user's process from messing with another user's process. If you're running a program as a user and you fire up a debugger you can attach to it. You can mess around with its files as long as all of the ownership things are straight. So the problem with that is if you have your HMI running as the user that's currently logged in you better be protecting them from bouncing out of that interface because if they can ever get out of it or if they can ever find some other way of running code USB, Firewire or anything like that then it's over because you have not only got access to all the files that are associated with that HMI but you can also monkeying around with the software. So now that brings us to Bob. The 1995 attempt by Microsoft to add a user friendly, captive, kiosk style interface with lots of physical analogies. So with an HMI we might have physical switch or digital representations of switches and gauges and things like that. Things that are reminiscent of the switches and gauges on a physical control panel. With Bob we have different rooms that we moved between and different other physical analogies to writing an email with a letter or a pen and paper and things like that. Does anybody remember this? Does anybody ever use this? Okay, yeah so I'm sorry. You can track this software down. It's pretty funny. And it does run on modern operating systems. And it is universally hated. Nobody liked this. So if you go back, we've got two screenshots here and anything from the past to the future here. I found a post from using it in 1995, basically panning Microsoft Bob. This person apparently works at a software source as we have a 100% return rate on Microsoft Bob. The customer who bought it came in an agitated mood. I don't know if he came in agitated before he bought it or after. The manuals of Bob is nothing more than a cheap advertising ploy. I don't know what he's expected from that. Bob needs eight megs of RAM just to run. Wow. Bob needs 32 megs of hard drive to install. Oh man. And then the latest software takes up another nine megs. This is a big deal. Now, to relate internet rage to the modern day, we have a post from 4chan here regarding Windows 8's metro interface. It's like running a media center and an iPhone at the same time except it's on my computer, not streamed to the TV, and I can't call Siri something that I blanked out for amusement. It was so offensive, but even I blanked it out. Why does this OS think that it's a cell phone? It's basically internet rage. So people hating on new interfaces. That's nothing new. On the security side of things, though, it's kind of interesting because it's kind of like an HMI software, and it also has some of the same kinds of vulnerabilities. So in Gary McGraw's book, Software Security, he has a little sidebar thing here where he talks about a design flaw in Microsoft Bob, and even he didn't verify it. But he says it's all repeated. And essentially the idea is that in Microsoft Bob, if you got your password wrong three times, Microsoft Bob would pop up and proclaim, I see you have forgotten your password, please enter a new password. And so the conclusion here is Microsoft Bob hackers friends. So Gary got a few of the details of this wrong, but he got the gist of it and anything through his oft-repeated stories. But since we can get Bob in running on modern stuff, we can verify this sort of thing. So there's my good friend, the dog there. There is no Microsoft Bob character in here that I know of, but there is the dog wearing the Bob logo on his collar there. So whenever you go to log into Microsoft Bob, it asks you for your password. Type your password here, and it'll tell you it's not right, and so you try it again. It's more polite than Gary McGraw stated. The dog says, pardon me, have you forgotten your password? And you can tell it now, but we're obviously going to tell it yes. What password would you like? Type it here. There's even a little note saying, the little symbols that show up when you type is my way of disguising your password. This way someone looking over your shoulder can't tell what it is. Never mind that when you leave the computer and here, and I just noticed this looking at this slide, instead of okay, it's now a-okay on the button there. Very friendly. So this verifies as a 17-year-old vulnerability. And also we're looking at insecure storage of credentials. This is where we're getting into the whole password hashing thing and hashing with salts and things like that. The software we're talking about today does it so wrong that it would be an improvement if they just hashed it in the first place. So this is actually just looking at, in Microsoft Bob's files here, the utopia.mdb. It's an access database, I believe, that you can just open up straight up in a viewer. Now, the Bob one uses an old version of the access database. Some MDB viewers like it, some don't manage to find what it does. You can see down here that there's the Wesley McGrew user there. That is my real birthday if you want to get me something. With my-with a gender field, Unique Identifier, and my password, which is O-Dear. There's also some other users built into the thing that the system doesn't really tell you about. There's one that doesn't show up on the user list within Bob, and it's called the Creator. And the password is secret. Very mysterious stuff there in Microsoft Bob. So Microsoft has done a lot of changes since then. I don't think that they'll mind me talking bad about Bob. But because it's been 17 years, Microsoft's made a lot of progress. And of course we forgive them. Do we forgive them? No? Okay. But software is a lot harder to break nowadays. It's mainstream IT software that's hard to break, because we have people that are working on breaking it all the time. You break Internet Explorer, you break Microsoft Windows, and boom, you've got millions and millions of people that are vulnerable to that, and that's sexy, and that's fun to talk about. But what about lost tribes of software? What about tribes of software of basically different genres that don't see a lot of attention from vulnerability analysts, such as SkateH and my software? Now that's getting more and more interest, of course. But for a long, long time, this software was developed without a whole lot of scrutiny as to the security features. It has security features, then we give the stamp of approval and send it out. But what you're going to see here is that this software has vulnerabilities in it that are very reminiscent of what you would see in mainstream IT software from the mid-90s. So for finding design flaws in HMI software today, you could go up to your hotel room and do this and find some zero-day, I promise you. And you can put away your fuzzer, you can put away your copy of Sheldon Coder's handbook, you can forget everything you knew about memory corruption and still do this. All you have to do is read the documentation for the security features that particular HMI package provides and just verify that it actually does it. And in a lot of times it doesn't, or it does it in such an insecure way that it can easily be broken. So the first steps for this, this is an older vulnerability that I reported a couple of years ago and this was basically my first go at SCADA HMI software. You have GE Fanox iFIX software. They weren't very happy about this. But essentially their passwords were stored exclusive or against the static key. So who here knows what that means essentially? Okay, about half of you. So that, and I'm going to kind of cover this in a little more detail here. If you went to Lost Talk on the DC-101 type stuff, he talked a little bit about exclusive or and why that can be good, why that can be bad. The idea is these passwords were stored against the static key that was the same key for every user and the same key for every system that iFIX is installed on. So if you had a trial version of iFIX, you could go and pop those out and pop those keys out. Network authentication in this case, and this actually turned it into something somewhat remotely exploitable. The documentation for network authentication in iFIX suggested that you put the password file on an SMB network share and point to it for authentication, which means that every time you go to login to the system, it pulls the entire password file in clear text across the network. And then if you can run code on the system, it's very easy to bypass local authentication. It's very much like cracking a shareware MP3 player or something like that. Instead of jumping here when the registration code's bad, you jump there. So the password authentication was straight up. You connect, you attach with a debugger or you go in and modify the code and you just tell it to jump to the left instead of jumping to the right. A one-bit change to the file. And you could make your own login process that did this exact same thing. And this is the thing. If you have the entirety of your HMI software running as the currently logged in Windows user, you cannot protect it. It's going to take some sort of architectural change to actually implement any of the security features. So this is not an isolated problem and this is the first zero day of the day or this talk, rather. And this is in KEP InfoLink HMI 50023. They've been notified and they're going to fix this. They actually got an email from them saying that they are planning to upgrade the encryption on their passwords. I don't know what that means, but I guess we'll see. So in the documentation it says that you can restrict access to a certain project by defining required access levels. So essentially you can have multiple users. They can all have access levels between zero and 200. So you can get very finely detailed with what you allow these people to do and what you don't allow them to do. But again, just like iFix and just like a lot of these packages, I bet you can find another one that does this. They encrypt their password with an exclusive or key. Same key for every user, same key every installation. So Crypto101, first day, how do we actually store a password securely? And it's not with what you would normally call encryption. You want to do it with hashing. If somebody tells you that they're securely encrypted their password, it doesn't matter if they've encrypted it with exclusive or or if they've encrypted it with AES-256. If you have to have a key to decrypt that password, that key has to be stored somewhere. And again, if the architecture of your system is such that you can't protect those files and you can't protect those keys, then you really know better often than exclusive or honestly. But you can store a password securely and at least make the attacker have to crack a hash. So the idea is we have our password, we have a random salt, we put the password and the salt together, we run it through a hashing algorithm, whatever you want to use, honestly, it's better than what's going on here. MD5, SHA1, 256, whatever you want to use. You store the hash and you store the salt with it. And then as I said on the previous slide, if you encrypt that password, it has to be stored somewhere on the system. And it's even worse, of course, if we do it with exclusive or because we can do an easy known plain text attack on exclusive or. I have my own copy of the HMI software, I set up my own users, their own passwords and everything. And you've got your truth table for XOR there. It's exclusive or if one or the other is one, then the result is one. If they're both the same, then it's zero. And people use this because it's the basis of an unbreakable crypto scheme. It's the basis of a one-time pad. If you're trying to communicate with somebody and you can pre-share a long enough key, you can communicate very securely using exclusive or as a one-time pad. It's not for password storage, though. So all we have to do is we take our encrypted password, we exclusive or it against the plain text key that we know, the plain text password that we already know because we're doing this in our environment. And we exclusive or those together and out pops the key. So because that's just the property of exclusive or. A XOR B equals C and B XOR C equals A. So for that, we take a field trip to the InfoLink VM. So in InfoLink, we have... I'll zoom in here for us. So with InfoLink, we have this whole system and I'm going to use the InfoLink demo project, which I've actually monkeyed around with the user list on. So we can go to the properties of the project and we have our security features here where we have users, we have access levels for them, things like that. And each object in the system, we can set it to where somebody has to have an access level of something or another to be able to use or modify this. You can disallow or allow users the ability to use, to modify the user list. You can choose who can use what interfaces. It's pretty cool. But if it saves it insecurely, then we're not doing too good. So it saves it into this project.hmi file. You can trace this sort of stuff down. If you're doing this yourself, you can track it down with Process Explorer. You can attach a debugger and just follow along and see what it's doing. Very easy stuff. You can actually get away with doing a lot of this without having to get too low into the assembly language of it or anything like that. You're monitoring the behavior of the software you can do this. So this project hmi file, which you may or may not be able to find on Google with some title index of searches, we can drag this out to the Mac here and run a program here that basically decodes all that out. And this is a very simple program. It's just doing that exclusive or with the key that we already know about. The interesting thing in this pops out is the test user of Password Easy Pass. The interesting thing about the key that InfoLink shows is the key is not like a static random key. It starts at ASCII zero and goes up. Up through nine. So the key is zero, one, two, three, four, five, six, seven, eight, nine. Yeah. And the funny thing, yeah, exactly. If that was your password, the encrypted key would be zero down. It would be great. I need to try that. All right. So we've got another field trip to the VM in a little while. Kingview, you really need to grab this one and install it and play around with it because it's kind of fun. I haven't fully reversed engineered the file format for this one, but essentially the entire project file stores the passwords. They just took FF in every position and just subtract the byte from it and save that. So you add FF back and you've got your plain text. So that's that. Kingview is interesting. It's a Chinese HMI product. And their tip of the day when you go into the software is always very cool English. I love it. Very DD tech. No field trip yet. So here we go with something that's very Microsoft Bob here. This is Iconics Genesis 32. Go ahead and grab a demo version of this to play with while you can because the vendor has stated that they are removing this feature from the software just altogether. It's so broken on this. So when you go to log into the security server for Iconics Genesis 32, you see your usual username and password. And what really struck me is this challenge here. So there's a thing called challenge. And I wanted to know what that was. So I go to the documentation. It actually helps to read the manual every once in a while. And in that documentation it said that emergency password can or essentially in a case when you're not able to log yourself into the security configurator, you can contact Iconics technical support and provide your challenge code. You will then receive an emergency password that you can type into the password field with no username in the user field. And it logs you in as a default administrator. Cool. So I didn't really want to bother tech support. And so I played around with this a little bit. I hit cancel and I opened it up again. And that challenge number there increments about 10 times a second. You can, if you sit there and watch it long enough and anything, and that's a lot of fun. If you watch it long enough, it cycles from, it's basically a 15-bit cycle. It goes from zero all the way up through 32,000 in change and then cycles right back through. And it does that several, several times a day, however many times it would with changing 10 times a second. But one thing interesting about it, it's not tied to your account with Iconics in any way. So even if we didn't want to crack this, we could beat this by just having our own, or basically buying our own copy of Genesis 32 to pass that level of technical support or social engineering and telling them that we are. And just call them up and say, well, I'm on my system and I need to get in. My challenge is 3-1-1-5-5. They tell me the correct answer and I break into somebody else's system. But it turns out we don't even have to call them up. It's not that hard. You can connect to this thing with the debugger and figure out what it's doing with your password once you hit OK. And essentially you go through this sort of thing. And I've added the dog there back again from Bob because this is very relevant. So basically it takes your password. It passes it through a function that does some really boring to reverse math that I don't want to really handle. It takes the results, the first eight characters the results and that's what's supposed to be the response. And if it's the response then it logs you in. As it turns out, I was really lazy and didn't want to reverse that function. So I went online and punched in my password into a hash calculator that did all the different hashing algorithms, suspecting that it was one of them. And it turns out that it's MD4. So basically it takes your password, it does an MD4 of it, takes the first eight characters, tests it against the correct response. And if it works then you're in. Default admin and we've added the dog in there because it's very much a what would you like your password to be sort of thing. So field trip to the Iconics VM to show that off. We have our security configurator here and so we're at 21,000 and change on this and we can log in. All right and if we run this again you'll see that that number will have changed slightly. Very predictable. All right, so we'll do it one more time here and we'll do this one, 21,101. So we have a script here, Iconics techsupport.py. 21,101. Our correct response, oh nice. Ba, 1928. I love it. Boom, we're in. So these are not Pony award-winning attacks. They're not leap, they're not hard to do and they're not even something that's like something that you can just attack a system with right now. Most of these require some level of access already but you can escalate what you're allowed to be doing with this. It's part of a larger attack. But the really helpful thing is if you're a pen tester and you're facing systems like this is this is a great place to gather credentials for other systems because I guarantee they're going to reuse this password somewhere else. The lesson learned for this for HMI development is that the architecture of your HMI must support your security goals. If you want to have this sort of authentication and you want to have this sort of protection against bad things between users you're going to have to do it differently. You can't run it as one monolithic piece of software in one user. You're going to have to break it off. You're going to have to run part of it as a demon or as an admin or system or something like that. You're going to have to break it out in the client server. At least across users, probably across systems would be better. And there are HMI packages that do that but not these. The developers of this need to be educated on basic design principles. Salsa and Schroeder. That's your classic basic security design principles. Things like complete mediation and things of that nature. Just your computer security 101 type stuff is what they need to be going for on that. And the last bullet point there is to find me more of these bugs. If you find one of these, let me know about it because I'll drop it in my dissertation. So we have time. Actually we have a good bit of time here. There are about 12 minutes for questions in here. When you're leaving the room, leave the room through the doors to my left, to your right. After the Q&A period here at 11.50, we'll go to the Track 1 Q&A room. There, if you ask a nice question, I have challenge coins. A few of them left here. I've been handing out while I'm here. These are coins from our Forensics Training Center. The Latin there is for acquire, authenticate, and analyze. Either that or whatever language guy we had do this is playing a prank on us. And it's computer scientists don't know Latin. That's what Google told us. That's what Google told us, yes. My Twitter account there and my email address. I'm happy to take questions in the Q&A room. Thank you. Hey, thanks very much. Curious if you have comments on the digital bond conference. And I guess this is probably the wrong place to say this, but some of the responsible disclosure of things that are used for critical infrastructure. It's a little bit frightening, but I think it's necessary because obviously the vendors are doing a piss poor job. Right. One interesting thing about that is ICS sort of announced the other day that they're drastically ramping up the timeframe for fixing vulnerabilities. Then they say it was something like 40-something days that they would hold on to something before they disclose whether there's a patch or not. And it's good because the thing about this stuff is the vendor can put out a patch for it, but how many of the end users, how many of the stakeholders are actually going to get that patch? Because it's got to go through the solutions providers and everything. It's far better to make the stakeholders aware of it so that they can layer defenses around it because the patching may not be as feasible as it would be in mainstream IT software. Anything else? Come on, somebody's got to have something for me. All right. Do you know how much market share the software that you found vulnerabilities has? The iComics, the one that I just bypassed the security of, they actually have a list of clients on their website as case studies and includes the Russian TransNet pipeline and the Pentagon's security systems. As far as percentage market share for these, honestly, not that much. Packages like Wonderware and iFix probably have a lot higher market share than these particular packages. Well, I appreciate y'all coming to the top. Give a round to my Mississippi State guys who volunteered not to watch the presentation.