So, in conjunction with the BlueHat team, I am pleased to announce that the SDL team will be organizing the sessions for the second day of the fall BlueHat conference. The BlueHat SDL sessions will be laser-focused on not just describing vulnerabilities but also solving them. Every attendee should leave every presentation with a clear idea of exactly what he or she needs to do to protect themselves from the threat that was discussed during the session.

The sessions will begin, appropriately, with the topic of secure design. Danny Dhillon of EMC and the SDL team’s own Adam Shostack will each present their organization’s approach to threat modeling. As a bonus, Adam will also be demonstrating the new SDL Threat Modeling tool that you might have heard about last week.

Next up is Matt Miller, a recent and very welcome addition to the Microsoft Security Science team. Matt has a fantastic presentation on the evolution of buffer overflow attacks and on the corresponding development of overflow mitigations. From there we will switch gears to look at some managed code implementation issues: iSEC Partners’ Scott Stender and Alex Vidergar will demonstrate coding techniques to mitigate elusive concurrency vulnerabilities in web applications.

At this point we will have covered the Design and Implementation phases of the SDL; where better to go from here than Verification? One of the most important activities in the Verification phase is fuzzing, and we have a trio of security experts from the Microsoft Security Science team to talk about it. Jason Shirk, Lars Opstad, and Dave Weinstein will answer three of the most common fuzzing questions: How should I fuzz? When have I fuzzed enough? And what do I do now that I’ve fuzzed?

Finally, we will wrap up the Verification phase talks with a return appearance to BlueHat by Stach & Liu’s Vinnie Liu. Vinnie will compare different approaches to security verification – static code analysis, blackbox analysis, and manual code review – and make recommendations as to when each approach is best used.

Even if you can’t make it in to BlueHat in person, you can still watch the sessions via streaming media on TechNet. Additionally, webcast interviews with the speakers – condensed “Cliff’s Notes” versions of their full presentations – will be posted on Channel 9. And we’ll be continuing the BlueHat tradition of inviting speakers and other industry notables to guest blog about their topics and the latest security trends. More information on all of these resources will be posted here when it becomes available.

So, Anton Security Tip of the Day #16: Virtually Screwed - Journey Into VMWare ESX Log Analysis

CISecurty guide for VMWare (here) and DISA STIG for virtual machines (here) both mandate collection and analysis of VM platform logs; none goes into enough details on what to look for in logs. Let's try to shed some light on security-focused log analysis of VMWare ESX v. 3.x logs.

First, at least until ESXi becomes the default choice, one needs to keep in mind that ESX as "Linux-inside" and thus diving into /var/log will not reveal any "alien technology" (well, not much :-)). However, one of the most useful logs is /var/log/hostd.N which is not a descendant of Linux standard logs. Extensive VM event records are written into this file.

Let's focus on various types of logins to the ESX platform and identify logs that indicate a successful and failed attempts to log in. Here are a few useful examples to analyze:

Successful logins:

• May 30 09:20:42 esx2 su(pam_unix)[9405]: session opened for user root by jhonny(uid=1626)

This is a classic Linux root login message; you can watch for these by searching VMWare ESX logs for "session AND opened AND user AND root."  Notice the user name of the user who switched to root.

• May 30 09:20:34 esx2 sshd(pam_unix)[9364]: session opened for user jhonny by (uid=0)

This is also a classic Linux message for a normal (non-root) user login.

• [2008-05-25 06:57:48.774 'ha-eventmgr' 111639472 info] Event 40645 : User jhonny@1.1.1.1 logged in

This is a VMWare -specific application login to ESX. You can track such events by username, by event ID or by keywords "event AND logged AND user" (if you are using search)

Failed logins:

• May 30 09:20:31 esx2 sshd[9356]: Failed password for jhonny from 1.1.1.1 port 54773 ssh2

Another classic Linux message from the ESX system; a failure to login due to incorrect password.

• May 27 12:06:59 esx2 sshd[4756]: Failed password for illegal user jonny from 1.1.1.1 port 30594 ssh2

A message indicating a failure to login due to incorrect username (note a typo).

• May 25 07:03:48 esx1 sudo:     jhonny : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/var/log ; USER=root ; COMMAND=/bin/bash

This ESX Linux platform message should also be familiar to Linux/Unix admins: it indicates multiple sudo password failures; look for such messages in the logs.

BTW, do you need to be reminded to track NOT only failed, but also successful login events?!

Overall, you must prepare for the future by learning to analyze  VMWare logs, just like you handled "legacy OS", such as Linux/Unix and Windows.

As I said before, I am tagging all the tips on my del.icio.us feed; here is the link: All Security Tips of the Day.

The conversation went well, I thought, until I received a call from another person in the company who proceeded to tell me how to do business in Thailand and how to determine the target market, and how to set up sales. Now mind you, I had already explained that there would be no immediate sales opportunities for a few years, realistically, and that this was a long term initiative, designed around a solid education and training program - build infrastructure first. From a strong education and training program, the market would become clear.

This is such a simple win-win-win situation, but companies do not seem to understand it. They just want to exploit every contact, event situation, for a quarterly sell. Why not take the long view as well, since it does not cost you any money?

The guy on the other end of the phone would have nothing to do with our way of thinking in Thailand. He seemed to be pushing to insure pre-sales contact immediately. Instead of supporting us, he wanted to manage us from overseas!! We asked for support to build their brand, what they seemed to offer was management by proxy!

Folks, this will not work in Thailand (or most Asia countries).

If you want to tap into the fast growing Asia market, leave behind your aggressive New York or Silicon Valley sales guns and forceful presale tactics, where you are content to find an opening, exploit it, make a sale, and report the sale on your quarterly report. You can get aggressive when you have built a sustainable infrastructure. The same is true in Japan, not only Thailand.

In Asia, do as the Asians. In Rome, do as the Romans. In Thailand, do as the Thais. In Japan, do as the Japanese.

It is easy to make money in Thailand (and other Asia countries) if you follow their way of business. Educate, teach, build a workforce, build a sustainable infrastructure on the ground, and then sell, sell, sell.

Granted, many companies do not have resources to do this overseas. In that case, enable your partners to do it and let them build the business; don’t manage them, support them.

For Immediate Release

The very first of the speaker slots for The Last HOPE have been announced with many more to come next week. We have had more submissions than ever and will need to add an additional track in order to accommodate the best of them. What follows are some of the highlights to date.

- Steven Levy, author of Hackers: Heroes of the American Revolution and chief technology writer and a senior editor for Newsweek.

- Adam Savage, co-host of the popular TV show Mythbusters and “a maker of things.”

- Kevin Mitnick, “the world’s most dangerous hacker” in the eyes of the government and mass media, imprisoned for over five years, and now a successful computer security consultant.

- Jello Biafra, a tradition at the HOPE conferences, former lead singer of The Dead Kennedys and one of America’s most interesting social activists.

- Steven Rambam, private eye extraordinaire, who can find out anything about anybody and has always been willing to share his knowledge of privacy with the hacker community. (The FBI prevented his 2006 talk from being given by swooping in and arresting him moments earlier. The case against him was later found to have no merit.)

These five speakers are only the tip of the iceberg. By the time the dust settles, we expect to have over 100 presentations in four tracks. While time is now quite short, if you feel you have an amazing talk idea or panel suggestion, you can still email us at speakers@hope.net. We will try and schedule as many good talks as we can cram into the weekend.

The Last HOPE will take place from July 18-20, 2008 at the Hotel Pennsylvania in New York City.

To preregister, visit http://store.2600.com/lasthope.html
To submit a speaker proposal, email speakers@hope.net
To become a vendor, email vendors@hope.net
To volunteer to help us run the conference, email volunteers@hope.net
To visit the official Last HOPE website, go to http://www.hope.net

Contact: HOPE Staff +1 631 751 2600
hope@hope.net

… and since I’m temporarily in charge — shwag is only available to those who recognize me.

Tags: the last hope, hacker conferences, 2600 magazine

So, Anton Security Tip of the Day #15: Fear and Loathing in Event 567

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?

First, why are we doing this? We typically need to know the following when we audit file access in Windows (or any other OS for that matter) for security (monitoring and investigation) or compliance:

• Time/date
• Computer where it happened
• User who touched the file
• Application he used to access the file
• File name + location (directory, share, etc)
• Type of access (read, write, create, delete, etc)
• Status (i.e. success or failure)

Can we get this from the above logs? No.

What? No!?! Really?

Yes, really. We can get some of the above, some of the time, not all of the above, all of the time. Here is an example, we are looking at event ID 560 (picture) and then at an extract from its description field.

Event:

Description (selected field):

Object Server: Security

Object Type: File

Object Name: C:\0\TestBed\simple_text_file.txt

Image File Name: C:\WINDOWS\system32\notepad.exe

Primary User Name: Anton

Primary Domain: XXXXXX

Accesses: READ_CONTROL

SYNCHRONIZE

ReadData (or ListDirectory)

WriteData (or AddFile)

AppendData (or AddSubdirectory or CreatePipeInstance)

ReadEA

WriteEA

ReadAttributes

WriteAttributes

WTH is that? Well, we know that the user  'Anton' has successfully read? wrote? changed attributes? did something? with a file named "C:\0\TestBed\simple_text_file.txt" using a program named "C:\WINDOWS\system32\notepad.exe." That's the best we can get, in this case! We may try to look at event IDs 562 and 567, but this missing information (i.e. the exact action performed) will not be added.

BTW, there will be  a few more dozen (sometime hundreds!) of the 560s, 562s and 567s  produced - all from just opening the text file in a notepad. The above event is notable for having BOTH "notepad" and "simple_text_file.txt" in the same event; others will have either of the two.

Anything else gets in the way? Yes, lots! MS Office will write to all files, even just opened for reading (with no user modifications to the content whatsoever), which will screw up your log monitoring efforts. If the file is on a share, more information will be missing (e.g. username might be).

So, how to use Windows event logs for file access tracking?

1. Enable logging (as described above)
2. Pick events 560 (most useful) and 562, 567 (useful too)
3. Look for fun filenames that might be touched by the users (have a list of files and users handy)
4. Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
5. Ponder the 'Accesses' section of each event until your brain turns blue :-) or until you decide whether such access is authorized or not...

Overall, this is still very useful for file access monitoring, but the process is paaaaaainful.

BTW, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Following the tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #14: More access_log Fun: What Are You Not GETting?

In this tip, we will look at some bizarre artifacts that show up in web server access logs today. Here we have a production log from an Apache web server that is full of interesting (and sometimes ominous!) little mysteries that we will investigate in order to determine their impact on security and operational health of the site.

Logs do contain more mysteries than we have time, so we will focus on a few of them: specifically, unusual web request methods.  Let's see who is trying to POST or use some other method (OPTIONS, HEAD, PUT or something - see a list here) on our site, instead of just GET'ting the content (GET command is used by web browsers to retrieve the pages, while POST is used to upload content, press buttons, etc  - at least in "web 1.0" land  - see earlier tip #12 where POST request was found in proxy logs)

Here is one little artifact that attracted my attention due to a POST request vs a web forum as well as a battery of slashes (which actually increases in subsequent request - of which there were many)

10.10.102.250 - - [12/Feb/2008:16:10:50 -0500] "POST /phpBB3////ucp.php?mode=register&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 14397 http://www.example.com/phpBB3///ucp.php?mode=confirm&id=7640df05c7e24b7acf7a68800fe6dc59&type=1&sid=e5efaa77a777066c61f71808e9e57b19 "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"

... more...

10.10.102.250 - - [12/Feb/2008:16:12:29 -0500] "POST /phpBB3///////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 9355 "http://www.example.com/phpBB3//////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19" "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"

This one really is a mystery; what do we know about it? The server responded to the request OK (code 200), so the POST actually happened. The first request was a request to register with a web discussion board and the second was a request to login. Multiple slashes are  actually ignored  by the web server, so why put them in the request (no answer)? Also, I think that the User-Agent is spoofed ... do you know why? Finally, if I see something like that in my logs, I will definitely investigate it, primarily due to the fact that Apache responded with 200 OK code.

The next one is so classic it it dumb (and so dumb, it's a classic :-))

10.10.123.226 - - [12/Feb/2008:03:46:54 -0800] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"

10.10.123.226 - - [12/Feb/2008:03:46:55 -0800] "OPTIONS / HTTP/1.1" 200 20210 "-" "Microsoft Data Access Internet Publishing Provider Protocol Discovery"

It is probably one of the ancient IIS attacks (check out this fun BlackHat preso on that, circa 2003) - why would someone probe for it now is beyond me. In any case, Apache on Linux and "*.exe" don't mix :-)

The final log record is also fun:

10.10.101.222 - - [12/Feb/2008:15:33:22 -0800] "PUT /zk.txt HTTP/1.0" 405 223 "-" "Microsoft Data Access Internet Publishing Provider DAV 1.1"

The above uses a PUT request which is pretty much deprecated now; the purpose of the above is clearly malicious. In fact, modern Apache shouldn't even allow it, thus it responds with code 405 "Method Not Allowed." Nothing to worry about (even though some poor critter got owned with that! BTW, if you follow that link, check out HTTP response code 201 - if you see it in your logs, run! :-))

Overall, if you see too many POSTs or too many "GET then POST" sequences from the same IP in rapid succession, investigate it since no legitimate access should produce such a pattern...

As further reading, I heartily recommend this paper: "Detecting Attacks on Web Applications from Log Files"

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Rolling Stone has this excellent article on the topic, about the Joint Terrorism Task Forces in the U.S.:

But a closer inspection of the cases brought by JTTFs reveals that most of the prosecutions had one thing in common: The defendants posed little if any demonstrable threat to anyone or anything. According to a study by the Center on Law and Security at the New York University School of Law, only ten percent of the 619 "terrorist" cases brought by the federal government have resulted in convictions on "terrorism-related" charges -- a category so broad as to be meaningless. In the past year, none of the convictions involved jihadist terror plots targeting America. "The government releases selective figures," says Karen Greenberg, director of the center. "They have never even defined 'terrorism.' They keep us in the dark over statistics."

Indeed, Shareef is only one of many cases where the JTTFs have employed dubious means to reach even more dubious ends. In Buffalo, the FBI spent eighteen months tracking the "Lackawanna Six" -- a half-dozen men from the city's large Muslim population who had been recruited by an Al Qaeda operative in early 2001 to undergo training in Afghanistan. Only two lasted the six-week course; the rest pretended to be hurt or left early. Despite extensive surveillance, the FBI found no evidence that the men ever discussed, let alone planned, an attack -- but that didn't stop federal agents from arresting the suspects with great fanfare and accusing them of operating an "Al Qaeda-trained terrorist cell on American soil." Fearing they would be designated as "enemy combatants" and disappeared into the legal void created by the Patriot Act, all six pleaded guilty to aiding Al Qaeda and were sentenced to at least seven years in prison.

In other cases, the use of informants has led the government to flirt with outright entrapment. In Brooklyn, a Guyanese immigrant and former cargo handler named Russell Defreitas was arrested last spring for plotting to blow up fuel tanks at JFK International Airport. In fact, before he encountered the might of the JTTF, Defreitas was a vagrant who sold incense on the streets of Queens and spent his spare time checking pay phones for quarters. He had no hope of instigating a terrorist plot of the magnitude of the alleged attack on JFK -- until he received the help of a federal informant known only as "Source," a convicted drug dealer who was cooperating with federal agents to get his sentence reduced. Backed by the JTTF, Defreitas suddenly obtained the means to travel to the Caribbean, conduct Google Earth searches of JFK's grounds and build a complex, multifaceted, international terror conspiracy -- albeit one that was impossible to actually pull off. After Defreitas was arrested, U.S. Attorney Roslynn Mauskopf called it "one of the most chilling plots imaginable."

Using informants to gin up terrorist conspiracies is a radical departure from the way the FBI has traditionally used cooperating sources against organized crime or drug dealers, where a pattern of crime is well established before the investigation begins. Now, in new-age terror cases, the JTTFs simply want to establish that suspects are predisposed to be terrorists -- even if they are completely unable or ill-equipped to act on that predisposition. High-tech video and audio evidence, coupled with anti-terror hysteria, has made it effectively impossible for suspects to use the legal defense of entrapment. The result in many cases has been guilty pleas -- and no scrutiny of government conduct.

In most cases, because no trial is ever held, few details emerge beyond the spare and slanted descriptions in the indictments. When facts do come to light during a trial, they cast doubt on the seriousness of the underlying case. The "Albany Pizza" case provides a stark example. Known as a "sting case," the investigation began in June 2003 when U.S. soldiers raided an "enemy camp" in Iraq and seized a notebook containing the name of an imam in Albany -- one Yassin Aref. To snare Aref, the JTTF dispatched a Pakistani immigrant named Shahed "Malik" Hussain, who was facing years in prison for a driver's-license scam. Instead of approaching Aref directly, federal agents sent Malik to befriend Mohammed Hossain, a Bangladeshi immigrant who went to the same mosque as Aref. Hossain, an American citizen who ran a place called Little Italy Pizzeria in Albany, had no connections whatsoever to terrorism or any form of radical Islam. After the attacks on 9/11, he had been quoted in the local paper saying, "I am proud to be an American." But enticed by Malik, Hossain soon found himself caught up in a government-concocted terror plot. Posing as an arms dealer, Malik told Hossain that a surface-to-air missile was needed for an attack on a Pakistani diplomat in New York. He offered Hossain $5,000 in cash to help him launder $50,000 -- a deal Hossain claims he never properly grasped. According to Muslim tradition, a witness is needed for significant financial transactions. Thus, the JTTF reached out for Hossain's imam and the true target of the sting -- Aref.