Jericho of Attrition.org (support the Open Security Foundation!) recently asked the VIM mailing list a question: Adobe Flash - vuln or just "design"?
The question, inspired by Mike Bailey's work for Foreground Security, leads to healthy debate, including press and vendor response. But, ironically the same day I received the VIM mail, I was led to explore a slightly different perspective on Adobe Flash issues. Thus, your author doesn't intend to get in the middle of above proposed curmudgeonly discussion.
I am however inspired to be curmudgeonly; grumpy even.
The crux of this conversation is the fact that the oft updated Adobe Flash Player continuously proves to be social engineering attack vector fodder. This is by no means news, or likely a surprise to the 19 of you who read this blog, but I recently stumbled on a real gem in the wild and I thought I'd share.
Whilst defending the Intarwebs from evildoers, I spotted
hxxp://www.abodeplugin.com/flashpayer/thankyou/flashplayer.htm
Explore this site at your peril, the binary sure isn't Adobe's; nor is it any update you want to install.
First, the use of letter juxtaposition (Adobe to Abode) is a pretty smooth endeavor likely to be missed by happily unaware clickers.
Second, the faux page layout is built largely right from the source Abod...er, Adobe site.
This irony is not lost on me: this "update" page is so pure it includes JSON formatted addon offers from Adobe, including a free McAfee Security Scan. Woot! You're going to likely need one if you install plugin.exe.
Speaking of, plugin.exe is a Trojan-Downloader.Win32.Genome sample that would normally go grab additional ill-intended binaries. Runtime analysis showed some common behaviors, though this sample seemed rather neutered.
1) Spawned a process and created C:\WINDOWS\system32\services.exe
2) Made a call to 212.180.97.163 (hxxp://www.sofec.21s.fr/k70.htm), now resulting in a 404.
3) Strings output was amusing (highlights parsed):
Buffer overrun detected!
unable to initialize heap
unexpected heap error
HeapDestroy
HeapCreate
HeapReAlloc
HeapSize
show me the money!
Nice. Really?
Who knows what additional evilware once lurked at 212.180.97.163, but it wasn't likely removed by anyone thinking clearly. The site hosted there is in miserable shape, suffering from numerous issues including SQL injection, horribly managed Frontpage extensions, cross-site scripting, and more. Which is to say, "give any one species too much rope and they'll f**k it up" (Roger Waters from Amused to Death).
So what's the lesson?
Negligence begets opportunity.
Opportunity begets maliciousness.
Maliciousness begets victimization.
Simple, yet entirely preventable.
The above mentioned combination of bad web application security and common malware practices likely means that someone may not have a nice Thanksgiving and that makes me sad. I don't like to be sad.
So beware fake Flash updates and button up your crappy websites so jerkwater ne'er-do-well's have less opportunity, damn it!
I am thankful for my dear family and all 19 of you readers.
Pass the Tofurkey!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Post Comments (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 ...
2 comments:
and we are thankful to you!
Yes we are!
Post a Comment