The Security Skeptic

Unforgiving?

 

In an article entitled Security Hats: Black and White, No Grayscale, I list reasons why organizations should avoid hiring crackers (convicted or admitted). Some readers feel this is an unforgiving attitude that fails to consider that individuals can make mistakes, but if they are contrite, serve jail time and reform, they should be forgiven. I'm entirely comfortable with being forgiving. But that's not the issue here. Many public administration degree holders feel we actually need to be tougher on 'white-collar' criminals, including those who may take advantage of their expertise.

A physician who performs illegal surgeries or violates the canons of medical ethics will lose his license and may serve jail time. He may regret his actions and pledge to reform. When he returns to society, he can try new careers, but he should never be allowed to practice medicine again. The MBA information technology holder who hacks and breeches security should be treated similarly

Similarly, an attorney who breaks the law, breaches an attorney-client privilege, or violates other legal canons of ethics will lose his license and may serve jail time. He, too, may regret his actions and pledge to reform. When the attorney returns to society, he can try new careers, but he should never be allowed to practice law again.

Why should we treat information technologists differently? An information technologist who engages in *cracking*, breaks computer crime laws, or who does not conduct himself ethically, lawfully and professionally should lose any certifications he has accrued and serve jail time. He may regret his actions and claim to reform, but when he returns to society, he can do many things, but he should never be permitted to work in the field of information technology again.

Serving time and paying fines are appropriate consequences for committing crimes, but should not the only ones. Some consequences should to be more enduring and the consequences of violating a trust should be more severe. It's unlikely that a disbarred attorney would be invited to speak at a law conference on ways to exploit privileged information. A physician barred from medical practice would not be invited to demonstrate surgical techniques at a teaching hospital. But I note with considerable disgust that we invite convicted hackers to present keynotes and *worse* teach for hacker academies.

If learning how to social engineer and hack networks from an ex-con is what it takes to earn a certification from your academy, you can keep it.

Archived at http://www.securityskeptic.com/arc20070401.htm#BlogID609 by Dave Piscitello  

To disclose or not to disclose

 

Happy coincidence! Having just published a podcast that casts a harsh light on the vulnerability disclosure practices and motives of certain "ethical hackers", I was intrigued to find an invited editorial by Professor Ric Steinberger on the subject of disclosure in Mich Kabay's 03/08/07 Network World's Security Strategies Newsletter . Professor Steinberger suggests that "there is no 'always correct' response that vulnerability researchers should follow" when they discover a flaw in a software product. Steinberger makes a case for tempering full disclosure in situations where a vendor is seemingly non-responsive. Steinberger argues that forcing a vendor response by going public with a vulnerability may indeed force a large software vendor with ample resources to respond in a more timely manner, but the same course of action may prove onerous or disastrous for a smaller company or startup that has fewer resources and may need more time to provide a patch or workaround.

Steinberger is suggesting that vulnerability researchers act with a degree of charity, an ounce of forgiveness. While I am certain that legitimate vulnerability researchers may consider this suggestion, I worry that the less than legitimate (ahem) researcher who only seeks attention may not have a charitable bone in his body.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID601 by Dave Piscitello  

Checkmate - a new and interesting security blog!

 

K. K. Mookhey and the folks at NII Consulting have begun a security blog. Checkmate focuses on forensics and penetration testing. KK invited me to visit the blog and "give it a quick read-over and your feedback as well". The first article I read - LINReS, An open source Linux Incident Response Tool - more than convince me that this is definitely a security blog worth visiting. The authors are competent and write well. The blog items are nicely presented, with abstracts that tease you into reading the full articles. And the articles address a nice mix of host and network security issues. On my first visit, I read articles about incident response software for Linux systems that is entirely self-contained, ways to secure password files against rainbow table attacks, and some details on the alternate data stream in the Windows NTFS file system.

If you enjoy good technical writing on a range of security subjects, add Checkmate to your RSS feed. The RSS feed can be found at http://www.niiconsulting.com/checkmate/feed/.

Archived at http://www.securityskeptic.com/arc20060701.htm#BlogID541 by Dave Piscitello  

New twist on an old exploit

 

Nearly a decade after the disclosure of the exploit code for the original LAND attack, a remote variants of the attack have resurfaced (see Remote LanD Attack). One variant affects Microsoft W2K3 and XP SP2 when Windows Firewall is disabled (see CVE-2005-0688). Others appear to affect a wide range of consumer grade DSL/cable modems, broadband access routers, and even some enterprise entry-level firewalls, e.g., the kind you typically see used by businesses with T1 access circuits.

 

The original LAND attack sent a TCP SYN segment to an open port on the victim's host, setting both the source and destination address fields in the IP header to the victim's IP address (i.e., from 10.0.0.1:139 to 10.0.0.1:139). In 1997, this attack caused systems to crash, BSOD, or reboot. Justin Wray and friends discovered two variants to the remote LAND exploit that create denial of service conditions.

 

In the first case, an attacker sends a TCP segment with the Ack/Syn/Push/Urgent flags set. He sets the destination IP address to the external (public) IP address of a target cable modem or broadband router/firewall, and sets the source IP address to the *private* IP address assigned to target device. This attack causes the modem/access routers to fail in several ways (vendor dependent). The source address of many consumer grade broadband access devices is easily derived. Most such devices use the RFC 1918 reserved IP number 192.168.x.0/24 and set the router to 192.168.0.1, 192.168.1.1, ...

 

In the second case, the attacker again send a TCP segment with the Ack/Syn/Push/Urgent flags set, again setting the destination IP address to the external (public) IP address of a target cable modem or broadband router/firewall, but sets the source IP address to a broadcast address. This causes the hosts on the private network to flood the broadband access device with responses.

 

Both attacks can be performed using a packet composition utilities like hping2 (no special code required).

 

Strictly speaking, these attacks are different from a traditional LAND attack - the source and destination IP addresses aren't the same - but the addresses are assigned to the same host, and the attacks have similar impacts.

 

The Microsoft patches have been available for some time. Several vendor products require patching (find the list in the referenced URL). A workaround for firewalls and routers exploitable in this manner is to include an firewall rule or ACL that blocks all traffic arriving at the external interface with an internally assigned address (this should be Firewall 101 by now). But as Wray observes, if the modems are vulnerable, the traffic won't ever be delivered to the firewall/router.

I think this is an interesting exploit for several reasons. First, it illustrates how quickly one "generation" of programmers forget the lessons ,learned less than a decade ago, and emphasizes how desperately our industry needs to teach secure code techniques and invest more in quality assurance. Second, it is a unique example of an exploit that spans many classes of systems and operating systems. Third, it is an example of an attack that will probably succeed for a long time, since it exploits consumer grade technology, and as Wray observed in an email exchange, few consumers are savvy enough to perform a firmware upgrade on a network device, and many simply won't try. What a considerate pre-Christmas gift for broadband help desk operators.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID481 by Dave Piscitello  

Password Lists

 

A recent thread on pen-test list at SecurityFocus.com exchanged favorite password lists for use in bruteforce attacks against weakly authenticated user accounts. Brute force password cracking tools like John The Ripper and numerous password recovery tools employ such lists.

 

Some of the posts offered interesting resources. To save you the bother of finding the thread, I've copied the hyperlinks to those resources that I found interesting:

 

• The Openwall Project offers a for-purchase CD of wordlists and common passwords in over twenty languages, along with trial versions password cracking software.

   

   

• Phenoelit provides a fairly exhaustive (3Com to xyplex) list of manufacturer default accounts and passwords.

   

   

• reversing.org presents a very interesting article describing the process of generating word lists for bruteforce cracking.

   

   

• Cotse.net has dozens of word lists, categorized in various ways: abbreviations, language-specific word lists, language-specific surnames, comic and cartoon characters, famous people, music genre, actors, myths and legends, etc.

 

 

The lists I mention give you enormous dictionaries against which to test the kinds of passwords users are composing. Since these lists are mostly common language words, the lists are quickly negated when you impose password length and complexity criteria on users (e.g., through a group security policy pushed to managed client PCs via Windows Active Directory). Good brute force password cracking and recovery tools of course factor such criteria into their processing.

There are also various "short" lists of common passwords that might be used in stealthy penetration testing. A claim was made by the poster that words from this list match a password in use on a network 80% of the time are "interesting". Here's a copy for your convenience (the hyperlink provided in the email was a cached Google page and will likely be blocked by many anti-fraud and phishing utilities)

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID472 by Dave Piscitello  

Mobile User and Mobile PPC Security

 

At the recommendation of a posting at bug-traq, I listened to a 15 minute presentation on Windows Mobile Pocket PC Security by Seth Fogie of Airscanner. If you have a PPC, grab a cup of coffee and invest the time to listen to this audiocast. You'll learn quite a bit about PPC attacks such as forced resets embedded in attachments or downloads, viruses,and trojans that can be installed via removable (flash) memory when Autorun is enabled. You can also hear how attackers use PDAs as attack tools (especially over wireless LANs).

I gave a presentation on Mobile User Security at IPcomm 2004 in Las Vegas. Hopefully, you'll find my presentation a useful complement to Seth's audiocast.

Archived at http://www.securityskeptic.com/arc20041101.htm#BlogID331 by Dave Piscitello  

Trolling or Trawling?

 

I lurk on a number of security email lists. Several cover penetration testing and "ethical hacking". I've searched the hosting sites for these lists for Codes of Conduct - you know, "I promise to exchange and use information posted here in an ethical manner and not for malicious purposes" - but can only find privacy statements.

 

Let's assume, then, that some lurkers and posters on some of these lists are legitimately trawling for information while others are trolling. According to the geeksnet glossary, trolling is "deliberately posting false information in order to elicit responses from people who really want to help".

 

Trolling can be a useful form of social engineering or information gathering. Consider a thread with the following exchanges:

 

 

 

 

 

 

 

 

 

Troller		"I'm using FrontPage 2002 on my Windows 2000 SBS. I installed URLscan and now my users complain they can't get to my site. I set AllowHighBitCharacter=0 what did I miss?"
Victim		"It sounds like your server's denying FrontPage access. Did you set AllowDotInPath to one? See MKBA-307976 and MKBA-309394"
Troller		"Yes its set to one are you using FP2002 and W2KSBS? Maybe I'm missing a patch?"
Victim		"Yes I'm using the same version of FP and SBS. I'm not current with patches, we've been busy here, so maybe a recent patch is screwing you up".

 

 

This troller's hit a home run. Assuming the victim's using his company email, he can use the information the victim disclosed trying to be helpful: operating system and server type, configuration of one of the security measures, and best of all, not current with patches.

 

Don't laugh. I see this all the time. It's amazing how much information otherwise responsible and intelligent people disclose if they feel they are in a comfort zone. Many technical professionals have as strong allegiances to their mailing lists as septuagenarians have to golf foursomes at their country clubs.

 

This is yet another example of why maintaining good net security is more a social than technology problem.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID271 by Dave Piscitello  

Security Hats: Black and White, No Grayscale

A recent CNET news column claims that "most security specialists classify hackers as white hats or black hats, but in reality, most hackers fall somewhere in between".

I contend the claim is entirely false. Read why.

Archived at http://www.securityskeptic.com/arc20040101.htm#BlogID193 by Dave Piscitello  

Glorifying Exploits is Misguided

 

Afred Huger posts lists of articles at SecurityFocus as they become available. Recently, he noted the publication of the first of thre articles entitled Exploiting Cisco Routers.

The column is very interesting, as it reveals several exploits and vulnerabilities that are not particularly new, but troublesome still.

In my opinion, this column would have been so much more valuable to the security community if written in a constructive manner.

The title itself disheartens me: "Exploiting cisco routers" is an "I'm sooo kewl look how easily I can crack your box" perspective that only encourages people that this is the true merit of pen-testing. Further into the column, I read the section entitled "Brute-Forcing Services: SNMP is always fun". Fun? How many networks can you probe and discover the same missing patch, or configuration error before you think, "this is sad..." rather than "oh, what fun!"? (Perseveration is symptomatic of psychological and language disorders, but now I stray from the topic...)

If I wanted to make a case for distinguishing pen-testing from security auditing, I can't help but feel columns like this reinforce the attitude that pen-testing is an amateur's activity. This is sad, too.

If SecurityFocus wants its portals and lists to continue to be a resource for people interested in securing systems, its editors might want to consider exerting some influence and encourage authors to write in terms of identifying and eliminating vulnerabilities than exploiting them.

Imagine how positive and more widespread an influence these same columns might make if they were titled "Identifying and Mitigating Cisco Router Vulnerabilities".

 

 

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID139 by Dave Piscitello  

Half-Life of Bugs?

 

SecurityFocus News reports that a recent study by Qualsys concludes that "Software security holes never die, they fade from the Internet at a rate of 50% every thirty days after a patch is released".

 

Stated in another way, disclosure of an exploitable flaw in software, formal or otherwise, causes a wave of attacks seeking out systems that remain vulnerable. This wave abates dramatically 30 days after disclosure. (Living on a barrier island, I think the correct analogy is *tidal surge*... OK, a small matter.)

 

My initial reaction to this statement is was, "did they ignore CodeRed and Nimbda?" When I reviewed my web logs over the past 6 months, I confirmed that I have a very consistent rate of attempts to exploit these IIS vulnerabilities.

 

Reading on, I find that Qualsys believes these fall into a different category: instead of decaying in a predictable manner, they return and become prevalent again. Qualys CTO Gerhard Echelbeck attributes this phenomenon, bug-immortality, to attackers seeking out "network administrators cloning new systems from old, unpatched images".

 

IMO, this is an oversimplified characterization. Staff with little security expertise are thrown into systems administration daily. Many barely understand how and what to do to get a host and web services operational, much less, secure, and they are pressed to do so in haste. Most probably don't know how to create a system image and simply build a Windows server from OEM or Microsoft CDs; in fact, a great many of these folks would be hard pressed to repeat the process they used to create their first server environment.

 

Exploitable bugs are immortal because our culture tolerates a level of hygiene when it comes to server security that modern societies would consider medieval if the same were applied to viruses and diseases.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID96 by Dave Piscitello  

Denial of Power Attack (Theoretical)?

The susceptibility of SNMP to attack is well-known. Here's a theoretical SNMP-based attack one could launch against an intranet or server farm. I think an attacker can spoof server (and client) systems that monitor a networked UPS into shutting down.

Assume

 

• you find a way into a company A (e.g., from war driving or trojan)

   

   

• company A uses SNMP to monitor UPS

   

   

• company A's SNMP read-only community string is default, easily guessed, or captured off the air/wire

   

   

 

First, the attacker scans the SNMP port until he finds responders. Next, the attacker walks the MIB to verify the device is a UPS. Spoofing the IP address of the UPS, the attacker issues the trap upsTrapOnBattery (described below), indicating a very small value of estimated minutes of battery remain to all IPs in the same subnet (perhaps the attacker refines this by reading the list of trap recipients to possibly determine which are management stations and which are servers since he doesn't want to notify the management stations.

Won't at least some servers respond to the trap by shutting down?

Is this wild speculation or yet another reason to find a more secure way to manage networks than SNMP?

The IETF UPS MIB trap upsTrapOnBatteryis as follows:

upsTrapOnBattery NOTIFICATION-TYPE

OBJECTS { upsEstimatedMinutesRemaining, upsSecondsOnBattery, upsConfigLowBattTime }

STATUS current

DESCRIPTION

"The UPS is operating on battery power. This trap is persistent and is

resent at one minute intervals until the UPS either turns off or is no longer

running on battery."

::= { upsTraps 1 }

 

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID69 by Dave Piscitello