Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 26 min 50 sec ago

Scanning for Single Critical Vulnerabilities, (Fri, Oct 24th)

Fri, 10/24/2014 - 15:57

Where I work, we have a decentsizedIP space and scanning can be problematic. Within our IP space, we can have ~20 Million IPs available. Traditional scanning using NMAP, while effective, can take a long time even with aggressive scan setting. By leveraging new scanning technologies like Masscan (hxxps://github.com/robertdavidgraham/masscan), this scanning can be done in minutes. With moderate settings, I dont want to crash firewalls, it takes about 15 min per port.

While this example is specific to Heartbleed, I use this technique for any of the exploit-of-the-day. By using a fast port scanner to reduce the number of hosts to only the systems running the service in question, you can dramatically speed up your scan time. Additionally, within the first couple of days of an exploit, you may be using a custom script to scan rather than a plugin from an enterprise solution.

Another use case is a vulnerability found during incident response. If I determine a specific vulnerability was used to compromise a server, I then use this technique to determine other possible compromised systems. If they were not compromised, then we have them patch.

Masscan

Installing ">">"> make install

Masscan uses a similar command line to nmap.

masscan -p 443,448,456,563,614,636,989,990,992,993,994,995,8080,10000

10.0.0.0/8 -oG 10-scan-ssl - -max-rate 10000

">--make-rate sets the speed of the scan

Once Masscan has quickly identified targets for deeper inspection, you can use your more specific tool to determine if the system is vulnerable. In this example, its an nmap plugin.

NMAP

cd /tmp

svn co https://svn.nmap.org/nmap

cd nmap

make install


To get the input file in the correct format, use the following command to get just a file with a single IP per line.

grep -v # 10-scan-443 |awk {print $2} /tmp/nmap

">nmap -p 443,448,456,563,614,636,989,990,992,993,994,995,8080,10000 --script=ssl-heartbleed.nse -iL /tmp/nmap -oA /tmp/ssl-vul-test


Ive had mixed results with other scanners (scanrand ect..). Any other large scale scanners with which you have had good success?

--

Tom Webb

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Shellshock via SMTP, (Fri, Oct 24th)

Fri, 10/24/2014 - 11:05

Ive received several reports of what appears to be shellshock exploit attempts via SMTP. The sources so far have all be webhosting providers, so Im assuming these are compromised systems." />

The payload is an IRC perl bot with simple DDoS commands and the ability to fetch and execute further code.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Are you receiving Empty or "Hi" emails?, (Fri, Oct 24th)

Fri, 10/24/2014 - 06:10

I wanted to perform a little unscientific information gathering, Im working with a small group who think theyre being specifically targeted by these, while I think its more widespread and opportunitistic. If youve recently received these no content probe emails, or a simple Hi message, please send a simple comment below in this format:

  • Industry
  • Order of magnitued in size (e.g. 10, 100, 1000)
  • Sending domain

Feel free to use our comment page to add extra analysis comments here: https://isc.sans.edu/contact.html

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, October 24th 2014 http://isc.sans.edu/podcastdetail.html?id=4207, (Fri, Oct 24th)

Thu, 10/23/2014 - 21:06
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Digest: 23 OCT 2014, (Thu, Oct 23rd)

Thu, 10/23/2014 - 11:36

A number of items for your consideration today, readers. Thanks as always to our own Rob VandenBrink for pointing out a number of these.

In case you missed it, Whats New in Windows PowerShell.

A new Snort release is available: Snort 2.97.

VMWare has released a security advisory: VMSA-2014-0011 - VMware vSphere Data Protection product update addresses a critical information disclosure vulnerability.

There">| font-family: ">@holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, October 23rd 2014 http://isc.sans.edu/podcastdetail.html?id=4205, (Thu, Oct 23rd)

Wed, 10/22/2014 - 20:50
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

telnetd rulez: Cisco Ironport WSA Telnetd Remote Code Execution Vulnerability, (Wed, Oct 22nd)

Wed, 10/22/2014 - 15:26

We received the following vulnerability advisory for a remote code execution vuln identified and reported in Ciscos Ironport WSA Telnetd.

Vendor: Cisco
Product web page: http://www.cisco.com
Affected version: Cisco Ironport WSA - AsyncOS 8.0.5 for Web build 075
Date: 22/05/2014
Credits: Glafkos Charalambous
CVE: CVE-2011-4862
CVSS Score: 7.6
Impact: Unauthenticated Remote Code Execution with elevated privileges
Description: The Cisco Ironport WSA virtual appliances are vulnerable to an old FreeBSD telnetd encryption Key ID buffer overflow which allows remote attackers to execute arbitrary code (CVE-2011-4862).
Cisco WSA Virtual appliances have the vulnerable telnetd daemon enabled by default.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
http://www.freebsd.org/security/advisories/FreeBSD-SA-11:08.telnetd.asc
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120126-ironport

Nice work by Glafkos but what you cant see is me shaking my head. *sigh*
Ill repeat the facepalm-inspiring statement again: Cisco WSA Virtual appliances have the vulnerable telnetd daemon enabled by default.
Still, with the telnets? And on by default?
From the related FreeBSD advisory:
The FreeBSD telnet daemon, telnetd(8), implements the server side of the
TELNET virtual terminal protocol. It has been disabled by default in
FreeBSD since August 2001, and due to the lack of cryptographic security
in the TELNET protocol, it is strongly recommended that the SSH protocol
be used instead.">Trying 192.168.0.160...
Connected to 192.168.0.160.
Escape character is ^]">| font-family: ">@holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

CVE-2014-6352 - Microsoft posts bulletin https://technet.microsoft.com/library/security/3010060 and quick "fix-it" https://support.microsoft.com/kb/3010060 . Look for a permanent fix in a future patch., (Tue, Oct 21st)

Wed, 10/22/2014 - 02:22

=============== Rob VandenBrink Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, October 22nd 2014 http://isc.sans.edu/podcastdetail.html?id=4203, (Wed, Oct 22nd)

Tue, 10/21/2014 - 20:52
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

CSAM Month of False Positives: Ghosts in the Pentest Report, (Tue, Oct 21st)

Tue, 10/21/2014 - 06:10

As part of most vulnerability assessments and penetration tests against a website, we almost always run some kind of scanner. Burp (commercial) and ZAP (free from OWASP) are two commonly used scanners. Once youve done a few website assessments, you start to get a feel for what pages and fields are likely candidates for exploit. But especially if its a vulnerability assessment, where youre trying to cover as many issues as possible (and exploits might even be out of scope), its always a safe bet to run a scanner to see what other issues might be in play.

All too often, we see people take these results as-is, and submit them as the actual report. The HUGE problem with this is false positives and false negatives.

False negatives are issues that are real, but are not be found by your scanner. For instance, Burp and ZAP arent the best tools for pointing a big red arrow at software version issues - for instance vulnerability versions of Wordpress or Wordpress plugins. You might want to use WPSCAN for something like that. Or if you go to the login page, a view source will often give you what you need.

Issues with the certificates will also go unnoticed by a dedicated web scanner - NIKTO or WIKTO are good choices for that. Or better yet, you can use openssl to pull the raw cert, or just view it in your browser.

(If youre noticing that much of what the cool tools will do is possible with some judicious use of your browser, thats exactly what Im pointing out!)

NMAP is another great tool to use for catching what a web scanner might miss. For instance, if youve got a Struts admin page or Hypervisor login on the same IP as your target website, but on a different port than the website, NMAP is the go-to tool. Similarly, lots of basic site assessment can be done with the NMAP --version parameters, and the NSE scripts bundled with NMAP are a treasure trove as well! (Check out Manuels excellent series on NMAP scripts).

False positives are just as bad - where the tool indicates a vulnerability where there is none. If you include blatant false positives in your report, youll find that the entire report will end up in the trash can, along with your reputation with that client! A few false positives that I commonly see are SQL Injection and OS Commmand Injection.

SQL Injection is a vulnerability where, from the web interface, you can interact with and get information from a SQL database thats behind the website, often dumping entire tables.

Website assessment tools ( Burp in this case, but many other tools use similar methods) commonly tests for SQL Injection by injecting a SQL waitfor delay 0:0:20 command. If this takes a significantly longer time to complete than the basic statement, then Burp will mark this as Firm for certainty. Needless to say, I often see this turn up as a false positive. What youll find is that Burp generally runs multiple threads (10 by default) during a scan, so can really run up the CPU on a website, especially if the site is mainly parametric (where pages are generated on the fly from database input during a session). Also, if a sites error handling routines take longer than they should, youll see this get thrown off.

So, how should we test to verify this initial/preliminary finding? First of all, Burps test isnt half bad on a lot of sites. Testing Burps injection with curl or a browser after the scanning is complete will sometimes show that the SQL injection is real. Test with multiple times, so that you can show consistent and appropriate delays for values of 10,30,60, 120 seconds.

If that fails - for instance if they all delay 10 seconds, or maybe no appreciable delay at all, dont despair - SQLMAP tests much more thoroughly, and should be part of your toolkit anyway - try that. Or test manually - after a few websites youll find that testing manually might be quicker than an exhaustive SQLMAP test (though maybe not as thorough).

If you use multiple methods (and there are a lot of different methods) and still cant verify that SQL injection is in play after that initial scans finding, quite often this has to go into the false positives section of your report.


OS Command Injection - where you can execute unauthorized Operating System commands from the web interface - is another common false positive, and for much the same reason. In this vulnerability, the scanner will often use ping -c 20 127.0.0.1 or ping -n 20 127.0.0.1 - in other words, the injected command tells the webserver to ping itself, in this case 20 times. This will in most operating systems create a delay of 20 seconds. As in the SQL injection example, youll find that tests that depend on predictable delay will often get thrown off if they are executed during a busy scan. Running them after the scan (again, using your browser or curl) is often all you need to do to prove these findings as false. Testing other commands, such as pinging or opening an ftp session to a test host on the internet (that is monitoring for such traffic using tcpdump or syslog) is another good sober second thought test, but be aware that if the website you are testing has an egress filter applied to its traffic, a successful injection might not generate the traffic you are hoping for - itll be blocked at the firewall. If you have out of band access to the site being assessed, creating a test file is another good test.

Other tests can similarly see false positives. For instance, any tests that rely only on service banner grabs can be thrown off easily - either by admins putting a false banner in place, or if site updates update packages and services, but dont change that initially installed banner.

Long story short, never never never (never) believe that initial finding that your scanning tool gives you. All of the tools discussed are good tools - they should all be in your toolbox and in many cases should be at the top of your go-to list. Whether the tool is open source or closed, free or very expensive, they will all give you false positives, and every finding needs to be verified as either a true or false positive. In fact, you might not want to believe the results from your second tool either, especially if its testing the same way. Whenever you can, go back to first principals and verify manually. Or if its in scope, verify with an actual exploit - theres nothing better than getting a shell to prove that you can get a shell!

For false negatives, youll also want to have multiple tools and some good manual tests in your arsenal - if your tool misses a vulnerability, you may find that many or all of your tools test for that issue the same way. Often the best way to catch a false negative is to just know how that target service runs, and know how to test for that specific issue manually. If you are new to assessments and penetration tests, false negatives will be much harder to find, and really no matter how good you are youll never know if you got all of them.

If you need to discuss false positives and negatives with a non-technical audience, going to non-technical tools is a good way to make the point. A hammer is a great tool, but while screws are similar to nails, a hammer isnt always the best way to deal with them.

Please, use our comment form tell us about false positives or false negatives that youve found in vulnerability assessments or penetration tests. Keep in mind that usually these arent an indicator of a bad tool, theyre usually just a case of getting a proper parallax view to get a better look at the situation.

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, October 21st 2014 http://isc.sans.edu/podcastdetail.html?id=4201, (Tue, Oct 21st)

Mon, 10/20/2014 - 20:27
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple Multiple Security Updates, (Mon, Oct 20th)

Mon, 10/20/2014 - 12:28


Apple released security update today for iOS 8 and Apple TV 7.

iOS 8.1 (APPLE-SA-2014-10-20-1 iOS 8.1) is now available for iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later, to addresses the following:

Bluetooth CVE-2014-4448
House Arrest CVE-2014-4448
iCloud Data Access CVE-2014-4449
Keyboards CVE-2014-4450
Secure Transport CVE-2014-3566

Apple TV 7.0.1 (APPLE-SA-2014-10-20-2 Apple TV 7.0.1) is now available for Apple TV 3rd generation and later, to address the following:

Bluetooth CVE-2014-4428
Secure Transport CVE-2014-3566

[1] https://support.apple.com/kb/HT1222

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Teaching SEC 503 end of October in Ottawa

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, October 20th 2014 http://isc.sans.edu/podcastdetail.html?id=4199, (Mon, Oct 20th)

Sun, 10/19/2014 - 20:57
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft MSRT October Update, (Sun, Oct 19th)

Sun, 10/19/2014 - 07:50

This past week Microsoft MSRT push contains detections/removals for several widely used APT tools. The coalition (led by Novetta) that brought about the inclusions of these tools in this month MSRT, are encouraging enterprises to push/execute this month MSRT update. Some of malware included in this month MSRT update have a preliminary report posted here.

If you are using either Snort or Sourcefire, the ruleIDs to detect some of the threat/family in this month MSRT release are listed below and can be downloaded from Snort or from Sourcefire VRT subscription.

Derusbi -- 20080
Fexel -- 29459
Hikit -- 30948
DeputyDog -- 28493
Hydraq -- 16368, 21304
DarkMoon -- 7816, 7815, 7814, 7813, 12715, 12724
Zxshell -- 32180, 32181

[1] http://blogs.technet.com/b/mmpc/archive/2014/10/14/msrt-october-2014-hikiti.aspx
[2] http://www.microsoft.com/security/pc-security/malware-removal.aspx
[3] http://novetta.com/commercial/news/resources/
[4] https://www.snort.org/downloads/#rule-downloads

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Teaching SEC 503 end of October in Ottawa

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple Updates (not just Yosemite), (Fri, Oct 17th)

Fri, 10/17/2014 - 04:42

Apple yesterday released the latest version of its operating system, OS X 10.10 Yosemite. As usual, the new version of the operating system does include a number of security related bug fixes, and Apple released these fixes for older versions of OS X today.

This update, Security Update 2014-005 is available for versions of OS X back to 10.8.5 (Mountain Lion).

Among the long list of fixes, here a couple of highlights:

Apple doesnt turn off SSLv3 in this release, but restricts it to non-CBC ciphers, limiting its exposure to attacks like POODLE and BEAST. The list of trusted certificate authorities has also been updates [2]

802.1x no longer supports LEAP by default due to weaknesses in this authentication method.

The bash fix, that was released as a standalone fix earlier to counter Shellshock, is included in this update.

An arbitrary code execution vulnerability in CUPS was fixed. (CVE-2014-3537)

And a quick note about OS 10.10 Yosemite:

After installing it, all security relevant settings Ichecked where untouched (good!). Among security relevant software, GPGMailwill not work with Yosemite yet, but according to the developers, a fix is in the work and may be release in a few weeks, but GPGMail may no longer be free. If you rely on software that you compiled with MacPorts: Wait for the release of XCode 6.1, as it is required to recompile the software for OS X 10.10. In general, it is adviced that you FIRST update all your software and then upgrade to Yosemite. Little Snitch, another popular piece of security software for OS X, works well with Yosemite, but I recommend you turn off the network filter during the upgrade (it works with it enabled, but you need to approve a lot of new connections from new software).

[1]http://support.apple.com/kb/HT1222
[2]http://support.apple.com/kb/HT6005

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, October 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4197, (Thu, Oct 16th)

Thu, 10/16/2014 - 15:59
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Logging SSL, (Thu, Oct 16th)

Thu, 10/16/2014 - 08:37

With POODLE behind us, it is time to get ready for the next SSL firedrill. One of the questions that keeps coming up is which ciphers and SSL/TLS versions are actually in use. If you decide to turn off SSLv3 or not depends a lot on who needs it, and it is an important answer to have ready should tomorrow some other cipher turn out to be too weak.

But keep in mind that it is not just numbers that matter. You also need to figure out who the outliers are and how important (or dangerous?) they are. So as a good start, try to figure out how to log SSL/TLS versions and ciphers. There are a couple of options to do this:

In Apache, you can log the protocol version and cipher easily by logging the respective environment variable [1] . For example:
CustomLog logs/ssl_request_log %t %h \{User-agent}i\%{SSL_PROTOCOL}x %{SSL_CIPHER}x

Logs SSL protocol and cipher. You can add this to an existing access log, or create a new log. If you decide to log this in its own log, I suggest you add User-Agent and IP Address (as well as time stamp).

In nginx, you can do the same by adding$ssl_cipher $ssl_protocolto the log_format directive in your nginx configuration. For example:

log_format ssl $remote_addr $http_user_agent $ssl_cipher $ssl_protocol

Should give you a similar result as for apache above.

If you have a packet sniffer in place, you can also use tshark to extract the data. With t-shark, you can actually get a bit further. You can log the client hello with whatever ciphers the client proposed, and the server hello which will indicate what cipher the server picked.

tshark -r ssl -2R ssl.handshake.type==2 or ssl.handshake.type==1 -T fields -e ssl.handshake.type -e ssl.record.version -e ssl.handshake.version -e ssl.handshake.ciphersuite

For extra credit log the host name requested in the client hello via SNI and compare it to the actual host name the client connects to.

Now you can not only collect Real Data as to what ciphers are needed, but you can also look for anomalies. For example, user agents that request very different ciphers then other connections that claim to originate from the same user agent. Or who is asking for weak ciphers? Maybe a sign for an SSL downgrade attack? Or an attack tool using and older SSL library...

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#logformats[2]

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Cisco Security Advisory: SSL Padding Oracle On Downgraded Legacy Encryption (POODLE) Vulnerability, (Thu, Oct 16th)

Thu, 10/16/2014 - 00:12



Advisory ID: cisco-sa-20141015-poodle

Revision 1.0

For Public Release 2014 October 15 17:30 UTC (GMT)

+---------------------------------------------------------------------

Summary
+======

On October 14, 2014, a vulnerability was publicly announced in the Secure Sockets Layer version 3 (SSLv3) protocol when using a block cipher in Cipher Block Chaining (CBC) mode. SSLv3 is a cryptographic protocol designed to provide communication security, which has been superseded by Transport Layer Security (TLS) protocols. By exploiting this vulnerability, an attacker could decrypt a subset of the encrypted communication.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-poodle


(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, October 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4195, (Thu, Oct 16th)

Wed, 10/15/2014 - 17:37
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Multiple Vulnerabilities in Cisco TelePresence Video Communication Server and Cisco Expressway Software, (Wed, Oct 15th)

Wed, 10/15/2014 - 11:10

Multiple Vulnerabilities in Cisco TelePresence Video Communication Server and Cisco Expressway Software
Advisory ID: cisco-sa-20141015-vcs

Cisco TelePresence Video Communication Server (VCS) and Cisco Expressway Software includes the following vulnerabilities:
Cisco TelePresence VCS and Cisco Expressway Crafted Packets Denial of Service Vulnerability
Cisco TelePresence VCS and Cisco Expressway SIP IX Filter Denial of Service Vulnerability
Cisco TelePresence VCS and Cisco Expressway SIP Denial of Service Vulnerability
Succesfull exploitation of any of these vulnerabilities could allow an unauthenticated, remote attacker to cause a reload of the affected system, which may result in a Denial of Service (DoS) condition.

Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-vcs

Note: This security advisory does not provide information about the GNU Bash Environment Variable Command Injection Vulnerability (also known as Shellshock). For additional information regarding Cisco products affected by this vulnerability, refer to the Cisco Security Advisory at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash



(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts