Steps To Prevent Gumblar / Martuz / Nine-Ball

Now that people are starting to finally notice the huge success of the recent trends of malware that attempt to obtain your FTP credentials, I thought I would try to compile together steps to prevent this type of attack. Now there has always been the battle of security and convenience and I truly believe that until this trend dies down, it is crucial for all companies to lean a little more towards the security side of things and to just deal with the lack of convenience.
No one is safe from this type of attack, including Bank of America, Cisco, Amazon, and even my own company McAfee (see link) . The security of your webserver is now also dependent on the security of your employees workstation or laptop.

So what can be done to prevent this type of attack? It will really be dependent on your server configuration, but there are always steps that can be taken.

CLIENT SIDE: Lets start by looking at steps that your employees can take in order to help prevent their workstation from being compromised with the root of the cause, MALWARE. These are not in any real order of convenience or impact of security.

1. Make sure that your anti virus is up to date: Even though there is a very low detection rate on these exploits, it is always recommended to have an Antivirus installed and make sure that it is updated regularly.
2. Make sure that you are running Windows Update: The more patched your system is, the less exploits you are giving an attacker to try to compromise your workstation with.
3. Make sure you get over to Adobe.com and update both Flash and Acrobat : These for the most part, are the exploits that attackers are attempting to compromise your workstation with. They are using exploits that have been identified in flash and acrobat months ago and have already been secured by adobe.
4. Disable Javascript access to Adobe Reader: Very useful and for the most part, you wont notice it disabled.

• Click on "Edit" from the file menu bar, then "Preferences."
• From the open dialog box, select the "JavaScript" item.
• Uncheck "Enable Acrobat JavaScript".
• Click "OK" .

5. Use a Secure FTP client if available: One of the methods that attackers are attempting to retrieve your FTP credentials, is to sniff out your plain text passwords when you connect out to your FTP server. If you use a secure FTP client, your passwords will not be sent in plain text or unencrypted. You will want to make sure that your FTP server accepts Secure FTP authentication.
6. Run an anti malware program like Malwarebytes: This is an awesome application that will attempt to discover if malware such as gumblar is infecting your workstation.
7. Change your passwords more frequently: Change your passwords often. This includes your workstation , FTP, cPanel or Bind, ect ect. There are even settings that will automatically change your FTP credentials Daily. You might want to utilize this feature until this trend calms down (or forever).
8. Install a client side firewall that checks for open inbound and outbound connections and alerts you of any changes: An example would be Zone alarm: These are extremely annoying but will be beneficial in the long run.

Server Side: Now lets look at server side modifications that will assist in the prevention of Gumblar based attacks. Once again, in no order.
Do you think that your website is a current victim of Gumblar? Step on over to www.unmaskparasites.com and find out.

1. Install an FTP server that allows Secure connections: There are so many FTP applications out there that allow the client to connect using a secure connection. For all you know, the FTP server you are using now might have this feature. Check it out.
2. Individualize FTP user credentials: Go back and reassess who has credentials. Do they actually need them? If they do, individualize the user name. This will assist in determining where the insecurity is coming from. You will be able to identify what user is compromised and is leaking their credentials.
3. IP restrict your FTP server: Create a whitelist of all IP addresses or ranges that are currently accessing your FTP server. Blacklist everything else.
4. Setup some type of application or routine that checks new or modified files on the server for unauthorized modification: Catch them in the act and prevent them from being able to modify files. List your file system by last modified and verify that the modification is authorized.
5. Routinely check your FTP log files for unauthorized activity: Grab your FTP log files on a daily or weekly basis and review all inbound connections. Check the IP address that established a connection and verify that it is authorized.
6. Make sure that you are running some type of Root Kit detection application on a regular basis: Added Protection, nuff said.
7. Step on over to a site like Unmaskparasites.com and check your site for current presence of malware. Wepawet is also another service that is used for analyzing malware sites. (quickly identifying malware on your website is something that I would consider damage prevention)


I think I have touched on most of the current methods of prevention. All of these are not necessary but will all help in prevention. If you are on a shared server, contact your hosting company and ask what they can do you to help prevent this issue.
Last but not least, if you have any other methods for prevention, let me know.

First attendance to an OWASP chapter meeting.

Yesterday June the 22nd I was able to attend my first ever OWASP SF chapter meeting at the SF Federal Reserve. Overall, it was a pretty cool meet up. I really enjoyed that the meeting was at the federal reserve building because on entry and exit to the meeting you really got to see the reserves security practices in real time. When we arrived we had to wait for a large enough group to be checked in and escorted to the conference room. They did not take security lightly and even stopped us all and required that we all wear our badges above the waist and visible. Once we were in the conference room, there was the usual IT diet (Pizza and Soda) and it was somewhat social which is always cool for networking.
There were two talks presented during the meeting. The first talk was presented by Jeremy Brotherton on "Analyzing Web Malware" which I found quite interesting because he went into depth on the exploitation of the recent Trend Gumblar which I have previously posted on(here and here). The talk focused on decompiling the Flash file that was used as the method of exploitation for gumblar which was very interesting for me being that I have never really dove into the actual cause of exploitation.
The second talk was by Dave Maynor on "Threats on the Go-Go, Web Threats to Mobile Devices". This was an eye opening discussion on Mobile Devices and the false assumption that all mobile devices are secure. The discussion was very interesting and will definitely motivate me to keep an eye out on Mobile Devices and their current state of security.

I think it would be beneficial during these meetings to go back elementary school style and have some time to randomly sit with peers and be able to introduce yourself and talk about current topics. I think that one of the greatest aspects of these meetings is to network and meet other professionals in your field of study. Living in Napa, it is quite difficult to meet other security professionals and to sit down and throw ideas back and forth.

Until the next meeting.

Hackersafe and Scanless PCI trustmark on same Website.

Got a cool email this weekend from "The Institute for Application Security Specialists" giving notification for the grand opening of their new store loaded with awesome ASS merchandise. Now you can let everyone know that you are an ASS, by proudly displaying the ASS logo wherever you go.
One thing that caught my eye on their store is the display of both the Mcafee Secure logo and the Scanless PCI logo.

I love it, even though the McAfee Secure badge is coming from the certification of cafepress, It is still an awesome sight and quite odd.

OnSite Audits, a Go for Level 2 Merchants.

In my Opinion, a positive step in the direction of PCI compliance has occurred that now requires all level 2 Merchants to have an annual OnSite Audit Conducted in order to obtain their compliance. This to me is a huge step over the security/convenience battle that I believe is having a large impact on PCI being an actual legit security solution. Now MasterCard is the only company who has made this positive change, but it will still need to be enforced, and I am hoping that all will follow suite.

Check the nfo...Link

Dear Webhost, Please enable Logging. Thank You.

Working with compromised accounts that have fell victim to the recent trend of Gumblar and Nine-Ball, I am noticing that there a lot of Web Hosting Companies that do not have logging enabled. They will either have RAW web access logs enabled for one day worth of retention (absolutely useless) , or none at all. So with that being said.

Webhosts, Please enable logging.
Please allow logging retention of at least 1 year.
Please enable FTP logging.

PCI DSS Requirement 10.7 asks that you retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. The entire portion of Section 10 in the requirements are devoted to audit trail and storage of log files. This is a very crucial entity to analysis of the webserver. If you are not retaining log files, then you are not running a PCI complaint hosting environment, Bottom Line.

How many Security Professionals does it Take to tell Google that it could be more secure?

And the answer is......37. You can put 37 different security gurus into one room and I can almost guarantee that if you bring up any current security topic, you will always hear pros and cons to each side of the story and its actual impact from a security standpoint. Give these professionals the topic of Making services within google such as gmail default to using high levels of encryption via SSL, and you have an unanimous agreement(its a no brainer). That is was occured in sending a letter over to google, in which google responded the very same day on their blog. To me, that is making an impact, and you are making google consider decisions that will affect a lot of users and a large impact to the overall security of the internet. I can properly justify that statement being that anything Google is doing, could some way impact the entire status of the internet.

Pretty Cool Stuff.

A look back on Twitter

For the Record, I think that an application like Twitter is one that will be mimicked often from here on out. Being a fan of Blogging, I have no problem with the idea of a "Micro Blog" and believe that the concept will be seen for years to come. I also believe that an application like Twitter will be used widely by security professionals as not only a way to tweet or communicate, but a way to share resources quickly maybe changing the game from zerosec to zerotweet. I can already mentally see how superior the crew in the movie Hackers would have been, with the ability to tweet at each other to pool resources and communicate. There would simply have been no need for a movie they would have been so leet. It would have at least spared all of us from a sequel.

With all of the articles that are being posted on Twitter it is no secret that they have been plagued with one security issue after another. I myself was even able to jump on Twitter about three weeks ago, and within a couple of minutes find some severe security related issues that will need attention by the busy Twitter staff. Aviv Raff posted today that he is going to blog on "July: Month of Twitter Bugs" in which I will try to follow closely because I not only want to see what he digs up, but I am also confident that it will spark up a lot more issues from other security professionals regarding twitter and their lack of security.

With my post today, I wanted to bring a little bit of historical data to the story of Twitter and there is just some things that do not make a lot of sense to me when I go back and look at the details. One of the common tools that I use often when assessing the overall security of a website is www.archive.org . Going back and reviewing archived pages of a website can be useful in so many different ways, but to me twitter has a lot more to reveal.
Besides the observation that Twitter.com has most likely been plagued with security issues since day one, the first thing that I noticed was "Wow, Twitter has sure been around a long time, why has it seen an enormous amount of growth only recently. Stats on Complete.com show that Twitter is really a product of 2009 (can be argued, but the stats do show convincing evidence), and to be sitting there basically idle for so many years is just crazy to me. It really makes you feel that twitter was not ready for the super boom and it just came somewhat out of the blue. Now I know that there are a lot of factors that play into Twitters recent popularity including the recent boom in Web enabled Mobile Phones , but I would most likely attribute that the major cause for the spike in popularity of twitter is due to its marketing and public craze having the feeling that if you are not on twitter, then you are not up on the newest social playground. I see this type of marketing as being the future trend in social networking sites jumping from one popular service to another leaving the previous site dried up like a ghost town.

The question that has been mind bottling to me is, when does a company like twitter , take a step back and identify that security needs to be a very large aspect to their product? You would assume that increasing in popularity by some million fold percentage would do it or their increase in budget ( I am only assuming they have a larger budget now these days, if they dont, there is a larger issue than security going on). Is it possibly going to take the Month of July and all of its bug releases and Blogging to have them go into overdrive with security?

One of the largest realizations that I made when I first came into Web Application Security, was that large or small, every company or website can be plagued with issues and to not trust a large website just because it is large and everyone else is using it. Twitter can really reinforce this observation and hopefully will bring some light into peoples eyes. But then again, does it stop the public from tweeting.

I can honestly say, that by following other professionals or groups, Twitter has had a positive influence on myself in the world of security. Maybe their developers should add a few more Twits to follow like the entire group SecurityTwits.

A must (IMO) for PCI to be successful.

This post might be a duplicate post for me, but every day that I work with the PCI standard, I am more convinced that something needs to change, so I want to touch back up on it.
PCI is honestly my favorite standard in the progression of web application security out right now. Not because of the fact, that I believe that it is making an impact, but I do feel that it gives me the leverage as a consultant to force customers to secure their website.

One of the largest issues that I believe to be contained in the standard of PCI compliance, is their balance between identifying if a website or payment application is secure and the ease of use/compliance for the customer. I honestly feel that the requirements for PCI compliance are fairly minimal in verifying actual security.
Now, working at McAfee secure I should be the first one to be able to recognize that in order to have a successful standard or product, you must also make sure that your standard is obtainable. If you create a standard that is out of reach for most customers, then you will clearly have issues with generating a following that is not only able to satisfy the necessary conditions, but are willing to support the standard itself. The issue with this, is that you will soon find that you might have to make decisions about your product or standard that might not be in its best interest from a security standpoint, in order to accommodate the customer in being able to satisfy conditions to meet the standard.
Now, ask every security professional out there and they will most likely tell you the exact same answer, "There should absolutely be no accommodation's or settling, when it comes down to security". Based on this answer, I must say, that if PCI is going to be successful, they must find a way to properly verify that the payment application or website is secure, while still making the standard, an obtainable one.

I touched a little bit on this before in a previous post "who takes pci seriously" but I honestly believe that the only way that this standard is going to have a chance at being successful is to take the customization out of the customers hands. What do i mean by this?

Every e commerce site on the internet that takes Credit Card information , must have some type of payment application or shopping cart. In working with customers who come to us or end up compromised you start to notice certain common patterns. One of these common patterns that I have been able to establish, is a customer is way way way more prone to their site being compromised if they use their own custom payment application or shopping cart.

Chances are, with most custom payment applications or shopping carts, the application or shopping cart itself was not coded correctly with any type of security coding best practices, and is most likely insecure in one way or another. THIS WILL NEVER STOP. You are always going to have websites who would like a shopping cart custom tailored to their product, and they are not going to shell out the money to make sure that their custom app is coded correctly. This happens every day and for the most part, will never cease.

What does PCI need to do to head this issue off at the pass?
This type of programming will never quit, and if PCI wants to do anything about it, they need to act sooner than later. I believe that the Payment Application or shopping cart must be checked with the highest standards for security and there must not be any accommodation's in verification. One way to do this, I believe, is to make it apart of PCI's standard to state that all payment Applications must either be approved by the PCI council by going through some type of high level certification (VISA's list of validated payment applications) or the application or shopping cart must be subject to a level 1 audit.

What this will accomplish.
This should assist to eliminate all of the horribly coded shopping carts out there that look like they are apart of foundstones Hackme series containing literally every web application vulnerability that has been in current use for the last decade. Web site owners, will not just be able to hire the local web developer to create a very sophisticated shopping cart with their 3 months of development experience. There are so many approved shopping carts out there, that I feel that at least one of them would be able to accomplish the task and be customizable enough for the customer. If it is not, they obviously have a product that is unique and should have the funding to create a custom shopping cart and send it through the certification process.

In my opinion, this is a must. This to me is the only way to help verify that a payment application is secure and was written with coding best practices and security guidelines. This is also one of the only methods that I see fit, that after an initial fight, would be able to be adopted by anyone who is storing, processing, or transacting credit card information. Obviously an adjustment this large to a standard would need a grace period, but by some time before lets say the end of the world in 2012, a standard like this should be able to be adopted and carried out.

I am really interested in identifying either a better solution in improving the PCI standard or in identifying the faults in this type of modification. Any opinions would be greatly appreciated. I feel that PCI has made a huge start in helping to secure e commerce online, but it is still very far off of accomplishing its task.

An update to updating.

One of the things that I keep telling myself that I am going to accomplish, is to update this blog more frequently. It is not the fact that I am picking up people who actually read this thing, but I would like to document more often, trends and issues that I am currently experiencing at my employment. The obstacle that I have been currently facing and have been facing since day one, is to publish to a blog, while never attempting to speak negatively about another security professional or company. I have no problems trying to identify an issue within a specific security practice, protocol or organization, but I will not use this blog to self promote myself by slandering another "professional" or the actual product of a specific company.
The reason for this, I am still what I consider a young individual in this field. There is no way that I am going to cutoff or eliminate opportunities to meet, discuss, or debate with security related professionals or issues.
So, with that being said, I am going to try to update this blog more often. I will try to stick with my ultimate goal here and try to properly document experiences, trends, and issues that I have been facing during my current employment. Although I find it very difficult to hold my tongue every once in a while because someone out there is being absolutely stupid from a security standpoint, I will try my best to focus directly on the issue itself from the security point of view and try not to include the individual or companies product.

I feel that this is a vital aspect to being a Security Professional and slandering an individual or company is something that I will leave to the 12 year old hackers.