Local PayPal Phishing – and why we need a CERT

This just came in the mail: (twice – at two different mailboxes – I must be a high value target for these guys)

A classic phishing email, with the only exception that it seems highly targeted at the Israeli market! (yeah – I know, I sound a little excited, but this is the first one I ever got…). Obviously, I am not the new owner of a BROWN denim jeans (eeewww!), so as I am very interested in who may want my PayPal details, a bit of digging brought this up:

 

  1. The phishing site (the one led to by the obvious “CANCEL TRANSACTION” link) is hosted on al3abnt.com.
  2. al3abnt.com is obviously not related to PayPal, and in a very unusual turn of events it is actually registered to a person, or at least something that may lead closer to a person than most phishing sites (that use whois anonymizing).
  3. The Whois registration (see below) also leads to a website on anasblog.me. This seems a personal blog from a local village called Salfit in Israel (I knew it reminded me of something… been around there a couple of times :-) ).
  4.  

  5. The blog (see screenshot below) seems pretty anti-Israeli (note the “we are with the third intifada” button on the top-left corner) – thus explaining the interest in local Israeli PayPal accounts.
  6. Obviously – there’s no-one to send the notification to… no CERT would handle this, and the police is almost comical in the way they reacted to calls of this nature…

I’m guessing that a CERT would have done the following:

  1. Publish a warning notification on the offending site, and the email template.
  2. Coordinate with ISP the takedown of the offending site and law-enforcement work to apprehend the scammer (A phone number is listed on the whois information – feel free to try it out :-) ).

Be safe out there!

Defining Penetration Testing

I have been fortunate enough to be working with a group of peers from the security industry over the past few months (since November 2010) on finally creating a solid definition of what a penetration testing is.

It has been a topic that has been abused, cannibalized, and lowered to a level where we (as in people in the industry) could not relate to it anymore. It was time to get the fake stuff out, and focus on content. We were all getting tired of “penetration tests” that were nothing more than a Nessus scan printed out and slapped on with the “security consultancy” logo.

Enter – the Penetration Testing Execution Standard.

This is our attempt to define what a penetration test should include – both from the tester side (vendors) as well as from the client side (the business/organization being tested).

It is the fruit of a huge collaborative effort from people who I consider to be some of the best in the industry. Getting together people who on their day-jobs often compete with each other, and come from different areas of the industry, all together and working on something as big as this has been a humbling experience. For that – you guys all ROCK!

Onwards to the content – remember that this is pre-alpha, and is aimed mainly to get feedback from everyone. A lot of branches do not appear in their full glory there, and some will surely not make it to the final edition. We welcome everyone to take a close look at this, contribute, criticize, assist, comment and generally get involved. Some of you may have been watching this and thinking we are holding back – could not have been further from the truth… In order to get to something as big as this we had to cap the number of participants in this revision in order to keep things somewhat organized, so this is a chance to get back in and offer your assistance – we promise to keep this as open as possible.

This is really exciting – for me at least. Hope some of you will be able to share this enthusiasm and weed out the industry from the bad form we got into.

the art of not thinking about elephants

We have been quite busy here at Security Art in the last few weeks (as the blog posting frequency suggests), but I figured I would provide a quick preview of some of the elements we have been working on in terms of risk management.

Now, I suppose you have read Yoram’s earlier post about risk informed decision making, so I won’t elaborate on this for too long, nevertheless, we are often posed with the question “so how does this apply to my organization”. this usually comes form someone who did spend a lot of time and resources on the technical aspects of their network security. The answer is usually “let’s take a look at how you do your business”, which is what we usually do anyways…

Having that in mind, we set off to investigate in a few recent engagements how would some of our clients actually fare against an informed and skilled attacker that has been commissioned to break into the organization. These engagements have been prompted by a few incidents in which the organization in questions was basically left in the dark as they were basing their forensics on the tools that commercial security vendors provided them with, and nothing much more than that (remember the ever expressive “generic” detection from your AV vendor… Ever wonder what it really means?).

With that in mind, and a network to steal data from as a target we accepted the challenge. The only caveat is that the network was disconnected. For real. No Internets…

But (and there’s always a “but”), there was a voice network that went out through PSTN to provide the office with telephony connectivity. Bingo. Ever seen a complete separation of the VOIP network and the internal network? yeah, neither have I. To make a long story short, we managed to get the data in the most old fashioned way possible… we beeped it away (actually transmitted over a VOIP connection using a custom written simulated trojan that encoded the data into audible voice signals and left them as a message on one of our voice mailboxes). Done deal. (and the PoC code can be found here if you’d like to play with some of the conecpts).

Bottom line – always remember that when you think of solutions, you should not be “blinded” by what’s available out there and the accompanying marketing materials. That’s basically the “pink elephant” that vendors tell you not to think about when pitching their solutions. You usually end up thinking about it (and buying the product thinking that you’ll never see that elephant again as you just bought the best “anti-elephant” solutions…).

Always challenge the way you think of networks and processes (we did have to get the code INTO the network somehow… but that’s for another post :-) ), and ALWAYS test your assumptions and protections. You’d be surprised how easy it mat be to out-compartmentalize you just because you were boxed in to take care of just a single aspect of the security 9and yes – that even applies to CIO’s, CISO’s, etc…).

Stuxnet Analysis Report

So, after quite some time of working behind the scenes, and making an effort to focus on essence rather than buzz, the CSFI have published their official report on Stuxnet.

I have had the opportunity to assist (just a bit… work has been taking its toll) in the report writing – mostly inCSFI Logo terms of countermeasures for a threat like this, and some basic analysis.

Feel free to download the report form here:CSFI_Stuxnet_Report_V1

As well as watch the demonstration video on the CSFI website: http://csfi.us/?page=stuxnet

Kudos to all the great contributions from the CSFI-CWD (Cyber Security Forum Initiative – Cyber Warfare Division)  fellows!

The Botnet Wars – industry Q&A

I was approached recently by Bart Parys from Panda security in order to participate in an industry expert Q&A about the botnet wars (apparently he did his homework as he got quite the lineup to participate in this, guessed he can count me as a close miss :-) …).

He managed to compile a great Q&A where you can read some of the views and opinions on the current state of business at the Botnet (including exploit kits and crimeware kits) marketplace.

The full article is available at: http://malwaredatabase.net/blog/index.php/2010/10/25/the-botnet-wars-a-qa/

Enjoy!

Pentesters and businessman are doing it wrong

Following my last post on the realistic cost of a pen-test (which as I mentioned was derived from long conversations on the topic with a couple of friends from the industry), I’d like to review one of the best presentations I have seen lately – Chris Nickerson’s Brucon talk.

I’ve had the opportunity to see this talk shape up to be what it ended up like in the week or so that we have been hanging out together. And let me tell you – it was one hell of a week. There were some reactions to the talk (no wonder – Chris was on stage) and I’d like to put things in perspective (at least mine, if you want more go talk to Chris…).

The first point which is directly derived from the talk is that we, as an industry, have been doing the wrong thing for a long time. Pentesting has become a glorified minion work, and we just kept it behind for such a long time. What the talk tries to say is open your mind, and DO YOUR HOMEWORK. Chris calls it “do work”, but I’m saying that before we do work we need to do homework. Learn. Inspect. Absorb. See beyond the technical aspects of a pentest. Understand what is the environment in which the business operates, who are the key players, partners and customers. How does the business make money? What would hurt the business the most? Only then, we can approach the pentest with a clear goal in mind (and no – it’s not getting root/shell on a box).

The second point that I’d like this talk to provoke is that we are not the only ones at fault. It’s also the customers (yeah – I said that the customer is wrong. Sue me). They have been trained to ask for technicalities. Be it a pentest, a product or even a service. Most of the times they can’t really explain the methodology behind what they are asking for and the business relevance of it. Instead of asking for a pentest for a new web application, they should be asking for a security assessment of what makes their business “tick” which may be related to the web application. Small difference in wording, HUGE difference in scope and ROI from such an engagement. And yes, this all comes back to us as we have been offering “off the shelf” pentests that have no actual relevance to the business side, and have “technofied” our services and products to fit checkboxes of some obscure regulatory compliance. We need to retrain our customers (i.e. the industry) and get ourselves trained on the business aspects as well.

This topic is just one of many more that were conceived during the security-on-steroids-week which was Source Barcelona and Brucon. I’d rather post these side-effect ideas that were generated from discussions around the talks than the actual talk contents (you should be able to download these anyway in the near future from the conference websites anyway).

Tying up loose ends before Vegas (scammer closure)

Instead of updating the post in question (again), I figured I’ll post all the new info here and call this a wrap.

So, we all know about the security scammer now, and the different ways he is working to defraud innocent users and steal their data and money. It has been quite an experience tracking this scam down and getting all the facts right (from the technical aspect of inspecting the keylogger and binaries used to sniff your data, to actually communicating with the scammer and getting his take on things).

Nevertheless, I must say that I appreciate the consistency in which our scammer (I’ll call him Fadzil Mahfodh as that’s his real name) has been trying to mask his wrongdoings. From trying to go around the facts and divert us to other software:

To “bragging” about his skills and the fact that his scripts are “leet” enough to get past some people:

And finally to the obvious – throwing a fit and trolling – initially by threatning to post my picture and CV on adult websites (what would my CV be good for on an adult site anyway??? must be a Malaysian thing :-) ):

All of which has been accompanied by adding my picture to his website (wow! I’m famous now!):

Getting it removed by the Google Blogger DMCA team, opening up a new blog site to accompany the specific “hack wpa without a dic” post along with my picture, and making some cosmetic changes to the site, removing the FBI log (which has been replaced with a larger DHS logo), and adding a disclaimer at his website stating that this is all a mistake, that I have been trying to pressure him into criminal actions, and that he has all our communications logged and will be happy to use it to prosecute. Too bad this has been removed from his site before I had a chance to document it – but trust me it was there! Pure epicness!

Now, I know – it’s not really fair to pick on these guys that hard. That’s why I’m leaving this to the Malaysia CERT (as you may have noticed, 1337 Fadzil forgot to proxy his connections to this blog and his IP has been logged on all comments and relevant hits on the site), to figure out how to handle. I truly hope that his suggestion to use the details provided on his paypal account and bank account will actually yield some results, and wish our friend the best of luck in his endeavors in the security business (although I highly doubt he’ll be at DefCon later this week).

Below are attached some of the additional supporting materials for the sake of fully disclosing all the communications with Fadzil.

Apache-access-log_FILTERED, Fadzil-chat, karma-decoded.sh, bg2-decoded.sh

8/18/2010 – Last update (I really hope)

All right, so it seems that the good guys actually win sometimes, so I had to post this quick update just to fill everyone in on what has been going on:

  1. The original site (yeah – the bad design, background music, scam outright) has been brought down. Not sure if it was the Google DMCA team that kept bugging Fadzil on removing my pics, or the Malaysia CERT that came down on him for the malicious and scamming techniques.
  2. The replacement site (chikiabu.blogspot.com) which has been originally set up just to host the infringing materials after Google rained down on Fadzil, is now actually the main site, and SURPRISE – it does not have the scamming software anymore!!! 2 points for the good guys.
  3. The new site still has some “security” software. I have been getting some questions from readers who saw it and didn’t know whether to use it or not. So I had a few minutes to spare today, and have analyzed the “software” provided on it (namely – the famous fi.sh script which is the pinnacle of our subject’s programming skills). Long story short – still scripting with no real software in it. The fi.sh code is (again) a compiles shell script, and… here it is: fi.sh (the decompiled version of course). Funny thing is – obviously there’s no real coding here, just a bunch of “infconfig”, “iwconfig”, “airodump-ng” and “aircrack-ng”. One thing to note though, is that Fadzil makes it look as if each version of the script is designed for a specific wireless adapter – this of course can be achiever by correctly configuring your wireless adapter when running BT. Additionally, the posts on his website still entice users to send him their capture files (although at some point he makes the spelling error of saving a capture file as “.cab” – freudian?), and I’m guessing that he’s going to be asking for some “donation” to keep his site running. Don’t be tempted again kids…

That’s all there is to it I guess. Again – good guys win, site cleaned (and hopefully bad guy learned his lesson). Keep your eyes open out there, and until next time (September in Barcelona and Brussles) bye!