Thursday, July 30, 2009

Destination Vegas!! Yee


Getting ready to take off for Las Vegas to catch the end of the conventions. I was not able to get the time to attend Black Hat but on short notice, I am going out for the defcon meetup.

It will be nice to meet some professionals in the industry, and maybe the opportunity to display my special set of skills used in the art of seeking new employment, whatever that means.

Thursday, July 23, 2009

Top 10 Botnets


A quick Post.
Network world has released a nice article ranking the top 10 botnets in activity.
Ranked by size and strength.
Check it (Link)

Another critical issue with Adobe Products.



Yesterday the 21st Adobe posted on their blog that they are aware of a serious issue and will release more details. Walking into the office this morning, they have already provided more details.

"A critical vulnerability exists in the current versions of Flash Player (v9.0.159.0 and v10.0.22.87) for Windows, Macintosh and Linux operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat v9.x for Windows, Macintosh and UNIX operating systems. This vulnerability (CVE-2009-1862) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild via limited, targeted attacks against Adobe Reader v9 on Windows."

The Current Fix

"Deleting, renaming, or removing access to the authplay.dll file that ships with Adobe Reader and Acrobat v9.x mitigates the threat for those products, but users will experience a non-exploitable crash or error message when opening a PDF that contains SWF content."

Stay up to date on this issue via their security bulletin. (Link)
Also a good write-up by Avert Labs (Link)


Wednesday, July 22, 2009

Social Engineering: Check!


With everything that you hear about in the news lately regarding social engineering attacks (twitter), it makes you wonder how vulnerable you are to this particular type of attack. Now I have always had some common sense with creating passwords and security questions, but I have not always been that concerned with security and bottom line, IM LAZY.

These days there are multiple levels of authentication that are necessary in order to retrieve a password and although it makes it a little more difficult, if it is successful, it usually results in multiple accounts being compromised (myspace --> email --> other email). I have always tried to create unique difficult security questions for each service or application but this can really become a mess. It seems as though the only current solution to this type of mess is something like OpenId or a password manager, which has security issues and theories on its own, so I will not get into them. So for the most part, you are stuck with multiple sites, with multiple passwords, with multiple security questions, that might be dependent on another service or application for fulfill your password request whether it be authentication or reset.

While pondering all of these security issues with passwords and social engineering, the first thing that I went out and did, was try and reset my password on multiple services and applications to verify that I do not have a week security question or password. This was somewhat of a difficult task, because how would you define which services are in danger of being used for social engineering. I possible cannot figure out every single service that I have signed up with and setup my password and secret question for. What I have to do is analyze which services would ultimately lead to the compromise of high priority or sensitive services, whether it be its own, or another service.
I have included in this list.
Email accounts
Social Networking Sites
Financial institutions
Educational Institution
Work Related Sites.

All other sites I would use generic unique throw away passwords, and If I happen to forget, I would just have it reset to to my email address. I am not sure if this would be classified as a security technique, but more likely classified in the laziness category.

The next thing that I did, was visit any social networking sites that I belong to, to make sure I am not just giving away sensitive information that would assist in social engineering. I searched these sites for things like making sure my background is not my favorite color (although I would never try to use that type of question as my security question.). I feel that social engineering sites have the potential of giving away more security questions, than doing a deep dive search into someones background. This leads me to the third step that I checked out which is doing a basic search on sites like google for more information on myself. I was amazed that the majority of information leakage came from the registration of this domain (thanks whoever, to bad it is not very accurate). I thought when I purchased this domain, I payed for suppression of my information but I guess I need to revisit that.

It is not very easy to assess the difficulty of being victim to Social Engineering attacks. I think in all reality, the only way to really know, is by waiting. I guess it would be a good idea to ask a really good friend who knows you really well to try to get into some of your services even using his above average knowledge of your life. For me, if some type of compromise would ever occur, it would be more embarrassing than damaging and either way, I would love to prevent it from ever occurring.

Until then, thank you to google and yahoo for going back and reminding me to change my security questions and provide a secondary email address. That was very thoughtful.

Monday, July 20, 2009

YourMom may cause a breach of browser security.

Ha, Found this on Site Advisor (Link)

Even Better.....JamesLester may cause a breach in your browser security.
Link

Tuesday, July 14, 2009

Fun with Logs: Chasin Doods Down


Came in this morning just waiting for something to pop up to get my mind off this little heat wave.
First thing this morning I received another compromise and had an opportunity to do a little investigating.

The customer came to me stating after an email that alerted him to his website being compromised, he was able to identify a malicious file on his webserver and removed the file. The next day, the customer noticed that the file reappeared so he decided to query our service. After conducting an interview with the customer, I was able to request his RAW log files for parsing. This is where the fun begins.

After doing a quick parse of the log files searching for signatures related to recent trends, requests that contain sql injection, or any type of malicious activity, I was able to find a call to a malicious .php file. I documented the ip address, timestamp and name of the .php file and modified my parsing signatures to further break down this attack. After parsing out the .php file I was able to see in the log files the duration where the customer removed the .php file and where the attacker was able to re apply the file. I was able to use this information to further parse the log files and identify the IP address that initially setup the call to install the malicious .php file for the initial instance and the second installation. With this information I was able to go back and further modify my parsing to include all requests made by this malicious IP address. Right before a call to the malicious .php file I was able to document the request that the attacker made to use a page within the customers admin section to upload a .php file which contains the code to install all malicious .php files.
Forwarding all findings to the customer, he is now able to get in touch with his hosting company to secure his insecure section of his website.

There is really nothing out 0f the ordinary here, but it has been a while since ive had to do any investigating other than looking at FTP logs and identifying the issue as being Gumblar. It is nice to get back to using skills to chase down legitimate webserver attacks. It has slowly been picking back up and I hope that these types of opportunities come in at a steady rate. The more of these, the faster the day seems to go by.
And on that note, time to go home.

Monday, July 6, 2009

0day in Cold Fusion.......Bring Them On!


Adobe has Blogged about a severe issue contained in the FCKEditor that is enabled by default in some versions of Coldfusion 8. I have finally met up with this particular attack and am actually excited to receive it. It has been a while since I have worked with customers on a compromise that actually occurred due to the insecurity of their webserver (Im talking about you Gumblar).
There has not been a patch released yet, but I am sure that there is one to come.

In the mean time, I have some logs to review and websites to manually test( Actual Kinda Police Work Again).

If you are running ColdFusion 8, Here is a Temporary fix to mitigate the issue. Ill put it up nice and PINK Too!

1. Disable connectors by setting config.Enabled to false in the editor/filemanager/connectors/cfm/config.cfm file.
2. Remove unused cfm files under editor/filemanager/connectors/cfm directory of the FCKeditor.
3. Inspect FCKeditor directories for content that has already been uploaded. The uploaded files go under the directory specified in the config.UserFilesPath set in config.cfm.