Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Security Update - Cisco 7900 Phones - cisco-sa-20130109-uipphone privilege escallation issue - advisory at:
Security Update - Cisco Prime LMS (cisco-sa-20130109-lms - remote execution as root vulnerability) - advisory at:

Hotmail seeing some temporary access issues

Published: 2013-01-09
Last Updated: 2013-01-09 20:45:23 UTC
by Rob VandenBrink (Version: 2)
0 comment(s)

Thanks to our reader James for letting us know about some current (but temporary) system issues at Hotmail - details at


As of now (10:30 on Jan 9), Hotmail is still having issues.  Problems seem to be isolated to mobile clients using Activesync.


MS is now comitting to an update by 11:20PM (not sure which timezone that's in). 

Cloud services are great, except when they're not!

0 comment(s)

SQL Injection Flaw in Ruby on Rails

Published: 2013-01-09
Last Updated: 2013-01-09 15:37:46 UTC
by Rob VandenBrink (Version: 2)
3 comment(s)

A SQL Injection Flaw (CVE-2012-5664) was announced last week (Jan 2) in Ruby on Rails, but I think we missed reporting on it (thanks to one of our readers for pointing this out).  Updates that resolve this are: 3.2.10, 3.1.9, and 3.0.18

Because of the security profile of Ruby on Rails (the largest Ruby project around is one you should be familiar with - Metasploit), any security issues should be taken seriously.  However, the hype and hoopla that any site with RoR code on it is vulnerable is just that - the vulnerability being discussed is very specific in nature, but folks hear "sql injection" and (mistakenly as far as I can see) send it to the headline page.

A very complete explanation of the scenarios that are at issue are outlined in this here:!topic/rubyonrails-security/DCNTNp_qjFM
and here:

Additional issues (CVE-2013-0155 and CVE-2013-0156) are resolved in these new releases also.


Thanks Ariel for pointing out that they've updated the original patch (just yesterday) with new RoR versions 3.2.11, 3.1.10, 3.0.19, and 2.3.15.  All previous versions should be considered vulnerable.  They're also ratcheting up the urgency in the language around this issue - perhaps there's a bit more of a problem here than originally thought?

You can follow the official revision history at:

Rob VandenBrink


3 comment(s)

New Format for Monthly Threat Update

Published: 2013-01-09
Last Updated: 2013-01-09 15:05:28 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Due to a scheduling conflict with another webcast, we had to cancle today's monthly threat update. However, we will use this opportunity to try something new. We had some complaints in the past with users having problems with our java based webcast platform. Already, we are seeing a lot more users downloading the audio only "podcast version" of the webcast compared to users actually participating in the live version.

This month, we will try a recorded screencast format, and publish the "webcast" in segments for you to pick and choose. Still working out the details, but the content should be live late today or tomorrow. As usual, we will cover the Microsoft patches and at least one additional topic (right now, it looks like a quick introduction into hardening OS 10.8 Mountain Lion). The new format should enable me to do more demos and less rely on slides. Best part: you wont have to accept the java applet with an expired signature, and I can tell you how to disable java with a straight face ;-)

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

0 comment(s)

The 80's called - They Want Their Mainframe Back!

Published: 2013-01-09
Last Updated: 2013-01-09 14:51:50 UTC
by Richard Porter (Version: 1)
5 comment(s)

When I see TCP Port 992 open, I always get a warm feeling – I’m taken back to my first IT job, as a night operator on MVS and VM systems at IBM in the early ‘80’s.  And yes, we had Virtual Machines (that’s what the “V” stands for) back in in 1980’s, just on much bigger hardware!  
When I see port 992 these days, that typically indicates the telnets service (telnet over SSL), which often means it’s an iSeries (previously AS/400), or a mainframe system (OS/390 or z/OS).  Oddly enough, after 30-plus years today's z/OS mainframe class machines still have current versions of z/VM and MVS.  As with most common ports, traffic statistics for port 992 can be found in our database, at

This all seems like kind of a “back in the day” thing, you might think.  Didn’t we migrate all the mainframes and AS/400’s over to Windows and *nix back in the late ‘90s?  Only old coots like – um – me should care about that stuff, right?  Think again – migrating mainframe apps written in COBOL and the like, written in the 70’s, 80’s and even 90’s is a bear of a task – it costs big money and carries a ton of risk, and LOTS of companies have just let those sleeping dogs lie (aside from patching and upgrading that is).  And the iSeries platform just never went away – if you drive past a factory or a big-box hardware or department store, chances are pretty good there’s an iSeries datacenter running the show.

So just how common are these platforms on the internet?  In a simple scan of 2 class B’s I picked at random (Ok, I knew that they were both at colo’s), I found 2 iSeries hosts and 1 z/OS  telnets host.   If you’re using nmap, be sure to use –sV to get a better handle on the host offering up the service:

Nmap –p 23,992,1023,2323 –sV –open x.x.x.x

iSeries hosts almost always are well identified by NMAP  (even  a –version-intensity=1 will find them):

23/tcp  open  telnet     IBM OS/400 telnetd
992/tcp open  ssl/telnet IBM OS/400 telnetd
Service Info: OS: OS/400

Mainframes (z/OS) hosts are also well fingerprinted by NMAP (though OS/390 is long gone, it should be labeled as z/OS):

23/tcp   open  telnet  IBM OS/390 or SNA telnetd
992/tcp open  ssl/telnet IBM OS/390 or SNA telnetd
1023/tcp open  telnet  BSD-derived telnetd

We’ve mentioned a few common ports - besides port 992, what other ports might you typically see open on an iSeries host?

Service Name Port (Plaintext) Port (SSL)
Telnet (PC5250 Emulation) telnet 23 992
NetServer netbios  (yes, really!) 137 ---
NetServer netbios 139 ---
NetServer CIFS 445 ---
DRDA DRDA 446 ---
DDM DDM 447 448
Server Mapper as-svrmap 449 ---
RUNRMTCMD REXEC (just as good as netbios most days!) 512 ---
HTTP Administration as-admin 2001 2010
Service Tools Server as-sts 3000 ---
POP3 (MAPI) pop3 5010 ---
License Management as-central 8470 9470
Database Access as-database 8471 9471
Data Queues as-dtaq 8472 9472
Network Drives as-file 8473 9473
Network Printers as-netprt 8474 9474
Remote Command as-rmtcmd 8475 9475
Signon Verification as-signon 8476 9476
Ultimedia Services as-usf 8480 9480
IBM AnyNet APPC over TCPIP 397 (TCP and UDP) ---
Management Central as-mgtc  5555 and 5544 5566

Note that ports 23 and  992 on these platforms generally serve up TN5250 (iSeries) or TN3270 (z/OS) terminal servers over telnet or telnets.  You’ll also find (thanks to suggestions in IBM’s Redbook Series of books) that it’s common to see the unencrypted telnet running on ports 1023 or 2323 as an added security measure.  We can have a whole 'nother debate about how effective that is, especially if it’s in the vendor documentation.

OK – so now that we’ve found a target host, what might we look for if you are in a pentest or a security assessment engagement?  The same thing as you’d look for in any *nix SSH or telnet server  – problems with encryption (and the phishing opportunity that comes with it), mismanaged ssl keys (isc story ) and well known accounts with easily guessable passwords are all good places to start.  If the easy stuff works (every time for me so far), there’s no reason to try complicated attacks right?

For starters, let’s take a look at a typical certificate hosted on an iSeries host (organization specifics are elided):

C:>openssl s_client -connect x.x.x.x:992 2>&1
Loading 'screen' into random state - done
depth=1 /C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate chain
 0 s:/C=Ca/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ISERIES.ORGNAME.COM
   i:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
 1 s:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
   i:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
Server certificate

Raw certificate material removed

subject=/C=Ca/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ISERIES.ORGNAME.COM
issuer=/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
No client certificate CA names sent
SSL handshake has read 1401 bytes and written 322 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 975A05E1077C10000000000000000178
    Master-Key: CB948E0C6F005C654B2208ECAD1DFD1E5CC692256BE8615C74F403ABB22B2B8A97910A305EB4D4B2C4209C55C1146D9F
    Key-Arg   : None
    Start Time: 1357423010
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

At this point, you might be asking “Wait, did I see that right?”   And I’d reply – “Yes, you did!” – while most TN5250 and TN3270 terminal emulation programs support SSL (on port 992), many do NOT ACTUALLY CHECK the host certificate for validity!  If the terminal application is capable of checking, normally that check is OFF by default.  This means that if you are assessing larger hosts like this, you’re very likely to run into self-signed certificates.

How might you take advantage of this?  Attack the weakest link – the users of the target host, with their “first initial last name” userid and 8 digit RACF (or OS/400 in this case) password.  For  a target host “”, go register a similar domain and a host name, say “”, then  mount a phishing run.  Send emails to internal users at from the fake domain, asking them to login to the host “” to reset their password, check a critical report status or whatever.  As they say, it only takes one person to fall for it, and you’ll have an interactive login account!  If your client asks you to narrow the attack, target the most senior people in the organization that you are permitted to.  Or target their helpdesk or operator staff.  Sadly, the helpdesk and senior execs - the two groups you never want to get phished in - almost always fall for the phish.

Note that the TN5250/TN3270 uses EBCDIC, so while you can use Ettercap for the MITM attack, you’ll need to decode back to ASCII when you read the final captured file in Wireshark. Or in a pinch you can use dd to move back and forth between ASCII and EBCDIC, though Wireshark does a *fine* job!

What else might you try?  How about let’s do something with the (well documented) list of default userids on the iSeries:


I’ve had some good luck in engagements involving iSeries hosts, taking advantage of  QSECOFR (the Security Officer) or QSYSOPR (the System Operator), both of which have elevated privileges on the system.  Try these with either QSYSOPR/QSECOFR as the password, or the company name, or sometimes a word scraped off the company website.  Or, if you phish was successful, you’ve already won.

Soldier of Fortran describes TSOBRUTE ( ), which you can use to brute force TN3270 passwords, with a list of known accounts plus the ones you can glean with a domain name and a bit of google-fu, it works like a charm!  He’s also written a password sniffer - MFSniffer, which you can find at  I still use ettercap and wireshark for my MITM setups, but a password snarfer like this can make things much simpler, if all you are looking for is credentials.

Is there an easy fix for these two simple issues?  Well, yes – sort of.  And no – not really.

Protecting an internet host with a packet filter firewall, SSL with a self signed certificate, SSL clients that don’t check the cert, plus a user-selected password is not much protection at all.  It’s not materially different than using straight-up telnet.  When I see a direct login to a target host of any kind that is not  as hardened (or as able to be hardened) as you might like, I’d normally suggest putting it behind a VPN gateway, or possibly behind an https gateway. 

There are a ton of HTTPS gateway products that will sit in front of an SNA host, either commercial or open-source (though mostly you’ll see commercial products in this space).  In many cases they’ll even web-ify an application by screen scraping and presenting the app in a gui.  SNA Gateways are a mature technology, in common use since the late ‘80’s (though back then we were front-ending native QLLC/SNA with TCP).  Using an HTTPS front-end can allow you to filter out the use of sensitive accounts, and also makes enforcing the use of trusted certificates much easier.  Also, it means that your end-users don’t need to install a terminal client. 

Using a VPN solution hides the host completely, but isn’t as useful if you expect customers or partners to use the system – forcing multiple logins on end users never won System Admins any friends.  

Neither of these approaches is a silver bullet – protecting anything with a simple password these days is less than stellar idea.   At the end of the day, the host being discussed has likely been internet connected for 10-15 years, so making any changes, especially changes that make life more difficult for end users, is going to be met with a lot of resistance.  You’ll likely get more traction on an HTTPS front end, mostly because it’ll make the green-screen application prettier and mouse-friendly.  But you’ll be replacing a userid and a password with, well, a userid and a password, just with better encryption.

Where can I go next for more information?
Well, for starters, IBM has a Security Reference Document for the iSeries, located at:

The folks at Tenable have conveniently integrated the contents of this doc into Nessus:

Soldier of Fortran has a site dedicated to mainframe security issues:, his tool repository is on github: .  A great site if you’re trying to keep up with the attack side of things (since vendor docs and audit resources will generally be about defense).

A couple of other useful IBM documents:

A couple of GIAC papers on AS/400 Auditing (both are a bit dated, but are mostly directly applicable to the newer iSeries platforms):

ISACA also has a decent document on auditing  OS/400:

If you’ve got suggestions, stories on internet-attached mainframe or iSeries hosts (good or bad), or comments, please post to our comment form!

Rob VandenBrink

5 comment(s)
Security Updates for Adobe Reader / Acrobat -

Firefox and Thunderbird Updates

Published: 2013-01-09
Last Updated: 2013-01-09 05:46:39 UTC
by Rob VandenBrink (Version: 1)
3 comment(s)

Firefox 18.0 and Thunderbird 17.0.2 are just released - the version numbers change so quickly on these now I can't keep track anymore!

Details at:

Rob VandenBrink

3 comment(s)
ISC StormCast for Wednesday, January 9th 2013
Diary Archives