Last Updated: 2013-01-11 13:36:49 UTC
by Adam Swanger (Version: 1)
This month starts a new format for the ISC Monthly Threat Update!
You can find the most recent podcasts including the daily StormCast at https://isc.sans.edu/podcast.html.
The monthly podcast is now split into two parts. We are releasing the Microsoft Patch Tuesday overview as Part1 and each month's feature as Part2. There will be part1/2 screencasts posted to youtube.com and audio links available in mp3 and ogg for each part. The youtube.com, audio and PDF slides are linked in the podcast show notes. There is also single audio file of both parts in mp3 and ogg formats like usual.
Please visit the newest ISC Threat Update details page at https://isc.sans.edu/podcastdetail.html?id=3043 and let us know what you think in the comments on the podcast page or below!
Don't forget to give your feedback on our Daily StormCast at http://www.surveymonkey.com/s/stormcast
Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu
Last Updated: 2013-01-10 23:26:55 UTC
by Rob VandenBrink (Version: 1)
As a side note to today’s iSeries / Mainframe story, and a follow-up to one I wrote last year (https://isc.sans.edu/diary/12103), another thing I’m seeing is more and more on telnets (tcp port 992 - https://isc.sans.edu/port.html?port=992) is voice gateway and videoconferencing unit problems.
Specifically, when scanning for port tcp/992, you will likely run across more videoconferencing systems than mainframes. They’ll often show up with less fingerprinting than the SNA platforms we discussed, for instance a videoconferencing unit (the host information in this story is from a recent penetration test, and is released with permission) might look like:
PORT STATE SERVICE VERSION
992/tcp open telnets?
For the videoconferencing unit in my client’s test scope, the telnets session was unprotected by anything as crass as a a userid and a password – if you open up a tn3270 (telnet over ssl) session, you’ll get something like this:
Funny, no credentials were needed to get to this screen. Not knowing exactly what we're on yet, let's type “help”, maybe we'll find that this box is "helpful":
Helpful indeed, looks like we've got full admin access, with no credentials! But from that first terminal screenshot, we see that an HTTP website is enabled, maybe things will be easier if we try that? From the screenshot below, we see this host gives you all the same admin information and rights as we had on the terminal session, also without a password!
What leaps out at me from this screenshot (aside from the vendor and model number ,greyed out in these examples) is the firmware date (2006), and the “remote control” selection, which does exactly what it sounds like!
The “Admin Settings” page gives you all the most common items you’ll need to change if you were actually going to attack this host (remember, I’m still on that session from the internet, with no authentication):
And yes, you did see “Place a Call” in that last screenshot! This particular option can add up to real dollars very quickly - there's an active community of folks stealing and reselling long distance service from units like this!
Note also, the install date and firmware date are the same (2006). This is one *vintage* videoconferencing unit. For some reason, people seem to think that maintenance of IP voice gear involves cleaning products rather than firmware updates! As long as the unit is shiny, it must be fine!
We also found SNMP open, with the default community strings (public and private). From this we found that this host was internet connected, then connected to the customers PBX (by listing the interfaces). I'll spare you those screenshots, you'll find similar in the story we ran on Voice Gateways last year ( https://isc.sans.edu/diary/12103 )
So, the main lessons here are:
Never trust the vendor to correctly install anything. This particular unit was installed as part of an RFP'd project by a VOIP vendor, who didn't see any issue with putting this on the internet. It’s just too common to see things configured to a minimum standard, with no regard for security. This is not specific to voice or video gear, though we see this a lot in VOIP projects
Scan your own perimeter. In fact, scan your own internal network also. There was no reason for you to wait for a paid security assessment to find the easy stuff like telnet interfaces open, admin interfaces with no credentials or default credentials, or SNMP open with default community strings. We’d much rather find the fun stuff (problems in websites for instance) than easy stuff like this.
Never trust documentation when the vendor docs tell you what ports need to be open to a host. I can't tell you how often I see vendors insist that they need inbound port 25 to *send* email, or inbound 53 to make DNS requests (both are incorrect of course).
Never put stuff outside your firewall unless you know exactly why it should be there. The gateway we found in this story was indeed outside the firewall, the documentation for the unit actually states that there is a firewall onboard (there is no such thing)
Patch. Your VOIP gear - the PBX, the phones, gateways, all of it, are really just a collection of computers. If you don't patch them, they will be exploited - VOIP gear is a real target these days! The difference between exploits in your computer network and voice network is that when your VOIP gear is exploited, it will show up as a large long distance bill at the end of the month. Hopefully your accounting group will see this as a problem, rather than just paying the invoice when this happens!
Last Updated: 2013-01-10 15:40:42 UTC
by Johannes Ullrich (Version: 1)
We haven't had an unpatched Java vulnerability in a while (a month?). To make up for this lack of Java exploitability, the creators of the Blackhole and Nuclear exploit pack included an exploit for a new, unpatched, Java vulnerability in their latest release . The exploit has been seen on various compromissed sites serving up the exploit kit. The latest version of Java 7 is vulnerable .
Leave Java disabled (I am not going to recommend to disable it. If you still have it enabled, you probably have an urgent business need for it and can't disable it)
If you have any business critical applications that require Java: try to find a replacement. I don't think this will be the last flaw, and the focus on Java from people behind exploit kits like blackhole is likely going to lead to additional exploits down the road.