To give you a sense of what Mike Bailey and I will be covering at defcon 17 this Saturday at 11am, I thought I'd give you a little taste courtesy of a Netgear RP614v4 router that suffers from cross-site request forgery (CSRF) vulnerabilities, as well as persistent cross-site scripting (XSS) issues.
See OSVDB advisory 54885 for further specifics. BTW, please support OSVDB!
The short version:
The Netgear RP614v4 web-based administration interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform administrative actions or conduct script insertion attacks e.g. when a logged-in administrator visits a malicious web site.
The sad truth of the matter is this, while I don't have access to the whole Netgear product line, the reuse the same firmware codebase across multiple devices.
Thus, in all likelihood, there are numerous Netgear devices vulnerable to this issue, if not all.
The same holds true with Linksys devices, which we'll cover in detail at DEFCON.
As you will see, the approach is simple, and too often effective.
1) Miscreant crafts email utilizing well proven social engineering methodology.
2) Victim follows orders and, while authenticated to vulnerable device, clicks on that damned link.
3) Vulnerable device does not perform any validity checks to verify the requests made via the attacker's web page lurking behind the link in the email.
4) Vulnerable device fails in whatever fashion it's told to.
As exhibited in the video I've created for your viewing pleasure, I force the admin session to enable remote management (disabled by default) and change the remote management access port to 6667 for old time's sake. If, as it so often is, the admin account is left to default password, game over. Or, in many cases, you can also force a password change via CSRF as well.
Any function the firmware provides can be forced via a victim admin's session; that which is exhibited here is but a single examplar.
Tokens, people...tokens!
The video, as promised:
Lo-fi (5.63 MB MP4)
Med-fi (53.9 MB WMV)
Hi-fi (73.4 MB AVI)
Hope to see you at DEFCON; please say hi if you're there on Saturday.
I'll be easily spotted in jeans and my white Certified Application Security Specialist (ASS) golf shirt.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Thursday, July 30, 2009
Tuesday, July 21, 2009
steekR security steenkS
My RSS reader continues to provide me subject matter for analysis, and the recent F-Secure purchase of steekR, “Your Secured Online Space”, was no exception.
The purchase was described by El Reg as follows:
F-Secure grabs online storage firm in cloud security push
Steek's technology is designed to allow users to upload data from either PCs or mobile phones. Bordeaux-based Steek already partners with mobile telcos (including Virgin Media, SFR in France and SingTel), a factor which F-Secure hopes will increase its ability to sell Software as a Service (SaaS) technology packages through operators.
Oh boy, here we go again.
I want to create a new line of Bobbleheads for Cloud and SaaS. They’ll talk as well, bobbling and blathering the latest buzz words:
“We’ll give you the best ROI in the cloud!”
“Our SaaS offering relieves you of any responsibility, we’ll do it all!”
I digress.
I understand the business model, and F-Secure’s motives for the purchase; it’s hard to find fault there.
But as I’ve indicated time and time again, when you purchase or integrate another vendor’s offerings, you immediately inherit their shortcomings as well.
I propose a blamestorming session. I’d like to start with steekR.
steekR suffers from persistent cross-site scripting (XSS) flaws.
They further suffer from a complete inability to respond to responsible disclosures (multiple attempts over two weeks).
Thus, I struggle with their “Your Secured Online Space” claim. As in…not so much.
Imagine this scenario:
1) An attacker creates a steekR account.
2) The attacker embeds malicious JavaScript.
3) The attacker then shares steekR content in a manner that exposes it to any victim who errantly clicks through.
4) You receive email notification of the share and given your use of steekR (you and 2,405,935 other customers), you click the URL.
5) Your browser is directed to a steekR share with a malware-laden IFRAME embedded.
6) You’re pwned.
I'll walk you through it.
Here's the email...
Here's the URL in the email (no, I'm not trying to pwn you):
http://www.steekr.com/n/50-2/share/LNK32784a66232b7baaf/
Click My Documents in the left pane and you'll see the IFRAME in the right pane when you mouse over the folder.
Here's the result when you click said URL...
That IFRAME could easily be something nasty.
Similar scenarios can easily lead to data breach, account compromise; pick your poison.
Lest you forget, persistent XSS issues are far uglier than their reflected kin.
Lesson for companies like F-Secure on the venture integration path:
Review the acquisitions security-related practices, or lack thereof, and conduct a thorough assessment of the product driving the decision to purchase them.
Lesson for users of SaaS offerings:
Assume no privacy, and no guarantee of security. A trusted resource may not be trustworthy.
Steek and you might stumble. ;-)
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
The purchase was described by El Reg as follows:
F-Secure grabs online storage firm in cloud security push
Steek's technology is designed to allow users to upload data from either PCs or mobile phones. Bordeaux-based Steek already partners with mobile telcos (including Virgin Media, SFR in France and SingTel), a factor which F-Secure hopes will increase its ability to sell Software as a Service (SaaS) technology packages through operators.
Oh boy, here we go again.
I want to create a new line of Bobbleheads for Cloud and SaaS. They’ll talk as well, bobbling and blathering the latest buzz words:
“We’ll give you the best ROI in the cloud!”
“Our SaaS offering relieves you of any responsibility, we’ll do it all!”
I digress.
I understand the business model, and F-Secure’s motives for the purchase; it’s hard to find fault there.
But as I’ve indicated time and time again, when you purchase or integrate another vendor’s offerings, you immediately inherit their shortcomings as well.
I propose a blamestorming session. I’d like to start with steekR.
steekR suffers from persistent cross-site scripting (XSS) flaws.
They further suffer from a complete inability to respond to responsible disclosures (multiple attempts over two weeks).
Thus, I struggle with their “Your Secured Online Space” claim. As in…not so much.
Imagine this scenario:
1) An attacker creates a steekR account.
2) The attacker embeds malicious JavaScript.
3) The attacker then shares steekR content in a manner that exposes it to any victim who errantly clicks through.
4) You receive email notification of the share and given your use of steekR (you and 2,405,935 other customers), you click the URL.
5) Your browser is directed to a steekR share with a malware-laden IFRAME embedded.
6) You’re pwned.
I'll walk you through it.
Here's the email...
Here's the URL in the email (no, I'm not trying to pwn you):
http://www.steekr.com/n/50-2/share/LNK32784a66232b7baaf/
Click My Documents in the left pane and you'll see the IFRAME in the right pane when you mouse over the folder.
Here's the result when you click said URL...
That IFRAME could easily be something nasty.
Similar scenarios can easily lead to data breach, account compromise; pick your poison.
Lest you forget, persistent XSS issues are far uglier than their reflected kin.
Lesson for companies like F-Secure on the venture integration path:
Review the acquisitions security-related practices, or lack thereof, and conduct a thorough assessment of the product driving the decision to purchase them.
Lesson for users of SaaS offerings:
Assume no privacy, and no guarantee of security. A trusted resource may not be trustworthy.
Steek and you might stumble. ;-)
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Sunday, July 19, 2009
Pick a toolsmith topic
I've decided to implement a new feature from time to time with regard to toolsmith, my monthly column in the ISSA Journal.
You, dear reader, are invited to propose topics. If I choose your topic, you will be mentioned in the column, and win an information security book of my choosing.
A few important guidelines.
1) It must be an information security tool I haven't already discussed. See the full list of those I have discussed here.
2) The tool must be information security related.
3) The tool must be free, and preferably open source.
4) Ideally, I prefer to try and focus on tools that aren't well known, with less exposure, in order to help them receive the attention they deserve.
Submit ideas at my contact page.
I look forward to hearing what might be of interest for you.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
You, dear reader, are invited to propose topics. If I choose your topic, you will be mentioned in the column, and win an information security book of my choosing.
A few important guidelines.
1) It must be an information security tool I haven't already discussed. See the full list of those I have discussed here.
2) The tool must be information security related.
3) The tool must be free, and preferably open source.
4) Ideally, I prefer to try and focus on tools that aren't well known, with less exposure, in order to help them receive the attention they deserve.
Submit ideas at my contact page.
I look forward to hearing what might be of interest for you.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Tuesday, July 14, 2009
Pete Hoekstra = ID Ten T
From a state that could definitely use congressional members with a bit more intellectual savvy comes Michigan's Pete Hoekstra.
Graham Cluley's blog states:
Hoekstra told The Washington Times' America's Morning News radio show that "it's time for America, South Korea, Japan and others to stand up to North Korea" by launching a retaliatory cyber attack or international sanctions.
Graham took Hoekstra to task for this moronic idea yesterday, before today's headlines quickly began to reveal the possibility that the attacks against S. Korea and the US may have actually originated in the UK. The simple reality is, maybe it did, maybe it didn't. The premise that one nation state should launch a cyber attack against another based on the presumise that they might be responsible for a DDoS attack is short-sighted to say the least.
Should we now cyber-bomb our British friends, Mr. Hoekstra? I believe, amongst other things, we and the Brits can agree that you are assuredly a daft git.
Dear readers, this is a man who recently Tweeted "Iranian Twitter activity similar to what we did in House last year when Republicans were shut down in the House."
Wow. Really?
For a good chuckle read Pete Hoekstra is a Meme.
I'm reminded of Ted Stevens' famous take on the Internet as a "series of tubes".
Pete's also running for Governor of Michigan.
Enjoy...
Thus, Pete Hoekstra is hereby awarded my second ID Ten C Award for foolishness above and beyond the call of duty.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Graham Cluley's blog states:
Hoekstra told The Washington Times' America's Morning News radio show that "it's time for America, South Korea, Japan and others to stand up to North Korea" by launching a retaliatory cyber attack or international sanctions.
Graham took Hoekstra to task for this moronic idea yesterday, before today's headlines quickly began to reveal the possibility that the attacks against S. Korea and the US may have actually originated in the UK. The simple reality is, maybe it did, maybe it didn't. The premise that one nation state should launch a cyber attack against another based on the presumise that they might be responsible for a DDoS attack is short-sighted to say the least.
Should we now cyber-bomb our British friends, Mr. Hoekstra? I believe, amongst other things, we and the Brits can agree that you are assuredly a daft git.
Dear readers, this is a man who recently Tweeted "Iranian Twitter activity similar to what we did in House last year when Republicans were shut down in the House."
Wow. Really?
For a good chuckle read Pete Hoekstra is a Meme.
I'm reminded of Ted Stevens' famous take on the Internet as a "series of tubes".
Pete's also running for Governor of Michigan.
Enjoy...
Thus, Pete Hoekstra is hereby awarded my second ID Ten C Award for foolishness above and beyond the call of duty.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Thursday, July 09, 2009
MIR-ROR updated, v1.1 now available
MIR-ROR 1.1 is available on the CodePlex MIR-ROR site. This is a minor update to the MIR-ROR script including a repaired path declaration. We also removed a pause statement to promote improve WMI scripting with MIR-ROR.
MIR-ROR is a specialized, command-line script for incident response that makes use of the Windows Sysinternals tools, as well as some other useful tools. Further, you can easily enhance the script to your liking with whatever command line tool you require for response.
Thanks to Bryan Casper, Mike Maonde, Alex Alborzfard, Gene Morganti, Andreas Bunten, Harlan Carvey, and Rick Wanner for feedback after the initial release.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Tuesday, July 07, 2009
ColdFusion, SaaS, and negligence
Recent headlines have described news pertinent to ColdFusion-related vulnerabilities and hacks specifically targeting the FCKEditor text editing tool, and the CKFinder file management tool. There have been further indications of attackers uploading a ColdFusion web shell as often seen on vulnerable PHP platforms.
These discussions reminded me of two significant pet peeves.
1) ColdFusion error verbosity and how useful it is to attackers.
2) Negligent vendors who do absolutely nothing about security vulnerabilities they've been advised of; worse still, when the vendor is a SaaS provider.
Case in point: WebPublish CMS
I communicated with these folks at multiple intervals via email and telephone from February 20, 2009 until April 23, 2009. It took multiple efforts just to get through as my messages were manually interpreted as "potential SPAM". Trust me, my security advisory language does not trip SPAM filters and is most often easily and well received. Yet, after finally making a connection, I received the classic "we don't have the time and resources to address this issue any time soon." To which I replied with useful resources for mitigation and remediation. My last received communication stated "I will have a look and see if I can incorporate as much as I can." That was two and half months ago.
I think we can agree the tenets of responsible disclosure were followed, yes?
Thus, a seemingly capable, growing SaaS provider quite simply blew me off.
So be it. Here's my favorite example of something they should immediately fix: A cross-site scripting (XSS) vulnerability exhibited in the ColdFusion error page leading to significant information disclosure (ID) while indicating possible SQL injection (SQLi) vulnerabilities. Wow, really?
A screen shot complete with a wee bit 'o appsec humor courtesy of an IFRAME insertion:
Now take this absurdity to the next level.
As many a vendor is prone to doing, WebPublish CMS sites clearly state that "This site is powered by WebPublish".
How helpful.
Try intext:"powered by WebPublish" via Google.
Just a few results, yes?
We'll use a few for further analysis. What do they all have in common?
kellyprecision.ie
multiples.ie
netcommunications.ie
snapprinting.ie
webpublishcms.com
Yep, all the same IP, as in all on the same server.
Core application vulnerabilities in a primary service offering (SaaS) from one vendor, on one server, affecting hundreds if not thousands of clients.
See the problem?
Negligence, plain and simple.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
These discussions reminded me of two significant pet peeves.
1) ColdFusion error verbosity and how useful it is to attackers.
2) Negligent vendors who do absolutely nothing about security vulnerabilities they've been advised of; worse still, when the vendor is a SaaS provider.
Case in point: WebPublish CMS
I communicated with these folks at multiple intervals via email and telephone from February 20, 2009 until April 23, 2009. It took multiple efforts just to get through as my messages were manually interpreted as "potential SPAM". Trust me, my security advisory language does not trip SPAM filters and is most often easily and well received. Yet, after finally making a connection, I received the classic "we don't have the time and resources to address this issue any time soon." To which I replied with useful resources for mitigation and remediation. My last received communication stated "I will have a look and see if I can incorporate as much as I can." That was two and half months ago.
I think we can agree the tenets of responsible disclosure were followed, yes?
Thus, a seemingly capable, growing SaaS provider quite simply blew me off.
So be it. Here's my favorite example of something they should immediately fix: A cross-site scripting (XSS) vulnerability exhibited in the ColdFusion error page leading to significant information disclosure (ID) while indicating possible SQL injection (SQLi) vulnerabilities. Wow, really?
A screen shot complete with a wee bit 'o appsec humor courtesy of an IFRAME insertion:
Now take this absurdity to the next level.
As many a vendor is prone to doing, WebPublish CMS sites clearly state that "This site is powered by WebPublish".
How helpful.
Try intext:"powered by WebPublish" via Google.
Just a few results, yes?
We'll use a few for further analysis. What do they all have in common?
kellyprecision.ie
multiples.ie
netcommunications.ie
snapprinting.ie
webpublishcms.com
Yep, all the same IP, as in all on the same server.
Core application vulnerabilities in a primary service offering (SaaS) from one vendor, on one server, affecting hundreds if not thousands of clients.
See the problem?
Negligence, plain and simple.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Wednesday, July 01, 2009
Malzilla: Exploring scareware and drive-by malware
Yesterday included a SANS ISC diary post regarding a tool list useful for de-obfuscation. Amongst the entries was Malzilla.
Fortuitous timing I say!
My toolsmith column for July's ISSA Journal is a complete analysis of Malzilla's capabilities.
Malzilla is best described as a useful program for use in exploring malicious pages, allowing you to choose your own User Agent and referrer and use proxies. While it downloads Web content, it does not render it, so it is not a browser. Think of it as WGET with a user interface and some very specific talents. In Using Malzilla, we’ll take a close look at rogue AV tactics and exploit sites in order to study the infection process utilized.
Lenny Zeltser contributed great feedback regarding Malzilla for this piece, thus furthering the tool's credibility.
Give the article a read and add Malzilla to your arsenal.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Posts (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...