 So what we are going to talk today is on the SCADA web HMIs. And the idea is to understand different kind of vulnerabilities that persist in those kind of web interfaces that are used by SCADA devices. So let's get it started. So a little bit back down on mine. I'm actually architecting the cloud threat labs for our cloud security from Bolaic Elastica. We're based out of San Jose. And just I wrote a book on targeted cyber attacks. If you get a chance, just try to take a look at it. And just normal scenarios. So before we're going to discuss the research in this talk, I just want to lay a disclaimer. Whatever the vulnerabilities or the issues that we're going to discuss are solely based on my research. It does not relate to my previous or present employers. And all the vulnerabilities that we are going to take a look at have been reported to ICS cert in this scenario. And they are in the process of patching it. A couple of the vulnerabilities have already been patched. So Siemens and other vendors are actually working to address the issue. So let me get into the brief idea of why SCADA is becoming a problem because of a big critical infrastructure or any several things. Because this is getting on the edge right at this part of time. Attackers are targeting SCADA infrastructure devices and all along trying to get control of the infrastructure. And then from there onwards you can have a diversified impact on the target. So just pick up some of what media is talking about in here. SCADA system face, software, attack threats and several other issues. But the end point is this is a problem. And we need to take a look into it as a community hunt for vulnerabilities report to the ICS cert and just make it secure. But later down the lane during the course of this presentation you will realize that security design is completely broken for this. So we will take a look into it. So before moving further let's have an idea of the vulnerabilities of SCADA that are being existed in the last few years and how the trend is going on. I took the snapshot from the SCADA hacker, a very good website, go along. I mean there's a lot of interesting resources on it. And so they actually took the statistics from the OSVDB. And then they get an idea that how the trend is moving forward. So until now 2015 you will see 98 vulnerabilities have been released. And if you look at from the last couple of years the trend is increasing. It's exponential. So it means that the more you get a visibility in here, the more you're prone to attacks in this scenario. And that is what happening with the SCADA infrastructure. Another brief look on the way the SCADA vulnerabilities from the ICS advisory. This one is released by 14 a few days, just like a few weeks back. So if you get an idea you will come to know that different kind of, they have put up like a granular analysis like different kind of vulnerabilities that exist in SCADA devices here. And so it goes from buffer overflows, directory travels, man in the middle, DLL high checking and different kind of things. But even if you look at this scenario, vulnerabilities like remote file inclusion, local file inclusion, authentication bypasses in those scenarios, still is a wide variety of vulnerabilities out there. We'll take a look into it. Now, again, it's a big problem because if you look at the crime wear as a service where you know attackers in the underground market basically compromises the SCADA infrastructure and sell the control to the other buyers for just making money. And that actually is a one interesting point is that because the security is not up to that mark with the SCADA SCADA, so it becomes very easy for them to go ahead, you know, just sell the access, whatever for, you know, manufacturing plan, dosing pumps and things like that. But this is a big problem these days. And as a community, as I mentioned earlier, we had to come front and, you know, find issues, report and help them to patch things. So take a look at it, the simple SCADA model. I mean, sometimes I have a couple of discussions with pretty good researchers and, you know, audience. Sometimes they think like HMI is not actually a part of SCADA, but if a whole model, if you look at it. So this is an HMI is the one component of it. You have a PLC, Programmable Logical Controls. You have drivers that are driving the end SCADA devices. In this picture, I have basically taken a simple scenario for, you know, you have HMI component, PLC, then you have interface to drivers. And then it goes from the endpoint where the actual manufacturing plant or various devices that are put in works. So if you look in this particular model, you see that HMI is the front end. And from there onwards, you get a lot of statistics about the different components of SCADA. And you can perform operations, you can look into statistics, you can go ahead and execute commands that will be flown through PLC to drivers and then at the endpoint motor. So target is looking into the HMI at this point on. So basically, a web HMI is a human machine interface through a web. It could be a web server embedded in a firmware and kind of other application, desktop applications. But in this particular talk, we are targeting the web. An interesting point is that HMI provides a visual representation of what is going inside the complete SCADA environment and how the data is taken from the panel and then how it is taken from the various devices that are running at the back end. So in a simple way, it's a centralized control center managed through web. Which means that if you control the web, the front component of it, you can do much more with that. And we'll take a look within a scenario. So this is basically a web HMI. You can consider any web application, any embedded web server in a firmware which is exposed on the internet or maybe not properly secure and things like that. But our motive in this particular talk is to go into the design and the security of that web HMI, how they have actually designed, why they are not following the security design principles and what could be the impacts. So in this particular talk, I mean, you can say most of these devices are not deployed with SSL, which is fine. They are basically configured in a wrong manner because not securely configured. They are having a default username and password. Or even if they configure the password, password is weak, you know, have self-signed certificates, no concept of declarative security, which actually means that if the web server tries to send some sort of headers, the embedded web server have no capability at this point of time to send some sort of headers back to the browser. And from there onwards, the browser can act accordingly. For example, X-Frame options can tend security. So there is no concept of that at this point of time. But we are not going into these issues in this talk. But what we are going to talk about is how the design has been done. So what we are going to hunt in this, so any embedded firmware, primarily web servers, Java clients, flash clients, web technology used by HMIs, anything that is exposed through web or, you know, thin or thick client is a target in this talk. So we are basically, in this particular talk, is going to target the front end. Any web-based software that is used to control HMI, any software that is used to support HMI, any web component providing interface to the scanner device. So that's the target here. So what vendors we are going to look into from a scanner vulnerability point of view. So there are a plethora of vendors out there, but I chose, and for this talk, is Rockwell Automation, Alan Prattley devices, Schneider Electric, Prisma, Mox, Zaccaco, Siemens, and there are a whole lot of vulnerabilities out there which I cannot discuss in this talk because of time constraint. But overall scenario, there are a lot of vulnerabilities out there. And we'll take a look and you might, you know, think it is a fun, but it is actually a fun. When you look at the vulnerabilities, there are so ridiculous vulnerabilities out there. Now we are going to target for the next couple of minutes on the BMX family of devices which are being provided by the Schneider Electric. It's basically HMI active web services as a part of the web server embedded in the firmware. It provides real time communication with the Ethernet, TCP, IP, what I have been used for that end device. It has a capacity to host dynamic user defined web pages to provide a lot of information what's going on. As a one target, let's talk about some vulnerabilities. So while I was doing research on it, so hard coded vulnerability, hard coded password actually for the FTP account and they're one of the jar file. We have multiple CSERF vulnerabilities, remote file inclusion, local file inclusion, and secure authentication design. And in this particular device I want to lay more stress on the RFI which I'll be demoing, hopefully the DEF CON network will work, otherwise we have our video. But let's just go into a bit of analysis. So let's say you go ahead and I have not mask URL in this case, but if you go ahead and you find this device and you open it in your browser, you will be presented with the Java, basically you need to install a Java app for that. So you will be served like this, so you want to install it because in order to access all the HMI functionality, you have to access this Java template and then you have to install it accordingly. So when you install it, you come up with, you know, when you download this Java app, you try to look into the source code, you know, where the Java app has been placed, how you can access it, and things like that. So the whole, this slide is going to tell you where the Java app is placed for that particular web HMI and how you can access it, basically simply looking into the source code of the web browser. Now when you do the source code analysis, I'm just presenting a figure here, so if you do the source code analysis of the jar file, you will get an idea that there is a one hard coded password in it and which is actually, you can see factory cast at Schneider and then you have a FTP login assist dialog. So you're basically looking into the decompilation of a jar file performing source code analysis and this is hard coded and you can use it to actually access the FTP account on the server. Moving forward, so a little bit doing a bit more of source code analysis, you get an idea, all the config paths are basically hard coded, so you can pick the path, put it in a URL and if you are authenticated, you can even access it or in certain cases you can even bypass that too. Moving forward, so cross-site request for tree vulnerabilities, no tokens are specified, so there is a complete URL which is simply HTTP get URL, you have these parameters, you simply force the user to click on the link and you can change the password, you can control the editor password and things like that. It's all open in that scenario. And this one of the interesting one, so they have a vulnerability in the scenario, it's an unauthenticated remote file inclusion, so there's a one URL when you go search for URLs on that web HMI, you get to the one specific URL which they're not validating the input you are supplying. So it is I basically framing the content, so in this case I have shown that on this particular device you can include a remote file. And I will be demoing just a bit in seconds. Similarly, all these vulnerabilities are also present in the factory cast devices, this might be by Tally Mechanica and I think Schneider Lactry and Tally Mechanica are not a collaborative way releasing these devices, but if you go ahead, even like previous devices, some old school devices or even some other devices that are being released these days, the same vulnerabilities applied to factory cast. So I want to demo here the remote file inclusion vulnerability hope network works. It just was working just five minutes back. Well, it happens at DEF CON all the time, but I have a backup, it was a very interesting demo to actually show that how you can even download as you smell in an encoded format to the device, but if you get a chance later on and I can show you where the network is working, but so this was the demo, so let's take a demo look from the video point of view. So in this video you will see that we are highlighting a remote file inclusion vulnerability in Schneider Lactry or BMX B34 CPUs, basically the web HMI. The video might not tell you the exact that how you can download even as used kind of thing in encoded format, but it can give you an idea where is the vulnerability and what you can do with it. So we just try to, as a researcher, you try to look at what's going on in and out of the system, and you can see that even if you try to access some resource, it is basically restricted, so you need to provide a basic, so they have actually a basic authentication here, but we have, this is the case we want to show, we actually want to look at it. So I closed it, so now you see that the vulnerability is present in one of the set up index.html file where they are not actually validating what kind of content is being passed through it, so you can easily load any third party website directly into it, so in this case we just uploaded the black at one. So I can explain that how this can be used in targeted attacks. The similar case, you can go for, you know, find a host or some sort of malware on the third party domain, you know, use or any other variant of it. You basically encode the URL or you can use a URL shortener. You can simply pass it through it and force the user to click it, basically any SCARA administrator or the guy, and in that way you are able to download the malware on the end user system. And it's very interesting, you can also pass an exploit code through HTML file, so whenever it's got framed, the exploit code will execute in the browser and then you can get compromised. Basically, simply through RFI in this case. The next device I'm going to target here is the Mox iOlogic, just from the authentication point of view. It's just a simple discussion. So basically they don't provide any built-in support for HTTPS in this. If you look at how the password is being hashed, it's basically the MD5 and there's no salt provided for it, which makes it pretty much vulnerable to the replay attacks. And even you can crack it within a spec of time. So whatever the vulnerabilities I'm discussing in this, we have tested on various versions along different devices and these are basically tested on the real time devices on the internet. So this is basically in self-design where you pass your credential in the HTTP because it gets cached everywhere and then it becomes easy for the attackers when they get access to that, any proxy device or maybe on the web server, everything is going to get cached. That's actually a bad security design. But in this case, we did a test for a real-time device. So in this case, if you look, you presented with this web login prompt, the remote iOS survey, you provide a password and that kind of HTTP request is issued. So you can see easily that there's MD5 hash is passed. And in this particular case, so we actually moved forward and just opened some normal website on the internet and then you can see here that when we passed the MD5 hash, it was easily crackable. And once you get an access to the web, you can go ahead and access the complete mock logic. So the problem is that no salt passed in HTTP get, you know, one level to man in the middle and things like that. But this is a big problem from the authentication point of view in several web HMI's. They are not up to the mark. Now on the next target is our semantic HMI web. I personally like the vulnerability that exists in this web HMI. The reason is that because this is an explorer interface. So when you click the explorer interface, you will be presented with the directory listing of all the hard drives that are connected to it and any directories that are present on the server. In that scenario, if you move forward, just a case, so I want to highlight what vulnerability present in this like cross-site file uploading. So it's possible to actually upload a file by sending a crafted link to a target. Once he clicks the explorer interface, he will be uploaded to the USB device that is connected to the web HMI or even any explorer interface on it. But again, these are vulnerabilities are there. You can execute any command or force the user to perform any actions which you are not authorized to do. In this particular snapshot, you get an idea that when you are uploading a file, no tokens are specified, which is very bad design practice. But this exists. So this is actually a web HMI for the Siemens Sematic HMI Web. So I have actually shown an explorer interface. So you can get an idea. We are into the root directory of that web HMI for this particular one. And there is another small snapshot is presented there that once we uploaded the file, you can access the file directly from there. And if you look at this particular screenshot, you get an idea that we can use in a simple XML HTTP request to trigger the cross-origin not a cross-origin, actually just trigger the cross-site request and then from there onwards we can upload any file directly to it. And then actually once we access it, you get a control over it. You can process files. You get a lot of data out of it. Maybe you can also upload a malware through the USB directly. If you remember in 2009, the StruxNet, we simply upload a malware on the USB. But in this particular case, you can go to the web and just force the user to click on a link. The file will be uploaded directly to the USB and once they are disconnected, it can be taken care of that. And that is one case, but you can also upload files on the web panel and things like that. So you have another cross-site request for tree vulnerability. You can delete any files by again forcing the user to go ahead with it. No tokens problem. You can keep on deleting files, log files and other interesting things. Now let's just take a look at this vulnerability. So actually, if I remember correctly, Siemens is actually in the process of patching this vulnerability. It might have already patched, but you can try. So now in this case, we go to the file browser. You can see that there's a www.temp directory, storage card, storage card 2. So now this is our target. We want to upload a file here. I've just created a custom demo. So just for the sake of showing what is exactly happening at the back. And so we click the button, but you can basically send a link. Once it has been clicked by the user, the active session is there, so automatically cookies will be taken care of and then the request will be issued. So this is a cross-site file upload vulnerability. Explore with just uploading a test file. If you see, we don't have any test file at this point of time. So there's no file uploaded right now. And let's trigger the export code. Just try to show that how the request has been issued through the HTTP Fox. And this all, the URL can be sent all in automated manner. So let's say we clicked it. The request has been issued. So the request has been accepted by the web server. And so this is a file we uploaded a simple text file in this case. Now if you go back and we refresh the page and there you go, we get the test2.exe file there. So idea is that upload any file, executable or other cases as I mentioned earlier and from there onwards you can even access the file through that URL. So it's just like routing or compromising the end systems through web. And all these vulnerabilities pay a significant role in it. And all these vulnerabilities as I mentioned tested against the real environment. So moving next, we're going to target cacosolar device in this scenario. I'm not sure you're interested but these devices are used to understand what kind of design they are falling. In this cacosolar device they have a hard coded administrator password. And these devices are heavily used for HMI visualization of solar plants and we'll just take a look into it. Once you open this HMI interface through a web, you will be served with this XP Java template. They call it but just the name. So you have to install a Java JAR file to it. And in the another snapshot you can see that there is a links to where the JAR file is placed. So we follow the same tactics and we perform the source code analysis and then from there onwards we get an idea. It's just an old system for the vulnerability demonstration. So if you take a look in that, so you get a username and password as cac2 and then something caco 2008 and all that. The second part is that this password will give you direct access to the web HMI. Now, once we use this password and then here you can see that we get access to that device. And if you see on this HMI interface there is an inverter placed in that mimic diagram and then you can get the complete idea that you are in control of this solar panel or maybe the solar devices through inverters and all that. The problem again here is that it's just a web. Through web, these problems persist and from there onwards attacker can exploit it very, very easily to gain control. I always believe that if I can do it, then I think any other person can easily do it because the reason is that as a security researcher you think from that perspective and attackers are thinking from much more wider perspective because they have a lot of time and significant resources to invest and I think these vulnerabilities can be pwned pretty easily and they can control all these devices. So I just we can take a look into it demo demo here. Just one minute demo, just try to show that the vulnerability actually exists here. So the vulnerability has been reported to ICSR, they are working with the vendor now. So see, you get our Java app like this. Although you have to accept the risk in this case, we are accepting try to load the Java app here. So let's say by default you are going to try the admin password but it's not going to work. You are not allowed. So we are going to forward our simple tactic. We are going to go into the source code and we will go for the JAR file to try to see what resides in there. And we file that they have this VMS JAR file and we already downloaded it earlier and now we are going to look into the source code analysis. Just a simple thing five minutes of stuff. And once you look at the classes, once you do a lot of source code analysis, you get an idea that you have to look into. For example, authentication login classes, session identifier classes and things like that. So you are just skimming over things. So first we are going to look into any hard coded configuration and other things. So now here you go. So when we look into this, the classes like hard coded information it's just like a 5 to 10 minute of job in this case. And for advanced attacker it might be a little lesser. But again the thing is that your hard coded credentials are being present in JAR files, flash files, in-scare authentication design frameworks. And we are using SCADA a lot these days. And we are finding vulnerability as protocol levels, you know, mod bus and all those kind of things. But we also need to look into the WebHMI. It's just broken. And we'll take a look a bit more into it. I can access to the complete WebHMI. I can look into, I can change configuration and I can screw the device if I want. But just for testing purposes. So again you don't need to attack the infrastructure right away. You just need to access the device to Web. And then you have the idea what's going on in and out of the system. And there you go. We got access. Now in the next set of devices, I'm just going into a wide variety of devices to show that the vulnerabilities are not actually present in one specific device. It's a wide range of devices. And this time I cannot cover all the vulnerabilities. But still, whatever the best I can I will take care of it. So in this Rockwell Automation Ethernet series, you know, there's a variety of, they have devices here. I766, I769 family and thing. Simple thing I want to highlight information through this, basically through default files. Just open it. There's a lot of information being present in it. By default design of, you know, web applications and things, I mean you need to get the credential first even to provide any kind of info. But in this case that design principle is not followed. Again, you have RFI, you have a local file inclusion and long live cross-site scripting. Cross-site scripting is good to just find out. But again it can be used in specific scenarios. But in case of SCADA it wants to vulnerability or basically hardcore one. So if you look at this particular screenshot, information disclosure is happening. We move forward remote file inclusion. Again we just reported that that blackhead webpage in it. And it's all unauthenticated. So you don't need to wait for the person to first do the authentication and process the link. You just click the link, things will be done. And I see if I get a time later on and the way, I prefer to show you that demo that how you can download malware on the fly with this thing. So cross-site scripting as usual it's unauthenticated, simply send a link get whatever you want. Now, so we have gone through the Schneider electrical devices. These Rockwell, CACO, Prisma. Now we're going to target actually Prisma web. And this is kind of pretty interesting is one of the most I think easy vulnerability you can say or a funny vulnerability when you see. So Prisma web is one of the vendor that are based out of Europe I suppose. And they actually build different devices like metal detectors. They build devices like checkwares and stuff like that. And they also build devices for X-rays like inspection machines. So interesting thing with this device is that through the web HMI is the password disclosure in JavaScript file. I mean let's say you are at some sort of airport or some other place metal detector you found that is a Prisma web metal detector is there. Somewhere you get an access to the IP. Boom I mean you can do a lot of back things order. It's all in JavaScript the client side. And it was working and all the vulnerability has been reported. Again Cs are full of Cs are full of heck lot of vulnerabilities which I don't want to go in right now. Simple JavaScript file. Take a look. So we access this Prisma web here. So you get served with this web panel and from there onwards we try to look into the source code to just understand what kind of components are being used, what kind of files are being included and with this web HMI. If you see now we access two specific JS file. One is the login.par JS. The other one is config.js. So the login.par and that's simple manner. But if you look at the login.js it says Prisma web and Prisma. So this actually show that they might be running in this case a default password could be possible but they are storing it in a JavaScript file. So if you are going to configure or any SCAR administrator are going to configure a new password for it, it's still going to be present in the JavaScript file because that's exactly how device works. And from there onwards you can see that is some vertical device. You can set up the parameters. It can screw up the process if it is going in. But this is one of the funniest vulnerability I have seen in this SCAR HMI research. But it has a lot of impact. For this vulnerability if you are going to manipulate metal detectors, I mean it's just crazy. But it's in front of you. From there onwards you also have a cross-site request forgery. Means the concept of TOE consists totally not followed with SCAR HMI. Simple through HTTP guest and you will change the password on the fly. And then you can get access to it. I'll see if Internet is working but it looks like we are not lucky today. But I can show you the demo if you are interested. I mean just outside somewhere I can show you. I mean just some live device somewhere. Moving forward now we are going to take a look into the ITC controller device. Device is primarily the dosing pumps. So if you look into these dosing pumps these are basically used for pumping water and some sort of other purposes. Again you can look into the snapshot and you can get an idea that what it actually looks like as the controller 3000 design for it. And you can get an idea of what it actually looks like. But they have some problem with that. Again you can upload the firmware in this case. It's just a variant previously from where we are uploading the files. Now you can go and upload the firmware through cross-site request forgery. And from there onwards you can go ahead and play. The device will be screwed in this case. But this is also a problem. So there are a lot of other problems. You can open platform. You can go ahead if you get some time or motivated enough to hunt for vulnerabilities. I think this is a very good platform to work with the ICSR to report them and patch those issues. And following that this is just a one ITC controller dosing pump, the request, HTTP request and response mechanism. And from there onwards you can see how the request has been issued and has been accepted. So you can upload files, firmware once you control the firmware you control the dosing pump. In addition to that these are poorly configured. You can find a lot of devices with default passwords and all that. But this is just from the design perspective. How the security has been aligned according to the research. Basically the people who actually develop this kind of devices. Now from there onwards hunting continues. And here this is just the tip of the iceberg. If you go around and search for there's a heck lot of vendors out there that provide WebHMI services. And if you keep on looking into them and you try to perform research into different devices you will find a lot of vulnerabilities. It's just not a rocket science. You need to look into the control point which you need to control. And from there onwards you can spy your own inputs stuff and then you see that there's a big playground out there. It's seriously broken. Not enough vulnerabilities in WebHMI have been reported back to the ICSR or there. But more all like the protocol level, DLL hijacking level. But if you open the scan there will be a lot and lot of vulnerabilities in there. And from the conclusion I can only say with this research and there are other vulnerabilities out there the SCADA WebHMI security is completely broken. Why it is so? Because we always used to say old is good and old is gold and you can see like SCADA technology is being used for a long period of time. But in this case when it comes to security it's not that golden. But the problem here is that it's still being used in most of the critical functions on the internet or our day-to-day routine purposes like I've discussed earlier metal detector, dosing pumps there, a lot of other additional details are out there. So easy to find vulnerabilities, so easy to attack them, so easy to control them. And you can see that how kind of big market like crime wear as a service can be built out of it. You can go ahead find it, register account and start selling these devices in the underground community. But this is a real problem. And for that I think for researchers, any motivated people they need to come up and hunt this is the actual state this part of time. Moving forward is some of the relative research which I've done earlier and other people, portals, good resources to look into to understand what kind of vulnerabilities have already been disclosed, what new are there. But I personally feel that the vulnerabilities like cross-site file uploading, firmware uploading, remote file inclusion all have a substantial impact considering the state of the world. And thanks and I'm open to questions. Feel free to have any questions and if you need some demos I can show you.