Tag Archives: Attack Vector

Botnet communications moving to Web2.0

Posted on by
2

A great find by Jose Nazario shows how botnets have moved on from relying on old-school communication schemes (usually IRC or direct HTTP connections) to utilizing the tools that Web2.0 provides.

I have been naming this development since it started being discussed in the back-channels, and predicted that these would be the next generation communication methods as they provide not only another layer of separation (anonymity) between the botnet manager and the controlled bots/trojans, but also a layer of scalability to the control scheme.

You can check out the last time I discussed this on my DefCon presentation slides which should be uploaded to the DefCon site soon. In the meantime here is an older presentation (at least 10 months old) where the same subject is being demonstrated (slides 31-32):
Behind the Scenes of E Crime July09

Basically, the Twitter messages are encrypted codes being sent between the command and control and the controlled bots, which is very close to the “homework” I mentioned at the end of my DefCon talk – encouraging researchers to look for “garbage” data on blogs and Web2.0 services which are actually encrypted data being passed over a public medium.

I guess that that’s one more issue to deal with when trying to deal with the growing threat of eCrime and cyberwarfare.

Are you Conficker-proof? Do you really need to be?

Posted on by
Reply

What a great way to sum up my last couple of posts – the Conficker media frenzy, and social aspects of web attacks. You can’t come up with these things anymore… Seems (for now) that the only real thing that came out of the Conficker issue is the fact that INFECTED machines started to look for info on a bunch of additional domains.

Side effect #1 of the media frenzy is the probable increase in the number of people buying security (AV) software (remember who was pitching the scare the hardest… see the ad just before the 60 minute spot on the previous post, and check out the scrutiny which McAfee was under at ZDNet).

Side effect #2 leads us to my previous-previous post and – you guessed it right, Rogue AV are taking advantage of the fact that people are searching for security solutions to protect themselves from Conficker, and manipulate users to install the rogue software… Classic social engineering meets security scare.

Bottom line (which should have been on every Conficker related story waaay before any advice on AV software): PATCH. Conficker can’t touch you if your Windows is up-to-date. Patched? Good, now go get an AV!

Social networking threats – the “hacker” story

Posted on by
1

As the social networking threats angle is picking up a lot of traction lately <pat_on_own_back>,  the folks at Netragard have posted a great write-up on using social networks as an attack tool – involving both social engineering as well as technical exploits. The post can be found here, and I just want to quote a couple of sections that I feel very strongly about:

“The social reconnaissance enabled us to identify 1402 employees 906 of which used facebook. We didn’t read all 906 profiles but we did read around 200 which gave us sufficient information to create a fake employee profile” … “After the payload was created and tested we started the process of building an easy to trust facebook profile. Because most of the targeted employees were male between the ages of 20 and 40 we decided that it would be best to become a very attractive 28 year old female. We found a fitting photograph by searching google images and used that photograph for our fake Facebook profile. We also populated the profile with information about our experiences at work by using combined stories that we collected from real employee facebook profiles.”

Needless to say that the newly created fake profile, which could just as well have been hijacked, went a long way in terms of enabling the attackers (who were commissioned to perform a penetration test this time) to gain access to internal company resources quite easily.

Fighting an infection vector with new standards – ClickJacking

Posted on by
Reply

If you haven’t heard yet, the newest version of Microsoft’s Internet Explorer 8 (RC1) have been endowed with support for “Anti-Clickjacking” (for more background on clickjacking, check out: http://ha.ckers.org/blog/20080915/clickjacking/).

This new feature is basically an implementation for a new header (X-FRAME-OPTIONS) that is returned from a server which defines the scope of “netsing” that is allowed for a specific site. This means that sites can potentially have control over whether their content is allowed to be rendered inside an IFrame element – and where (on pages from 3rd party sites, only on pages within the site itself, or not at all).

The solution that is being proposed here is nice, but time will tell if or when sites would start adopting it. Nevertheless, while playing around with the new feature behavior, I noticed that without much PR, Firefox is also supporting the same functionality.

cj
Image 1: blocking the inclusion of a site in an IFRAME where the site returned a header X-FRAME-OPTIONS: DENY

cj2
Image 2: Firefox blocking the included IFrame, and showing the actual header returned from the site.

Now with only Chrome and Opera to jump on the bandwagon, we might actually have a chance to see some changes in the web security landscape (as you may remember – most of the web borne attacks are delivered through the inclusion of an invisible IFrame hosting malicious code). That isif only this protocol could have been reversed to define that no IFrames should be rendered ON a said site, thus preventing injected IFrame elements from being delivered to the users of a compromised site.

Malicious code, exploit vectors or top-programmer job?

Posted on by
Reply

What would you say if you saw one of these code snippets in a website you browse to:

dim tass

Set tass = CreateObject(“CnsHelper.CH”)

If IsObject(tass) then

HasCns = true

else

HasCns = false

end if

or:

function winIE5upPlyrDetect(){
var playerAxObj;
var iectlAxObj;
try{
iectlAxObj = new ActiveXObject(“Shell.Explorer”);
}
catch(e){
}
try{

or:

var fs = new ActiveXObject(“Scripting.FileSystemObject”);

try {
//open file, 8=appends to file, true=will create file if doesn’t already exist
var a = fs.OpenTextFile( fileUri, 8, true );
a.Writeline( text );
a.Close();
}

You are probably looking at this and thinking, “ok, what is he going to show us now – some newfangled attack vector, spyware drive-by installer, local system access…”. Guess again.

Sample #1 is coming from Yahoo.com (more specifically http://cn.zs.yahoo.com/func.vbs), and yes – you saw that correctly, is creating the CnsHelper.CH object – an object that multiple sources consider an unwanted AdWare application (see: http://www.trendmicro.com/vinfo/grayware/ve_graywareDetails.asp?GNAME=ADW%5FCNSMIN%2EA, http://www.spynomore.com/bho-hijacker-toolbar-cnsmin.htm, http://www.pestpatrol.com/spywarecenter/pest.aspx?id=453072511, …)

Sample  #2 is unreal. Well, actually it’s real. Real.com. (http://uk.real.com/js/playerdetection.js?rev=9507). This is how a developer tests to see if the browser looking at the page is Internet Explorer…

Sample #3 is the all powerful walmart.com (http://www.walmart.com/kiosk/js/log.js) which, and I’m quoting the code comment right before the function (sit tight):

/**
* Opens a local file and appends a string to it.
* Returns boolean indicating succes of opening/writing.
*/
Right. When browsing the web…

You do the math. Just think now how hard it is to work in such a demanding environment, where the good guys do not always follow the good guys coding manual (what? Didn’t you all get the memo?).

Till next time,