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
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Tuesday, July 22, 2008
Monday, July 21, 2008
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
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
Wednesday, July 16, 2008
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. ;-)
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. ;-)
Thursday, July 03, 2008
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
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
Monday, June 30, 2008
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
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
Friday, June 27, 2008
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
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)
2)
3)
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
Thursday, June 26, 2008
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
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
Tuesday, June 10, 2008
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
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
Wednesday, May 28, 2008
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
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
Friday, May 23, 2008
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
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
Tuesday, May 20, 2008
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
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
Sunday, May 18, 2008
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
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
Friday, May 16, 2008
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
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
Tuesday, May 13, 2008
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
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
Monday, May 12, 2008
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
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
Friday, May 09, 2008
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
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
Friday, April 25, 2008
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
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
Wednesday, April 16, 2008
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
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
Tuesday, April 15, 2008
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
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
Thursday, April 03, 2008
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.
UPDATE 4/5/08: We're back, a painful migration to new hardware, but complete, and fully functional. Thanks again for your patience.
Tuesday, April 01, 2008
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:
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
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
Friday, March 21, 2008
Upcoming conference presentations
I'll present The XSS Epidemic: Discovery, Disclosure, and Remediation at the 2008 ISSA NW Regional Security Conference on April 23rd, 2008, in Olympia, WA:
In the same mindset of a "month of browser, Mac OS X, PHP, etc. bugs" I challenged myself to find and report as many XSS (cross site scripting) vulnerabilities as possible in a 30 day period. The result was well more than 100 vulnerabilities in sites ranging from General Motors to George Mason University, 6 Secunia/CVE advisories for weak software, and a raging debate over the value of ScanAlert’s Hacker Safe label.
Our discussion will include a technical dive into this epidemic, including methodology, tools, examples, inherent risks, and the need to aid the Internet community in remediating this issue as well other web application security lapses.
I'll also present Malcode Analysis Techniques for Incident Handlers at the 20th Annual FIRST Conference in Vancouver, B.C. on June 25th, 2008. Details here.
In the same mindset of a "month of browser, Mac OS X, PHP, etc. bugs" I challenged myself to find and report as many XSS (cross site scripting) vulnerabilities as possible in a 30 day period. The result was well more than 100 vulnerabilities in sites ranging from General Motors to George Mason University, 6 Secunia/CVE advisories for weak software, and a raging debate over the value of ScanAlert’s Hacker Safe label.
Our discussion will include a technical dive into this epidemic, including methodology, tools, examples, inherent risks, and the need to aid the Internet community in remediating this issue as well other web application security lapses.
I'll also present Malcode Analysis Techniques for Incident Handlers at the 20th Annual FIRST Conference in Vancouver, B.C. on June 25th, 2008. Details here.
Sunday, March 16, 2008
RAPIER featured in SANS Ask The Expert Webcast
I gave an overview of RAPIER during a SANS Ask The Expert Webcast,
Malcode Analysis and Response: Proficiency vs. Complexity on March 20th, 2008.
"The threat landscape changes constantly, driven in part by the "bot economy" and changing malcode techniques. In response, incident handler techniques must keep pace. This presentation will cover the use of RAPIER, a security tool built to facilitate first response procedures for incident handling. It is designed to acquire commonly requested information and samples during an information security event, incident, or investigation. RAPIER automates the entire process of data collection and delivers the results directly to the hands of a skilled security analyst. From detection and discovery, capture and containment, count on a useful discussion meant to further your incident response practices."
You can listen to the stream and/or view the slides here.
Malcode Analysis and Response: Proficiency vs. Complexity on March 20th, 2008.
"The threat landscape changes constantly, driven in part by the "bot economy" and changing malcode techniques. In response, incident handler techniques must keep pace. This presentation will cover the use of RAPIER, a security tool built to facilitate first response procedures for incident handling. It is designed to acquire commonly requested information and samples during an information security event, incident, or investigation. RAPIER automates the entire process of data collection and delivers the results directly to the hands of a skilled security analyst. From detection and discovery, capture and containment, count on a useful discussion meant to further your incident response practices."
You can listen to the stream and/or view the slides here.
Monday, February 18, 2008
Fastest fix in the West - a vendor's excellent response
Rare is the occasion when one who researches and responsibly reports web application vulnerabilities is met with an open, immediate, consumer oriented response from a vendor. But so it was when I let the folks who develop Tendenci, a Schipul offering, know about a few XSS issues. These are people who take great pride in their product; had they simply fixed the issue, and perhaps sent back a quick note many days later, I would have accepted that as the typical norm for most responsible vendors.
Yet, Schipul took the process to a new height, raising the bar entirely.
I literally heard back from Schipul's Jennifer Brooks within an hour of notification. Within 24 hours the issues had been addressed, and even more surprising, Tendenci posted the issue and its resolution to their blog, providing customers with a summary and an FAQ.
This rapid, public response exemplifies a company who seeks to protect their brand, their customers, and the end user, all in the same spirit and with the same intent.
To Schipul I say well done, extremely well done, and thank you.
del.icio.us | digg
Yet, Schipul took the process to a new height, raising the bar entirely.
I literally heard back from Schipul's Jennifer Brooks within an hour of notification. Within 24 hours the issues had been addressed, and even more surprising, Tendenci posted the issue and its resolution to their blog, providing customers with a summary and an FAQ.
This rapid, public response exemplifies a company who seeks to protect their brand, their customers, and the end user, all in the same spirit and with the same intent.
To Schipul I say well done, extremely well done, and thank you.
del.icio.us | digg
Friday, January 25, 2008
An Open Letter to Ken Leonard, CEO, ScanAlert
Dear Mr. Leonard,
As well you are aware; the Hacker Safe brand has long been viewed by those in the information security field with varying levels of skepticism, if not vehement disdain. As there are a plethora of blogs, articles, and exposed vulnerabilities available for you to review, I will not waste your time with excerpts validating our position. Suffice it say, the community at large shares certain doubt about the service offering ScanAlert arrogantly calls Hacker Safe.
It is our view that this is a marketing position only. Nothing, I repeat, nothing, is truly "hacker safe". You claim that websites are free of vulnerabilities when they are clearly not. This is disingenuous and is at the root of what angers information security professionals. If a site is vulnerable while under the auspicious care of ScanAlert's Hacker Safe program should it not lose its Hacker Safe credential until such a time as the vulnerability is remediated? If I take this down to a fundamentally simple premise, saying a site is Hacker Safe while vulnerable to SQL injection, XSS, CSRF, etc. is, in essence, a misrepresentation. If a consumer commits a transaction on a site that is vulnerable, are they not at risk due to vulnerabilities your service claims to scan for? While we understand that you are in the business of growing revenue by indicating websites as “hacker safe”, we believe you are also beholden to the consumers using those sites.
We ask of you this: if a site is found to be vulnerable during your scans, or as reported by third parties, then enforce the findings and suspend their certification. Strive to improve your scan engine where possible. It is your responsibility to NOT label a site “Hacker Safe” when it is not. Then, at least, you are telling the truth, and a consumer can make an informed choice as to how confident they feel about the site's security practices.
There are, at the time of this writing, sites still vulnerable to XSS, yet branded Hacker Safe, that were identified as vulnerable MORE THAN A YEAR AGO. These sites should not be reported as Hacker Safe, period.
Please don't insult us with more of Joseph Pierini’s pearls of wisdom like “XSS vulnerabilities aren't material to a site's certification”. Adopting a view like this is ridiculous and blatantly ignorant given the risks to consumers. You scan for XSS and clearly denote it in your How We Scan section. Therefore, if a site is vulnerable to XSS it is not “Hacker Safe”.
This is far from the first round, credit sla.ckers.org with driving this point home in 2006, only to be shrugged off by Pierini then too. I think there may be a job opening for him over at Zango. Perhaps he could change his mantra from “XSS is not our problem” to “We don’t make spyware.”
What about the PCI argument? If a site is vulnerable to XSS, it’s simply not compliant. See this post for details. It all adds up to consumers at risk. ScanAlert should remember, above all, that safety for the consumer is paramount. Why not live up to your marketing hype and offer a service that truly, honestly, and with integrity, lives up to even a fraction of its namesake.
"What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so. - Mark Twain"
Sincerely,
Russ McRee
Those information security professionals wishing to lend your name to this plea, please add your name as a comment.
del.icio.us | digg
As well you are aware; the Hacker Safe brand has long been viewed by those in the information security field with varying levels of skepticism, if not vehement disdain. As there are a plethora of blogs, articles, and exposed vulnerabilities available for you to review, I will not waste your time with excerpts validating our position. Suffice it say, the community at large shares certain doubt about the service offering ScanAlert arrogantly calls Hacker Safe.
It is our view that this is a marketing position only. Nothing, I repeat, nothing, is truly "hacker safe". You claim that websites are free of vulnerabilities when they are clearly not. This is disingenuous and is at the root of what angers information security professionals. If a site is vulnerable while under the auspicious care of ScanAlert's Hacker Safe program should it not lose its Hacker Safe credential until such a time as the vulnerability is remediated? If I take this down to a fundamentally simple premise, saying a site is Hacker Safe while vulnerable to SQL injection, XSS, CSRF, etc. is, in essence, a misrepresentation. If a consumer commits a transaction on a site that is vulnerable, are they not at risk due to vulnerabilities your service claims to scan for? While we understand that you are in the business of growing revenue by indicating websites as “hacker safe”, we believe you are also beholden to the consumers using those sites.
We ask of you this: if a site is found to be vulnerable during your scans, or as reported by third parties, then enforce the findings and suspend their certification. Strive to improve your scan engine where possible. It is your responsibility to NOT label a site “Hacker Safe” when it is not. Then, at least, you are telling the truth, and a consumer can make an informed choice as to how confident they feel about the site's security practices.
There are, at the time of this writing, sites still vulnerable to XSS, yet branded Hacker Safe, that were identified as vulnerable MORE THAN A YEAR AGO. These sites should not be reported as Hacker Safe, period.
Please don't insult us with more of Joseph Pierini’s pearls of wisdom like “XSS vulnerabilities aren't material to a site's certification”. Adopting a view like this is ridiculous and blatantly ignorant given the risks to consumers. You scan for XSS and clearly denote it in your How We Scan section. Therefore, if a site is vulnerable to XSS it is not “Hacker Safe”.
This is far from the first round, credit sla.ckers.org with driving this point home in 2006, only to be shrugged off by Pierini then too. I think there may be a job opening for him over at Zango. Perhaps he could change his mantra from “XSS is not our problem” to “We don’t make spyware.”
What about the PCI argument? If a site is vulnerable to XSS, it’s simply not compliant. See this post for details. It all adds up to consumers at risk. ScanAlert should remember, above all, that safety for the consumer is paramount. Why not live up to your marketing hype and offer a service that truly, honestly, and with integrity, lives up to even a fraction of its namesake.
"What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so. - Mark Twain"
Sincerely,
Russ McRee
Those information security professionals wishing to lend your name to this plea, please add your name as a comment.
del.icio.us | digg
Friday, January 18, 2008
XSS and PCI: Not compliant, or Hacker Safe
As a follow up to the last post on sites vulnerable to XSS that are certified McAfee Hacker Safe, there is more to this story.
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?
del.icio.us | digg
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?
del.icio.us | digg
Tuesday, January 15, 2008
Hacker Safe? Not so much.
Likely you've all read about Hacker Safe certified Geeks.com being hacked. ScanAlert, recently bought by McAfee, says that "research indicates sites remotely scanned for known vulnerabilities on a daily basis, such as those earning 'Hacker Safe' certification, can prevent over 99% of hacker crime."
I agree...but here comes strike two.
I was happily bouncing about the internet looking for things that should be fixed, when what did I see at Toastmasters International but a McAfee Hacker Safe certificate. Ever the skeptic, I said to myself "Prove it." But, of course, because my white hat and professional values require it, I remembered that first, do no harm are words to live by. But a wee script test in a form field can't hurt, right?
There's video of this here if you prefer.
Let's begin.
Here's the Advanced Search page, note the McAfee Hacker Safe tag in the lower right:
Then, said little test script about to be submitted to the Advanced Search page:
Ruh roh, Rastro. Can you say XSS?
Man, that's not good, so let's try a bit more trickery.
XSSed indeed.
Something tells me the McAfee Hacker Safe service offering would do well to dig a little deeper before certifying a site.
Meanwhile, sanitizing input might not be a bad idea for our Toastmasters friends.
Play nice until Toastmasters gets a chance to fix it, please. I've already let them know.
Cheers.
del.icio.us | digg
I agree...but here comes strike two.
I was happily bouncing about the internet looking for things that should be fixed, when what did I see at Toastmasters International but a McAfee Hacker Safe certificate. Ever the skeptic, I said to myself "Prove it." But, of course, because my white hat and professional values require it, I remembered that first, do no harm are words to live by. But a wee script test in a form field can't hurt, right?
There's video of this here if you prefer.
Let's begin.
Here's the Advanced Search page, note the McAfee Hacker Safe tag in the lower right:
Then, said little test script about to be submitted to the Advanced Search page:
Ruh roh, Rastro. Can you say XSS?
Man, that's not good, so let's try a bit more trickery.
XSSed indeed.
Something tells me the McAfee Hacker Safe service offering would do well to dig a little deeper before certifying a site.
Meanwhile, sanitizing input might not be a bad idea for our Toastmasters friends.
Play nice until Toastmasters gets a chance to fix it, please. I've already let them know.
Cheers.
del.icio.us | digg
Thursday, January 10, 2008
NSM-Console and HeX update
While researching the HeX System for the pending February toolsmith, I was extremely pleased to discover NSM-Console, from Matthew Lee Hinman. I've not yet seen such an efficient, useful, all encompassing framework for offline packet analysis. NSM-Console includes modules for:
# aimsnarf
# ngrep (gif/jpg/pdf/exe/pe/ne/elf/3pg/torrent)
# tcpxtract
# tcpflow
# chaosreader
# bro-IDS
# snort
# tcpdstat
# capinfos
# tshark
# argus
# ragator
# racount
# rahosts
# hash (md5 & sha256)
# ra
# honeysnap
# p0f
# pads
# fl0p
# iploc
Consider giving both HeX System and the included NSM-Console an immediate look.
# aimsnarf
# ngrep (gif/jpg/pdf/exe/pe/ne/elf/3pg/torrent)
# tcpxtract
# tcpflow
# chaosreader
# bro-IDS
# snort
# tcpdstat
# capinfos
# tshark
# argus
# ragator
# racount
# rahosts
# hash (md5 & sha256)
# ra
# honeysnap
# p0f
# pads
# fl0p
# iploc
Consider giving both HeX System and the included NSM-Console an immediate look.
Thursday, January 03, 2008
Zango's in your Face(book)
The Zangonistas are at it again, this time deftly disguising their "software" as a Facebook Widget. Fortinet, who discovered the issue, discusses the "Secret Crush" widget at length, so no need to repeat their extensive effort.
Instead, I'd like to offer a bit of analysis, then invoke a debate.
ANALYSIS
I ran Setup.exe, as found in hxxp://static.zangocash.com/Setup/46/Zango/Setup.exe, through the analysis mill and I think the evidence speaks for itself.
IMPORTANT NOTE FOR YOUR CONSIDERATION: All of the following occurs BEFORE you accept the EULA.
IPs called:
66.150.14.74 Zango
66.150.14.65 Zango
66.150.14.61 Zango
64.94.137.72 Zango
URLs:
http://installs.zango.com/downloads/valueadd/SRS/UCI/R1/seekmo.html
http://installs.zango.com/downloads/valueadd/SRS/UCI/R1/zango.html
http://installs.zango.com/downloads/valueadd/SRS/Installer/2.0.26/R1/Installer.exe
http://static.zangocash.com/Setup/Update/
http://public.zangocash.com/php/rpc_uci.php
http://te.seekmo.com/TrackedEvent.aspx
http://te1.zango.com/te.aspx
Registy Keys:
HKEY_CURRENT_USER\Software\ZangoInstall
HKEY_CURRENT_USER\Software\ZangoDebugSettings
softwaredistributionfaild
HKEY_LOCAL_MACHINE\Software\MediaGateway
SoftwareList
hkey_local_machine\software\seekmo
hkey_local_machine\software\zango
softwareurl: %s, registry: %s
GetSoftwareList
The software you are trying to install does not yet support Windows Vista@.
The software you are trying to install does not support your operating system.
Anti-virus and firewall applications can interfere with this and other software installation programs.
You may want to temporarily disable these applications during software installation.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
HKEY_LOCAL_MACHINE\software\Mozilla\
HKEY_CURRENT_USER\Software\
HKEY_LOCAL_MACHINE\Software\
Software\Microsoft
softwarecount=%d&retrycount=%d&reason=%s
HKEY_LOCAL_MACHINE\SOFTWARE\ShoppingReport
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\
HKEY_LOCAL_MACHINE\software\microsoft\Internet Explorer\ActiveX Compatibility
Software
API Log (edited for brevity, but oh so interesting):
416a68 LoadLibraryA(crypt32.dll)=762c0000
762ec91d RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography\OID)
77ddecaf RegOpenKeyExA (SOFTWARE\Microsoft\Cryptography\Providers\Type 001)
77dded3f RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types\Type 001)
77ddee3b RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Strong Cryptographic Provider)
77ddf4b3 ReadFile()
77e6ce44 CreateFileA(C:\WINDOWS\System32\rsaenh.dll)
ffeb87e ReadFile()
77ddf43f LoadLibraryA(C:\WINDOWS\System32\rsaenh.dll)=ffd0000
ffe8206 RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography)
ffeb11f RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography\Offload)
762ec6c4 RegOpenKeyExA (CryptDllFindOIDInfo)
What are we encrypting and offloading? Hmm?
719546f9 LoadLibraryA(UxTheme.dll)=5ad70000
41996b RegOpenKeyExA (HKLM\SOFTWARE\WindUpdates)
4195f3 RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Winad Client)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows SyncroAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Win Comm)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdTools)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdControl)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows TaskAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdService)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows ControlAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows ServeAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Admilli Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\DeskAd Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Admanager Controller)
41996b RegOpenKeyExA (HKLM\SOFTWARE\AdStatus Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdStatus)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows FormatAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\AdTools Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Preview AdService)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Pass)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Access)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Gateway)
41996b RegOpenKeyExA (HKLM\SOFTWARE\MediaGateway)
Wait a minute...I haven't accepted the EULA yet!
Let's discuss.
DEBATE
You know my opinion, I think Zango's offerings are spyware, I always have and I always will. They'd prefer their products be referred to as adware and that they're harmless. I have debated this issue with them in person (perfectly nice people, but analysis supplants personality), and they would argue that, because their software only installs with the explicit consent of the enduser, it can't be labeled as spyware. To which I say, if it calls home, reports behavior, and shapes a response based on said behavior, it's spyware, EULA or not. Round and round we go, where we stop, no one knows. The searches define:spyware and define:adware will provide impetus for the debate.
If a user knowingly installs a widget or a piece of software with a EULA that describes it behavior, can it objectively be called spyware or malicious?
Comments welcome. Cheers.
Instead, I'd like to offer a bit of analysis, then invoke a debate.
ANALYSIS
I ran Setup.exe, as found in hxxp://static.zangocash.com/Setup/46/Zango/Setup.exe, through the analysis mill and I think the evidence speaks for itself.
IMPORTANT NOTE FOR YOUR CONSIDERATION: All of the following occurs BEFORE you accept the EULA.
IPs called:
66.150.14.74 Zango
66.150.14.65 Zango
66.150.14.61 Zango
64.94.137.72 Zango
URLs:
http://installs.zango.com/downloads/valueadd/SRS/UCI/R1/seekmo.html
http://installs.zango.com/downloads/valueadd/SRS/UCI/R1/zango.html
http://installs.zango.com/downloads/valueadd/SRS/Installer/2.0.26/R1/Installer.exe
http://static.zangocash.com/Setup/Update/
http://public.zangocash.com/php/rpc_uci.php
http://te.seekmo.com/TrackedEvent.aspx
http://te1.zango.com/te.aspx
Registy Keys:
HKEY_CURRENT_USER\Software\ZangoInstall
HKEY_CURRENT_USER\Software\ZangoDebugSettings
softwaredistributionfaild
HKEY_LOCAL_MACHINE\Software\MediaGateway
SoftwareList
hkey_local_machine\software\seekmo
hkey_local_machine\software\zango
softwareurl: %s, registry: %s
GetSoftwareList
The software you are trying to install does not yet support Windows Vista@.
The software you are trying to install does not support your operating system.
Anti-virus and firewall applications can interfere with this and other software installation programs.
You may want to temporarily disable these applications during software installation.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
HKEY_LOCAL_MACHINE\software\Mozilla\
HKEY_CURRENT_USER\Software\
HKEY_LOCAL_MACHINE\Software\
Software\Microsoft
softwarecount=%d&retrycount=%d&reason=%s
HKEY_LOCAL_MACHINE\SOFTWARE\ShoppingReport
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\
HKEY_LOCAL_MACHINE\software\microsoft\Internet Explorer\ActiveX Compatibility
Software
API Log (edited for brevity, but oh so interesting):
416a68 LoadLibraryA(crypt32.dll)=762c0000
762ec91d RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography\OID)
77ddecaf RegOpenKeyExA (SOFTWARE\Microsoft\Cryptography\Providers\Type 001)
77dded3f RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types\Type 001)
77ddee3b RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Strong Cryptographic Provider)
77ddf4b3 ReadFile()
77e6ce44 CreateFileA(C:\WINDOWS\System32\rsaenh.dll)
ffeb87e ReadFile()
77ddf43f LoadLibraryA(C:\WINDOWS\System32\rsaenh.dll)=ffd0000
ffe8206 RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography)
ffeb11f RegOpenKeyExA (HKLM\Software\Microsoft\Cryptography\Offload)
762ec6c4 RegOpenKeyExA (CryptDllFindOIDInfo)
What are we encrypting and offloading? Hmm?
719546f9 LoadLibraryA(UxTheme.dll)=5ad70000
41996b RegOpenKeyExA (HKLM\SOFTWARE\WindUpdates)
4195f3 RegOpenKeyExA (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Winad Client)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows SyncroAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Win Comm)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdTools)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdControl)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows TaskAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdService)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows ControlAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows ServeAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Admilli Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\DeskAd Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Admanager Controller)
41996b RegOpenKeyExA (HKLM\SOFTWARE\AdStatus Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows AdStatus)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Windows FormatAd)
41996b RegOpenKeyExA (HKLM\SOFTWARE\AdTools Service)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Preview AdService)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Pass)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Access)
41996b RegOpenKeyExA (HKLM\SOFTWARE\Media Gateway)
41996b RegOpenKeyExA (HKLM\SOFTWARE\MediaGateway)
Wait a minute...I haven't accepted the EULA yet!
Let's discuss.
DEBATE
You know my opinion, I think Zango's offerings are spyware, I always have and I always will. They'd prefer their products be referred to as adware and that they're harmless. I have debated this issue with them in person (perfectly nice people, but analysis supplants personality), and they would argue that, because their software only installs with the explicit consent of the enduser, it can't be labeled as spyware. To which I say, if it calls home, reports behavior, and shapes a response based on said behavior, it's spyware, EULA or not. Round and round we go, where we stop, no one knows. The searches define:spyware and define:adware will provide impetus for the debate.
If a user knowingly installs a widget or a piece of software with a EULA that describes it behavior, can it objectively be called spyware or malicious?
Comments welcome. Cheers.
January's toolsmith - Gpg4win
January's toolsmith column in the ISSA Journal features Gpg4win, a suite that integrates GPG into your Windows envronment. Next month will be discussing more powerful NSM opportunities with HeX, a FreeBSD-based Live CD loaded with network security monitoring tools. toolsmith offers insights on tools useful to the infosec practitioner, typically open source or inexpensive. The ISSA Journal is available to members in print and online at issa.org. Article copies are available on the toolsmith page.
Thursday, December 27, 2007
Storm keeps coming (4th variant)
They just keep coming...this one is very similar to the 3rd variant we reviewed, but some changes are apparent.
1) Hash: 1f362ad74d62262bff6bcb1d078cbf7d
2) Aside from yet again changing the domain and binary, the hidden files written upon execution are as follows:
Helios Rootkit Detector
Scanning File System For Hidden Files
[*] Scanning Drive C
1 C:\WINDOWS\system32\bldy.config Hidden From API
2 C:\WINDOWS\system32\bldy3a80-61.sys Hidden From API
Execute Duration (in seconds)=18
Loaded Drivers:
Driver File Company Name Description
C:\WINDOWS\System32\bldy3a80-61.sys
Kernel31 Api Log
***** Installing Hooks *****
4012d8 CreateFileA(C:\WINDOWS\System32\bldy.config)
40117f CreateFileA(C:\WINDOWS\System32\bldy3a80-61.sys)
DirwatchData
WatchDir Initilized OK
Watching C:\WINDOWS
Created: C:\WINDOWS\system32\bldy.config
Modifed: C:\WINDOWS\system32\bldy.config
Modifed: C:\WINDOWS\system32
Created: C:\WINDOWS\system32\bldy3a80-61.sys
Modifed: C:\WINDOWS\system32\bldy3a80-61.sys
Better AV coverage again:
AntiVir - TR/Crypt.XDR.Gen
Authentium - W32/Dropper.gen6
Avast - Win32:Zhelatin-ASX
AVG - Dropper.Generic.TLX
BitDefender - Trojan.Peed.IRG
ClamAV - Trojan.Peed-66
DrWeb - Trojan.Spambot.2386
Fortinet - W32/Tibs.G@mm
F-Prot - W32/Dropper.gen6
F-Secure - Email-Worm.Win32.Zhelatin.pr
Kaspersky - Email-Worm.Win32.Zhelatin.pr
NOD32v2 - Win32/Nuwar.BA
Panda - Suspicious file
Prevx1 - Stormy:Worm-All Variants
Sophos - Mal/Dorf-H
Symantec - Trojan.Peacomm
VirusBuster - Trojan.DR.Zhelatin.AS
Webwasher-Gateway - Trojan.Crypt.XDR.Gen
Aside from the inherent value of keeping an eye on the ISC Diary, please refer to the US-CERT alert.
They'll keep coming, we'll keep watching.
1) Hash: 1f362ad74d62262bff6bcb1d078cbf7d
2) Aside from yet again changing the domain and binary, the hidden files written upon execution are as follows:
Helios Rootkit Detector
Scanning File System For Hidden Files
[*] Scanning Drive C
1 C:\WINDOWS\system32\bldy.config Hidden From API
2 C:\WINDOWS\system32\bldy3a80-61.sys Hidden From API
Execute Duration (in seconds)=18
Loaded Drivers:
Driver File Company Name Description
C:\WINDOWS\System32\bldy3a80-61.sys
Kernel31 Api Log
***** Installing Hooks *****
4012d8 CreateFileA(C:\WINDOWS\System32\bldy.config)
40117f CreateFileA(C:\WINDOWS\System32\bldy3a80-61.sys)
DirwatchData
WatchDir Initilized OK
Watching C:\WINDOWS
Created: C:\WINDOWS\system32\bldy.config
Modifed: C:\WINDOWS\system32\bldy.config
Modifed: C:\WINDOWS\system32
Created: C:\WINDOWS\system32\bldy3a80-61.sys
Modifed: C:\WINDOWS\system32\bldy3a80-61.sys
Better AV coverage again:
AntiVir - TR/Crypt.XDR.Gen
Authentium - W32/Dropper.gen6
Avast - Win32:Zhelatin-ASX
AVG - Dropper.Generic.TLX
BitDefender - Trojan.Peed.IRG
ClamAV - Trojan.Peed-66
DrWeb - Trojan.Spambot.2386
Fortinet - W32/Tibs.G@mm
F-Prot - W32/Dropper.gen6
F-Secure - Email-Worm.Win32.Zhelatin.pr
Kaspersky - Email-Worm.Win32.Zhelatin.pr
NOD32v2 - Win32/Nuwar.BA
Panda - Suspicious file
Prevx1 - Stormy:Worm-All Variants
Sophos - Mal/Dorf-H
Symantec - Trojan.Peacomm
VirusBuster - Trojan.DR.Zhelatin.AS
Webwasher-Gateway - Trojan.Crypt.XDR.Gen
Aside from the inherent value of keeping an eye on the ISC Diary, please refer to the US-CERT alert.
They'll keep coming, we'll keep watching.
Wednesday, December 26, 2007
Holiday Storm Part 3
I know, I know...enough already. But our Storm friends have changed the game a bit for the third round, as discussed on the ISC Diary, in particular Update 3. The changed domain and binary name led me to ponder what else has changed. So...
1) New hash: BE22F894AC662C905C37CEFDE66DE065
2) Better hiding skills, no visible running processes, nastiness all hidden from the API (can you say rootkit?). No more hanging out in the open, easily seen.
The Helios Rootkit Detector, now included in RAPIER, discovered darker voodoo than the last two versions:
Scanning File System For Hidden Files
[*] Scanning Drive C
1 C:\WINDOWS\system32\cleanmgr.exe Hidden From API
2 C:\WINDOWS\system32\clean.config Hidden From API
3 C:\WINDOWS\system32\clean6c9-3320.sys Hidden From API
4 C:\WINDOWS\system32\dllcache\cleanmgr.exe Hidden From API
SysAnalyzer says:
Loaded Drivers:
Driver File Company Name Description
C:\WINDOWS\System32\clean6c9-3320.sys
Kernel31 Api Log
***** Installing Hooks *****
4012c1 CreateFileA(C:\WINDOWS\System32\clean.config)
40117f CreateFileA(C:\WINDOWS\System32\clean6c9-3320.sys)
DirwatchData
WatchDir Initilized OK
Watching C:\WINDOWS
Created: C:\WINDOWS\system32\clean.config
Modifed: C:\WINDOWS\system32\clean.config
Modifed: C:\WINDOWS\system32\config\system.LOG
Modifed: C:\WINDOWS\system32
Created: C:\WINDOWS\system32\clean6c9-3320.sys
Modifed: C:\WINDOWS\system32\clean6c9-3320.sys
3) AV coverage is further improved for this version:
AntiVir 7.6.0.46 - TR/Rootkit.Gen
Authentium - W32/StormWorm.R
Avast - Win32:Zhelatin-ASX
AVG - Dropper.Generic.TLF
BitDefender - DeepScan:Generic.Malware.FMH@mmign.55A134E9
ClamAV - Trojan.Zhelatin
DrWeb - Trojan.Spambot.2387
Fortinet - W32/Tibs.G@mm
F-Prot - W32/StormWorm.R
F-Secure - Email-Worm.Win32.Zhelatin.pl
Ikarus - Virus.Win32.Zhelatin.ASX
Kaspersky - Email-Worm.Win32.Zhelatin.pl
Microsoft - Backdoor:WinNT/Nuwar.B!sys
NOD32v2 - Win32/Fuclip.AW
Panda - Suspicious file
Prevx1 - Stormy:Worm-All Variants
Sophos - Mal/Dorf-H
Webwasher-Gateway - Trojan.Rootkit.Gen
How perfectly unpleasant, making things more difficult to spot. Here's my New Years wish for the Storm lamers. Bugger off (kept pleasant for the kids).
1) New hash: BE22F894AC662C905C37CEFDE66DE065
2) Better hiding skills, no visible running processes, nastiness all hidden from the API (can you say rootkit?). No more hanging out in the open, easily seen.
The Helios Rootkit Detector, now included in RAPIER, discovered darker voodoo than the last two versions:
Scanning File System For Hidden Files
[*] Scanning Drive C
1 C:\WINDOWS\system32\cleanmgr.exe Hidden From API
2 C:\WINDOWS\system32\clean.config Hidden From API
3 C:\WINDOWS\system32\clean6c9-3320.sys Hidden From API
4 C:\WINDOWS\system32\dllcache\cleanmgr.exe Hidden From API
SysAnalyzer says:
Loaded Drivers:
Driver File Company Name Description
C:\WINDOWS\System32\clean6c9-3320.sys
Kernel31 Api Log
***** Installing Hooks *****
4012c1 CreateFileA(C:\WINDOWS\System32\clean.config)
40117f CreateFileA(C:\WINDOWS\System32\clean6c9-3320.sys)
DirwatchData
WatchDir Initilized OK
Watching C:\WINDOWS
Created: C:\WINDOWS\system32\clean.config
Modifed: C:\WINDOWS\system32\clean.config
Modifed: C:\WINDOWS\system32\config\system.LOG
Modifed: C:\WINDOWS\system32
Created: C:\WINDOWS\system32\clean6c9-3320.sys
Modifed: C:\WINDOWS\system32\clean6c9-3320.sys
3) AV coverage is further improved for this version:
AntiVir 7.6.0.46 - TR/Rootkit.Gen
Authentium - W32/StormWorm.R
Avast - Win32:Zhelatin-ASX
AVG - Dropper.Generic.TLF
BitDefender - DeepScan:Generic.Malware.FMH@mmign.55A134E9
ClamAV - Trojan.Zhelatin
DrWeb - Trojan.Spambot.2387
Fortinet - W32/Tibs.G@mm
F-Prot - W32/StormWorm.R
F-Secure - Email-Worm.Win32.Zhelatin.pl
Ikarus - Virus.Win32.Zhelatin.ASX
Kaspersky - Email-Worm.Win32.Zhelatin.pl
Microsoft - Backdoor:WinNT/Nuwar.B!sys
NOD32v2 - Win32/Fuclip.AW
Panda - Suspicious file
Prevx1 - Stormy:Worm-All Variants
Sophos - Mal/Dorf-H
Webwasher-Gateway - Trojan.Rootkit.Gen
How perfectly unpleasant, making things more difficult to spot. Here's my New Years wish for the Storm lamers. Bugger off (kept pleasant for the kids).
Malware analysis tools
I've been asked to share the tools I use for malware analysis, in particular API details.
The Malcode Analysis Software Tools from iDefense Labs are extremely useful. toolsmith featured the suite in the July 2007 column.
API-Logger can be used as a standalone tool or you can run the .exe through SysAnalyzer which includes API-Logger output.
Other important pieces in my sandbox included VMWare Server (Linux host, Windows VMs), PE Explorer, RAPIER 3.2, Wireshark, Mandiant Red Curtain (MRC), and the Systinternals tools.
Check the toolsmith page for articles on Wireshark, MRC, and RAPIER use as well.
Required reading from the "The Godfather of RE", Lenny Zeltser, includes his Reverse Engineering Malware paper.
The Malcode Analysis Software Tools from iDefense Labs are extremely useful. toolsmith featured the suite in the July 2007 column.
API-Logger can be used as a standalone tool or you can run the .exe through SysAnalyzer which includes API-Logger output.
Other important pieces in my sandbox included VMWare Server (Linux host, Windows VMs), PE Explorer, RAPIER 3.2, Wireshark, Mandiant Red Curtain (MRC), and the Systinternals tools.
Check the toolsmith page for articles on Wireshark, MRC, and RAPIER use as well.
Required reading from the "The Godfather of RE", Lenny Zeltser, includes his Reverse Engineering Malware paper.
Tuesday, December 25, 2007
New Years Storm deja vu
Not content to settle for all the new bot's they got for Christmas, the RBN would like to wish you a Happy New Year as well with hxxp://uhavepostcard.com/happy2008.exe.
New hash, 5bb3606d36019142507043f30401c5d2, same malware as that we received when we fell for the Christmas strip show they offered us ;-).
Again, it copies itself to C:\WINDOWS as disnisa.exe, writes the same registry keys and config file, and follows the same network attributes as mentioned in previous post, but better AV coverage now that this variant's been around for a few days:
AntiVir - Worm/Zhelatin.ob
Authentium - W32/StormWorm.P
BitDefender - Trojan.Peed.IRE
CAT-QuickHeal - (Suspicious) - DNAScan
DrWeb - Trojan.Packed.263
eSafe - Suspicious File
eTrust-Vet - Win32/Sintun.AT
F-Prot - W32/StormWorm.P
F-Secure - Packed.Win32.Tibs.gu
Kaspersky - Packed.Win32.Tibs.gu
Microsoft - Trojan:Win32/Tibs.gen!ldr
Prevx1 - Stormy:Worm-All Variants
Symantec - Trojan.Peacomm.D
Webwasher-Gateway - Worm.Zhelatin.ob
I was further intrigued by the name they chose for the .exe, in particular, disnisa. Appears it was or is the name of a wine and spirits import company in Nicaragua, importers of Heineken, Chivas Reagal, Cuervo, Concha y Toro, and Moet & Chandon. Is there correlation given the time of year? Who knows.
Happy New Years from disnisa. Drink the product (responsibly), but don't open the ecard. ;-)
New hash, 5bb3606d36019142507043f30401c5d2, same malware as that we received when we fell for the Christmas strip show they offered us ;-).
Again, it copies itself to C:\WINDOWS as disnisa.exe, writes the same registry keys and config file, and follows the same network attributes as mentioned in previous post, but better AV coverage now that this variant's been around for a few days:
AntiVir - Worm/Zhelatin.ob
Authentium - W32/StormWorm.P
BitDefender - Trojan.Peed.IRE
CAT-QuickHeal - (Suspicious) - DNAScan
DrWeb - Trojan.Packed.263
eSafe - Suspicious File
eTrust-Vet - Win32/Sintun.AT
F-Prot - W32/StormWorm.P
F-Secure - Packed.Win32.Tibs.gu
Kaspersky - Packed.Win32.Tibs.gu
Microsoft - Trojan:Win32/Tibs.gen!ldr
Prevx1 - Stormy:Worm-All Variants
Symantec - Trojan.Peacomm.D
Webwasher-Gateway - Worm.Zhelatin.ob
I was further intrigued by the name they chose for the .exe, in particular, disnisa. Appears it was or is the name of a wine and spirits import company in Nicaragua, importers of Heineken, Chivas Reagal, Cuervo, Concha y Toro, and Moet & Chandon. Is there correlation given the time of year? Who knows.
Happy New Years from disnisa. Drink the product (responsibly), but don't open the ecard. ;-)
Sunday, December 23, 2007
Storm-Bot stripshow analysis
Merry Christmas from the RBN. Now on a PC near you, a stripshow from Santa's helpers. Or not.
The ISC reported the expected Storm surge Christmas eve at 0000 GMT.
hxxp://merrychristmas.com/stripshow.exe (modified to protect the innocent) yields a hash of 2BBA62FBC3B9AF85C3C7D64A82E1237C. Once executed it immediately copies itself as disnisa.exe to C:\WINDOWS and adds a startup registry key for the same.
Current AV detection includes:
Kaspersky stripshow.exe - Email-Worm.Win32.Zhelatin.pd.
eTrust-Vet - Win32/Sintun.AT
Microsoft - Trojan:Win32/Tibs.gen!ldr
Symantec - Trojan.Peacomm.D
After a quick time check to Microsoft's time server, this variant switches immediately to very noisy P2P on a variety of ports. In addition to the ISC-recommended HTTP and email blocks for outbound to merrychristmasdude.com, you have to consider if you really need outbound UDP traffic above 1024. I'm a firm believer in deny all and make exceptions only via legitimate business case. If you can achieve such lockdown, even though your hosts may suffer infection, they won't be communicating with their friends and neighbors.
From API analysis we see a few interesting tidbits:
w32tm /config /update
403014 Copy(c:\malware\stripshow.exe->C:\WINDOWS\disnisa.exe)
77e6bc59 WriteFile(h=7a0)
403038 RegOpenKeyExA (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)
40305f RegSetValueExA (disnisa)
402ba0 WinExec(w32tm /config /syncfromflags:manual /manualpeerlist:time.windows.com,time.nist.gov,100)
77e7d0b7 WaitForSingleObject(788,64)
402ba8 WinExec(w32tm /config /update,100)
40309b CreateProcessA(C:\WINDOWS\disnisa.exe,(null),0,(null))
4030df WinExec(netsh firewall set allowedprogram "C:\WINDOWS\disnisa.exe" enable,100)
71ab52c6 LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71a5716a LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71aa14eb GlobalAlloc()
40da1b bind(8c, port=26790)
77e7ac53 CreateRemoteThread(h=ffffffff, start=404b05)
40da1b bind(b8, port=7018)
40d9c7 listen(h=b8 )
40a262 WaitForSingleObject(d4,2710)
Nice, do a little time sync, allow ourselves through the firewall, then bind, listen, and wait.
First, add another registry entry,
0cd2d RegCreateKeyExA (HKLM\Software\Microsoft\Windows\ITStorage\Finders,)
then start connecting:
71a54cee LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
77e7ac53 CreateRemoteThread(h=ffffffff, start=71a519c4)
40d9f1 connect( 193.33.146.178:24714 )
40d9f1 connect( 74.60.173.98:3887 )
40d9f1 connect( 58.74.135.13:30843 )
40d9f1 connect( 222.119.113.135:22295 )
40d9f1 connect( 71.234.220.147:20232 )
40d9f1 connect( 76.84.231.43:14172 )
40d9f1 connect( 124.5.147.194:16544 )
40d9f1 connect( 58.8.236.130:13224 )
40d9f1 connect( 190.79.151.75:2952 )
40d9f1 connect( 58.8.122.191:29646 )
Once this little bugger hits the network, expect flood-like traffic.
My infected sandbox victim exhausted my 1.5mb DSL connection instantly, in part from a ton of inbound responses from peers being logged at my firewall:
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=59178 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=60978 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=4987 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=6619 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=13762 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=18384 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=19891 PROTO=UDP SPT=24045 DPT=26790 LEN=33
At last, the peer list referred to by the ISC, written to C:\WINDOWS (many more entries not included):
[config]
[local]
uport=20142
[peers]
00003D6C8F338A3FDD3DF3648666F55C=0CCE03EE2BD100
0100A634122F3553A046EC451061927C=0CCEEF9C5BF700
02007E238D780D25FD5511285E2E596E=0CD9D73081A500
03001E62DC533E7AF6161729A953891B=180BB9671B4800
0400EB5EC13599373A3D544A2D6AF94F=180FAC024F7300
05004710B3440F5D2117CE555A62D04A=1810D0AE22DA00
06001471521206296D099433C93EC427=1813911C2E6100
07002D6D5B0FE3019C56B1290A564E59=1820B08043D700
0800A2417153943DC23C6C5C817C4159=18257B254F2600
There's nothing new or exciting here: SPAM component, headless P2P, seasonal social engineering, fast flux, and other pervasively annoying attributes.
User awareness, as always, is your strongest defense.
Cheers and happy holidays, except for you RBN a$$h0735.
The ISC reported the expected Storm surge Christmas eve at 0000 GMT.
hxxp://merrychristmas.com/stripshow.exe (modified to protect the innocent) yields a hash of 2BBA62FBC3B9AF85C3C7D64A82E1237C. Once executed it immediately copies itself as disnisa.exe to C:\WINDOWS and adds a startup registry key for the same.
Current AV detection includes:
Kaspersky stripshow.exe - Email-Worm.Win32.Zhelatin.pd.
eTrust-Vet - Win32/Sintun.AT
Microsoft - Trojan:Win32/Tibs.gen!ldr
Symantec - Trojan.Peacomm.D
After a quick time check to Microsoft's time server, this variant switches immediately to very noisy P2P on a variety of ports. In addition to the ISC-recommended HTTP and email blocks for outbound to merrychristmasdude.com, you have to consider if you really need outbound UDP traffic above 1024. I'm a firm believer in deny all and make exceptions only via legitimate business case. If you can achieve such lockdown, even though your hosts may suffer infection, they won't be communicating with their friends and neighbors.
From API analysis we see a few interesting tidbits:
w32tm /config /update
403014 Copy(c:\malware\stripshow.exe->C:\WINDOWS\disnisa.exe)
77e6bc59 WriteFile(h=7a0)
403038 RegOpenKeyExA (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)
40305f RegSetValueExA (disnisa)
402ba0 WinExec(w32tm /config /syncfromflags:manual /manualpeerlist:time.windows.com,time.nist.gov,100)
77e7d0b7 WaitForSingleObject(788,64)
402ba8 WinExec(w32tm /config /update,100)
40309b CreateProcessA(C:\WINDOWS\disnisa.exe,(null),0,(null))
4030df WinExec(netsh firewall set allowedprogram "C:\WINDOWS\disnisa.exe" enable,100)
71ab52c6 LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71a5716a LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71aa14eb GlobalAlloc()
40da1b bind(8c, port=26790)
77e7ac53 CreateRemoteThread(h=ffffffff, start=404b05)
40da1b bind(b8, port=7018)
40d9c7 listen(h=b8 )
40a262 WaitForSingleObject(d4,2710)
Nice, do a little time sync, allow ourselves through the firewall, then bind, listen, and wait.
First, add another registry entry,
0cd2d RegCreateKeyExA (HKLM\Software\Microsoft\Windows\ITStorage\Finders,)
then start connecting:
71a54cee LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
77e7ac53 CreateRemoteThread(h=ffffffff, start=71a519c4)
40d9f1 connect( 193.33.146.178:24714 )
40d9f1 connect( 74.60.173.98:3887 )
40d9f1 connect( 58.74.135.13:30843 )
40d9f1 connect( 222.119.113.135:22295 )
40d9f1 connect( 71.234.220.147:20232 )
40d9f1 connect( 76.84.231.43:14172 )
40d9f1 connect( 124.5.147.194:16544 )
40d9f1 connect( 58.8.236.130:13224 )
40d9f1 connect( 190.79.151.75:2952 )
40d9f1 connect( 58.8.122.191:29646 )
Once this little bugger hits the network, expect flood-like traffic.
My infected sandbox victim exhausted my 1.5mb DSL connection instantly, in part from a ton of inbound responses from peers being logged at my firewall:
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=59178 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=60978 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=4987 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=6619 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=13762 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=18384 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=19891 PROTO=UDP SPT=24045 DPT=26790 LEN=33
At last, the peer list referred to by the ISC, written to C:\WINDOWS (many more entries not included):
[config]
[local]
uport=20142
[peers]
00003D6C8F338A3FDD3DF3648666F55C=0CCE03EE2BD100
0100A634122F3553A046EC451061927C=0CCEEF9C5BF700
02007E238D780D25FD5511285E2E596E=0CD9D73081A500
03001E62DC533E7AF6161729A953891B=180BB9671B4800
0400EB5EC13599373A3D544A2D6AF94F=180FAC024F7300
05004710B3440F5D2117CE555A62D04A=1810D0AE22DA00
06001471521206296D099433C93EC427=1813911C2E6100
07002D6D5B0FE3019C56B1290A564E59=1820B08043D700
0800A2417153943DC23C6C5C817C4159=18257B254F2600
There's nothing new or exciting here: SPAM component, headless P2P, seasonal social engineering, fast flux, and other pervasively annoying attributes.
User awareness, as always, is your strongest defense.
Cheers and happy holidays, except for you RBN a$$h0735.
Monday, December 03, 2007
SANS Top 20 contribution
I was very pleased to contribute to the SANS Top 20 this year, working under the tutelage of Rohit Dhamankar, and cooperatively with Adam Safier, specifically on the P2P section.
Each year this list brings value to the global information security community, I am proud to have participated, and look forward to contributing again next year.
Bruce Schneier offers some excellent commentary on it, as well. A slightly different view can be found at SearchSecurity.
Ultimately, although I speak for myself, I am quite certain that SANS intends for this list to provide the impetus to aid enterprises in the endless challenge of tightening their security posture.
Use it in good stead! Cheers.
Each year this list brings value to the global information security community, I am proud to have participated, and look forward to contributing again next year.
Bruce Schneier offers some excellent commentary on it, as well. A slightly different view can be found at SearchSecurity.
Ultimately, although I speak for myself, I am quite certain that SANS intends for this list to provide the impetus to aid enterprises in the endless challenge of tightening their security posture.
Use it in good stead! Cheers.
Subscribe to:
Posts (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho... -
First off, Happy New Year! I hope you have a productive and successful 2018. I thought I'd kick off the new year with another explorat...