Last Updated: 2008-09-08 23:45:34 UTC
by Raul Siles (Version: 5)
In June we talked about a SCADA buffer overflow vulnerability discovered by CORE that affected the CitectSCADA product. It could allow a remote un-authenticated attacker to force DoS or to execute arbitrary code on vulnerable systems. The patch was available at that time, so if you have not patched or taken extreme security precautions and countermeasures yet, you have another reason to do so today!
This weekend, Kevin Finisterre has published a working exploit in the form of a Metasploit (MSF) module that demosntrates how critical this vulnerability aginst the ODBC service is. The original CORE advisory details the vulnerability (CVE-2008-2639), the paper associated to the exploit summarizes all the details about the exploit and related research, and the working exploit publicly available for MSF provides access to a command prompt with the privileges of the currently running Citect process. In fact, our DShield service shows a peak in the wild associated to the target vulnerable port (TCP/20222).
Time to act!!
UPDATE 1: Kevin notified us that a Snort signature to detect the SCADACitect ODBC exploit has been released by Dale:
alert tcp $EXTERNAL_NET ANY -> $HOME_NET 20222 (msg:”CitectSCADA ODBC Overflowflow Attempt”; flow:established,to_server; dsize:4; byte_test:4,>,399,0; reference:cve,2008-2639; sid:1111601; rev:1; priority:1;)
Others may come in the next days from common sources.
UPDATE 2: Port TCP/20222 is on the top ranking of the Dshield trends.
UPDATE 3: Thanks to fellow handler Joel, signature above has been slightly modified to improve performance.
Last Updated: 2008-09-08 23:26:45 UTC
by Raul Siles (Version: 2)
The Web Application Security Consortium (WASC) has published the WASC Web Application Security Statistics Project 2007. This is one of the main references about Web-based vulnerabilities and attacks, together with the OWASP Top 10 project (I hope OWASP also updates it soon with data from 2007, as it currently covers 2006 although it's called 2007 ;) ).
The main advantage of the WASC statistics is that it focuses on vulnerabilities discovered in custom Web applications, instead of collecting data from the Mitre CVE project and linked to open source and commercial Web applications. At first sight, this year the number of contributtors feeding data to the project has notably increased from previous years.
Looking at the details, on the one hand, I'm surprised as only 7% of the applications analyzed can be automatically compromissed. Based on all the incidents we see associated to automated tools, such as the so many times mentioned automated SQL injection attacks, I'd have said this is a bigger number. On the other hand, after performing manual analysis and testing (including white and black box), almost 97% of the analyzed applications present a high severity vulnerability. This roughly matches the numbers I see on penetrations testing engagements. Overall, this also means to me that although the automated tools have improved a lot over the last few years, a lot of detailed and manual testing is still required.
Once again, Cross Site Scripting (XSS) and SQL injection (the big two players) are in the top of the list, together with information leakage. Looking at the numbers, I thought SQL injection would have a bigger presence in the number of vulnerabilities and vulnerable sites. Although the statistics seem to show the number is decreasing from previous years, do not stop fighting this class of attack, and all types of injection in general!! From a threat classification perspective, client-based attacks and information disclosure (again) are the most prevalent ones.
In my opinion, the missing vulnerability is Cross-Site Request Forgery (CSRF), as most Web sites are vulnerable to it. It does not appear in the diagrams, although reading carefully through the project notes, it says (literaly):
The most prevalent vulnerability Cross-Site Request Forgery in this statistics is not on top because it is difficult to detect in automatically and because a lot of experts take its existence for granted.
I suggest you to read the details, get your own conclusions from the numbers (as they are just numbers), but definitely continue monitoring, auditing, and improving the security of your Web applications!
Raul teaches the SANS "Web Application Penetration Testing In-Depth" course in London on December!
Last Updated: 2008-09-08 23:24:46 UTC
by Raul Siles (Version: 2)
At the end of last month we talked about some Vishing enhancements, or how attackers record voice snippets of the target IVR (Interactive Voice Recording) system to provide credibility about their fake environment, something they have been doing for some time and that definitley is going to grow. This is trivial for an attacker, in a similar way it is trivial to duplicate a Web site in a traditional Phising scam (except for the SSL certificate), and it can be easily acomplished by acquiring a SIP number (or set of numbers), an associated VoIP/SIP trunk, and setting up an IVR using an open-source VoIP PBX/server, such as Asterisk. The attacker simply gets the voice recording from the company to impersonate, and setup the recorded files in Asterisk.
Some of the best practices against Vishing attacks suggest the victim to:
- Verify that the number she is calling to belongs to the "calling" company, typically through the company Web page or other printed material, but unfortunately, lot of users are used to check in search engines.
- Directly call the company number instead of trusting a received call ensuring XYZ is calling you with a very important or juicy request, even if the caller ID is the right one.
Websense recently published details about Reverse Vishing attacks in China. These attacks focus on making useless the two previous recommendations by:
- Using search engine optimisation (SEO) poisoning techniques to position the fake phone numbers associated to legitimate organisations on top of search engines.
- Encouraging the victim (through the initial fake e-mail) to call the fake number.
If the victim checks the number through a search engine, the "authentication" is successful :( If the victim is cautious and performs the verification of the number through the company Web page... let's hope the attackers didn't break into the Web server too to subtlely modify this information. I'v not seen this in the wild yet, but with the huge amount of Web vulnerabilities nowadays, keep an eye on this in the future!
When talking about VoIP security (and traditional telephony), any reference to a phone number or the "so many times trusted and easily spoofable" caller ID must be verified and authenticated. With the recent DNS vulnerability this summer, it is mandatory to take a look at the impact on ENUM, the phone number (E.164) to domain names translation protocol (e164.arpa), and add secure capabilities, especially authentication, to it!
Meanwhile, it is recommended to verify and correlate phone numbers (got by e-mail, IM, caller ID...) using different sources: the company Web page, printed material from the company, multiple search engines and specific phone queries (like Google's "phonebook:" operator), and specific phone searching services, like Who Called Us, 800Notes, NumberZoom, Switchboard.com, Whitepages.com, Reversephonedirectory.com, or Phonenumber.com. Unfortunately, most of them mainly apply to the US, so you need to find a similar service for your country.
UPDATE: Thanks Dan for the notification about the "vhising" typos; of course, "vishing" is the right term!