Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 52 min 43 sec ago

Hacking with the Oldies!, (Thu, Oct 30th)

13 hours 14 min ago

Recently we seem to have a theme of new bugs in old code - first (and very publically) openssl and bash. This past week weve had a bunch more, less public but still neat bugs.

First, a nifty bug in strings - CVE-2014-8485, with more details here http://lcamtuf.blogspot.ca/2014/10/psa-dont-run-strings-on-untrusted-files.html
a problem in wget with ftp: https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-wget-ftp-symlink-arbitrary-filesystem-access
and now the ftp client (found first in BSD) - http://cxsecurity.com/issue/WLB-2014100174

These all share some common ground, where data that the code legitimately should be processing can be crafted to execute an arbitrary command on the target system. The other common thing across these as that these utilities are part of our standard, trusted toolkit - we all use these every day.

Who knew? Coders who wrote stuff in C back in the day didnt always write code that knew how much was too much of a good thing. Now that were all looking at problems with bounds checking on input data, expect to see at least a couple more of these!

===============
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 Thursday, October 30th 2014 http://isc.sans.edu/podcastdetail.html?id=4215, (Thu, Oct 30th)

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

The Wonderful World of CMS strikes again, (Wed, Oct 29th)

Wed, 10/29/2014 - 12:34

I think that I will start this Diary with the following statement:

If you use an open source CMS, and you do not update it frequently, there is a very high chance that your website if not only compromised but also part of a botnet.

You probably already saw several of our diaries mentioning vulnerabilities in very well-known CMS systems like WordPress and Joomla, which are quite powerful and easy to use/install, and also full of vulnerabilities and requires frequent updates.

The third one in this list is Drupal. We mentioned last week, on our podcast about a criticalvulnerability fixed by the developers, and today they released a Public Announcement in regards to that vulnerability. And it is scary (yes, Halloween pun intended...).

The PSAmentions that within hours of the Patch announcement, there were already several automated attacks looking for the SQL injection vulnerability in the Drupal implementations.

As our reader Gebhard noted, there is a very interesting quote in the PSA:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement

This means, that by now, evenif you updated your server, there is very high chance that your server is now part of a botnet...so, if you have a website with Drupal, I would highly recommendthe Recovery section of the PSA document.

---

Pedro Bueno (pbueno /%%/ isc. sans. org)

Twitter: http://twitter.com/besecure

(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 29th 2014 http://isc.sans.edu/podcastdetail.html?id=4213, (Wed, Oct 29th)

Tue, 10/28/2014 - 16:32
(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 28th 2014 http://isc.sans.edu/podcastdetail.html?id=4211, (Tue, Oct 28th)

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

Do you remember your "first love"?, (Tue, Oct 28th)

Mon, 10/27/2014 - 19:05

I will never forget the name of my first server - Rachel. I was very proud to be the person whose job it was to defend Rachel from all types of disruption. To this day I still remember each IP address, user account, service account and application. When patches were installed, I manually verified they had been applied successfully. I diligently reviewed the logs and configured full auditing to let me know the success and failure of just about everything.">I have administered many servers since Rachel, but do not remember as much about them as I do about my first love. Consider this an invitation to fall back in love withyour">How can you do this? The act of actively measuring how well you manage, secure and maintain your severs can very well be the catalyst you need to return back toyourfirst love. Consider creating and sending yourself a daily report that clearly shows its current security posture. What are good candidates for this report? I am glad you asked, Some of my favorites include the following.">Mean time to identify a new service running (or not running anymore)
">There are certainly many metrics you could track. Pick a few and diligently check themevery day for the next month. Youll be glad you did!">Feel free to use our comment page to let us know what you are doing to remember your first love.

">@russelleubanks

(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 27th 2014 http://isc.sans.edu/podcastdetail.html?id=4209, (Mon, Oct 27th)

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

CSAM: False Positives, and Managing the Devils, (Mon, Oct 27th)

Sun, 10/26/2014 - 16:19

Continuing our theme of False Positives this month, Id like to talk about the process of managing false positives we encounter in the course of analysis. False positives will almost always show at some point during a security analysis, which leads to unwanted additional work on the part of either the sysadmins, security teams, or both. Even worse, continued false positives can lead to complacency during analysis, where things are assumed">">Managing false positives in our testing and analysis is part of the overall security process, which can be used to identify and eliminate false positives. ">-Ports, Protocols, and Services baseline (need to know what we have on the wire, and where it">">An ideal scenario in an operating environment may run something like this: A Continuous Monitoring program alerts that a vulnerability exists on a host. A review of the configuration of the host shows that the vulnerability does not exist, and a verification can be made from the traffic logs which reveal that no traffic associated with the vulnerability has transited the wire. The Continuous Monitoring application should be updated to reflect that the specific vulnerability reported on that specific host is a false positive, and should be flagged accordingly in future monitoring. The network monitoring would *not* be updated, because it did not flag a false positive, leaving the defense-in-depth approach in tact.">">Now, this is *ideal*, and a very high level, but it hopefully gives some ideas on how false positives could be managed within the enterprise, and the processes that contribute. We would really like to hear how false positives are managed in other enterprise environments, so let us know. :)

tony d0t carothers --gmail

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

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