ISC Monthly Threat Update New Format

Published: 2013-01-10
Last Updated: 2013-01-11 13:36:49 UTC
by Adam Swanger (Version: 1)
0 comment(s)

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

0 comment(s)

What Else runs Telnets? Or, Pentesters Love Video Conferencing Units Too!

Published: 2013-01-10
Last Updated: 2013-01-10 23:26:55 UTC
by Rob VandenBrink (Version: 1)
4 comment(s)

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!

 

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

4 comment(s)

Java is still exploitable and is likely going to remain so.

Published: 2013-01-10
Last Updated: 2013-01-10 15:40:42 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

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 [1]. The exploit has been seen on various compromissed sites serving up the exploit kit. The latest version of Java 7 is vulnerable [2].

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.

[1] https://krebsonsecurity.com/2013/01/zero-day-java-exploit-debuts-in-crimeware/
[2] http://malware.dontneedcoffee.com

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: java
4 comment(s)
ISC StormCast for Thursday, January 10th 2013 http://isc.sans.edu/podcastdetail.html?id=3040

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives