Blood, Sweat, and Information Security

Another SSL cert atrocity!

2010-10-24T18:47:00.001-07:00

My Website hosted by "The Planet" has an https control panel with a self-signed cert. Self-signed certs are very very bad. A web site hosting company should know better

OWASP AppSec at U.C. Irvine a success!

2010-10-10T20:16:00.000-07:00

I worked as a volunteer at the OWASP AppSec conference at the University of California at Irvine, held Sept 7 through the 10th.

Unfortunately I did not get to sit in on any of the training sessions - they all looked first rate. I *was* invited to the VIP reception. It had a nice selection of appetizers and good drinks from the bar, with opportunities to chat with other conference volunteers, organizers and speakers.

The sessions I was able to attend were all very good, some excellent. My best take-away from the CxO panel was that "buy a tool" inevitably fails as an approach. I already knew this, but it is refreshing to hear this truism so bluntly stated.

The session on Threat Modeling covered the Microsoft-supported STRIDE/DREAD model for assessing application security. I've used this tool before so it was interesting to hear the speaker's perspective. Threat modeling belongs as part of the application's architecture review, and should be embedded in the development life cycle. The threat model should be maintained and updated for as long as the application is in use.

Bill Cheswick gave the end-all of password security talks. I've seen his video online, and this was similar. He gave a lot of very useful ideas about password vulnerabilities, user psychology, and how to realistically manage passwords better given human and technical limitation.

Other sessions I attended included ones on secure coding practices, OWASP projects, "Reducing Web application Vulnerabilities: Moving from a Test-Dependent to Design-Driven development", and HD Moore's talk.

HD's talk was given in a rapid-fire style that took some careful listening to follow and dwelt exclusively with the Metasploit product and plans to incorporate more Web application testing in future versions. And a Linux Meterpreter module may be out by version 3.5

RISSC's 3 year grant is ending

2010-09-06T16:04:00.000-07:00

Got an email about a reception for the RISSC industry advisory board (including me). Their NSF RISSC Grant is winding to a close and they'd like to thank those of us in industry who have helped them over the last 3 years. I won't be able to make it - I will be attending SANS Las Vegas that week. I will be facilitating the Wireless Ethical Hacking, Penetration Testing, and Defenses course taught by Josh Wright.

Speaking of volunteering - I just got the assignment sheet for the OWASP AppSec Conference in Irvine. I will be working as a volunteer on Thursday.

Defcon 18 quickly summarized

2010-08-29T15:43:00.000-07:00

I skipped Defcon last year, so I made a point to be there all 3 days. I strongly recommend arriving Thursday evening. Registration is no hassle, you get the official badge, and you get to check out the facility at your leisure. Even though Defcon has been at the Riviera for years, I still need a walk-through to remember how to get around. Maybe casinos hope that lost hotel guests will gamble more.

Defcon is generally well organized and with few exceptions the talks are first rate. My main complaint is the long line to get into just about every talk. I suspect they have greatly oversold admission. I wanted to attend the SCADA track on Saturday, so I showed up almost an hour early for the first session, and remained in my seat for as many sessions as biological needs would permit.

The best session was given by Fyodor on scripting nmap. He gave a very useful and clear explanation of how to customize nmap using the Lua programming language. Fyodor is also a very engaging speaker. I was very fond of his dry wit.

Dan Kaminsky and Paul Vixie gave a double-shot of DNS on Friday. Vixie discussed the use of passive DNS to gain information useful in tracking malware and criminal activity by flagging malicious use of DNS. Kaminsky gave a talk similar to Toorcon 2009, on the use of DNSSEC to provide a true, usable public key infrastructure. Using signed DNS records can authenticate destination sites. DNS authority can also be delegated more elegantly (and more usefully) than X.509.

The SCADA track was interesting, with the talks varying between those concerned with general risk discussions, technical information systems, and general discussions of plan operations. If you've ever wondered how a small water district works, this was your chance.

"Wardriving the Smart Grid" gave an overview of the technology used for wireless monitoring and control of electrical utilities. Exploitation of field tech boxes would provide privileged access to these networks. The speaker suggested that it is only a matter of time until software for these boxes is available on bit-torrent.

"SCADA and ICS for Security Experts" gave a definition of SCADA and discussed what systems can be called SCADA and which ones aren't really SCADA. SCADA involves interconnected sensors and controls under central management. Not all industrial control systems (ICS) are SCADA. Electrical "Smart Meters" are really a billing system, not a remote control system, for example. The hard part of attacking SCADA and ICS isn't getting into the network - it is understanding the physical impact of various logical controls.

Speaking of Smart Meters, "The Night the Lights Went Out in Vegas" covered some of the details of Smart Meter networks. Radio communications involves either 900 mHz licensed spectrum and GRPS, with a small number of other methods like powerline RF.

"Cyberterrorism and the National Drinking Infrastructure" gave an overview of operations at a small public water district. There are a lot of fail safe mechanisms that make it difficult to effectively attack a drinking water system. Water districts themselves are highly fragmented, meaning an attack would likely be local in scope, confined to a single municipality.

Aside from SCADA other notable topics included cyber-warfare and hardware hacking. "How to Build a Cyber Army" discussed a possible budget for a hypothetical cyber-army (North Korea was the example). Having agents embedded in the target nation's critical infrastructure is essential - remote attacks would not have their full impact without this. The final budget came out to something short of $50 million (I'm relying on memory here).

Hardware hacking included hacking WiMAx customer boxes, basics of the Arduino ("Hardware Hacking for Software Guys"), and building electronic weapons (a variant of the old Defcon "Build your own HERF gun" talk).

It wouldn't be Defcon without some controversy. Here's a short rundown:

A talk on Chinese cyberattacks was canceled due to objections of the Taiwanese government, ever desirous of not offending the mainline Chinese. The key speaker was a Taiwan national, so his government's request carried the day.
A talk on evading censorship by using TOR had one of the key speakers, affiliated with Wikileaks, detained by US authorities upon entering the country from the Netherlands. His electronics (computer, cell phone, etc.) were seized.
A talk on jackpotting ATMs went on as scheduled. It was pulled last year due to pressure from the presenter's employer (Juniper). He now works fo IOActive, who had no objection.
GSM-based cell phone communication was intercepted using a mock base-station built using $1500 of equipment. Lots of notices were prominently posted warning people not to use your cell phone during this time!

Lastly, one of my favorite things was the exhibit of old computer technology. A fully functioning DEC PDP-11 was featured that brought back memories of my first computing experiences.

And while I fully support the EFF, I did *not* get a mohawk, thank you

Another entry in the broken cert hall of shame

2010-08-13T07:37:00.001-07:00

Noted this when trying to log into gmail using my secure POP client. I hope this is just a quirk in Google's cert management

OCEAN AS/400 Conference Notes

2010-08-03T16:02:00.000-07:00

I attended the July 16 OCEAN annual technical conference on the iSeries (which I will always call the AS/400). I've spent a good chunk of my professional career working on this system and while it seems to be slowly fading away, I still like to keep up on it. Who knows when you might run across one? Being one of the last people around familiar with this technology may prove useful.

Some general notes: There was a session on iPhone integration with the iSeries, showing this venerable back end is still being adapted to the latest client gadgets. A whole series of PHP development sessions was provided, including ones on the Zend environment.

My main focus here is the session on security, given by John Earl (who immediately recognized me in the audience after over 10 years). He covered some of the laws governing breach reporting and personal information protection, noting that Massachusetts has the strictest state laws in the US. His main focus was on insider threats, as he believes the iSeries is hard for an outsider to attach without some sort of inside access and knowledge.

John noted that default passwords are still a problem, especially for vendor software. The ANZDFTPWD command will help by checking for many of these. Unencrypted passwords on the wire is another problem, with FTP, telnet and the iSeries Access Servers (formerly Client Access). He noted some common mechanisms for finding user IDs and user profile information that can be exploited even with a limited capability account that supposedly restricts command line access. Read access to a user profile provides the ability to take over the profile - so do not allow *PUBLIC (world in unix-speak) read access. Taking over a profile involves using it in the SBMJOB commands, in a JOBD, or through ADDJOBSCDE (look these up if they don't make sense!). John is a strong believer in relying on object authority rather than exit programs for security.

Having been outside the iSeries world for a while, it was discouraging to hear the same flaws mentioned that I had known about ten and fifteen years ago. The approach to taking over an AS/400 seems similar to that used in Windows systems - get the authentication credentials, execute a command using that credential, use the command to gain command line access. What ADDJOBSCDE does in an iSeries, "schtasks" (or "at") does for Windows.

ISSA LA gets some press

2010-07-19T21:42:00.000-07:00

Our very own Stan Stahl has been quoted in the LA Business Journal:

It seems starting Internet security companies has become something of a gold rush, according to Stan Stahl, chief executive of L.A. cybersecurity firm Citadel Information Group and president of the Information Systems Security Association.
“In the last year, all of a sudden this industry has taken off,” Stahl said. “Legally, anyone can hang up a shingle and say they are a computer security expert.”

This is in an announcement for a new independent information security firm headed by Hemu Nigam called SSP Blue.

A new infosec boutique isn't in itself so newsworthy - but the mention of ISSA along with some positive business prognostications about infosec in general make the article worth a read.

News from 2009 - SSL Cert Atrocities from WAMU/CHASE

2010-07-09T07:00:00.000-07:00

For historical reasons I'd rather not detail, I had an account with WAMU (now Chase). During the middle of the Chase acquisition, I noticed the ssl cert error displayed in this post. This was during the process of setting up an online savings account, which the bank was heavily touting at the time. I wish I had saved a screenshot, but at a slightly later time in the acquisition process, the cert error changed from expired cert to cert not matching URL.

I called customer support at WAMU/Chase and got absolutely nowhere. I went as far as to send a complaint to the OCC. Their response was that they can't do anything, as they do not regulate Internet banking.

Now think about this a bit. This is a bank. You trust them to hold your money - lots of it. This particular bank is heavily pushing their Internet-only services. They then commit the most atrocious ssl cert error possible - a cert that does not match the URL for their heavily-promoted online savings enrollment. This is an error that every modern browser screams loudly about - for good reason. This type of cert error is the one encountered with a man-in-the-middle attack. I've just entered all the information required for major identity theft, and I then have my browser telling me the site I've encountered is likely fake. When the error is reported the response is - crickets chirping. Not just from the bank itself, but from the regulators.

You may accuse me of being a luddite, but I still do a minimal amount of electronic banking. Most of my bills are paid with old fashioned checks sent via the US Postal Service. If banks want to gain the trust of customers like me, they need to start getting the very basics of security right - regardless of whether or not they are undergoing a merger.

Where does Windows 7 hide GnuPG keys?

2010-07-05T17:27:00.000-07:00

Look under C:\Users\yourName\Application Data\gnupg

Secret to getting Kismet to work in Ubuntu 9.04 on a Dell Inspiron 1420

2010-06-01T21:24:00.000-07:00

the secret is:

source=rt8180,wlan0,ALFA

PHP Code Scanners

2007-07-09T08:05:00.000-07:00

PHP code scanners

Investigating source code for possible security flaws is an important part of a security assessment. Common source code flaws can include trusting untrustworthy input, allowing executable strings in data input, buffer overflows, timing flaws

There are code scanners for C, java and other common languages.

The growth in Web-based applications means that the focus of code flaws has shifted to common Web programming languages.

I've found two tools specifically designed for analyzing PHP code:

- PHP security scanner from http://securityscanner.lostfiles.de/

- Pixy from http://pixybox.seclab.tuwien.ac.at/pixy/

These tools can both provide some useful information, unfortunately both lack certain key functionality, and both look like fully-functioning prototypes that are no longer actively maintained.

The PHP Security Scanner tool requires that you install it under your Apache server's document root. It requires pre-existing MySQL service. In addition, two php modules, Smarty and Pear are required. Both should be installed in the same directory as the tool. Ideally, PHP Security Scanner would include these as part of the install process.

The PHP Security Scanner tool will automatically search for php source files, starting at a given document root. I like this feature - it allows reviewing an entire Web site in one execution. It also has the ability to force include or exclude of specific files via a black/white list filter. I did not review this feature (maybe in the future).

Flaws are found via a regex match - no parsing of PHP code is performed. It looks for "dangerous" operations with a variable (any variable) as an operand.

Results from PHP Security Scanner are displayed as a Web page. While very visually attractive, I question the sanity of displaying your Web server's vulnerabilities using that very same server. Advertising your vulnerabilities on a Web page is not very smart.

Some of the messages shown in the results are a bit generic. The regex patterns and the error messages are stored in a MySQL database, and thus are easily editable.

Pixy actually attempts to parse the PHP syntax, to determine the severity of a code flaw based on its role. Pixy attempts to track the flow of "tainted" (untrustworthy) values through the program using data flow analysis. A paper presented at the IEEE Security and Privacy conference describes the approach in more detail.

Pixy is written in Java, and specifically requires JRE 1.5 or more recent from Sun (it will NOT work with the Gnu version of Java). Installing Sun Java on my Ubuntu test system was more of a pain than I first realized.

The output from Pixy is plain text, not as visually stunning as the HTML from PHP Security Scanner. Interpreting the output seems challenging as well. I consider myself fairly well versed in security and had a tough time figuring out what the messages meant.

SANS loses it

2007-06-12T21:43:00.000-07:00

I subscribe to SANS Newsbytes, one of the best mailing lists for security news around. Many of the news articles come with brief commentary by the editors, which usually adds value to the original articles.

I've noticed many recent articles about missing laptops (of course). This is a major security issue that requires a combination of technical and administrative countermeasures.

One measure I've seen SANS advocates indicates they have lost all sense of proportion, and any consideration of the secondary consequences of excessively severe policies. Yes, they are advocating that companies "make automatic termination the consequence of losing the laptop" (comment by Kreitner in May 8 2007 Newsbytes).

Knowing most organizations, I'm sure that terminating an otherwise diligent productive employee for a missing laptop will not faze them in the least. Losing a laptop is a likely consequence of carrying one. Given the nature of business travel, the difficulty of keeping a laptop in your possession at all times, and the determination of thieves, it is inevitable that the most diligent employee will find their laptop missing. Too bad - you lose your job. I assume termination would result that if the laptop were stolen from your vehicle or home as well.

Let's also look at the unintended consequences of such a policy. If my company had a policy of automatic termination for a missing laptop, I would keep my company laptop in a safe at home (after all, theft from autos is common) and use my personal laptop for my day-to-day work. The company asset would be protected, I would not be at risk from termination, and I could get my work done. If the laptop is stolen or lost, I pay the cost. The end consequence is that sensitive information is even less protected than before, because I no longer use a controlled company asset for my work. Other less severe work-arounds include employees using their personal PDAs for work, or just doing without a computer on some business travel. If you need to access email, well you can do that from a kiosk, right? And we all know how secure Webmail from a public kiosk can be.

The sad part about this poor advice from SANS is that many organizations will end up adopting this policy, based on SANS' reputation. They will find their overall security degraded as employees come up with creative ways to keep their laptops theft-free at the expense of greater information security goals.

There is a general point here as well. Severe, draconian punishments may discourage the santcioned behavior, but usually encourage other sorts of mis-behavior that are far worse.

NSA IAM/IEM

2007-04-29T19:53:00.000-07:00

I'm moving along with the lecture notes for my class. I've got some more detail on the NIST FISMA criteria. It looks like a perfectly decent security standard on the surface. You start by categorizing your information systems, determine the security controls, document these controls, assess the effectiveness of the controls, lather, rinse and repeat. FISMA gets a lot of criticism, expecially on the SANS mailing list for being an ineffective paperwork drill. This may well be true, but if an agency has absolutely nothing in place, I imagine FISMA would at least provide a framework for future improvements.

I'm also looking at the NSA IAM/IEM process. I was certified in the IAM via SecurityHorizon. It is very puzzling that this process is so minimally documented in any public domain sites or documents. If you do a Google (tm) search on "NSA IAM" the first hits are all training organizations offering certification prep. A security certificaiton methodology so heavily endorsed by the premier Federal government security agency should at least have a standards document available.

I finally (after many months) received permission to reproduce the PCI documents in my course reader. Unfortunately the reader went to UCLA previously. There is no change of including the printed versions of the PCI standards at least this go-around.

If you are interested in my class, check out UCLA Extension's Web site. I wish they would allow deep linking to a single class, but I am not their Webmaster.

Books on Security Assessment

2007-03-24T21:59:00.000-07:00

I'm building the course material for my upcoming UCLA Extension class on security assessment. After searching the reviews at Amazon, Slashdot articles, and archives of the pen test mailing list, I've come up with the following:

Penetration Testing and Network Defense by Andrew Whitaker and Daniel Newman
Hacking Exposed, 5th Edition by McClure, Scambray, and Kurtz
Network Security Assessment, by Chris McNab
Network Security AssessmentGuarding Your IT Infrastructure by Gregg and Kim
A Practical Guide to Security Assessments by Sudhanshu Kairab

These are all good books and each would be an excellent addition to the library of an IT auditor, security analyst, or penetration tester.

Gregg and Kim's book is the best introduction to the subject. It gives an overview of the risk assessment process. It focuses on security essentials, then describes the components of a assessment methodology. It is really a management overview, a good text for an intro class or for an IT manager considering hiring an assessment consultant.

Sudhanshu Kairab's book goes into more detail on the business process behind performing an assessment. This is a more detailed methodology for a senior security analyst. The nuts and bolts of managing an assessment project are described, including hints on how to gather information via interviews and how to structure the final report. A good third of the book is appendices covering various security checklists that can guide an assessment project.

The remaining books provide a more in-depth look at technical aspects of security assessment. These include the techniques used in performing a penetration test. Their shelf life is much shorter than the process-based guides, as techniques for security analysis have a very short lifespan. New techniques are developed very quickly, and older vulnerabilites often die just a s quickly. A vulnerability testing tool only needs to be neglected for at most two years before it becomes useless.

Chris McNab's book is part of the O'Reilly family of technical publications. It is well written, easy to follow, and tends to focus on examining UNIX-like systems. Hacking Exposed is the latest of a long dynasty of books from the former E&Y guys. It is very detailed, with chapters on current topics like VoIP hacking, phishing, and browser client attacks. An older version I had (2nd) seemed to be rather Windows-centric in its choice of tools. This current version does not suffer from such an emphasis. Finally, Whitaker and Newman's book, published by Cisco Press, also has a good technical emphasis. It does not seem as up-to-date as Hacking Exposed v5, though becoming out-of-date is a hazard of the genre. Any technical "how to hack" book should be regarded as only a starting point. Once you have mastered the basics, the professional pen tester should attend conferences and use mailing lists such as the pen test list.

Blogger now part of Google empire

2007-02-25T14:01:00.000-08:00

I had to set up a Google account to edit my blog. In the process, I found that almost every email account I have is associated with a pre-existing Google account. I have no record of what password I used in setting up this account, and no desire to maintain three unused Google account.

Google does not make it easy to delete accounts once they are set up. Their help page suggests going to a "contact Google" link that does not appear to exist.

I sent a fax right to Google requesting this. I will see if anything happens.

Unused accounts are the space debris of the Internet.

We've got mail

2007-01-21T14:39:00.000-08:00

I received a very nice email from Peter Herzog on OSTTMM, letting me know that "the OSSTMM is taught at 14 universities in Europe and 1 in Hong Kong". This approach definitely has its fans. I was sent a copy of version 3 of the OSTTM to distribute to the class. I'll incorporate it into the section on pen testing as I work out the class material.

A new class at UCLA Extension

2006-12-28T09:35:00.000-08:00

I've "volunteered" to take on a new class at UCLA Extension. It will be titled "Security Vulnerability Assessment" or something like that. I'm going to teach it over 2 consecutive weekends (fri/sat two weeks in a row) sometime in Spring (mid-April most likely).

Here is my outline so far:

Overview of information security, including the basic threat model, types of vulnerability, technical security architecture and principles of security management.
Discussion of the types of security assessment that may be conducted, including general controls audits, technical audits, vulnerability scans, and penetration tests.
Standards for vulnerability assessment, including AICPA/PCAOB, NIST SP 800-30 and related docs, NSA IAM/IEM, and Payment Card Industry (PCI) standards. I MAY talk a bit about HIPAA. I'm not sure if I should do the OSSTMM. Does anyone actually use OSSTMM aside from the folks who wrote it?
Some specific review items for most common technical platforms, meaning how to review Windows serves, Linux servers, and overall network security.
Demonstration of network security tools such as nmap, Nessus and the like.

I'll have a course reader with the slides as well as public domain material. I'll include relevant NIST documents and maybe FFIEC audit programs. I hope to get permission to use PCI documents. I really wish the NSA IAM had public domain documentation. I wish the Web site wasn't broken. It seems the Feds outsource this to training firms, who make a good business cranking out these certs.

I've tried finding similar courses offered elsewhere, but with little luck. Most of the "learn to hack" classes are proprietary, with no description other than the bare minimum. They tend to be entirely tool oriented as well. Classes on IT auditing only cover, well, IT auditing. Classes that touch on security assessment tend to do so as a small subtopic of a bigger intro to security class.

Halloween InfoSec News

2006-10-24T15:01:00.000-07:00

A few short items (again):

The Blue Box podcast service has a new recording which includes a rant about the lack of security provided by some VoIP Service Providers. This came out of a "Service Provider Shootout" provided by the Internet Telephony West conference earlier this in October.

SCADA security issues are covered in the scada security blog. Recent postings include how to detect ICCP servers with Nessus and a plug for the SCADA Security Scientific Symposium (January 24-25 in Miami)

And finally, what could be more "Halloween" than Zombies? ZDNet has an article titled "Zombies try to blend in with the crowd". Compromised zomby systems, instead of using easily recognizable (and easily blocked) communication protocols, are now using more familiar one like HTTP.

VoIP Security Exposed: Perspectives of a "Hacker"

2006-09-25T14:16:00.000-07:00

The IT Security World Conference is being held in San Francisco this week. I was able to attend one of the pre-conference workshops, titled VoIP Security Exposed. The presenter’s name was Eric Hacker. That is his real name. He swears it is his real name, and that he comes from a long line of hackers.

I’m going to give the main points of the seminar right now, and hold off a lengthier discussion until later:

ITU-T X.805 was introduced as a framework for telecom security architecture. It seems that Lucent was heavily involved in developing this standard, so it is no surprise Eric used it to illustrate VoIP security threats and mitigation measures.

A Session Border Controller (SBC) can be connected in parallel with an external firewall, or in series with it.

Windows Messenger includes SIP capabilities, so it is a VoIP client that is often included by default with Windows XP. This means you have less control over softphone use than you may have thought.

BYE messages in SIP can be forged, making an interesting denial-of-service attack against VoIP. The attacker can repeatedly hang up calls.

Your firewall must understand Session Description Protocol (SDP) to effectively pass VoIP traffic. SDP tells the firewall which "pinholes" to open to allow the bearer RTP (voice) traffic through. There are no good open-source tools to test these ephemeral firewall rule exceptions.

Voicemail sometimes uses SMTP or even POP/IMAP to support convergence. This introduces all the security flaws of these protocols into your VoIP application.

Eric mentioned one case where an SBC uses a Java communication protocol for management. The protocol requires arbitrary ports, hence creating a security exposure.

Firewalls often require version upgrades in order to support VoIP. these upgrades are non-trivial in a production environment.

Traversing Network Address Translation is another issue. STUN and TURN are often suggested as solutions, but for different reasons don’t work well (Eric made some comments about academics designing protocols that fail in the field...). Either SIP extensions with a proxy, or a Back to Back User Agent (B2BUA) may work for handling NAT issues.

End point devices (both PC-based softphones and hardware handsets) have their own security issues. Methods for downloading software and configuration updates may be insecure (e.g., TFTP), VLANs used to separate VoIP devices can be breached, and endpoint authentication requires a Public Key Infrastructure.

A Man In The Middle (MITM) attack was mentioned as a high risk, enabling eavesdropping, endpoint spoofing, and call manipulation.

Wrapping up, Eric discussed the following tools for VoIP vulnerability testing:

Sivus - Lots of unnecessary tests, hasn’t been updated in a while. Free.

SFTF - More of a QA tool than a vulnerability testing tool. Code and tests are tightly coupled, requiring a Python programmer to use. Not updated since 2004. Free.

SIPp - More of a QA tool than a vulnerability scanner. Tests are in XML hence easily extendable. Under active development. Free.

SIP Bomber - Based on the original Protos suite. More of a QA tool. Not recently updated. Free.

SipSak - really is a framework for testing SIP software than a security testing tool. Free.

Codenomicon - The commercial (not free) version of Protos. A very good QA tool. Your SIP vendors should have used this one.

VoIPSheild VoIPAudit - A basic vulnerability testing tool that has some promise (per Eric). Checks for vulnerabilities and for some policy compliance items. Commercial (not free)

Odds and ends

2006-09-15T14:03:00.000-07:00

If you are looking for examples of security awareness videos, a good place is the educause Website. They held a security video contest with 64 entries. Winners took home a thousand dollar prize. The videos are posted on their site. While definitely applicable to academic environments, they still provide useful lessons for other organizations.

My book is now featured in the ISACA bookstore. Buy it! Be the first to review it for Amazon.com.

And evidence that the focus of computer crime (I hate the word "cybercrime") has shifted from the stereotypical adolescent hacker to organized crime comes from this Wired article.

Defcon 14 in Vegas

2006-08-20T21:03:00.000-07:00

Defcon had its 14th year in Las Vegas just a few weeks back (specifically August 4 – 6). I haven’t attended for a few years. The old Defcon had gotten too glitzy and commercial. It had lost the juvenile antics and outlaw spirit, becoming another commercialized security fest, with slick marketing-like presentations lacking in technical substance. No more Mylar balloons launched over Area 51 anymore.

I decided to attend this year mainly because I felts I was losing my edge in technical security issues. My employer is going through fits regarding our training budget, so the $80 registration fee was something I could easily swallow.

After many years at the Alexis Park, Defcon moved to the Riviera. It’s a larger hotel, with a full-on casino (unlike the Alexis Park, which distinguished itself as the one place in Vegas with no gambling, hence friendly to the under-18 set). The hotel was OK as far as accommodations was concerned. It was at the chintzy side of the strip, though a reasonable walk to the better hotels. The layout of the hotel was very confusing – it took me the full 2 days before I could figure out how to get from point A to point B. I also found the staff to be a bit on the surly side.

I was very pleasantly surprised at the conference presentations. Defcon has made the full transition to a professional security conference very well. The speakers were all well prepared, spoke well, and presented valuable topics in a comprehensible fashion. No more swaying drunks trying to talk about PBX hacking.

Here are the sessions I attended with a short summary for each:

Visual Log Analysis – The Beauty of Graphs (Raffael Marty) – Different visual styles for presenting firewall logs, basically tree maps (node-to-node) and bar-charts ( leveled breakdown by protocol, with cell size proportional to number of events). He really likes Afterglow for parsing logs and providing them in a standard format for GraphViz or LGL to display.

802.1x Networking (tommEE pickles) – Tutorial on how to build a small secured wireless access system, including use of RADIUS for authentication.

Evolving Art of Fuzzing (Jared DeMott) - Very good stuff on software quality assurance in general, and specific issues with fuzzing. Notes the trade-off between random tests and total test time (lots of random cases mean testign will take a lot longer). A big issue is how to know when the application is “broken” by input. For example, running the app in a debugger will give you useful information, but the debugger itself changes how the application responds (e.g., to timing attacks).

IBM Networking Attacks (Martyn Ruks) – Looks at Datalink Switching (DLSw) as a means of attacking large IBM mainframes. DLSw is a method for encapsulating SNA in IP. Very good intro, could be used as a tutorial in SNA.

Secure Cloaking and Anonymous Services (Michael Rash) – A lot about Tor and how to combine it with single packet authentication.

Fun with 802.11 Device Drivers (Johnny Cache) – Showed a video of a machine being rooted via a vulnerable 802.11 device driver. Nothing a firewall can possibly do about this attack, as it occurs at layer 2. Scary stuff.

UNCLASSIFIED Information Sharing with Non-Traditional Partners (Linton Wells) – The straight guy in the group. He gave a very polished talk on DoD humanitarian initiatives, ending with a pitch for Defcon attendees to join up and become part of the DoD team.

Corporate Network Spying (Andrew Whitaker) – Very basic Hacking 101. Nice summary of methods for attacking switched networks. I only stayed for the first hour.

Traffic Analysis Panel (Jon Callas, moderator) – Think your encrypted communications will keep you safe? Think again. An amazing amount of information can be inferred from traffic analysis, and there is no feasible way to mask traffic patterns given the current Internet. Typing patterns can reveal what you are saying, even if you use SSH.

Graphical Representations of Security Relationships: Awesome or Bullshit? (Foofus) – Awesome graphical representations are simple and illustrate a specific useful relationship. Bullshit presentations are complex and impossible to read.

Phishing Tips and Techniques: Tackle, Rigging, and How & Where to Phish (Peter Guttman, all the way from New Zealand) – Server certs mean nothing. Most Web users have absolutely no clue about what they mean. Users are trained by bad sofvtware to ignore security warnings, and US banks are miserable when it comes to securing their own Websites. A successful phish should skip the server cert and just make a nice fancy dynamic Web page

that looks just like a real bank’s.

Hardening Fedora Core 5

2006-08-04T15:04:00.000-07:00

I revised a year-old hardening document designed for Red Hat Enterprise, forking it to create a hardening document for Fedora Core 5.

I followed the CIS recommendations in general. These consist of:

Remove (or don’t install) unnecessary services
Further harden with Bastille Linux
Apply a few more scripts to provide additional hardening.

The first two points are no-brainers. The difference is that yum is used to patch Fedora, while up2date is used for RH Enterprise. Do the following:

yum update

Fedora Core 5 supports SELinux to the extent of asking for configuration as part of the install process. I decided the hardening process should set SELinux to “warn” (permissive) mode initially, then set it to ‘enforce” mode once it is clear that applications would not be affected. There is an obvious analogy to installing RACF in this process. The trick is to eventually graduate from permissive to enforce mode.

Here’s how to do this:

Review SELinux policy violation messages
After applications have been installed and are running, search the messages log file for any SELinux error or warning messages:
```
grep avc /var/log/messages
```
If SELinux were to be installed in enforce mode, the listed errors would cause the application to fail. SELinux policy violations resulting from normal application use should be corrected by modifying the policy before setting SELinux to enforce mode.
Revise SELinux policy to permit normal application functions
A procedure is described in http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizing.html to modify the local SELinux policy to prevent authorization failures from normal application use. This procedure is summarized as:

2.a. Install the yum module checkpolicy:
```
yum install checkpolicy
```
2.b. Create a file containing the SELinux error log messages
```
grep avc /var/log/messages > avc
```
2.c. Create a local SELinux policy file:
```
/usr/bin/audit2allow –M local 
```
2.d. Load the policy file into the kernel:
```
/usr/sbin/semodule –i local.pp
```
SELinux error messages should be tracked to ensure no other authorization failures occur.
Set SELinux to enforce mode
Observe the messages log file for any further SELinux error or warning messages. If no authorization failures occur due to normal application operations, SELinux should be set to enforce mode:
```
/usr/sbin/setenforce 1
```

Bastille has turned out to be a real pain. Bastille allows use of batch files to automate the hardening process. The batch files are replicas of the questions and answers used in the interactive hardening. Unfortunately, the batch files must follow a specific format exactly, or the entire process aborts. If a question/response is missing or out of order, the hardening never happens. You then have the option of running Bastille interactively, in either graphical or curses-text mode.

Running in a graphical environment requires X. Hardened servers should not run X or even have the applications installed. First, I’ll be damned if I install X just to run a one time configurator. Second, if I’m going through the trouble to harden a server using Bastille, why would I introduce an unsafe application?

Text mode requires the perl curses modules. If you don’t have the modules, you would have to install them. Installing curses requires a ‘c’ compiler. Again, what hardened server keeps compilers around “just in case”? The same issues as with X – why go through the trouble, and why weaken security to run a hardening script?

Instead, I reviewed Bastille’s functions and specified shell commands to perform the same functions:

Remove non-root access to the following commands: linuxconf, fsck, ifconfig, runlevel and portmap:
```
chmod 700 command
```
Disable suid for mount/unmount commands:
```
chmod ug-s command
```
Remove suid status for dump and restore, cardctl, at, news server stuff (inndstart and startinnfeed), printing utilities (if not using anyway), usernetctl:
```
chmod ug-s /usr/bin/command
```
Remove all permissions for r-utilities ( rcp, rlogin, rdist, RSH, REXEC, RCP) so not even root can run these utilities without changing permissions explicitly:
```
chmod 000 command
```
Enable password aging in /etc/login.defs. The password change interval should be set as required by ITD policy. The minimum password length should be set to eight characters using the parameter PASS_MIN_LEN 8
Require use of strong passwords for user accounts. To set up password restrictions, edit the /etc/pam.d/system-auth file and add/change the following:
```
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3    minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
```
Note that running authconfig will destroy these changes, so permissions to authconfig should be set to avoid this:
```
chmod 000 /usr/bin/authconfig
```
```
chmod 000 /usr/sbin/authconfig
```
Set default umask - always edit the /etc/login.defs file to change the default umask to 077. Add the line UMASK 077 to the end of the file.
Remove unnecessary accounts: news, uucp, games, gopher. Also remove ftp, apache, and named if not using these service. Remove all associated groups having the same name as the removed accounts. userdel account groupdel group
Create authorized use banner in /etc/motd .
Disable these services unless specifically required: nfs, nfslock, ypbind, portmap, rpcidmapd, rpcgssd, netfs, cups, cups-config-daemons, hplib, and kudzu. Note that many servers may require printer access. Printer services may remain enabled if documented in the SIS and approved by ITD Security.

These services are specifically described in the CIS hardening document. Other unnecessary services should be disabled as well, including isdn and bluetooth-related services.

To disable services, from the System menu select the option Services. Select the background tab to remove services started at boot time.
Remove these applications unless specifically required: apmd, PCMIA services, GPM, and news. To remove applications, from the Applications menu select the option Add/Remove Software.

These don’t cover everything Bastille could cover, but they reflect the needs of the environment. I specifically excluded hardening steps designed to protect against inappropriate physical access (e.g., USB boot devices, boot passwords, etc.). The servers are in a secured data center, so physical security should be adequate. An intruder with physical access can always work around logical security measures. Conversely, these measures will make needed emergency maintenance more difficult.

VoIP Security and Technology Maturity

2006-06-28T07:44:00.000-07:00

Traditional telephony services, using Private Branch Exchange (PBX) systems and dedicated wiring are being supplanted by provision of telephony services over existing IP-based networks. Referred to as Voice over IP (VoIP), these services provide cost savings by using the same cable plant for both voice traffic and data traffic, and by permitting calls to be routed over lower cost IP networks.

Supporting voice traffic over existing IP-based networks means telephony services are subject to the same attacks that have traditionally plagued data networks. Virus outbreaks, denial of service attacks, and eavesdropping are threats found on IP based networks that are not typically found on traditional telephony systems. Compounding the security issues is voice traffic’s lack of tolerance for performance degradation. End user expectations of voice systems performance and reliability are much higher than for information systems. A lack of dial tone is much more disruptive of work processes than is a delay in receiving email messages.
VoIP provides a tempting target for attackers. Common data network attacks may be used to perform toll fraud, voice wiretapping, and to shut down VoIP systems with denial of service attacks. Impersonation of users supports fraud as well as general mischief. In common with older PBX-based phone systems, theft of service is an issue.

VoIP protocols have often been designed with only secondary attention to security. Low tolerance for network latency hampers use of encryption and network proxies as security countermeasures. This emphasis on performance and reliability is common with many emerging technologies.

VoIP security, in my opinion, is at the same stage as Web-based ecommerce security in 1995. The service is new and growing rapidly, standards are being tested, and technical innovators are putting out something new almost every day. Security specialists are concerned about possible threats but can only speculate what these threats might look like, and which threats will turn out to have the most impact.

With VoIP security, we have seen several recently published books attempting to cover the subject:

Voice over Internet Protocol (VoIP) Security, by PhD, CISM, CISSP, James F. Ransome, PhD, CISM, John Rittinghouse (Elsevier)
Practical VoIP Security, by Thomas Porter, Jan Kanclirz Jr. (Syngress)
Understanding Voice over IP Security, by Alan B. Johnston, David M. Piscitello (Artech)

(Note that a “Hacking Exposed” book covering VoIP is promised for future publication.)

Of these, I have read the first two. Both appear hastily written, to capitalize on an emerging high-interest field. Both spend a large portion of their text covering background material on IP networking and traditional telephony systems (even though the latter topic is only marginally relevant to VoIP security). Lastly, their coverage of threats, vulnerabilities, and countermeasures is an amalgam of existing IP-based data network attacks (hacker, worms, etc.) and traditional telephony concerns (mainly toll fraud).

I don’t fault these books too much for their failings. As an author, I understand the pressures and constraints of technical book publishing. The problems in writing about VoIP security reflect the immaturity of the field as much as the constraints of the media.

With little history of actual attacks, security specialists can only speculate on how VoIP systems will be compromised. This speculation naturally borrows from the two networking disciplines most related to VoIP – IP-based data communications and traditional PBX-based telephony. Think about trying to assess the threats to online ecommerce in 1995. You’d probably look at the prior ten years of public network security intrusion and combine this with some knowledge of fraud in the catalog retail business.

I recall reviewing an audit done by a “Big 6” firm of a Public Key Infrastructure system in 2000. The audit program was a mix of a standard IT general controls review and the IETF RFC defining PKI best practices. That audit program was the best that could be done absent a track record of PKI installations to provide real insight into PKI control issues. A similar exercise for a contemporary VoIP audit would likely yield similar observations.

Layer 1 – “Security” Conference, April 15, 2006

2006-05-12T12:48:00.000-07:00

The “hacker” community holds periodic conferences or “cons” to share tricks and techniques, impart practical and theoretical knowledge, socialize, drink, and have a good time. The big, well-known cons include Defcon (Las Vegas), HOPE (New York City) and the European Chaos Computer Club (Berlin). Local and regional events are held on a smaller scale.

Layer 1 is one such local con, held in the Los Angeles area every year since its first session 3 years ago. The 2006 con was held the weekend of April 15 (Easter). I was able to attend Saturday. My notes from the Saturday sessions include the following:

Ken Caruso – Seattle Wireless 6 years later
This community network uses RFC 3626 Optimized Link State Routing (OLSR) protocol. It is a mesh routing protocol that does not assume central control over routers. The protocol pro-actively builds network routes. A nice utility is available that creates SVG images of the network topology.

Seattle is up to 35 nodes. Not all of these nodes are interconnected. There are some “islands” of networks.

Some thoughts on the future of Seattle Community Wireless include:

OPN, “Other People’s Networks”, including open access points within the free network.

802.11 power saving mode could be used to store messages, to be retrieved when the devices are polled later.

Use of 900 mHz cards, for better RF penetration.

Use of a Nocat captive portal to advertise the community network (and to display some basic acceptable use policies, legal disclaimers, etc).

Use a new captive portal, wifidog, to aggregate community information.

Ken’s Web site is http://ken.ipl31.net . It has many links associated with his talk under the entry “LayerOne Talk Wrap Up”.

Enno Rey – MPLS Security
MPLS is the Multiprotocol Label Switch, specified in RFC 3031. MPLS is typically used in carrier networks. Layer 3 MPLS VPNs are used in enterprise networks, for traffic separation and segmentation (see RFC 2547 and RFC 2917).

Enno went through a number of attack scenarios against MPLS networks. These include replaying traffic and forging labels. The most credible scenarios required access to the MPLS core, specifically involving modifying labels to send traffic to the wrong VPN. Longer term, provision of Ethernet through MPLS will open up some interesting scenarios.

Luiz Eduardo Dos Santos – RFID Active Tags
Tags are distinguished as either UHF tags (passive, cheap legacy tags) and WiFi tags (longer range, more expensive, uses existing WiFi infrastructure). Basic technology behind these tags were discussed, and some potential attacks described.

Billy Hoffman – Covert Crawling
How do you crawl a Website without the owner knowing it was a bot? How do you get an automated program to look like normal human-based Web crawling? This is not as easy as it looks. Not only do you have to mimic human timing and attention to links, you also have to replicate rendering Web site objects and reference dynamic link information. One interesting suggestion is to hide your crawling inside the “slashdot effect”.

Paul Henry – Anti Forensics
Police are losing the forensics war against digital criminals. There are many tricks that can hide data inside ordinary storage without the most common forensic tools being able to discover. Data wiping routines are really getting good, they are cleaning out places where vestiges of the cleaned data could be inferred (such as the MFT). Specific mention was made of Evidence Eliminator, CyberScrub (for cleaning up email) and Metasploit’s anti-forensics project.

Converging facility and information security

2006-04-19T21:51:00.000-07:00

Convergence in this case refers to a coming together of physical and information security practices within organizations. This “coming together” is being driven by two trends: increasingly sophisticated network-based management of facility infrastructure and the increasing importance and sophistication of physical attacks against IT infrastructure. This merger is a difficult one, as facility and information security come from different cultures, and corporate turf wars make either side wary of reliquisinhg their traditional control.

Facility infrastructure requires measures to protect physical assets, through guard services, intrusion alarms, CCTV surveillance, and facility access control systems. Included among the physical assets are information technology resources such as servers, network devices, and communication lines. Denying potential attackers physical access to network equipment is essential to securing that equipment.

Facility access systems themselves are increasingly managed using shared information technology resources. Servers using off-the-shelf operating systems, network connections relying on IP and shared with other data and management consoles based on common Web browsers are becoming common. A compromise of network security could result in ineffective or compromised facility security systems.

Information security and facility security share common concerns. Both protect valuable organizational assets. An attack against one can compromise resources that are the responsibility of the other. A breakdown of facility security can compromise information systems, and an attack against information systems can harm facility security.

Information and facility security convergence implies formal coordination between facility security operations and information security. In some cases, information and facility security functions may be merged and managed under a single executive. More commonly, these functions continue to report to separate executives, establishing formal and informal coordination on matters of common concern.

Some of the benefits of coordinating facility and information security include:

The ability to provide a common security program to support an organization-wide risk management program. This facilitates executive level visibility to security issues, and allows for coordinated strategies for asset protection.

Having a one-stop-shop for resolution of security issues particularly at the executive level. This assumes a corporate culture that values an explicit organization-wide risk management approach.

Increased information sharing among staff. While upper management benefits from increased coordination at top levels, information sharing among middle management and technical staff can improve the delivery of security services.

More versatile staff, cross-trained in facility and information security disciplines. Staff may perform roles involving both information and facility security such as investigations and audits.

Monetary savings by being able to optimize the use of technology across the board for asset protection.

Areas of common concern include investigations, hiring and termination processes (or “user provisioning”), business continuity, and industrial/facility control systems. The user provisioning process is of particular interest, as it opens up use of a single identifier for both facility and system access, relying on a common directory backend for authentication and authorization.

More information on facility/information security convergence may be found at:

http://www.fcw.com/article84751-12-12-04-Print
http://www.csoonline.com/fundamentals/abc_convergence.html
http://www.varbusiness.com/showArticle.jhtml?articleID=51200143
http://www.computerworld.com/securitytopics/security/story/0,10801,108571p2,00.html

Emerging Challenges in Information Security

2005-12-29T10:07:00.000-08:00

I’m updating a client’s information strategy document. This requires that I identify emerging challenges in information security. This involves some prognostication regarding trends in the near future, and concise summaries of selected infosec pundits.

I’m looking for truly new developments, not a rehashing of recent history, and not the usual security chestnuts like IDS, firewall policies, VPN administration, incident response, etc.

Here are some topics I’ve found:

Information Security and Physical Security Convergence – Physical security has always been important to IT security. The relationship has become more intertwined as the computing environment has become more distributed. It is no longer just about securing the data center. Intelligent computing devices and network access points are all over. A stronger reason for this convergence is the adoption of IP-based management protocols for traditional facility-based devices (CCTV, alarm systems, facility access control, HVAC, power, etc.).

Integrated Security Management Systems – Sometimes called the “security dashboard”, this is an attempt to create a security management console similar to what products like HP OpenView provide for fault and performance management.

Voice over IP Security – The cost and management advantages of VoIP are leading some organizations into a full charge ahead with this technology. The combination of IP-based networks and old-fashioned telephony promised to bring back the era of phone phreakers.

Wireless LAN Security – This is almost an “old news” category, but were it not for the constantly evolving security standards and constantly evolving attack tools. It seems every time an improved crypto protocol is released, a new tool designed to attack it follows.

Business Partner links – In some form, this has been around since the days of EDI. The current version involves Web services. The key buzzword acronym is SAML (Security Assertion Markup Language).

End point security – Securing the desktop and laptop device, especially when IT may not have direct control over the machine. Employees want to work from home, traveling executives may check their email from kiosks, etc. How can one evaluate the security of the endpoint, and allow or deny services based on that security?

As I research these, I will post my findings and analysis here.

Router brute force authentication program

2005-11-07T20:53:00.000-08:00

I've written a perl script to perform a brute force login to network devices. It is mainly designed for use with Cisco routers, but works with other devices as well.

I wrote it because I had a very difficult time getting Hydra to work at performing brute force attacks on Cisco routers. My program differs from other brute force login programs by checking for a failed login, rather than a successful one. I found that many times a successful login did not produce a prompt having the magic characters brute force programs look for (such as >, #, etc.). This program assumes that any text that does not match a specified failure message is good. Just unzip, untar, and use the -h option to find out how it works.

You can download a tarball of this script from:

http://pages.sbcglobal.net/vleveque/brute-routers.tgz

Just type ./brute-routers -h for the help text.

Infraguard session on SCADA security

2005-11-02T20:09:00.000-08:00

The quarterly Infraguard meeting was held this morning at the Metropolitan Water District Headquarters in downtown Los Angeles. The topic was securing Supervisory Control And Data Acquisition (SCADA) devices. Speakers were Jason Larsen and Jeff Tebbe, both from the Idaho National Laboratories.

Their facility at the Idaho National Laboratories is intended to provide a perfect test environment for hacking industrial control systems. According to Jeff, vendors will provide them with their latest products for "test hacks", designed to help improve the product's security. This is all done with the support of the US government, specifically the Department of Homeland Security.

The Laboratory is developing a framework for SCADA security, based on NIST (SPP-PCSRF) and Common Criteria (ISO/FIC 15408) standards. These sometimes obtuse standards documents are made more comprehensible and more modular, and a database is created of the requirements combined with the SCADA components to which the requirements apply. Based on this framework, a security assessment methodology is applied to determine the actual security assurance level of the tested component. The goal of the framework is to provide common standards for assessment, such that an assessment performed by two different teams will produce similar findings.

Generic attack methods were then discussed. An attacker must first reach the LAN containing the SCADA devices. This LAN is typically isolated from the business LAN by a firewall. The isolation is often not perfect, and successful penetration of the SCADA LAN may come from back-doors, rather than a frontal assault through the business network. Some methods to penetrate the SCADA LAN include:

Remote Terminal Units with modem access
Wireless interception, either of cellular or of 802.11 networks. Point-to-point microwave is actually quite difficult and expensive to intercept.
Vendor access for service
Control channels from IT directly to devices, bypassing the firewall.
Peering networks with other utilities, for load balancing. A "mom and pop" utility is compromised, and the peering relationship allows compromising a much larger utility
IT management VPN, by compromising the IT admin's desktop system
Cross-network database links
Hi-jacking vendor patches, and introducing Trojan horse modifications on the fly

Inherent complexities in SCADA systems tend to make them difficult to hack. Unless the hacker really understands the details of the industrial process being controlled, they can at best conduct minor vandalism (closing random switches, etc.). Vendor protocols have historically been proprietary, relying on serial busses rather than well-understood networking links. The device communication language itself is poorly if at all documented. Modifying the control communications is very difficult given this, and requires time and patience on the part of the attacker.

Banks to require 2-factor authentication

2005-10-22T13:17:00.000-07:00

By the end of 2006, the FFIEC will require banks to adopt 2-factor authentication for Internet customers. Quoting from the article:

BOSTON - Federal regulators will require banks to strengthen security for Internet customers through authentication that goes beyond mere user names and passwords, which have become too easy for criminals to exploit.

Bank Web sites are expected to adopt some form of "two-factor" authentication by the end of 2006, regulators with the Federal Financial Institutions Examination Council said in a letter to banks last week.

See this yahoo news story. Also the FFIEC report.

Two factor authentication will make phishing attacks much harder - wheedling the password or pin out of a victim will not be enough, you'd also have to steal (or "borrow") their authenticator as well. A password stolen via a Trojan horse program (keyboard logger or screen-scraper) would at best grant the thief one chance to login as the user.

The Letter is drafted broadly enough that some wiggle room is there to allow a bank to get away without using 2 factor authentication. The letter calls for a risk analysis, with high-risk transactions specifically called out as requiring better than current single factor authentication. Would "high risk" apply to a typical consumer online banking transaction?

Lastly, this applies to online banking. Online retail purchases and other non-banking transactions would not be covered. Even with two factor authentication, there are still opportunities for theft. Man-in-the-middle attacks are still possible, and crooks could compromise the security tokens either by reverse engineering them or by fraudulently obtaining cards in the name of bank customers (through social engineering, etc.). Tokens designed according to good cryptographic practices should be resistant to reverse engineering, however the actual history of commercial cryptography suggests exploitable flaws are likely.

Note that the UK bank Lloyds TSB is experimenting with token based authentication, per this Computerworld article.

Scanning tools help build a network inventory

2005-08-22T16:32:00.000-07:00

I was able to use some hacker tools legitimately, for purposes of developing a device inventory in a large distributed network. The point of the exercise was to figure out which IP addresses were live, and then to identify these live devices.

The utility nmap was used for the initial scan. Two consecutive scans were performed, the first a ping scan:
nmap -sP -iL ip-master-range -oG ip-alive-ping

Then a so-called TCP ping scan:
nmap -sP -PA -iL ip-master-range -oG ip-alive-tcp

The TCP ping scan sends a SYN packet to an open port. If either a SYN-ACK or a RST are received, then the address is live. If nothing comes back, the device either is not there or TCP is filtered en route.

The two lists were sorted and merged to remove duplicates.

A nice little c program called onesixtyone was used for the snmp scan. This program accepts a file of ip addresses and a file of community strings. It goes through the entire list of addresses for each community string. The program returns the ip address, the working community string and the snmp system description. The description sometimes provides detailed information about the device. Sometime, the description is maddeningly brief.

A more precise description of the device make and model is provided by the system object ID MIB variable. I wrote a script that took the results of onesixtyone, read this variable, and created a nice comma separated file of ip address, community string, system object id, and system description.

I made some effort to grab telnet login banners en masse. The two available programs were amap and grabbb. I wrote off grabbb immediately. I was struggling with the command arguments (the README file was useless) and got these rude haxor error messages (“"illegal portlist supplied, check your eyes, lamer”). What little information was in the README said that it only captures the first line of output (not good enough) and it wasn’t really designed for telnet.

The other program, amap, was more professionally packaged. It is positioned as a generic application identification tool. It can optionally send “stuff” to open ports and based on the response tries to guess what service is actually behind the port (useful if someone is hiding a Web server or something behind a non-standard port). This program has a very well written README as well. Oh, and it handles multiple lines of output very well. Often the output includes screen formatting codes. I used a perl script to scrub these and just generate a plain character string.

It takes a while to perform a banner-grab. I estimated about 22 seconds per host.

For specific devices I grabbed the arp table from the remote routers and looked at the first bytes of device mac address. I used the perl module Net::Telnet::Cisco for this. The module was very easy to use and provided reasonable performance. One obvious gotcha – don’t print anything to standard out while communicating with the router. Anything sent to standard out will be sent to the router console session, not to your terminal.

Pen Testing Goes Mainstream

2005-08-13T09:15:00.000-07:00

Found this article in today's BBC News:

"Industry experience suggests," the report said, "that penetration tests always lead to findings such as the discovery of old, unpatched software or dangerous services running on web servers that would permit a hacker to enter a system."

With modern penetration techniques, it may only take one such loophole to give an unfriendly intruder access to sensitive information.

Which is precisely why pen testing courses are springing up all over the country.
As a result, more and more IT staff are becoming aware of the tools and techniques required to probe a network and then penetrate it.

See http://news.bbc.co.uk/1/hi/business/4142628.stm

The point is that regular pen tests are part of routine assurance activities - in the same sense as ongoing audits.

Pen testing is not longer seen by the mainstream press as some sort of hacker voodoo, but as a routine business activity that is part of normal operations. Security is like quality assurance, a process of gradual improvement.

This is a very good sign. Of course folks offering pen test courses and certifications love it too.

SNMP Security

2005-07-17T14:14:00.000-07:00

My client has decided that monitoring power and environmental sevices with snmp would be a good idea. They already use snmp for monitoring servers and other network devices, feeding this information into HP Openview and Cricket for fault and trend analysis. They need to monitor support devices and not just network elements. For example, irregular power can affect network device reliability. A failure in an air conditioner may require planned shutdown of servers, if the data center temperature gets too high. These alert conditions require data center staff to take action, even though they do not manage the environmental devices themselves. Capacity trends are useful for data center planning as well. Knowing actual power use trends indicates whether a power upgrade would be required for anticipated new servers. The same holds true for air conditioning. Will the extra servers that will arrive in three months end up overtaxing the current air conditioning?

Environmental devices provide several options for this monitoring. The building management industry has evolved communication schemes for monitoring and management independent of mainstream network management practices. These include ModBus and BACnet. ModBus is based on an underlying multipoint master/slave serial protocol (see http://www.modbus.org/default.htm for more info). BACNet is often based on a variant of the old ARCNet LAN protocol (I never thought I’d see ARCNet again!). BACNet also supports “BACNet over IP” (see http://www.bacnet.org/ for more on BACNet). Typically, building management systems were managed and monitored on parallel networks. Their traffic was never carried over shared IT infrastructure. Attacks against environmental devices from the IT network would be near impossible.

This all changes when snmp is used. Network managers want to monitor their data center environmental systems using the same tools used to monitor switches and routers. Equipment vendors accommodate these desires by supporting snmp via Ethernet. Liebert, for example, markets what they call the OpenComms NIC, a network interface card with a built-in SNMP agent. Other options include gateways between Modbus/BACnet and TCP/IP that include support for snmp.

Using snmp opens up serious security holes. Most devices support snmp version 1. This version provides “authentication” via a cleartext community string. Bad enough, but in many installations, the vendor default community strings are never changed. There are some fairly basic tools for doing brute-force attacks against snmp. Unlike a console login, snmp will not “lock out” after a certain number of invalid access attempts. SANS has listed insecure snmp use as one of the top 20 security vulnerabilities (http://www.sans.org/alerts/snmp.php). Vendor snmp implementation have demonstrated vulnerabilities, which allow an intruder to “crash” the snmp agent and gain unauthorized access. CERT has published an advisory (http://www.cert.org/advisories/CA-2002-03.html) concerning this very issue.

Devices may be managed as well as monitored by snmp. Electric power devices may be shut down with a simple snmp command. Imagine the havoc that can be created in the data center by a mass power shut down.

The advice given by CERT is not to use snmp at all. Short of this, the following measures are recommended:

Use snmp version 3 instead of version 1, if supported by the vendor. Version 3 supports encrypted authentication, hampering community string sniffing.
Change the default community string to something not subject to dictionary attack. In no case use vendor defaults, or “public”/”private”.
Set up traffic filtering rule in your network to filter snmp traffic from outside the network, and to block snmp from unauthorized hosts.
Configure the snmp agent so that only specific management hosts have snmp access.
Disable snmp SET (if possible).

An snmp proxy would be a good solution. The ideal proxy would establish an encrypted channel with the management stations, and perform application level traffic filtering. Devices that only support snmp v1 would then only be vulnerable within their own subnet. Proxies for snmp have been proposed for managing devices in a firewalled DMZ. ExtraLan makes a proxy that translates between snmp v1 and the more secure snmp v3 (see http://www.extralan.co.uk/products/Diagnostic-Tools/Adventnet/SNMPutils.htm).

Some snmp agents allow authentication traps. The authentication trap reports that an attempt is made to access the agent using an invalid community string. This is useful evidence of an attempted brute-force attack against the agent. The net-snmp trap agent allows logging trap conditions into the syslog files.

Regarding tools for testing snmp security, ADMsmnp is a very simple tool for brute-force testing various community strings. It’s not included in WHoppix, but is part of the port tree in various BSD implementations. See http://adm.freelsd.net/ADM/ to download the tarball.

SolarWinds makes a similar tool for Windows. It costs, but a 30-day free eval is available. I have downloaded this tool, but haven’t (yet) tried it out.

Lastly, the Protos test suite is available to test the robustness of various snmp agents when presented with non-compliant requests. Protos runs as a java application. It may be downloaded from http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/ . WARNING – these tests are designed to crash the snmp agent, and may result in the associated device halting or rebooting. You do not want to use this tool against a production system!

I like Whoppix!

2005-07-07T13:52:00.000-07:00

I just downloaded Whoppix. It's a "boot from CD" version of linux, based on Knoppix, that includes a good suite of security penetration test tools. Most of the failiar tools are available from a menu. It has the most user friendly version of Nessus I've seen. I've just started to work with it, so I will post what I find.

I noted that Whoppix is dead! Yes, it is being replaced with a new bootable CD-based security scanner called Whax. See http://iwhax.net/modules/news/. The new version is based on SLAX, a bootable Slackware distribution. The Whax Web site has support forums and much useful documentation.

I will have to download Whax and test it. I'll still review Whoppix, and then compare the two products.

Microsoft Security Templates and Group Policies

2005-06-17T16:24:00.000-07:00

Microsoft security templates are text files designed to apply specific policies to individual computer systems. Templates are great tools for hardening Microsoft servers to a specific standard. Templates may also be used to analyze the server’s configuration, providing an audit report of where the server’s configuration does not match the template. The tool for applying the text template (stored as an *.inf file) is the Microsoft Management Counsel snap-in called “Security Configuration and Analysis” (SCA). With SCA, you may import a template, then either apply it to the computer or perform an analysis.

Unfortunately, the ability to export or print the results of the audit is very limited. While the graphical output of the security analysis lists the computer and template standards separately, the log file only lists the fact that a discrepancy exists. If the server is actually more secure than the template, it is still a discrepancy. If the names in a list are in different orders, it is shown as a discrepancy, even if for all practical purposes the result is identical.

Superficially, security templates function a bit like Bastille for Linux. It’s a standard template for applying policies to a single system. It can also audit for compliance with those policies.

In Windows, the options specified in the template end up being applied to the local security policy. You can see this by looking at the Local Computer Policy snap-in after applying the template. All the values in the template are now part of the local system policy.

Now suppose the machine is part of a domain. The domain policy will overwrite the local system policy! The template that has just been applied to the server will vanish. If the domain policies are weaker than the template policies, the template policies will be rolled back. The same holds true if the server is part of an organizational unit – though an OU must be deliberately created, while every Active Directory implementation has a domain with a default domain security policy. The policies in the template must be consistent with those in the domain and the OU.

Standard security templates are available from a variety of sources. I advocate using those provided by Microsoft. I make an assumption that these have been reasonably well tested and will likely not break applications. The templates are provided in the Windows Server 2003 Security Guide, found at :
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/W2003HG/SGCH00.mspx.

The templates are actually not designed to be applied to individual servers. They are intended to be applied to the domain and to various OUs holding servers of different types. An OU is defined for IIS servers, another for file servers, and so forth. A server can have three templates applying security policies – a domain policy, a member server OU policy, then another OU for the type of server. If your environment does not have this domain and OU structure, you can still apply the templates by hand, one at a time, to individual servers.

Security templates are not really the equivalent of the hardening scripts used in the Unix world. The cannot be applied to servers at once, one at a time, in isolation from other servers – at least not if the servers are members of a domain. Active Directory provides flexibility and power to enforcing policies. You will be assured that every server in the OU follows the same security policy. If the policy changes, it will automatically change for all applicable servers. The disadvantage is that it becomes harder to isolate changes to a subset of servers. You may not want to change the policy for all servers in a domain or OU – you may only want to change one server’s policy.

Gartner Over Hypes Insecure Technologies

2005-06-11T09:28:00.000-07:00

The latest news is that the renowned pundits, the Gartner Group, believe that the security community has "over hyped" several security threats. The fear of security risks, in Gartner's opinion, is causing companies to avoid deploying technologies with clear business benefits.

Quoting from the SC Magazine article (http://www.scmagazine.com/news/index.cfm?fuseaction=newsDetails&newsUID=549bd799-f520-4ee1-a411-bcb45b81620f&newsType=Latest%20News):

Unsafe Internet Protocol (IP) telephony, dangerous mobile malware, "Warhol worms", regulatory compliance and unsafe wireless hot spots were named by the company as the security threats that caused users most problems, because vendors exaggerate the dangers.

In most cases, Gartner argued that the benefits of adopting new technologies, such as IP telephony, far outweighed the actual dangers.

Gartner then goes on to say these technologies can be properly secured and, if so, businesses can realize the benefits without taking undue risks. Well, duh, properly secured of course these technologies are likely not to present any unusual risks. I remember a comic making a point about ads claiming certain dessert products were delicious with strawberries and cream. Replied the comic, "Even old mattress tacking would taste good with strawberries and cream".

The problem is that companies implementing these technologies are not properly securing them, that efforts of information security professionals to enforce proper security are ignored, stonewalled, or overridden by management. By downplaying security concerns, Gartner is effectively encouraging company management to continue implementing these technologies with inadequate protection.

I will look at the specific examples of wireless 802.11 LANs (“wireless fidelity” known as Wi-Fi) and of Voice Over IP (VoIP).

Running Wi-Fi with IPSec has always been considered secure, as far as eavesdropping and traffic modification goes. Actually setting up and managing IPSec can be difficult, it and certainly requires some technical background in the subject. The reality of organizational Wi-Fi deployment suggests most installations are blindly ignoring security practices. Most new Wi-Fi deployments are maverick installations, where someone just goes to Best Buy, gets an access point, sets it up on their desktop computer, and hopes nobody from IT notices. No WEP, default SSID, etc. - perfect for war drivers. Even when deployed by IT, configuring IPSec (or other secure transports) can be difficult, and is often skipped in the interests of getting it running. Management wants their laptops to work in conference rooms without cumbersome wires, and they want it NOW!

I am very concerned about Gartner's dismissal of wiretapping concerns with VoIP. Tools for re-assembling this traffic and creating audio files are out there (one with the appealing name of "VoMIT" is part of standard BSD port trees). Putting voice traffic in its own VLAN is an obstacle to eavesdropping but not a protection measure. VLANs can be compromised and their misconfiguration can expose VoIP traffic without an actual attack. VLANS were meant to separate traffic for collision management purposes. VLANs were never intended to be a primary security protection measure. FYI, a good paper from Cisco on VLAN security best practices may be found at http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/vlnwp_wp.pdf.

There are secondary concerns with VoIP that must be addressed in terms of the authenticity of calls, and the extent everyday business trusts certain types of phone communication. Thanks to VoIP, anyone with a DSL line and a bit of Linux expertise can set up a PBX, spoof caller ID information, and generally have a lot of fun with call routing functions. I suspect we are on the verge of a new phishing epidemic, where social engineering attacks are supported by sophisticated telecom technology. All the old 1970's phone phreaking tricks may suddenly become popular again. An article in New Scientist (March 5, 2005, http://www.newscientist.com/channel/info-tech/electronic-threats/dn7136) addresses these issues.

Security problem with new technologies often do not manifest themselves until many years after the technology has been adopted. The prototype of the information gathering Trojan horse program was demonstrated by the German Chaos Computer Club in 1996 (see http://www.iks-jena.de/mitarb/lutz/security/activex.pe.clari.html). Using a rogue ActiveX program, they were able to devise a Web site that would steal end user information from Quicken. The theoretical danger from this program was well demonstrated. It took a few years until these malicious programs became a serious concern. Any new technology requires a certain critical level of installed base before mass exploitation becomes feasible. Until then, it looks like security concerns are over hyped.

New technologies are often the ones that organizations have the most difficulty in securing. There is an urgency to deploying new technologies that counters the thoughtful, deliberate approach necessary for good security. New "must have" technologies are often driven by non-technical business groups, who are motivated to downplay threats. Even where an IT group is implementing the technology, proper security requires "out of box" thinking that is rare to find. A voice telecom group familiar with traditional PBX technology likely is not familiar with the security threats in an IP-based VoIP product that uses shared media.

By calling security concerns "hype", Gartner is doing a dis-service to legitimate security concerns.

Server Hardening thoughts

2005-06-01T13:09:00.000-07:00

I'm developing hardening procedures for various types of Windows and *nix servers - specifically Win 2000 server, Win 2003 server, AIX 5.3, and Red Hat AS 3.0.

A hardening document is part procedures "cookbook" and part standards document. The procedures consist of a core of technical procedures for reconfiguring the server. Surrounding this core are the pre-hardening procedures for server inventory management and the post-hardening procedures for deployment, secure management, and periodic security assessment. I consider the asset and inventory management to be just as important as the technical hardening. If you don't know where it is, you don't know if it is secure or not.

The technical hardening piece relies on published, reputable security standards. Good sources for these include SANS, the NSA, NIST, and the Center for Internet Security. As much as possible, I like to use standards provided by the server's vendor. Vendor-provided standards have credibility with server administrators. This helps in acceptance of the standards. Vendors presumably know how hard to push hardening before commonly used applications "break". I assume if Microsoft says to configure something in Windows 2003, then most Microsoft applications can live with this. Finally, in large organizations, there is a support contract with the vendor. If there is a problem with a vendor-recommended security setting, then a trouble ticket can be opened up to resolve the issue.

As much as possible, I make sure the hardening recommendations reflect the most current operating system version. I noted some significant differences between Red Hat Enterprise 3.0 and the version 4.0. The hardening documents for these two reflect these differences. For example, version 4.0 allows for enabling SELinux in the installation procedure, while 3.0 does not.

I make each step in the hardening document as clear as possible. If certain services are to be disabled, I list every single one of them, along with the relevant command. I avoid vague generalities, such as "eliminate unnecessary services". I want to eliminate wiggle room for the system administrator. System administrators are under tremendous time pressure, and often are forced to make performance and flexibility their priorities rather than security. Specificity is necessary to ensure the job gets done.

Along with specificity must come an escape valve for cases where the standard hardening configuration will not work with specific applications. The reason for a variance must be documented and approved by the information security manager. The exception process should discourage trivial variances, but should not be so onerous that there is a strong temptation to ignore or bypass the requirements. Ultimately, the purpose of exception documentation is to maintain known security configuration documentation. In the event a new vulnerability is found, the information security manager can establish which servers are vulnerable and how they must be corrected.

I see the purpose of hardening standards as not so much providing the best security as providing consistent, documented security. Servers do not need to be impenetrable, they need to be manageable.

Greetings, Blog World!

2005-05-14T22:52:00.000-07:00

Hello,

I'm Vincent LeVeque, an information security consultant. I'm currently on assignment with a large local government entity. I do general network management stuff in addition to security tasks.

I'm currently developing some security hardening documents for several operating environments: IBM AIX, Red Hat Enterprise Linux, Apache (Unix and Windows versions), and Windows 2000/2003 Server.

I've settled on the following criteria:

Refer to the vendor's recommendations as much as possible rather than third party standards. SANS (http://www.sans.org), NIST (http://www.csrc.nist.gov) and the Center for Internet Security (http://www.cisecurity.org/) all have excellent recommendations. They lag the most current vendor releases, and most importantly, if I follow a vendor recommendation and it breaks something, there is a valid reason to open a trouble ticket with the vendor. If one of NIST's recommendations break a Windows 2003 server app, do you think Microsoft will do anything about it?
Tie into the client's emerging change management and inventory management practices. If the device isn't in the asset inventory system, then it can't be hardened. Good management practices come before good technical security.
Make the recommendations as specific as humanly possible. Don't allow wiggle room.
Where wiggle room is necessary, set up a documented exception process.
Ensure that it is possible to audit for compliance. Standards should be testable after the fact.