Re: Vulnerabilities in some SCADA server softwares
On Wed, Mar 23, 2011 at 02:36:38PM -0400, J. Oquendo wrote: On 3/23/2011 2:13 PM, Theo de Raadt wrote: If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. You're flawed in your response: Public exposure increases the visibility, and therefore customersinstall the patches quicker. ... When someone full discloses a vulnerability, there is no patch to install quicker. That does not change the fact that the bug might already have been exploited for a long time. Without the disclosure, the vendor has the possibility to guess that it's not the case and take a long time to fix it. After the disclosure, this possibility vanishes and he has to work for a fix. Also, if vulnerabilities were waiting for disclosure to be exploited in such environments, Stuxnet would not have existed *before* Luigi's post, only after. Recent facts have proven you wrong here. Granted now there's emergency and we'll possibly get poor quality patches or workarounds in the first time. At least if some of these vulns are currently actively being exploited, we can expect those exploits to quickly stop from now on. Willy
Re: Vulnerabilities in some SCADA server softwares
On 3/23/2011 11:27 AM, Kent Borg wrote: Would I install a stack of SCADA upgrades to *my* functioning factory? Maybe not. Scary, scary stuff. Security needs to be designed in, implemented carefully each step along the way, and reviewed. Instead people with security in their job title so often seem to think security is firewalls, buying anti-virus support contracts, and requiring use of MS Outlook and Internet Explorer. -kb, the Kent who will shut up now. This is a big fact that many are overlooking. Regardless if the vendor is a complete and utter moron, patches don't come easy for these systems. Secondly, many of these systems are very old and are being propped' up by new software. There is no running out to deploy PLCs that can fail because of a glitch. Security wasn't a factor in the 50s, 60s, 70s and so on as it has become now. No one foresaw that by even sending one too many ICMPs at a modbus would crash it. THIS is the reality of SCADA systems. It has nothing to do with hiding the bugs hoping they will go away. It isn't about: they attacked Linux, then Windows, now SCADA boo-hooisms. Completely separate playing field. Sure these need to be designed properly however the reality is, many of these systems are old. Many of these systems control the quality of the water we drink, the pollution leaving a plant, the power being generated. This isn't: release it... make em fix it fast... that'll teach them. I wonder how the author would feel if say a water treatment plant in his area was affected causing all the water around him to be toxic. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2BF7D83F210A95AF
Re: Vulnerabilities in some SCADA server softwares
On Mon, 21 Mar 2011, J. Oquendo wrote: Reality: Car manufacturer was never made aware of the issue. How do you propose a manufacturer fix an issue? Due dilligence. If you sell a car that falls apart when someone pokes it with a finger--or a piece of mission-critical software where someone with a few days of free time to carry out a quick experiment and no prior knowledge can find a dozen of security vulnerabilities (and do not warn your customers that it is absolutely necessary to operate the software in an isolated environment), you fail to exercise it in an epic way. -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ For death is come up into our MS Windows(tm)... \ 21st century edition /
Re: Vulnerabilities in some SCADA server softwares
The correct time for vendors to do their own homework on SCADA was 2003 - that was the wakeup call. Anyone who has programmed for SCADA has always wondered what would happen if they started poking undocumented values into undocumented registers, but may not have the luxury of trying it out. Having been a security/network admin, there are many things that can be done when you know of a vulnerability - snort sigs, snort flexible response (thanks Jeff!), firewall configs, etc. I've done them before when vulns have been published before patches, and it is much better knowing that something is up than not. Do not rely on your vendor to keep you up to date on security issues. cheers, Jamie On 23 March 2011 18:36, J. Oquendo s...@infiltrated.net wrote: On 3/23/2011 2:13 PM, Theo de Raadt wrote: If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. You're flawed in your response: Public exposure increases the visibility, and therefore customersinstall the patches quicker. ... When someone full discloses a vulnerability, there is no patch to install quicker. This is obvious because there is no patch until either the vendor releases one, or staff using the product are capable of creating a work-around. In the case of the SCADA environment, we (again) are not talking about the potential of a defacement, blue screen, silly shell, we're talking about sensor, gears and often so much automation that it would be absurd for a SCADA engineer to go it alone and try create their own patch. Many of these systems don't have the option of failing or being taken offline. You also state: Without public visibility, they will keep running the old code the reality is, no one is going to outright replace some of these systems in these environments. These are not applications and or systems one can plop onto donated boxes. They have no choice BUT to run the code. -- Jamie Riden / ja...@honeynet.org / jamie.ri...@gmail.com http://uk.linkedin.com/in/jamieriden
Re: Vulnerabilities in some SCADA server softwares
On 03/23/2011 03:01 PM, Jim Harrison wrote: BTW, now that you know about it and there is no defined mitigation, what exactly*will* you do about it? This seems rather obvious, but 1. Ensure none of the affected SCADA systems are present on my work's network (BTW none are present on my home LAN). 2. Ensure that these systems, if they exist, are not accessible from either the Internet or even the local network where most of the users are. (BTW those first two are a given as far as security 101 is concerned, the rest seem like common sense) 3. Use Luigi's advisories and POC to understand the nature of the vulnerabilities. 4. Write custom IDS/IPS signatures to detect said vulnerabilities (not the exploits, big difference). 5. *If* these systems must, for whatever stupid reason, be attached to the regular LAN with the regular users, the IDS/IPS signatures will disallow the malicious connectivity they detect. If I am really paranoid, or feel that I cannot construct an adequate mitigation strategy that allows access, then all access is disallowed until a patch is available. 6. *If* the systems are not accessible, but in the future they have to be, for whatever stupid reason, I have some sigs and some steps I can take. Is that perfect? No of course not. Can I sell this plan to upper management? Sure. All of the bad info is public, remember? Can I now lean on the vendor and bitch about how vulnerable we are? Absolutely. I have worked at large corporations, done full/limited/responsible disclosure professionally and as a hobby, and have worked for vendors who sold security solutions and who have had bugs in their products reported to them. There is no solution for bug disclosure, period. Someone somewhere will get pissed off, and no matter what the rules are someone will break them. The disclosure method is irrelevant actually. One learns to adapt quickly to new information whether good or bad, or dies standing around bitching about something that didn't go their way they can't control anyway. -SN
Re: Vulnerabilities in some SCADA server softwares
If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. Actually both are true. More systems will be owned by these unmitigated issues since more attackers will be aware of their existence. While it is true that others knew about these issues (always assume so), many more will know about them now, and more systems likely will be exploited. This was certainly the case when tavis published an unmitigated windows vuln http://www.theregister.co.uk/2010/06/30/windows_exploit_spike/ . To your point people who 'are paying attention' will patch once a patch is available, and others who wouldn't normally know will see this in the news and become more aware of the issue/s. I don't think people on this list are arguing that the public shouldn't be made aware of problems in these devices, they are arguing that POC shouldn't be published for unmitigated issues as it doesn't benefit users. If you can provide real world statistics to the list demonstrating proof that people are safer by being aware of unmitigated threats with working PoC's, please send it to the list. I don't ask this to flame you, I think that this is data that people would be genuinely interested in learning from. Regards, - Robert http://www.qasec.com/ http://www.webappsec.org/
Re: Vulnerabilities in some SCADA server softwares
Simple Nomad wrote: 2. Ensure that these systems, if they exist, are not accessible from either the Internet or even the local network where most of the users are. Much easier said than done. The really scary SCADA systems are small cogs in large facilities that have been been built up over the years. New bits added now and then, old bits removed, things reconfigured. How do they know whether they are connected to the larger internet? And if they know one day how do they know a week later that no one plugged in something s/he shouldn't? (I just wanted to check my e-mail...) I am not saying it is impossible to keep a network isolated, but when dealing with a big legacy system (maybe measured in acres/hectares) with lots of random personnel tempted to do random things, and other annoying daily requirements (manufacturing the clothespins, generating the power--whatever it is that pays the bills), it is hard to do everything necessary to mitigate all dangerous and poorly documented security decisions, some from many years ago. And even if one is successful in being isolated, it sounds like Stuxnet didn't require a direct connection, I think it could spread the old fashioned way, via sneakernet. How do you stop that? (And then how do you apply a security fix from the responsible SCADA manufacturer?) As for encouraging creation and application of patches, say the responsible SCADA manufacturer sends a floppy (!) with a patch to your local, aging, nuclear power plant: Hmmm, we have three motor controllers that possibly match the model numbers they say this is for. The one circulating the number one storage pool has an -A suffix that the others don't, and it isn't mentioned on the datasheet that came with floppy. I phoned the manufacturer's help line and was told the patch is compatible. What do *you* want them to do with that floppy...? (I have no idea if nukes use computerized motor controllers--if not, substitute chemical plant or oil refinery or...) Yes, one can be more stupid or more smart, I am all for the smart stuff, and lots of us know lots of smart stuff, but I fear some underestimate the difficulties with legacy SCADA. -kb, the Kent who is willing to bet there are SCADA products available with features that require a connection to the public internet.
Re: Vulnerabilities in some SCADA server softwares
On 23/03/2011 6:13 PM, Theo de Raadt wrote: If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. Whilst I understand the whole stick it to the vendor argument, and now SCADA systems seem to be fair game to security researchers wanting to make a name for themselves in this high profile field. A lot of people are failing to see the vendors customer side of things. Industrial Control Systems (ICS), SCADA users, historically have their focus on availability (you don`t want you electricity/water/petrocehmicals being cut now do you) and safety (no one want to die making sure you get your electricity/water/petrochemicals), and security was never an issue because the SCADA systems were air gapped and the security needs were different that IT security. With Business pressures this air gap has gone away, but the original requirements of availability and safety still hold. And whilst you can all say that scada systems are broken you are failing to understand what they are designed for and what the vendors and customers priorities are. ICS/SCADA engineers also tend to be a wary and cautious lot particularly with changes to their systems, the last thing they need is a patch that breaks their functionality, and so even with patches a lot of testing takes place. A SCADA system isn't something that you can simply run the equivalent of Windows Update, reboot the machine and all will be well. Because the safety and availability requirements, upgrades can take a lot of planning and a lot of time to impliments. I've heard of upgrades taking anything from a couple of hours to a couple of years! Because no one wants their electricity cut off just to install the next round of patches. Now obviously none of this is ideal, but with the issues of patch management within an ICS, full disclosure can cause a lot of problems that whilst the vendor could respond to quickly will cause a lot of grief for the end user, through no fault of their own, or the vendor.
Re: Vulnerabilities in some SCADA server softwares
A lot of people are failing to see the vendors customer side of things. Industrial Control Systems (ICS), SCADA users, historically have their focus on availability (you don`t want you electricity/water/petrocehmicals being cut now do you) and safety (no one want to die making sure you get your electricity/water/petrochemicals), and security was never an issue because the SCADA systems were air gapped and the security needs were different that IT security. Exactly the same arguments could have been brought up 15 years ago against the then-disruptive and novel disclosure of vulnerabilities in Unix systems or in Windows (you can't just expect to shut down a bank and roll out potentially disruptive security updates every week! coupled with vendors certainly know what's best for us). Back then, commodity OSes have been designed insecurely because of similar business considerations, and not because of malice. The roots of BUGTRAQ are with the movement to end bug secrecy of that era. It caused some pain, and also caused some significant long-term improvements by convincing the public and the vendors that security is something you simply can't afford not to care about. Views on the cost / benefit balance of this process are varied, of course, but knowing what I learned thanks to this process, I sure wouldn't want to be using any of the operating systems available back then. /mz
Re: Vulnerabilities in some SCADA server softwares
Analogy: Car owner has his car speed up ending up in almost near catastrophe. Car owner goes to media outlets condemning the manufacturer: How could you be so reckless! Thousand of lives... Reality: Car manufacturer was never made aware of the issue. How do you propose a manufacturer fix an issue? Yes, the discussion definitely needed a car analogy... The author decided to follow a particular route, probably not out of malice, but because he believes that his responsibilities to inform the public outweigh the responsibility to assist the vendor. You wouldn't do the same, but you haven't discovered these bugs. Unless your view is that you would rather not know about about security problems at all, than see a disclosure mode you do not agree with, I do not think it's fair to lash out against the reporter; and it's not particularly fitting to do so on BUGTRAQ. /mz
RE: Vulnerabilities in some SCADA server softwares
Michal, First; while I agree with your statement regarding the overuse of car analogies, the comparison is accurate and fair in this case. The vendor's customers are now potentially at greater risk because of this announcement that includes no mitigation. Second; I fundamentally disagree with the idea that public disclosure as a means of vendor notification serves any purpose beyond tooting one's own horn and causing a panic state for the application vendor and users. Anyone who honestly believes that the bad guys are not watching the same lists where the good guys are communicating is operating far too close to a famous Egyptian river. IMHO, public disclosure only serves to increase the threat for the vendor's customers. Third; it is in lists exactly like this on where opinions on security matters and behaviors may be aired (to a degree; that's what moderators and common sense are for). While it's true that a person will act as he sees fit, you may also reasonably expect that differing opinions on that behavior will be expressed when the opinions are as polarized as in the responsible vs. public disclosure debate. HTH, Jim -Original Message- From: Michal Zalewski [mailto:lcam...@coredump.cx] Sent: Tuesday, March 22, 2011 2:24 PM To: J. Oquendo Cc: Luigi Auriemma; bugtraq@securityfocus.com Subject: Re: Vulnerabilities in some SCADA server softwares Analogy: Car owner has his car speed up ending up in almost near catastrophe. Car owner goes to media outlets condemning the manufacturer: How could you be so reckless! Thousand of lives... Reality: Car manufacturer was never made aware of the issue. How do you propose a manufacturer fix an issue? Yes, the discussion definitely needed a car analogy... The author decided to follow a particular route, probably not out of malice, but because he believes that his responsibilities to inform the public outweigh the responsibility to assist the vendor. You wouldn't do the same, but you haven't discovered these bugs. Unless your view is that you would rather not know about about security problems at all, than see a disclosure mode you do not agree with, I do not think it's fair to lash out against the reporter; and it's not particularly fitting to do so on BUGTRAQ. /mz
Re: Vulnerabilities in some SCADA server softwares
While I support full disclosure, I also advocate responsible disclosure. The public _has_ a right to know, but in this case, they can play no significant part in remedy or mitigation unless they are employees of the vendor or the customer. I believe the best course of action for a SCADA vulnerability would be to let the vendor know first, let them know you intend to disclose publicly after a reasonable time, then release to the potential customers in a responsible time thereafter, and finally the public (admittedly could be very arbitrary per researcher). This way you can hopefully get the fix started and let the security-conscious vendor notify customers how to defend in the interim for defense purposes _before_ you let a potential attacker in on the problem. Just my $0.02... Sent from my mobile launching platform... On Mar 22, 2011, at 16:24, Michal Zalewski lcam...@coredump.cx wrote: Analogy: Car owner has his car speed up ending up in almost near catastrophe. Car owner goes to media outlets condemning the manufacturer: How could you be so reckless! Thousand of lives... Reality: Car manufacturer was never made aware of the issue. How do you propose a manufacturer fix an issue? Yes, the discussion definitely needed a car analogy... The author decided to follow a particular route, probably not out of malice, but because he believes that his responsibilities to inform the public outweigh the responsibility to assist the vendor. You wouldn't do the same, but you haven't discovered these bugs. Unless your view is that you would rather not know about about security problems at all, than see a disclosure mode you do not agree with, I do not think it's fair to lash out against the reporter; and it's not particularly fitting to do so on BUGTRAQ. /mz
Re: Vulnerabilities in some SCADA server softwares
I believe the best course of action for a SCADA vulnerability would be to let the vendor know first, That's fine, but the controversy around the proper mode of disclosure is here to stay. For every good argument you make, there is an equally compelling counter-argument that other reasonable people believe in good faith. It really comes down to personal beliefs, and nothing has changed here in the past 15 years or so. Any of us can disagree, but lashing out against other people seems first of all impolite, and second, somewhat amusing on this particular forum. /mz
RE: Vulnerabilities in some SCADA server softwares
You appear to assume that because no one else has reported these vulns publicly that no one else has discovered them. This is false logic; proof is not satisfied by a lack of evidence to the contrary. To be clear, I do appreciate researchers who spend their time seeking and reporting security issues and sometimes just bugz in vendor software - it's this sort of independent scrutiny that keeps the vendors honest and on their toes. Where I take issue is with the false notion that public reporting leads to anything more than an increased threat potential for the customers themselves. Your argument that SCADA devices are by their nature less threatened due to their use case is false at best. If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology; whether that threat is limited to clean rooms or public-facing services is merely a matter of scale. in fact, in many cases where full-disclosure has forced immediate reaction by a vendor, neither the underlying problems that cause the vulnerability nor vendor's code response were as fully vetted as they might have been otherwise, leading to an incomplete solution caused by a rushed effort. This frequently leads to rework and reissuing of product updates, hardly a customer-serving process. As to the question of bugz for hire, there are at least as many arguments on either side of that discussion. HTH, Jim -Original Message- From: Luigi Auriemma [mailto:alu...@autistici.org] Sent: Wednesday, March 23, 2011 09:54 To: Jim Harrison Cc: Michal Zalewski; J. Oquendo; bugtraq@securityfocus.com Subject: Re: Vulnerabilities in some SCADA server softwares I fundamentally disagree with the idea that public disclosure as a means of vendor notification serves any purpose no problem, if you don't agree with full-disclosure or how I and the other researchers like me handle these security vulnerabilities you have the full power and freedom of finding them by yourself and handling them as you desire. so now the question is, why don't all these good guys spend their personal time and skills to find these vulnerabilities and reporting them to the vendors before me? the answer is that usually such people don't have the skills or simply don't like the idea of doing a professional work completely for free and even with the obligation of doing everything the vendor wants before the releasing of the patch that can take months or even years... practically a slave. or do you think that you can contact the vendor asking funds for the research you have already found? it would be logical but it's a non-written rule in the security community: it's better to go with full-disclosure for free. the only exceptions are Mozilla and Google with their bug bounty programs but oh well, they are pioneers. anyway regarding this particular case of SCADA I didn't like the behaviour of ICS-CERT at all. this entity has the full power for handling the security research and the communication between vendor and researcher with benefits (knowledge, funds and credits) for both but simply does nothing as resulted from the mails I exchanged with them covering all these aspects... I even don't understand what should be its work at this point except saying there is a bug in this SCADA and now the vendor says it's fixed. beyond tooting one's own horn and causing a panic state for the application vendor and users. my mail was completely neutral and had no alarmism in it, I'm even amazed that someone noticed it. as usual the panic is generated by non-technician people or people who have personal interests in speculating on the thing. Bugtraq is a technical mailing-list for people in the security field and in same cases its content may not be ready or correctly filtered for the other people who could see risks that are different than the reality. Anyone who honestly believes that the bad guys are not watching the same lists where the good guys are communicating is operating far too close to a famous Egyptian river. be sure that the bad guys are already aware of similar problems but you can't know it. if I can find these vulnerabilities in some hours without knowledge of SCADA and with a motivation not much far from the mah let's try this program imagine what can be done by how has strong motivation, time and knowledge. IMHO, public disclosure only serves to increase the threat for the vendor's customers. take the following consideration: SCADA systems are intended to work in isolated private networks so nobody except the authorized users should be able to even ping the machines where are running the vulnerable softwares. if this happens means that the security of the company has been already compromised before. now that the users of the vulnerable products are aware of the vulnerabilities they can verify if their network is really safe like it should be in any case and in the meantime they will wait the patches of the vendors
Re: Vulnerabilities in some SCADA server softwares
On 3/23/2011 12:54 PM, Luigi Auriemma wrote: I fundamentally disagree with the idea that public disclosure as a means of vendor notification serves any purpose so now the question is, why don't all these good guys spend their personal time and skills to find these vulnerabilities and reporting them to the vendors before me? the answer is that usually such people don't have the skills or simply don't like the idea of doing a professional work completely for free and even with the obligation of doing everything the vendor wants before the releasing of the patch that can take months or even years... practically a slave. You stated: usually such people don't have the skills Humor me and others on this list why don't you... Reported to CERT two days ago: Vulnerability Report Vulnerability Description Over 300 ActiveX based vulnerabilities have been discovered on multiple VMWare Server applications. Vulnerabilities range from denial of service attacks to full control of EIP which can lead to code execution Vulnerability Impact Attacker can trigger code execution Date 2011-03-21T11:53:40 I contacted CERT after getting a slight run around from the vendor yet I could have turned around and unloaded this information anywhere. The reality is what point would it prove? This does not include the fact that I'm sitting on vulnerabilities for SAP, IBM, CA even Siemens via way of Stuxnet analysis. There others that I've reported and others I haven't had time or chose not to and I'm sure there are plenty of security researchers, hackers, attackers, etc. who do the same. Sure I understand where the argument comes from: they can take months or even years but the reality is, SCADA is hip right now so this comes across as nothing more than juvenile idiocy to release SCADA based bugs. Look at me, I has SCADA! You assume that every vendor is similar to the irresponsible vendors who do take forever to respond. To that I refer back to the car analogy. You did nothing to give anyone an iota of an idea there was/is an issue. Bravo. Personally, I am torn between full, responsible and even no more free bugs types of disclosure, however, common sense dictates that playing with SCADA right about now is like playing with fire. We're not talking about a system blue screen or website graffiti as the outcome. Look at me I reverse shelled MS08067. With SCADA based systems, we are potentially dealing with the risks of physical harm to individuals via those systems. Did this cross your mind as being responsible or would you rather jump out in the public with the following: Look, I have a gun... See I just shot someone, you can too, all you have to do is the following What you did was nothing more than that. Look I have SCADA bugs, SCADA systems can be dangerous and kill you. Here, here is the bug to trigger potential damage. Thank you sincerely, Luigi. now that the users of the vulnerable products are aware of the vulnerabilities they can verify if their network is really safe like it should be in any case and in the meantime they will wait the patches of the vendors. How about we reflect reality? Now that millions of script kiddies, organized crime groups, need I mention the *t* word here also have this information. Now anyone can custom target these vulnerable products. It's ok because many SCADA systems engineers are not coders and many are incapable of making a patch on their own but hey, what the hell!!! I has lots of bugs Systems that otherwise could have been secured had you taken the time to be responsible and or mindful maybe even clueful are now at a greater risk. What did you accomplish? SCADA vulnerabilities are no big mystery and there are plenty of researchers who do things responsibly and make money at the same time. You could have chose the ZDI route which would have yielded you the same credits in the advisory while being paid for your research. So unless you live under a rock, your argument is sort of moot with regards to: or do you think that you can contact the vendor asking funds for the research you have already found? -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2BF7D83F210A95AF
Re: Vulnerabilities in some SCADA server softwares
If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code.
Re: Vulnerabilities in some SCADA server softwares
On 3/23/2011 2:13 PM, Theo de Raadt wrote: If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. You're flawed in your response: Public exposure increases the visibility, and therefore customersinstall the patches quicker. ... When someone full discloses a vulnerability, there is no patch to install quicker. This is obvious because there is no patch until either the vendor releases one, or staff using the product are capable of creating a work-around. In the case of the SCADA environment, we (again) are not talking about the potential of a defacement, blue screen, silly shell, we're talking about sensor, gears and often so much automation that it would be absurd for a SCADA engineer to go it alone and try create their own patch. Many of these systems don't have the option of failing or being taken offline. You also state: Without public visibility, they will keep running the old code the reality is, no one is going to outright replace some of these systems in these environments. These are not applications and or systems one can plop onto donated boxes. They have no choice BUT to run the code. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2BF7D83F210A95AF
Re: Vulnerabilities in some SCADA server softwares
I fundamentally disagree with the idea that public disclosure as a means of vendor notification serves any purpose no problem, if you don't agree with full-disclosure or how I and the other researchers like me handle these security vulnerabilities you have the full power and freedom of finding them by yourself and handling them as you desire. so now the question is, why don't all these good guys spend their personal time and skills to find these vulnerabilities and reporting them to the vendors before me? the answer is that usually such people don't have the skills or simply don't like the idea of doing a professional work completely for free and even with the obligation of doing everything the vendor wants before the releasing of the patch that can take months or even years... practically a slave. or do you think that you can contact the vendor asking funds for the research you have already found? it would be logical but it's a non-written rule in the security community: it's better to go with full-disclosure for free. the only exceptions are Mozilla and Google with their bug bounty programs but oh well, they are pioneers. anyway regarding this particular case of SCADA I didn't like the behaviour of ICS-CERT at all. this entity has the full power for handling the security research and the communication between vendor and researcher with benefits (knowledge, funds and credits) for both but simply does nothing as resulted from the mails I exchanged with them covering all these aspects... I even don't understand what should be its work at this point except saying there is a bug in this SCADA and now the vendor says it's fixed. beyond tooting one's own horn and causing a panic state for the application vendor and users. my mail was completely neutral and had no alarmism in it, I'm even amazed that someone noticed it. as usual the panic is generated by non-technician people or people who have personal interests in speculating on the thing. Bugtraq is a technical mailing-list for people in the security field and in same cases its content may not be ready or correctly filtered for the other people who could see risks that are different than the reality. Anyone who honestly believes that the bad guys are not watching the same lists where the good guys are communicating is operating far too close to a famous Egyptian river. be sure that the bad guys are already aware of similar problems but you can't know it. if I can find these vulnerabilities in some hours without knowledge of SCADA and with a motivation not much far from the mah let's try this program imagine what can be done by how has strong motivation, time and knowledge. IMHO, public disclosure only serves to increase the threat for the vendor's customers. take the following consideration: SCADA systems are intended to work in isolated private networks so nobody except the authorized users should be able to even ping the machines where are running the vulnerable softwares. if this happens means that the security of the company has been already compromised before. now that the users of the vulnerable products are aware of the vulnerabilities they can verify if their network is really safe like it should be in any case and in the meantime they will wait the patches of the vendors. --- Luigi Auriemma http://aluigi.org
Re: Vulnerabilities in some SCADA server softwares
On 3/23/11 9:46 AM, J. Oquendo wrote: How about we reflect reality? We can't honestly do that, we all only have our perception. It's funny how we can get stuck in a trap of 0 and 1. My perception is we'll always disagree on disclosure technique, or at least nitpick some minor detail into infinity like we do with politics or religion. We're human after all. That said, bugs exist whether we find them or not, every software has them, and if the author had never reported them that in no way implies they were not already known and/or being used for subversive means with the potential intent to cause harm. I guess I'm oldsk00l enough to like responsible disclosure, but also anti-authoritarian enough (who's making the rules? why are they god?) to believe this is not black and white. Scare away those who disclose (regardless of method), and you're left with undisclosed vulnerabilities the bad guys with the most to gain ($$$ to invest in teams of hacke^H^H^Hengineers, not just script kiddies) still know about and can most effectively leverage. I say the only bad disclosure is no disclosure. If vendors can't move fast enough, they'll be usurped by those who can make better use of new processes and technologies to keep up with trends. PS: Is this really hot now? My only thought when I read the original post was about time -- SCADA has been known (as in publicly aired on broadcast television) to have many gaping vulnerabilities for at least a decade. The (obviously bogus) justification was usually it's restricted deployment model.
Re: Vulnerabilities in some SCADA server softwares
On 03/23/2011 01:36 PM, J. Oquendo wrote: You're flawed in your response: Public exposure increases the visibility, and therefore customersinstall the patches quicker. ... When someone full discloses a vulnerability, there is no patch to install quicker. This is obvious because there is no patch until either the vendor releases one, or staff using the product are capable of creating a work-around. In the case of the SCADA environment, we (again) are not talking about the potential of a defacement, blue screen, silly shell, we're talking about sensor, gears and often so much automation that it would be absurd for a SCADA engineer to go it alone and try create their own patch. Many of these systems don't have the option of failing or being taken offline. You also state: Without public visibility, they will keep running the old code the reality is, no one is going to outright replace some of these systems in these environments. These are not applications and or systems one can plop onto donated boxes. They have no choice BUT to run the code. Actually they have the choice to not run SCADA systems open to the Internet. If they are so critical that you are playing with fire like you mentioned in another email, why would they be accessible via script kiddie attack, or any remote over-the-tubes attack? Running SCADA systems open to the entire Internet is what I would call irresponsible. At this point, it is academic anyway. The cat is out of the bag. Thanks Luigi, I at least know about these issues now. -SN
Re: Vulnerabilities in some SCADA server softwares
On 3/23/2011 2:13 PM, Theo de Raadt wrote: If *any* threat exists, that threat is increased by public exposure of unmitigated attack methodology I think you have it wrong. Public exposure increases the visibility, and therefore customers install the patches quicker. Without public visibility, they will keep running the old code. You're flawed in your response: Public exposure increases the visibility, and therefore customersinstall the patches quicker. ... When someone full discloses a vulnerability, there is no patch to install quicker. With public involvement, the timeline goes a bit like this: 1 - Full disclosure 2 - Publically, the vendor looks bad to customers 3 - A fix is crafted immediately; tested rapidly, then released to customers. 4 - Publically, customer and vendor would look bad if they did not install the fix immediately -- as soon as it is available I am very well aware of what is going on out there in industry: Customers do not install patches unless they have to, because various realities of the environment make it hard. That does not make deferring the repairs acceptable. The public eye can help improve this situation. This is obvious because there is no patch until either the vendor releases one, or staff using the product are capable of creating a work-around. No, it is not obvious that no patch is available. Quite often patches or upgrades do exist, but it has not been deployed. Sometimes the SCADA vendor is responsible for trying to charge more, also. In the case of the SCADA environment, we (again) are not talking about the potential of a defacement, blue screen, silly shell, we're talking about sensor, gears and often so much automation that it would be absurd for a SCADA engineer to go it alone and try create their own patch. Many of these systems don't have the option of failing or being taken offline. You also state: Without public visibility, they will keep running the old code the reality is, no one is going to outright replace some of these systems in these environments. These are not applications and or systems one can plop onto donated boxes. They have no choice BUT to run the code. Oh give me a break. You are talking to me as if I am a child, which means you don't know who I am. The people involved in selling and re-selling these broken SCADA system software are the children. For financial or other reasons they have assumed that the same quality control failure leads to bugs leads to exploits game that has affected generations of software would not apply to them. It happened to the Unix environment. Then it happened to the Microsoft environment. Then it happened to the Linux environment. And then it happened to the browser environment. Currently it is happening to the cell phone environment. You expect me to believe it will not eventually happen to the SCADA environment? And it does not make an ounce of difference how much the defenders of the SCADA world whine about full disclosure being evil. I expect a surge of published exploits against SCADA software, and whining about full disclosure will not stop it. You might think you are all creative with your arguments, but we've heard it all before. And yes, I think someday soon we are going to start having the same arguments about software in use at hospitals, and I think full disclosure will happen about those too. As it should. Quality controls do not get strong until the risks are visible. So go ahead, talk about the risks but do not blame messengers. Yes, with SCADA there is tremendous danger to our infrastructure - from a safety perspective and from a financial perspective. But is the browser situation any different, for the public, if you total potential financial losses? (It is fair, a utility with a massive SCADA failure would eventually socialize the losses after conversion to dollars and cents). If there is danger, why are the vendors not getting ahead of the curve? We know they are not getting ahead of the curve. If you use SCADA software, go read your contracts to gauge where the liability lands. I suspect you already know. And I suspect all the people arguing against full disclosure work on that side of the industry.
Re: Vulnerabilities in some SCADA server softwares
J. Oquendo wrote: At what point in time did you try contacting any of the vendors for these issues? SCADA systems are infamous for being terribly insecure. (You can search the internet for demonstration video of equipment catching fire because of such bugs.) SCADA manufacturers seem to have a firewall mentality that excuses them from needing to be secure. I am not at all surprised to see these bugs, though I do cringe at how embarrassing they are. Heaping some embarrassment on the vendors seems well deserved. The downside to doing it publicly: Just because SCADA systems communicate with the public internet and so are directly or indirectly vulnerable doesn't mean the people who run them *intended* to hook them up to the internet nor are aware what wire got plugged in or thumbdrive transferred that made the bridge. They probably think they are invulnerable, I bet the Iranians thought so. The manufacturers might release a bug fix and customers (who discovered they have some equipment for which there is an upgrade), maybe won't think they need them. Also, once I have my clothespin factory, or nuclear plant, up and running smoothly, how attractive is it to start applying upgrades? Should I validate them first on my testbed nuclear power plant? It is hard to test a SCRAM adequately. And if my vendor is so incompetent as to write so many security holes into the software in the first place, how much faith should I have in a different programmer, maybe years later, patching code s/he probably doesn't understand as well as the first sloppy programmer did. And who gets this thankless task? The senior programmer who is working on the new project that is already behind schedule, or the new guy? Does the new guy fully understand the build procedure to even make all the parts correctly? Do they even have good source code control to be sure they know what sources the old (and largely working version) was built from? Are the upgrade procedures reliable and understood by the vendor and by the worker the customer will send out on the factory floor with a CD-ROM in hand? (Will that worker stick the CD-ROM in the right slot and reboot the right box?) Maybe. Would I install a stack of SCADA upgrades to *my* functioning factory? Maybe not. Scary, scary stuff. Security needs to be designed in, implemented carefully each step along the way, and reviewed. Instead people with security in their job title so often seem to think security is firewalls, buying anti-virus support contracts, and requiring use of MS Outlook and Internet Explorer. -kb, the Kent who will shut up now.
Re: Vulnerabilities in some SCADA server softwares
On 3/21/2011 12:16 PM, Luigi Auriemma wrote: The following are almost all the vulnerabilities I found for a quick experiment some months ago in certain well known server-side SCADA softwares still vulnerable in this moment. At what point in time did you try contacting any of the vendors for these issues? Analogy: Car owner has his car speed up ending up in almost near catastrophe. Car owner goes to media outlets condemning the manufacturer: How could you be so reckless! Thousand of lives... Reality: Car manufacturer was never made aware of the issue. How do you propose a manufacturer fix an issue? Where in any of your advisories did you take the time to let a company know: hey you guys have some potential issues, here they are!!! -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2BF7D83F210A95AF
Re: Vulnerabilities in some SCADA server softwares
At what point in time did you try contacting any of the vendors for these issues? the vendors of the affected softwares have not been contacted. How do you propose a manufacturer fix an issue? in the security field a public vulnerability is a dead vulnerability, anyone who has found and released at least one security bug in his life knows it and knows to what I refer. 90% of the job of fixing a bug is just finding it first, I have even showed the details, the causes and the ways to replicate them. Where in any of your advisories did you take the time to let a company know: hey you guys have some potential issues, here they are!!! I have done it in the exact moment that I have uploaded my advisories on my website making anyone aware of the problems, included the same vendors that now can fix them. --- Luigi Auriemma http://aluigi.org
Vulnerabilities in some SCADA server softwares
The following are almost all the vulnerabilities I found for a quick experiment some months ago in certain well known server-side SCADA softwares still vulnerable in this moment. In case someone doesn't know SCADA (like me before the tests): it's just one or more softwares (usually a core, a graphical part and a database) that allow people to monitor and control the various hardware sensors and mechanisms located in industrial environments like nuclear plants, refineries, gas pipelines, airports and other less and more critical fields that go from the energy to the public infrastructures and obviously also the small normal industries. In technical terms the SCADA software is just the same as any other software used everyday, so with inputs (in this case they are servers so the input is the TCP/IP network) and vulnerabilities: stack and heap overflows, integer overflows, arbitrary commands execution, format strings, double and arbitrary memory frees, memory corruptions, directory traversals, design problems and various other bugs. Full-disclosure advisories and proof-of-concepts: Siemens Tecnomatix FactoryLink: http://aluigi.org/adv/factorylink_1-adv.txt http://aluigi.org/adv/factorylink_2-adv.txt http://aluigi.org/adv/factorylink_3-adv.txt http://aluigi.org/adv/factorylink_4-adv.txt http://aluigi.org/adv/factorylink_5-adv.txt http://aluigi.org/adv/factorylink_6-adv.txt (DoS only) Iconics GENESIS32 and GENESIS64: http://aluigi.org/adv/genesis_1-adv.txt http://aluigi.org/adv/genesis_2-adv.txt http://aluigi.org/adv/genesis_3-adv.txt http://aluigi.org/adv/genesis_4-adv.txt http://aluigi.org/adv/genesis_5-adv.txt http://aluigi.org/adv/genesis_6-adv.txt http://aluigi.org/adv/genesis_7-adv.txt http://aluigi.org/adv/genesis_8-adv.txt http://aluigi.org/adv/genesis_9-adv.txt http://aluigi.org/adv/genesis_10-adv.txt http://aluigi.org/adv/genesis_11-adv.txt http://aluigi.org/adv/genesis_12-adv.txt http://aluigi.org/adv/genesis_13-adv.txt 7-Technologies IGSS (Interactive Graphical SCADA System): http://aluigi.org/adv/igss_1-adv.txt http://aluigi.org/adv/igss_2-adv.txt http://aluigi.org/adv/igss_3-adv.txt http://aluigi.org/adv/igss_4-adv.txt http://aluigi.org/adv/igss_5-adv.txt http://aluigi.org/adv/igss_6-adv.txt http://aluigi.org/adv/igss_7-adv.txt http://aluigi.org/adv/igss_8-adv.txt DATAC RealWin: http://aluigi.org/adv/realwin_2-adv.txt http://aluigi.org/adv/realwin_3-adv.txt http://aluigi.org/adv/realwin_4-adv.txt http://aluigi.org/adv/realwin_5-adv.txt http://aluigi.org/adv/realwin_6-adv.txt http://aluigi.org/adv/realwin_7-adv.txt http://aluigi.org/adv/realwin_8-adv.txt --- Luigi Auriemma http://aluigi.org
