segunda-feira, março 26, 2012

Linkedin Portal URL Redirection (Open Redirection) Vulnerability


 After some time,  that is a old problem, but only now was fixed ...


=======================================================
Linkedin Portal URL Redirection (Open Redirection) Vulnerability
=======================================================

1. OVERVIEW

A security flaw on main linked in portal: www.linkedin.com

2. SITE SERVICE DESCRIPTION

LinkedIn is the world’s largest professional network with over 120 million members and growing rapidly. LinkedIn connects you to your trusted contacts and helps you exchange knowledge, ideas, and opportunities with a broader network of professionals.
More Information: http://learn.linkedin.com/what-is-linkedin/

3. VULNERABILITY DESCRIPTION

A security flaw on main linkedin portal: www.linkedin.com trough the "redirect" file with "url" parameter. This parameter is unvalidated by application resulting in a Open redirect Flaw, where it receive any url and forward the user for it. 

4. PROOF-OF-CONCEPT/EXPLOIT

+ Open Redirect (OWASP Top 10 2010 / A10 - Unvalidated Redirects and Forwards)

http://www.linkedin.com/redirect?url=www.google.com.br&urlhash=OpenRedirect

http://www.linkedin.com/redir/redirect?url=www.google.com%2F&urlhash=asasdad

5. IMPACT

This flaw can be used by a malicious user to send phishing to the linked in customers, abusing of the users trust on Linkedin portal, tricking the user. This user can be forward to a linkedin clone site to stolen credentials, to some malicious site hosting malware and more.

6. VENDOR

www.linkedin.com - http://www.linkedin.com

7. CREDIT

This vulnerability was discovered by:
Emanuel dos Reis Rodrigues
emanueldosreis at gmail.com
twitter: emanueldosreis

8. DISCLOSURE TIME-LINE

01-28-2012: Vulnerability discovered
01-29-2012: Vendor Contacted by e-mail Customer support support@linkedin.com,linkedin_support@cs.linkedin.com
02-04-2012: Vendor answer creating a ticket: 120129-000734
02-04-2012: Vulnerability Reported
03-26-2012: Vulnerability Corrected
03-26-2012: Public Disclosure

9. REFERENCES

Top 10 2010-A10-Unvalidated Redirects and Forwards


terça-feira, março 20, 2012

Joomla Privilege Escalation Flaw and some CMS hardening

On the last week, was released this flaw [1].

The problem is amplified by user auto registration on com_users, that, by default is allowed anonymous users to register themselves as Administrator leading to Joomla Administrator take over.

This problem affect 1.6.x/1.7.x/2.5.0-2.5.2 versions [2].

Now, many defacers are using google to find vulnerable sites to attack.

Dork: inurl:index.php?option=com_users&view=registration

May be that, coming soon , we have a rise of a worm to exploit it, …. remember about JBOSS Worm ? that use CVE-2010-0738 to spread ?


So, we have some mitigation options about this flaw:

-> Block the user auto registration resource on com_user

-> Upgrade to 2.5.3, because 1.6.x and 1.7.x have no patch yet.


For all Joomla's/CMS installation, you can follow some steps more:

- Remove all unnecessary plugins/components/extensions/others, keeping what really is needed.
- Use the minimum of extensions as possible.
- Use the lastest version of all components and core
- Only allow the apache user to write where really is needed.
- Keep yourself up to date about Joomla related vulnerabilities
- Remove all default users and groups when it is possible.
- Control the access to /Administrator, by source IP, change the Administrator path and block IP sources with a bad reputation
- Use some WAF - Web Application Firewall , as ModSecurity
- Use Antivirus, yes, do it at your Linux Server, it can save your life.
- Use a file integrity checker as AIDE.
- Use database and system accounts with minor privileges.
- Make a hardening on PHP configuration
- Take care about temporary folders as /tmp /var/tmp/ joomla uploads, e.g. don't allowing execution programs from here with noexec partition bit.
- Implement strong password policy for joomla' s administrators
- Use jail system for apache's instances.
- Always use captcha when it's possible
- Use Enhanced Security as SELinux or AppArmor


This is not all , but can be followed for generic CMS/WebServer Hardening…


[1] http://jeffchannell.com/Joomla/joomla-161725-privilege-escalation-vulnerability.html
[2] http://developer.joomla.org/security/news/395-20120303-core-privilege-escalation.html


t: @emanueldosreis