07 May, 2009

Do we need anti-virus software?

My friend Richard has a good post about Verizon's 2009 Data Breach Report. One of his last comments really struck me since it is something I have seen firsthand again and again.

Most companies are probably relying on their anti-virus software to save them. This is too bad, because the explosion in customized malware means it probably won't.
Anti-virus software just does not work against most recent malware. The table from the Verizon report shows a drastic upswing in customized malware and my experience tells me that doesn't tell half the story. Even only small changes will often evade anti-virus software.

I'm not saying anything new here. Anyone that does penetration tests, reverse engineers malware, writes exploits, or is involved with information security in a number of ways already knows that anti-virus software is terrible at detecting new malware. I have even written about it before and pointed out that more subtle methods of exploitation aren't always necessary because of the effectiveness of commodity malware.

My question is, do we really need anti-virus software?

When you take into account the amount of resources spent running anti-virus in the enterprise, is it a good investment in risk reduction? We pay for hours worked to setup the anti-virus infrastructure, update, and troubleshoot. If you are in an enterprise, you're paying for the software, not using a free alternative. You're probably paying for support and also paying for hardware.

What does it get you? I find malware on a weekly basis, sometimes daily, that is not detected by the major vendors. I submit the malware to some of these vendors and places like VirusTotal, but the responses from anti-virus vendors are inconsistent at best. Even after definitions are updated, I'll then run across malware that is obviously just an altered version of the previous but is once again not detected.

I don't pretend to have the answers, but I do wonder if all the resources spent on anti-virus by a business, particularly large or enterprise businesses, might be better spent somewhere else. Is it really worth tens or hundreds of thousands of dollars in software, hours, and hardware to make sure old malware is detected? If not, how much is it worth? Does the occasional quick response to emerging malware make it more worthwhile? If you have enough influence on the vendor, does being able to contact them directly to help protect against a specific attack make it more valuable?

Anti-virus software is too ingrained in corporate culture to think it is realistic that companies will stop using it altogether, but we need to keep asking these types of questions.

28 April, 2009

Building an IR Team: People

For some time I have been thinking about a series of posts about building an incident response team. I started in security as part of a very small Computer Incident Response Team (CIRT) that handled network security monitoring (NSM) and the ensuing security incidents. Although we were small, we had a very good core of people that helped us succeed and grow, probably well beyond anything we had imagined. We grew from a handful of people to four or five times our original size. While there were undoubtedly setbacks, we constantly got better and more efficient as the team grew.

As the first in this series, I definitely want to concentrate on people. I don't care what fancy tools, enormous budget, buy-in from management, or whatever else you have. If you don't have the right people, you'll have serious problems succeeding. Most of this is probably not unique to a response team, information security, or information technology.

Hiring
Of course, hiring is where it all starts. What do you look for in a candidate for an incident response team? Here are some of the things I look for.

  • Initiative: The last thing I want is someone that constantly needs hand-holding. Certainly people need help sometimes, and sharing knowledge and mentoring are huge, but you have to be able to work through the bumps and find solutions. A NSM operation or CIRT is not a help desk. Although you can have standard procedures, you have to be flexible, adapt, do a lot of research, and teach yourself whenever possible.
  • Drive: Most people who are successful in security seem to think of it as more than a job. They spend free time hacking away at tools, breaking things, fixing things, researching, reading, and more. I don't believe this kind of drive has to be all-consuming, because I certainly have plenty of outside interests. However, generally speaking there is plenty of time to be interested in information security outside of work while still having a life. I, and undoubtedly many successful security professionals, enjoy spending time reading, playing with new tools, and more. Finding this type of person is not actually difficult, but it can take some patience. Local security groups or mailing lists are examples of places to look for analysts to add to a team. Even if they have little work experience, by going to a group meeting or subscribing to mailing lists, they are already demonstrating some drive and initiative.
  • Communication skills: Although this may be more important for a senior analyst, being able to write and speak well is crucial. Knowing your audience is one of the most important skills. For instance, if you are writing a review of a recent incident that includes lessons learned, the end product will be different depending whether the review is for management or the incident responders on the team. Documentation, training, and reporting are other examples where good writing and speaking skills are important. I think good communication skills are underrated by many people in the field and IT in general, but the higher you look the better the chance you will find someone that realizes the importance of effective communication.
  • Background: Most of the successful NSM analysts and incident responders I know have a background in one or more of three core areas; networking, programming, or system administration. A person from each background will often have different strengths, so understanding the likely strengths of each background can go a long way toward filling a missing need on the team. You do not have to come from one of these backgrounds, it is just relatively common for the good analysts I know to have backgrounds in these areas.
  • The wrong candidate in the wrong position: Do not be scared to turn down people that are wrong for the job. That seems obvious, but it is worth emphasizing. Along the same lines, if someone is not working out, take steps to correct the problems if possible, but do not be afraid to get rid of a person that is not right for the job. Try to understand exactly what you are looking for and where in the organization the person is most likely to excel.
Experience versus Potential
When filling a senior position, experience is definitely important. However, when filling a junior position I think automatically giving a lot of weight to information security experience can be a mistake. The last thing I want to do is hire someone who has experience but is overly reliant on technology rather than critical thinking skills. I don't mean to denigrate or automatically discount junior analysts that have experience, I just mean that I'd rather have someone with a lot of potential that needs a little more training in the beginning than what some would call a "scope dope", someone whose experience is looking at IDS alerts and taking them at face value with little correlation or investigation. If you have both experience and potential, great!

Training
Information security covers a huge range of topics, requires a wide range of skills, and changes quickly. Good analysts will want training, and if you don't give it to them you will wind up with a bunch of people that don't care about increasing their knowledge and skills as the ones that do want to learn look for greener pastures.

There are many different types of training in addition to what most people think of first, which is usually formal classes. Senior analysts mentoring junior analysts can be one of the most useful types of training because it is very adaptable and can be very environment-specific. "Brown-bag" sessions where people get together over lunch and analyze a recent incident or learn how to more efficiently investigate incidents can also work well. Finally, when someone researches and learns new things on one's own or with coworkers as mentioned previously, that is also an excellent form of training. Load up a lab, attack it, and look at the traffic and resulting state of the systems.

Finally, do not forget about both undergraduate and graduate degrees. Though you may not consider them training, most people want to have the option open to either finish a degree or get an advanced degree in their off hours. There are a huge number of ways to provide training.

People versus Technology
Analysts are not the only ones that can overly rely on technology. Management will often take the stance that paying a bunch of money for tools and subscriptions means two things. One, that the systems must be what they need and will do all the work for them. Two, that the money means that the selling company has the systems optimally designed and configured for your environment. Just because you pay five or six digits for an IPS, IDS, anomaly detection, or forensics tools does not mean that you can presume a corresponding decrease in the amount you need to spend on people. Any tool is worthless without the right people using it.

Turnover, Retention, Mobility, and Having Fun
Creating and continuing a successful response team is to make sure the people you want to keep remain happy. There are a lot of things you need to retain the right people, including competitive pay, decent benefits, a chance for promotion, and a good work environment. Honestly, I think work environment is probably the most important factor. I know many analysts I have worked with receive offers of more money, but a good work environment has usually kept them from leaving. My boss has always said that the right environment is worth $X dollars to him, and I feel the same way. Effective and enjoyable coworkers, management that listens, and all the little things are not worth giving up without substantial reasons. Some opportunities are impossible to pass up, but having an enjoyable work environment and management that "gets it" goes a long way towards reducing turnover.

Bottom Line
I believe getting a good group assembled is the most important thing to have an effective response team. Obviously, I kept the focus of this post relatively broad. I would love to see comments with additional input. I hope to post additional material about building a response team in the near future, possibly covering organizing the team, dealing with growth, and a few other topics.

10 April, 2009

Upgrading to Snort 2.8.4

Hopefully, everyone running Snort has been paying attention and noticed that Snort 2.8.4 was released on 07 April and the corresponding new rule sets were released on 08 April. If you pay for Snort rules, the new netbios.rules will not work with Snort versions prior to 2.8.4, so you need to upgrade.

Upgrading was mostly painless just to get Snort running, though the dcerpc2 preprocessor settings definitely may require tweaking beyond the defaults. Generally, when I'm upgrading and there is something like a new preprocessor, I will start by getting Snort upgraded and successfully running with the defaults for the preprocessor, then will tune the settings as needed after I'm sure the new version is working.

The first thing to do after downloading and extracting is read the RELEASENOTES and also any applicable READMEs. Since the dcerpc2 preprocessor is new, the README.dcerpc2 may be of particular interest. A lot of people don't realize how much documentation is included.

$ wget http://www.snort.org/dl/snort-2.8.4.tar.gz
$ tar xzf snort-2.8.4.tar.gz
$ cd snort-2.8.4/doc
$ ls
AUTHORS README.alert_order README.ppm
BUGS README.asn1 README.sfportscan
CREDITS README.csv README.ssh
INSTALL README.database README.ssl
Makefile.am README.dcerpc README.stream5
Makefile.in README.dcerpc2 README.tag
NEWS README.decode* README.thresholding
PROBLEMS README.decoder_preproc_rules README.variables
README README.dns README.wireless
README.ARUBA README.event_queue TODO
README.FLEXRESP README.flowbits USAGE
README.FLEXRESP2 README.frag3 WISHLIST
README.INLINE README.ftptelnet faq.pdf
README.PLUGINS README.gre faq.tex
README.PerfProfiling README.http_inspect generators
README.SMTP README.ipip snort_manual.pdf
README.UNSOCK README.ipv6 snort_manual.tex
README.WIN32 README.pcap_readmode snort_schema_v106.pdf
The following is the default configuration as listed in the README.dcerpc2.
preprocessor dcerpc2_server: default, policy WinXP, \
detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
smb_max_chain 3
For some environments, it may be useful to turn off the preprocessor alerts or turn them off for specific systems.
preprocessor dcerpc2: memcap 102400, events none
Or:
preprocessor dcerpc2_server: default, policy WinXP, \
detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
smb_max_chain 3
preprocessor dcerpc2_server: net $SCANNERS, detect none
No matter what, the dcerpc configuration should be removed from the snort.conf and replaced with a dcerpc2 configuration for Snort 2.8.4.

After that, I'll configure and install Snort.
$  ./configure --enable-dynamicplugin --enable-inline --enable-perfprofiling
$ make
$ sudo /etc/rc.d/rc.snort-inline stop
$ sudo make install
$ which snort
/usr/local/bin/snort
$ snort -V

,,_ -*> Snort! <*-
o" )~ Version 2.8.4 (Build 26) inline
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
Copyright (C) 1998-2009 Sourcefire, Inc., et al.
Using PCRE version: 7.7 2008-05-07

$ sudo /etc/rc.d/rc.snort-inline start
Starting snort-inline
Initializing Inline mode
building cached socket reset packets
Although the old netbios.rules will still work with the new version, it's also time to update to the latest rules to take advantage of the smaller number of netbios.rules. Note that this only applies for subscription rules since the free ones won't reflect the changes for 30 days.

Some of the rules in the new netbios.rules file have SIDs that were unchanged, so I decided to re-enable any of those that I had previously disabled in my oinkmaster.conf. I can always disable them again, but with the new preprocessor and possible changes to the remaining SIDs, I decided it was best to reevaluate them.

Since I'm also using precompiled shared object rules, I also update from the ones compiled for 2.8.3.2 to the ones compiled for 2.8.4. I keep the rule stubs in a directory along with symlinks to the corresponding SO files, so I simply remove the symlink and recreate it to the new SO rules.
$ rm /etc/snort/so_rules/*so
$ ln -s /etc/snort/so_rules/precompiled/CentOS-5.0/i386/2.8.4/*so /etc/snort/so_rules/

09 April, 2009

Watching the watchers

The Washington Post had an article on the Federal Page about falsified security clearance checks.

Half a dozen investigators conducting security-clearance checks for the federal government have been accused of lying in the reports they submitted to the Office of Personnel Management, which handles about 90 percent of the background inquiries for more than 100 agencies.

Federal authorities said they do not think that anyone who did not deserve a job or security clearance received one or that investigators intentionally helped people slip through the screening. Instead, law enforcement officials said, the investigators lied about interviews they never conducted because they were overworked, cutting corners, trying to impress their bosses or, in the case of one contractor, seeking to earn more money by racing through the checks.

This is not particularly surprising, especially when you consider that the article reports a 22 percent increase in security checks since 2006. Presumably, the personnel and budget allocations did not get a corresponding 22 percent increase. Even before 2006, there were plenty of reports about the backlog for security investigations. Factor in the increase in investigations and you have a situation ripe for abuse through shortcuts.

The problem shows the importance of management and quality assurance. Through the fairly simple process of sending follow-up questionnaires to 20 percent of those that were interviewed, OPM was able to identify falsified interviews and investigations. GAO also has determined that 90 percent of a sampling of reports were missing at least one required document. These seem like fairly easy and accurate ways to determine whether the investigations were being completed properly.

Fixing the problem is another matter, but you can't fix a problem until you've identified it. Prosecuting the responsible investigators, reviewing allocation of funds and personnel, and changing compensation structure are all just a few things that may help reduce the amount of fraud.

The personnel problem immediately jumps out when you see the numbers in the article, which lists 1380 staff investigators and 5400 contractors doing 2 million investigations last year. You have to assume that even the most basic clearance requires a minimum of a credit check, criminal background check, employment history check, and some type of interview. I don't know how 292 investigations per investigator per year could possibly be exhaustive enough to provide the needed information.

It also seems to demonstrate that the number of people requiring clearances is excessive, which is really a whole different discussion.

26 March, 2009

Slackware-current updates and Nvidia driver

I recently updated a desktop running Slackware-current to the latest packages released up to 24-Mar-2009. There were a few minor issues. The first is that, if using slackpkg to upgrade, I had to upgrade the findutils package before everything else or slackpkg would no longer work properly.

# slackpkg update
# slackpkg upgrade findutils
# slackpkg upgrade-all
The second was that I couldn't install the Nvidia driver for the new 2.6.28.8 kernel package because it was failing.
ERROR: The 'cc' sanity check failed:

The C compiler 'cc' does not appear able to
create executables. Please make sure you have
your Linux distribution's gcc and libc development
packages installed.
It turns out that gcc-4.3.3 in slackware-current depends on mpfr.
# slackpkg info mpfr

PACKAGE NAME: mpfr-2.3.1-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 348 K
PACKAGE SIZE (uncompressed): 930 K
PACKAGE DESCRIPTION:
mpfr: mpfr (Multiple-Precision Floating-Point Reliable Library)
mpfr:
mpfr: The MPFR library is a C library for multiple-precision floating-point
mpfr: computations with exact rounding (also called correct rounding).
mpfr: It is based on the GMP multiple-precision library.
mpfr: The main goal of MPFR is to provide a library for multiple-precision
mpfr: floating-point computation which is both efficient and has
mpfr: well-defined semantics. It copies the good ideas from the
mpfr: ANSI/IEEE-754 standard for double-precision floating-point arithmetic
mpfr: (53-bit mantissa).
mpfr:

# slackpkg install mpfr
After installing mpfr, I was able to compile the Nvidia module for the running kernel.

Finally, kdeinit4 was failing with an error about loading the libstreamanalyzer.so.0 and libqimageblitz.so shared libraries. I fixed this by installing strigi and qimageblitz.
# slackpkg info strigi

PACKAGE NAME: strigi-0.6.3-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 904 K
PACKAGE SIZE (uncompressed): 2570 K
PACKAGE DESCRIPTION:
strigi: strigi (fast and light desktop search engine)
strigi:
strigi: Strigi is a fast and light desktop search engine. It can handle a
strigi: large range of file formats such as emails, office documents, media
strigi: files, and file archives. It can index files that are embedded in
strigi: other files. This means email attachments and files in zip files
strigi: are searchable as if they were normal files on your harddisk.
strigi:
strigi: Homepage: http://strigi.sourceforge.net/
strigi:

# slackpkg info qimageblitz

PACKAGE NAME: qimageblitz-r900905-i486-1.tgz
PACKAGE LOCATION: ./slackware/l
PACKAGE SIZE (compressed): 82 K
PACKAGE SIZE (uncompressed): 240 K
PACKAGE DESCRIPTION:
qimageblitz: QImageBlitz (Graphical effect and filter library for KDE4)
qimageblitz:
qimageblitz: Blitz is a graphical effect and filter library for KDE4.0 that
qimageblitz: contains many improvements over KDE 3.x's kdefx library
qimageblitz: including bugfixes, memory and speed improvements, and MMX/SSE
qimageblitz: support.
qimageblitz:

# slackpkg install strigi qimageblitz
After those minor issues, I had KDE4 up and running with the latest Nvidia driver.

12 February, 2009

Snort 2.8.4 has a new DCE/RPC preprocessor

According to the VRT blog, Snort 2.8.4 is going to have a new DCE/RPC 2 preprocessor. The README.dcerpc2 was not included in the first release candidate for 2.8.4, but a follow-up on the snort-users list included it. The README covers a lot of information, and is definitely useful to understand the changes and configuration options.

These changes look to be an improvement, but they also have the potential to cause a lot of work and heartache in the short term for Emerging Threats and Snort users. From the VRT blog:

This preprocessor handles all the decoding functions that were previously taken care of using rules and flowbits in a lot of those rules. The upshot is that the number of netbios rules released for any vulnerability that can be exploited over dcerpc is going to be reduced greatly. The number of netbios rules previously released is also going to be reduced in a similar manner.

The downside is that this functionality is only available in Snort 2.8.4 with the dcerpc2 preprocessor. There is no backwards compatibility. Also, a number of netbios rules will be deleted and replaced.
Snort users are going to have to make sure to properly configure the new version. I know from the snort-users mailing list that far too many people use old versions of Snort, so this causes them problems. Realistically, there is usually no reason to use older versions rather than the latest stable release.

Emerging Threats distributes quite a few NetBIOS rules, so I'm sure the new preprocessor will also have an effect on Emerging Threats rules. I seriously doubt that either VRT or Emerging Threats wants to maintain a set of rules for 2.8.4 and above, plus another set for older versions. If I'm interpreting Nigel's blog post correctly, it seems that VRT is going to force the issue by only issuing new and updated NetBIOS rules for 2.8.4 and above. Assuming the improvements in the preprocessor are as stated, I think that is the right choice, but lots of users are going to complain.

08 February, 2009

Shmoocon 2009 Notes

I attended Shmoocon V over the weekend and had a good time as usual. There are always interesting people, the usual suspects, and some good talks. I think Shmoocon is still a great conference for the money. The bags given to attendees this year were by far the best of the four years I've been. There were some very good entries to the Barcode Shmarcode contest and I also saw some entertaining runs through the lockpick contest.

These notes do not include every time slot.

Friday

1500: Bruce Potter started the con with his opening remarks. He said that Shmoocon added around 500 tickets this year, bringing the total number of attendees above 1600. To have enough space, they had to add another room down the hall from the main area. The satellite room was out of sight of the main area, but not too difficult to find. Potter said that moving to the next larger space available instead of adding the one room would have been overkill and cost too much for the number of attendees.

One of the things I really like about Shmoocon is their involvement in charities. As usual, tshirt proceeds went to charities, in this case the buyer's choice between the EFF and Johnny Long's Hackers for Charity. Shmoocon also had a raffle with proceeds going to Covenant House, as did the proceeds from the Hacker Arcade. It is nice to see Bruce and other Shmoocon organizers promoting charity among their peers.

Potter often will make a small comparison between Shmoocon and other conferences, and this year he mentioned other conferences charging large amounts for training. Conversely, at Shmoocon if you want to learn something in a non-classroom environment, you can try to participate in Shmoocon Labs to help build a functional enterprise-like environment rather than just slapping together a simple wireless network. As an example, this year they had an open wireless network, a WPA-enabled wireless network, and third using RADIUS. All attendees are welcome to walk through the room serving as their NOC and ask questions.

I really like The Shmoo Group's philosophy when it comes to running a conference. They try to be very transparent and take feedback, don't overcharge, and just generally want everyone to have a great time while still providing good technical content. It's a really attendee-friendly conference, right down to the 0wn the Con talk near the end.

Finally, Potter went on a rant about how security isn't working. Nothing to see here, move along. ;)

1600: The first technical talk I heard was Matt Davis and Ethan O'Toole presenting Open Vulture - Scavenging the Friendly Skies Open Source UAV Platform. Open Vulture is a software application and library designed to control unmanned vehicles. It was a neat talk though not a topic I know much about. Some of the possible uses for this would be controlling an unmanned vehicle to sniff wireless networks or take photos. They even have a GPS navigation module.

Saturday

Saturday is always the meat of the conference since it is the only full day and most people haven't been there long enough for the late nights to catch up to them.

1000: I enjoyed Matt Neely's presentation, Radio Reconnaisance in Penetration Testing. Matt had a lot of practical advice for radio reconnaisance, including recommending some relatively inexpensive hand-held scanners, the AOR 8200, Uniden Bearcat BCD396T, and the Uniden Bearcat SC230, which also happens to be a good choice for NASCAR. He pointed out what features to look for in scanners, for example channel memory.

His anecdotes from penetration tests included sniffing wireless headsets from blocks away, even when the phone is hung up. Apparently, many wireless headsets transmit constantly even if on the cradle, effectively functioning like a bug for eavesdropping. He has also used video converters when sniffing video.

When testing a client's casino, he visually scouted the location to help identify their hand-held radios, and then was able to get information from casino security through their radio communications, including their radio link to the police. He got a ton of information useful for social engineering and more, like guard names, the dispatcher's name, times of shift changes, and the lingo used by the guards.

At another client site, he noticed people using wireless headsets and got those added to the rules of engagement. Once they were added, he was able to eavesdrop on calls to the help desk for password resets, people calling their voicemail, and found that the headsets would keep transmitting even when the phone was hung up. Matt was able to get passwords, voicemail passwords, and assorted Personally Identifiable Information (PII) that was sensitive or could be used for social engineering. Rules of engagement and adhering to applicable laws are very important if you don't want to end up in jail after eavesdropping on voice communications.

I also talked to Neely the next day regarding learning about RF for a personal project I am interested in. He was very helpful and nice, just like most Shmoocon presenters I've ever spoken with. Hopefully, I will have time to start learning more about RF and playing around with it for a "fun" project.

1100: Next, I attended Fail 2.0: Further Musings on Attacking Social Networks presented by Nathan Hamiel and Shawn Moyer. Their talk was fun and definitely relevant. Their main focus was that "social engineering + vulnerabilities in social networks = ROI". They pointed out a number of ways to manipulate various social networking sites, including malicious code like IMG to CSRF, CSS javascript hijacking, and request forgeries (POST to GET).

One good anecdote was getting permission from Marcus Ranum to make a phony profile in his name and then using it to socially engineer others, particularly security professionals, on a social networking site. They actually got Ranum's sister to attempt to contact them through the phony profile.

Hamiel and Moyer demonstrated technical tricks to force someone to "friend" you and also posting a comment with code that will force the user to log out, effectively denial-of-servicing the person off his or her own profile. They also told anecdotes about posing as a recruiter, joining groups on LinkedIn so they could more easily build up a lot of connections, then looking for candidates with government security clearances and getting many responses to their inquiries.

1400: I skipped the 1200 talks to have a long lunch with some friends, then attended Jay Beale's Man in the Middling Everything with the Middler. The talk had a very slow start because of audience interaction, particularly involving Shmooballs and launchers.

Jay Beale's Middler is a tool to help leverage man-in-the-middle attacks, including injecting javascript, temporary or permanent redirects, session hijacking, and more. It seems like a neat tool and was released to the public at his talk. Jay pointed out some dangers of mixed HTTP and HTTPS sites and their vulnerabilities to things like injected javascript, stored session keys, intercepted logout requests, and replacing HTTPS links in proxied pages with HTTP links. Although the Middler has some specific support right now for attacking social networking sites and wide area sites like Google/GMail and live.com, it uses a plugin architecture so we should expect to see more plugins targeting specific sites.

1600: I had heard a good talk last year by Enno Rey and Daniel Mende, and combined with my focus on network security monitoring I definitely was interested in their presentation this year, Attacking backbone technologies. Their main focuses this year were BGP, MPLS, and Carrier Internet, one example of the latter being Carrier Ethernet. They were careful to point out that you really have to be part of the "old boys club" of trusted backbone providers to successfully use most of their attacks and that not just anyone would have enough access to core backbones to download their tools and use them for successful penetration testing or attacks.

For BGP, they mentioned that it is mostly manually configured, thus making it susceptible to simple mistakes like the famed AS7007 incident or the Youtube/Pakistan blocking incident. Rey and Mende also did a live demonstration using their "bgp_cli" tool to inject routes, and demonstrated how a single BGP packet signed with MD5 can be used to crack rather than brute forcing directly against a router that limits the number of attempts per second.

Multiprotocol Label Switching (MPLS) is deployed on carrier backbones and uses a trusted core assumption while attacks from outside the core are not possible. Rey and Mende demonstrated their "mpls_redirect" tool to modify MPLS Layer 3 VPN labels and redirect traffic. This is possible in part because of trusting carrier insiders and can be used to send traffic to different customer networks. Rey had a great line where we called it "branching" the traffic because he was told, due to his thick German accent, he should not use the word "forked" (or "fokt" as it sounded when he said it).

These two definitely are in a position to test the security of major providers from an insider perspective, which is not the norm, and they do a good job explaining some of the issues they find.

1700: David Kennedy's Fast-Track Suite: Advanced Penetration Techniques Made Easy was probably the most crowded presentation I attended. One suggestion I have for getting a good seat at Shmoocon is to plan your schedule ahead and note the presentations that are likely to be crowded. If you are not changing rooms, do not get up and lose your seat, because rooms definitely end up standing room only sometimes.

Kennedy was a good presenter. When you have fun on the podium, it definitely shows and keeps everyone attentive. He had a lot of audience participation as he showed a slide and said "Let's Pop a Box" each time before he used Fast-Track to own a system. When he started to forget "Let's Pop a Box," someone from the audience would invariably ask him if he forgot something or shout "Pop a Box!" as Kennedy did a face-palm.

Fast-Track itself is obviously pretty neat. He showed a variety of automated attacks against different targets that most often ended with a reverse shell back or reverse VNC back to his attacking system. He also talked about his evasion technique using Windows debug to download his stager, which is actually just a version of Windows debug without the 64k size limit.

Fast-Track 4.0 includes some new features like logging and payload conversion so you can load your own payloads to deliver. Although Fast-Track has a smaller list of exploits than Metasploit, Kennedy said that he strives to make them available across as many OS versions as possible. Version 4.0 also includes a mass client attack using ARP poisoning combined with emailed links to targets. The malicious page will display a generic "loading please wait..." message as it launches a multitude of attacks, but Kennedy said that 4.1 will also include browser profiling for more targeted exploits. One really nice feature is the auto-update to update a multitude of tools included in Fast-Track. Although I didn't look into it yet, I did wonder if it had any SNMP attacks and I think a SNMP auto-own attack would be a neat and not too complicated addition if it's not there yet.

Sunday

1000:
I really feel for anyone in this time slot. After a weekend of hacking and partying, the number of people in any room is much smaller than the number of people at 1000 on Saturday. The numbers increase as people drag themselves into the talks through the hour.

I attended Re-Playing with (Blind) SQL Injection by Chema Alonso and Palako during this hour. I was starting to think I made the wrong choice because they started off slow and quite dry, but maybe they were included in the ones recovering from the previous night's festivities. By the second half, they started to have a little fun and had some funny moments, including a slide with, "Yes, we can!" Another funny moment was when they found a database username length of two and referred to it as "the most famous Microsoft SQL user..."

Although we've all probably seen or read about blind SQL injection before, they did have some interesting techniques and used their Marathon Tool to ease the tedious nature of blind SQL injection. One thing I liked was their method of using timing to seperate a True answer page from a False answer page if there is no visible or code difference. Most SQL engines have slightly different supported methods to introduce time-based blind SQL injection so a response that is timed above a certain value can be considered true. Even those that don't include time-delay functions can be leveraged with by running a "heavy" query only if a "light" query first returns as true. An example of a heavy query that would slow the response after a successful light query is multiple cross-table joins.

Alonso and Pakato also did a good job answering questions. They definitely seemed more comfortable by the end of their presentation.

1100: Chris Paget is a very entertaining presenter and clearly had fun showing off his RFID reader during EDL Cloning for Under $250. He demonstrated how easy it is to read, clone, and write RFID cards created as part of the Western Hemisphere Travel Initiative. By design, these cards are supposed to be readable from 30 feet but it is trivial to read them at more than 200 feet and much longer distances, possibly around half a mile, should be possible. The cards also have no encryption or authentication.

Paget was able to buy an enterprise-level card reader by Motorola on eBay. Although he needed to perform some repairs on the RFID reader, the whole sniffing setup was only around $250. The card reader has no real security mechanisms for logon and listens on port 3000.

There are no federal anti-skimming laws to prevent RFID skimming/sniffing, though CA and WA states do have laws. Paget was able to grab a lot of information through war driving with his setup and pointed out that correlation means the cards can provide more than just an anonymous number. For instance, if you detect the same card tag twice you could compare it to photos to see whose face you saw twice. You could also correlate against other data like credit cards containing RFID to figure out which data belonged to which person.

Eventually as RFID cards become more common, this could present more serious issues like collecting tons of RFID card data until you get one where the person's appearance is close enough that you could use his identity, or terrorists could use it to identify targets in a crowd.

Paget stated that the supposed purpose for the cards was to enhance security, which clearly is a failure, and also to speed border crossings, which also has been a failure since users still have to present their cards directly. Paget believes that WHTI is broken but that RealID could be an alternative if it was revamped to fix all the serious problems. Ideally, among other recommendations, he advocates a contact smartcard rather than one that can be read remotely.

Another Shmoocon in the books. Thanks to the Shmoo Group, speakers and attendees for a good time.