Slick New Logo!

We updated our logo at WhiteHat Security. I was really fond of the old one, but the new one turned out to be pretty slick!

The New

The Old

PCI enforcement is about money

There's been a lot of PCI chatter going on the blogosphere, and having followed the standard for years now, I figured I'd toss in my .02c via SC Mag.

Firms seeking PCI compliance face dilemma
"Like the laws of the land, the impact of industry regulation is dictated by the capability to enforce regulatory law. Manpower and funding are required. Without resources available, laws and regulations don’t matter much. In the U.S., our roadways are maintained and kept safe, marked with street signs, lined with guardrails and patrolled by law enforcement with funds collected from drivers’ license and vehicle registration fees. The cost of enforcement is what drives adoption and someone has to cough up the cash. The question for PCI-DSS is: who?"

two woots on the horizon

Firefox 3 to support httpOnly cookies and Apple removes javascript support in QuickTime.

Sure, its not much, but its something!

Make that three woots.

Mozilla is making Improvements to help protect against Cross-Site Scripting attacks

Jikto, crossing the line?

Another Update: Robert McMillan from IDG describes how the Jikto leak occurred in some detail, including some quotes from Mike Schroll, who originally snagged the code and posted it to Digg.

Update: via sla.ckers.org RSnake posted that the source code to Jitko did in fact make its public debut. I checked with Billy on the authenticity of the code, he verified it, and also explained how the leak occurred. Was bound to happen eventually, but its surprising how fast.

Update: Billy has more to say about his conference experience with Jikto and about me personally.

Update: Billy sets us straight in his ShmooCon post: "The first part of my presentation will provide an overview of all these new advanced threats. Specifically, how this attacks work and how they can be prevented. In the second half I’ll discuss how JavaScript is capable of crawling and auditing 3rd party websites just like a traditional web scanner. As a proof of concept, I created Jikto, a web scanner written in JavaScript. Although I will not be releasing the source code of Jikto, I will be giving a full live demo and provide a detailed discussion about its methodology and architecture."

It appears there was some miscommunication in the original c-net story.
"Hoffman, who developed the tool as a way to advance Web security, plans to release Jikto publicly later this week at the ShmooCon hacker event in Washington, D.C."

Figured "release" meant distribute rather than demo. That's that. next topic.

---

I think most security professionals would agree that releasing information about vulnerabilities, attack techniques (what I'm known for), and tools is generally positive. People should have information they need to defend themselves should they choose to. For example nessus, nmap, whisker and even metasploit have the distinction of evening the playing field. The good guys and bad guys can both use it. Industry ethics would say you wouldn't want to release a virus or phishing toolkit for real-world use because it only helps the bad guys. Then I see this:

"Billy Hoffman, lead research and development engineer at Atlanta-based SPI Dynamics Inc., has developed a tool called Jikto that can use XSS flaws and JavaScript to create a distributed botnet without any kind of user interaction at all. Hoffman plans to discuss the tool and publish the source code for it at the upcoming Shmoocon conference in Washington ."

Sounds like a nicely packaged script kiddie tool, usable in the real world, and only helpful to the bad guys. Without getting my hands on the code or the slide... am I'm reading way too much into this? Apparently I wasn't the only person who saw something strange about this as Don Park and RSnake weighed in with their thoughts.

"Yes, I understand these tools can be used to protect but what about tools that use questionable means? Jikto, for example, uses unsuspecting website visitors' browser to scan other websites for holes. Would any businesses use such tools to protect their sites? If not, who does it benefit? Is it security researchers' job to push the envelope of black hat's state of art?"
Don Park

"One very narrow line that we all must face is where the distinction between security research and building script kiddy tools comes into play. I think a lot of us have fallen victim to writing tools to make our own lives easier, while also making script kiddie’s lives easier. In this case Jikto doesn’t make a security researcher’s life easier, except perhaps to demonstrate how bad script kiddies can be if given that exact tool."
RSnake

RSnake asks is it for Good or for Evil. I'd say neither, just unnecessary. Being a SPI competitor, I don't presume to tell they or Billy what to do. Its probably good that Billy hasn't spoken yet or released the code at ShmooCon. Maybe he'd reconsider releasing this code into the wild. Or perhaps he'll get pissed and say myself or RSnake or others have done the same thing with all our PoC. To which I of course disagree entirely.

A parody of the security widget interview process

(via Anton Chuvakin's blog). Kevin Murphy posts masterfully hilarious description of how press interviews go in the security space. Perhaps its because I've had to do so many of these recently that the mental picture in my head was painfully vivid. I should write-up something similar from the Interviewee perspective. If I only had his wit. Kevin, if we ever had to do any interview together, I'll buy the first pint! :)

PCIv1.1 Sec 6.6 clarification leads to more ambiguity

Update: Dennis commented below, its worth a read. I figured we were on the same page.

Dennis Hurst posted the interesting response he got from the PCI Council on the same question many people had about this section. I'm going to have to copy/paste large sections of his original post to keep the flow somewhat linear.

Section 6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security

Does this mean an an organization must hire an outside firm to do a source code review, black box pen-test or what? Can this same process be satisfactorily performed by internal staff with a commercial scanner? What scanner?

The "official" response Dennis received:

The answer to your inquiry is as follows.

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

Thank you and regards,

The PCI Security Standards Council Response Team

Here is Dennis's conclusion:

"So there you have it, you don’t have to go through every line of code, or even hire someone else to do it. You can use other means, including application assessment tools like WebInspect and AMP, to test your applications. "

Hold on there pilgrim. (Always wanted to say that) That's not exactly accurate and advice that could get an organization is some hot water. TWICE the PCI Council stipulated that internal staff have the appropriate skills and expertise:

"also has the internal expertise to understand the findings and make appropriate changes"

"when internal staff have the skills to use the tool and fix defects"

My question now is how the heck is that going to be checked for? What would be the minimum bar? Will every brand X scanner start giving away user certification with each proof of purchase? Talk about a serious conflict of interest. The problem is there's no industry standard certification for web application security proficiency. I've talked about the need for a Web Application Security Professional Certification in the past.

Anyway, I'm glad we got even a little bit of clarity so now that we can move onto new bits of ambiguity. It keeps things fresh. :) Plus it'll be nice when PCI eventually documents what scanners should be able to identify and what web application firewalls should be able to block. Won't that be nice.

Go SecTheory!

Robert "RSnake" Hansen just publicly let the cat out of the bag... He's finally entering the security world and launching his own company, “SecTheory”. Congratulations!

Robert’s been talking to me about striking out on his own for a while now and I've been encouraging him to do so. Starting a security consultancy is no small task. I did it with WhiteHat six years ago, so I know first hand how tough but also how rewarding it is. What I also know is Robert and id are highly experienced and intelligent guys with a lot of domain knowledge to offer. Few can match they’re skill set.

They’re focusing on the mid-tier who have very particular and specialized needs who can’t yet afford high-priced full-timers. There are a ton of companies our there who could utilize their talents so I know these guys will do very well. I’m sure I’ll be passing a few people their way because they’ll get treated right.

5 Stages of Web Application Security Grief

Over the past year many organizations are noticeably starting to "get" the importance of web application security and studying up on the issues, but experience doesn’t come overnight. At WhiteHat we meet a lot of different people possessing a variety of views on the webappsec world. So a couple days ago, I was sanity checking some of Bill Pennington’s (VP of Services) slides on "Five Things Every Security Professional Should Know about Website Security". For some reason the way the advice was laid out it reminded me of the Five Stages of Grief (if your familiar) because it closely mimicked the attitudes of those we encounter depending on their degree of webappsec sophistication.

Bill re-did the stages, webappsec style, and it came out pretty funny actually.

Denial
"We have firewalls, IDS, and SSL. We are Secure."

Anger
"How the heck did this get so bad?!?!?"

Bargaining
"We can solve this with frameworks, developer education and some scanners."

Depression
"We have so many websites and the code is changing all the time. Maybe if I leave now no one will notice."

Acceptance
"I guess my job just got a lot more interesting."

Bill says he’s in the Anger stage. Though, that could just be the way he is. Heh. I’d place myself in the optimistic Bargaining stage having left Anger about a year back. However, I’m starting to slowly gravitate towards Depression as I witness and write about the enormous scale of the problem. From time to time I believe I’ve encountered those farther along than I, but probably pass them off as overly cynical.

So, what stage are you at?

Using CSRF to Frame Someone

Update: I guess I'm not the only one playing around with CSRF today, Chris Shiflett (OmniTI) blogged a CSRF issue in Amazon after a year of waiting in vien for a fix to go in.

"In the description, I explained how to exploit the infamous "1-Click" feature, causing victims to purchase items of my choosing without their knowledge or consent"

---

No not "framing" as in "iframe", but as in framed for a crime.

Slashdot points to a dailyrecord.com article where Google and MSN search history, obtained from the suspects computer(s), was used as strong forensic evidence in a murder investigation. Prosecutors say the defendant, searched for "How To Commit Murder," "instant poisons," "undetectable poisons," "fatal digoxin doses," and gun laws in New Jersey and Pennsylvania. Not good. From a web application security perspective here's where it gets interesting. Check out a snippet from the article:

"Jennifer Seymour, who worked for the State Police digital technology unit, testified this morning how she examined the digital contents of computers and hand held devices obtained as part of the investigation.

Her testimony was the strongest evidence yet in the state's circumstantial evidence case against the 34-year-old McGuire, who allegedly murdered her husband with a .38 caliber weapon, dismembered his body and placed body parts in three suitcases found in the Chesapeake Bay in May of 2004."

Catch that? "strongest evidence yet in the state's circumstantial evidence case".

It’s conceivable that if someone wanted to try and frame you for a crime like the one described, its pretty easy to forge the same forensic evidence, then go out and commit the crime. The much discussd Cross-Site Request Forgery (CSRF) attack makes it trival for someone to force your browser to make a request you didn't intend to make. Even seeding Google and MSN with undesirable search phrases. For example if I really wanted to, I could have loaded in these IMG SRCs on this page upon loading.

<* img src="http://www.google.com/search?hl=en&q=How+To+Commit+Murder">
<* img src="http://www.google.com/search?hl=en&q=instant+poisons">
<* img src="http://www.google.com/search?hl=en&q=undetectable+poisons">
<* img src="http://www.google.com/search?hl=en&q=fatal+digoxin+doses">

Your browser, your ip, your search. All roads point back to you. Have a nice day.



P.S. Then again, now that my blog has these odd terms it it, I might be considered a phishing website by this time tomorrow. :)

Big trouble if PCI-DSS requires CSRF

PCI-DSS is requiring more web application security focus probably because most of the CC# heists we're reading about either have to do with a lost/stolen PCs or web application hacks. Whatever the reason, Approved Scanning Vendors (ASV's) and website merchants require guidance as to what vulnerabilities need to be tested for and protected against. So far this guidance has referenced the OWASP Top 10, which in the new 2007 draft, includes Cross-Site Request Forgery (CSRF). Though if someone isn’t thoughtful, this could mean that no website will be able to pass PCI-DSS scans if both documents (PCI and T10) are taken at face value.

Most experts will agree that CSRF is a serious issue and that on a global scale we’re talking about a HUGE number of vulnerabilities. Just about every "important" feature of every website, relatively speaking, is likely to be vulnerable to CSRF. The other problem is automated scanning for CSRF is hard, really hard. I'm not ready to say impossible, because is some occasions it isn’t, but the needle is still very near zero for everybody. (Anyone care to correct me?) To top it off, CSRF solutions aren’t exactly simple to implement, as opposed to XSS or SQL Injection. It’ll require more than a one-line input validation or output filtering regex to defeat. A fairly sophisticated piece of logic (session token / form keys/ nonce) needs to be placed the middle of each "important" business process.

As an ASP and VA vendor, we’re generally paid to identify "a plate of red" (vulnerabilities) in our customer’s websites, with the primary value being to help them get secure by recommending solutions. In the case of CSRF, if compelled by PCI-DSS to add it to our testing methodology, its may be we'd identify literally thousands of these vulnerabilities for each few hundred sites. Merchants seeking PCI compliance are not going to enjoy the results when they figure out how long its going to take them combined with everything else they have to do. Of course, the PCI Council could simply say not to follow the OWASP Top 10, because hey, even the document itself says not to use it as a standard.

"This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first!"

I guess its still an open option, but Andrew van der Stock (a main architect of the document) says the following:

"It’s unlikely that the PCI folks will pick up this Top 10 as is; they’re looking for “Top 10 things you should code well on when dealing with financial apps, particularly cc apps”."

Fair enough, so perhaps they'll cite the all encompassing WASC Threat Classification. Maybe, but this document will also be updated soon to include CSRF. So no getting away from it unless the PCI Council simply says to ignore CSRF entirely. Could happen I guess. Anyway, I thought I’d lay this out there and see what insight others had. I have no idea what’ll happen with PCI-DSS down the road. We’ll have to wait and see.

Worst CAPTCHA Ever is RIGHT!

I just came across the Worst CAPTCHA Ever post and upon seeing the title I was thinking, "cmon, how bad could it be." Then I saw it. OMG!

Father knows Infrastructure, not Web Apps

I was reading a Dark Reading interview with Vint Cerf, co-designer and the TCP/IP stack and chief Internet evangelist at Google. Anyone with that type of street cred is elite in my book. Vint shared his thoughts on the Internets biggest threats.

“His move from MCI to the post of chief Internet evangelist at Google in late 2005 led him to a part of the Net he hadn't focused on before: the applications. "Having spent a good portion of my career on the infrastructure of the Internet, it’s fun to work on new ways to use it."

Vint is a network/infrastructure guy now focusing on applications. I’ll give you one guess as to where he things the biggest threats are. Give up?

"Cerf says the biggest threats are the proliferation of spam, botnets, malware, and denial-of-service attacks. "Much work is needed to increase the security of the Internet and its connected computers," he says, "and to make the environment more reliable for everyone."

Cerf says the emerging Domain Name Security (DNSSEC) technology could help secure the Net's DNS servers, which have increasingly become targets. And more filtering of source IP addresses is needed. "And use of IPSec would foil some higher-level protocol attacks, and digital signing of IP address assignment records could reduce some routing/spoofing risks," he says. OSes need to be more airtight, too, and two-factor authentication should be more the norm than plain old passwords, he says.

I agree these are big and important threats, but I don’t think they are the biggest anymore. Far more damage can be done with simple web application hacks. I think XSS and CSRF are probably going to be the main threats over the next 10 years. Then again, I’m a web application and not a network security guy and have the same biases.

(almost) Rending HTML without JavaScript

I was researching a way to allow users to upload HTML but not allow the browser to execute javascript. A solution like this would go along way towards mitigating persistent XSS issues. A couple of days ago, I thought I had stumbled across a odd behavior in Firefox that would allow me to do exactly that. See the code below. Turns out one of WhiteHat engineers pointed out a flaw fairly quickly, but I figured I'd post this because what the browser does it weird. ARGH, so close.

When writing HTML content to an iframe using the "magic" line, tags do not execute, while event handlers do. What also happens is the DOM security, or domain, gets all messed up for some reason and you get errors on valid function calls.

<* html>

<* script>

function addInput() {

var input = document.getElementById('input');
var output = document.getElementById('output');

if (! output.contentWindow.document.body) {
output.parentNode.removeChild(output);
addOutput();
output = document.getElementById('output');
}

/* MAGIC! */
output.contentWindow.document.body.parentNode.innerHTML = input.value;

}

function addOutput() {
var container = document.getElementById('container');
var output = document.createElement('iframe');
output.id = "output";
output.style.width = "600px";
output.style.height = "200px";
container.appendChild(output);
}

<* /script>

<* body onload="addOutput();">

Input:<* br />
<* textarea id="input" style="width: 600px; height:200px;"><* /textarea><* br>

Output:<* br />
<* div id="container"><* /div><* br><* br>

<* input type=button onclick="addInput()" value="Input">

<* /body>
<* /html>

Website Bug Bounties. A good idea?

In web application security, the disclosure debate mostly revolves around the legalities of vulnerability “discovery”. This is because security researchers don’t have the same freedom to find vulnerabilities in custom web applications as they do in desktop software. However, if your running a large and popular website (or many of them), you probably know that there’s still a lot of white/gray/black hats are looking for vulnerabilities anyway, but we normally don’t invite them to do so. That’s probably why Microsoft Security Response Center (MSRC), the group responsible for handling issues in their issues, posted a cordial message inviting the sla.ckers.org community to submit vulnerabilities to them first before public disclosure. Wow!

What happened next was interesting. digi7al64 suggested a “reward system” would be nice incentive and gesture since the act of disclosing requires a certain amount of time and effort on behalf of the researcher. There might be something to this. If you consider the roughly 1,000 XSS issues already publicized on sla.ckers.org (including in Google, Yahoo, MySpace, Microsoft and so on), obviously there’s not shortage of issue. I’m going to hazard a guess that most of the people disclosing vulnerabilities probably do not work professionally in the web application security field and do this for fun in their spare time. If the reward was a simply crisp $100 bill, maybe a bug hunter t-shirt, or perhaps an XBox 360 for a particular high severity issue, I bet that’d make their day and everyone would be happy.

Now think about this… if given the option, how many of the organizations that have been outted would have gladly paid a voluntary reward for the disclosure and saved themselves the negative press? Probably a fair number would have participated. Also of course, if they choose not to participate, there’s nothing lost and things remain the same. Though if an organization budgeted say $10,000, which could help to eliminate a ton of XSS and SQL Injection issues. And at some point vulnerabilities would get much hard to find and system security would improve. Obviously a lot of details would have to be worked out to counteract any extortion or blackmail schemes. I’m not quite ready to begin recommending this approach, but I think it’s worth continuing a dialog over.

We're Hiring!

WhiteHat has been growing very rapidly over the last several months. In fact during 2006 we tripled ourselves in sales, customers, websites under management, employees, etc. To keep up with our success we need great people. People that are passionate as we are, eager to learn (A LOT), and would enjoy spending their time discovering vulnerabilities in the world’s most popular websites. We’re looking for a very select group of entry-level and experienced candidates possessing strong analytical skills and aptitude to be a part of our services team.

At WhiteHat our sole focus is web application security, which is probably the hottest sector in all of information security. And the services team is responsible for a variety of vulnerability assessment operational responsibilities for our corporate clients. If you have a background in web development or QA testing and interested in pursuing a career in security, this is the place to do it. It’s a rare opportunity, unlike anything else in the industry, to be a part of such a young innovative company.

To apply you must be in the San Francisco Bay Area or able to re-locate. If you’re interested, please send your resume to wh-jobs ___ AT __ whitehatsec.com with “Application Security Specialist” in the subject line.

I still know where you've been, without JavaScript

Looks like RSnake has one-upped me with his new CSS History Hack Without JavaScript (PoC). The hack still relies up the a:visited component of CSS, but instead of using JavaScript to check link color, he uses the display: property to create the conditional logic required. Nice! This is mitigated in many ways by SafeHistory (Firefox), but again, your not protected by turning off JavaScript. Great. In classic pdp fashion, he quickly improved upon the PoC with his own version. Good stuff.

Anti-DNS Pinning in the News!

Second Google Desktop attack reported. Now I've seen everything. This is the first time I've seen the esoteric anti-DNS Pinning term actually mentioned by the mainstream media. Talk about guts on behalf of Robert McMillan to cover the story and attempt an easy to understand explanation of what this thing is and does. This has got to be right up there with the press coverage of Back Orifice during a Defcon many years back. The issue in question had to do with RSnake's follow on research into Google Desktop product as sparked by Watchfire’s paper on “Overtaking Google Desktop”.

"Once you can repoint Google to another IP address, instead of Google getting the traffic, the bad guy does," he said.

Very few people, including the experts, have any idea of “DNS Pinning” and how important it actually is. DNS-Pinning is a browser security mechanism preventing secondary DNS lookups by hostile web servers attempting to read data from other domains.

Example:
Why DNS Pinning? Lets try to attack web bank (111.111.111.111)

1) User visits “attacker” website (222.222.222.222) with a DNS timeout of 1 second.
2) Browser receives JavaScript reconnecting to attacker in two seconds. (attacker is down!)
3) Browser re-connects to the DNS server for attacker’s new IP address. (111.111.111.111)
4) Browser connects to 111.111.111.111 thinking that its attacker.

Not entirely useful because of an invalid host header sent to webbank, cookie won’t be sent either, even if the browser allowed step #3. However, its still dangerous enough to add DNS-Pinning to modern web browsers. Basically your browser is instructed not ask for a new IP on a hostname. It is pinned to the original IP.

Enter Anti-DNS Pinning (or forcing the browser to stop this behavior)

1) User visits “attacker” website (222.222.222.222) with a DNS timeout of 1 second.
2) Browser receives JavaScript reconnecting to attacker in two seconds. (attacker firewalls itself!)
3) DNS Pinning is dropped. (Anti-DNS Pinning)
4) Browser re-connects to the DNS server for attacker’s new IP address. (192.168.1.1)
5) Browser connects to 192.168.1.1, from its perspective, thinking that its attacker.
6) Attack can now force read access to places where they couldn’t get to directly.

Now, Anti-Anti-DNS Pinning, a security solution to defend against Anti-DNS Pinning. And finally, Anti-Anti-Anti-DNS Pinning attacks, to circumvent any Anti-Anti-DNS Pinning solution. Head hurt yet? I know its crazy and even I don't have a good handle on all of it.

My Bio, by Anurag Agarwal

Over the last couple of weeks Anurag Agarwal has been doing a lot work creating a background piece for Reflection on Jeremiah Grossman. You'll notice a long list of organized links to most of the work I've published. This turned out to be a great resource in addition to the interview material contained within. Until this point I had only a vague idea of how much stuff was actually out there. Honestly, I can't take sole credit for all of this. I've had the amazing opportunity to converse with many stellar experts whom I frequently exchange ideas. This ability is invaluable to anyone conducting research and developing insights in the information security field. Thanks Anurag!

After Anurag completes a few more of these Reflections, I think we're going to have a really good webappsec knowlege base. Of course someone is going to have to do the same for Anurag. :)

High 5 profile on InformationWeek

During last Christmas I did an interview and a photo shoot for the High 5 profile section of Information Week. Meet Jeremiah Grossman, CTO Of WhiteHat Security. This was a first for me and an interesting experience to say the least. Sure I've done plenty of interviews, but never anything like this before. Larry Greenemeier did an excellent job describing my professional and personal interests, without the cheesiness factor I've seen in similar publications. If you check out my picture you'll find me doing my best impression of a local-boy-turn-security-pro-tough-guy-look. I'm told it looks good, but my face turns red when I look at it. Either way, might as well have fun with it I guess.

Back to the Real World

A lot has happened this last week and I'm racing to catch up. A couple interviews, new hacks, research, and press mentions. Also, I typically receive hundreds of email a day, even with multiple spam filter layers. As of today literally have over 100 emails to answer. So if you've sent me a message, please bear with me, I'm trying. :)

The Big 3-Oh!

I spent the last week on Maui celebrating my 30th with the family. The wife and kids love it, well, who doesn’t right. I went to the beach (a lot), BBQ’ed, jumped off a few cliffs, trained Brazilian Jiu Jitsu with one of my lil’ brothers, 4-wheeled in the pineapple fields with another lil’ brother, ate a lot, slept even more, played Magic the Gathering, looked around at properties for sale, and generally had an amazing time. You know, I’ve never paid much attention to my age, though 30 seemed like a nice round number for reflection. A time to think about some of the more important things you’ve learned and an opportunity to measure accomplishments. I got in web application security, oops cgi security, professionally back in 2000, but had been doing a lot of amateur stuff since 92-93. Since then…

I’ve learned that:

• Possible does not mean probable and hard doesn’t mean valuable
• Its best to surround yourself with good people that are smarter than you are
• Great things are not accomplished through reason and compromise, but somehow progress is.
• One should be well-rounded in personally, professionally, and physically
• To enjoy the journey because there doesn't seem to be a destination
  

And I figured I’d take a different approach to measuring work…

IM Buddy List: 42
Address book contacts: 733
Sent email folder: 19,876
Public presentations: 64
Foreign countries visited: 5
U.S. States visited: 22
LinkedIn connections: 133
Articles/papers written: 16
Exploits developed: A few dozen
Number of press mentions: a couple hundreds, maybe more.
Thanked by organizations: A few dozen
Google vanity search: 85,200 links
Blog posts: 272
Certifications: 0
Websites hacked: A few hundred
Community organizations founded: 2
Buzz words/terminology invented: 6
Programming languages: 3
Companies founded: 1
Papers/articles/books read: Probably hundreds, maybe thousands
Books written: 0 (first is on the way)
Book forwards written: 2
Customers: Undiscolsed
Slashdot’ed: 5
College Degrees: 0