Hi PLUGgers,
Good discussion here so far. It seems this exploit has been posted
already in Google, August this year (as per link given). As per
member's suggestion above, my inputs here is to subscribe to some
sites that posts some vulnerabilities and exploits too. I'm not sure
if you can find the "real" action pertaining to this exploitation.
Though you mentioned already that you've (Philip) lockdown the sites
and force the customers to update their apps which is a good idea
already.
Doing your own (pen test) would be good, but some can be done via
consulting or outsourcing depending on your company policy and of
course the need.
Kudos to all!
Thanks,
Mike
On Tue, Nov 4, 2008 at 2:25 AM, Christian Masancay <[EMAIL PROTECTED]> wrote:
> Good morning,
>
> Hi Drexx, I believe that we are on the same industry, but I guess you
> can say that I just see things differently. Don't worry, you don't
> have to lecture me about SQL Injection. I'm very familiar and very
> creative with it.. =) It's a general recommendation, but it's fairly
> straight-forward. Anyway, I do understand what you're saying so here
> is my "expounded thoughts" about this vulnerability and its possible
> solutions:
>
> The query where the web application retrieves the user based on the
> token provided is outlined below:
>
> $db->setQuery('SELECT id FROM #__users WHERE block = 0 AND activation
> = '.$db->Quote($token));
>
> When a user requests a password reset in Joomla, the application will
> send an email to that user. The email contains a randomly generated
> token which will be used to change the password on the web
> application. When the user provides the token to the web application,
> it tries to find the user associated with that token. If an attacker
> substitutes a single quote as a value of the $token variable, then the
> SQL statement would be like this:
>
> SELECT id from #_users WHERE block = 0 AND activation=" ";
>
> The Quote function of the $db or $database variable returns a quoted
> string with all characters that have special meaning for the database
> removed. Given the SQL statement above, the reset will be for the
> first user in the result set, which is likely an admin account.
>
> The documented fix is to check if the $token variable length is not
> equal to 32 characters. A valid token doesn't contain just a single
> quote and should be 32 characters in length.
>
> if(strlen($token) != 32) {
> $this->setError(JText::_('INVALID_TOKEN'));
> return false;
> }
>
> Hi Philip,you can remind your customers to upgrade to the latest
> Joomla version or apply the patch (the block of code above) on the
> /components/com_user/models/reset.php page. In addition to what Drexx
> has already said, make sure that the web server runs under the apache
> account (don't worry, this has been the default since eternity). For
> network controls, you can also use a firewall that can filter/validate
> web application traffic, specifically the confirmreset action of the
> form and the contents of the $token variable.
>
> Although I believe that the Common Criteria is overkill for this or
> may even be irrelevant (At the bottom of my silly mind, the TOE is not
> even a security product), you can surely try to audit your
> implementation based on that standard..=) Maybe having a defined PP,
> SFRs, ST, plus a nice level of confidence/QA (SARs and EAL) would be
> ok..just kidding, I think I know what you mean...=)
>
> Aside from the OWASP Development Guide as guidance, you can also
> suggest the OWASP Testing Guide
> http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents
> to your customers for conducting tests/audits to validate their
> remediation implementation on their web applications.
>
>
> --
> Sincerely yours,
>
> Cris
>
> "In the lower marketplace, the accountant is just a face. The musician
> is just a state. People are darker than it seems - 11226|68]-["
>
>
> On Mon, Nov 3, 2008 at 3:54 AM, Drexx Laggui [personal]
> <[EMAIL PROTECTED]> wrote:
>> 03Nov2008 (UTC +8)
>>
>> On 11/2/08, Christian Masancay <[EMAIL PROTECTED]> wrote:
>>> Given the circumstances, the risk exposure may be limited only to the
>>> application layer. You can minimize the security risk if you have
>>> strong operating system and network controls.
>>
>> I believe such general advice begs for a better clarification. By
>> itself, it *may* mislead the PLUG readers, to misunderstanding the
>> risk exposures, which will be then underestimated, and therefore
>> inadequately treated. Care to expound on your thoughts?
>>
>> For you see, one can get really creative and mix SQL with shell
>> commands in MySQL statements (using the prefix "system"). Or, on MS
>> Windows with MS SQL (yes, also with Joomla) systems, it is easy to
>> reconstruct tools like the Metasploit "metsrv.dll" or "nc.exe" using
>> the xp_cmdshell stored proc, which will re-assemble text files using
>> debug.exe --without even uploading (in the traditional sense of the
>> word) anything. Needless to say, it's way more than the ' OR 1=1--
>> kung-fu because you got the O/S right then and there.
>>
>> But of course, once you obtain even limited access but with privileges
>> that has later been escalated (allowing writes to the filesystem), you
>> use the web application to get you where the money is: databases. Add
>> to the web application more SQL statements that will record names,
>> account numbers and PINs on a temp db, which you can then just get
>> them later at the your convenience. (Yes, you just made the web server
>> itself as a "key logger".) And we're not even doing any XSS yet on the
>> web application server. That's just not theory, but actual exercises
>> done recently.
>>
>> But I digress. To add more to my previous answer to Philip's question:
>> 1. Verify the filesystem and web app's ACL for your htaccess.txt and
>> make sure it doesn't leak out. All you input validation controls on
>> the web application are for nothing if the attacker can easily figure
>> them out. It's a common implementation mistake with this one.
>> 2. Go to http://<site>/index.php?option=com_user&view=reset
>> 3. Enter a valid admin e-mail address. Google around to find out who
>> owns the website, and then who's the admin for it. Don't forget
>> LinkedIn, Friendster, Yahoo Groups or Facebook ;)
>> 4. SQLi the input field where it asks for a verification token, then
>> reset the password of the attacked user, and login.
>>
>> I've simplified it a bit, so as not to make this too easy for the
>> script kiddies out there. Kindly let me know if this works for you too
>> please?
>>
>>
>>> On Sat, Nov 1, 2008 at 8:18 PM, Philip Morales <[EMAIL PROTECTED]> wrote:
>>> >
>>> > I received the following about Joomla Password Remind Functionality -
>>> > Exploit" attack
>>> >
>>> > ---------------------------
>>> > There has been several (successful) hack attempts in the past 48 hours
>>> from
>>> > your network:
>>> > below you will find a small overview of the different IP address and the
>>> > timestamps they were used,
>>> > at the end of this message you will find the complete http log file
>>> entries
>>> > which proof this is a
>>> > full "[20080801] - Core - Password Remind Functionality - Exploit"
>>> attack.
>>> >
>>> > 89.108.36.198 - - [30/Oct/2008:06:02:10 +0100]
>>> > 89.108.31.218 - - [31/Oct/2008:00:37:13 +0100]
>>> >
>>> > Pleas take appropriate actions.
>>> > ---------------------------
>>> >
>>> > Our Linux server was hacked was due to insecure software hosted by one of
>>> > our customers,
>>> > normally this should only affect the website of the customer it self -
>>> not
>>> > the entire server -
>>> > but since this has happened in the past days we decided to locked down
>>> > customers websites and
>>> > force the them to update their software for this particular
>>> vulnerability.
>>> >
>>> >
>>> http://developer.joomla.org/security/news/35-core-security/241-20080801-core-password-remind-functionality.html
>>> >
>>> > vulnerability exists in all versions prior to 12-08-2008.
>>> >
>>> > Do you know any additional fix I can do?
>>
>>
>> Drexx Laggui -- CISA, CISSP, CFE Associate, ISO27001 LA, CCSI, CSA
>> http://www.laggui.com ( Singapore / Manila / California )
>> Computer forensics; Penetration testing; QMS & ISMS developers; K-Transfer
>> PGP fingerprint = 6E62 A089 E3EA 1B93 BFB4 8363 FFEC 3976 FF31 8A4E
>>
> _________________________________________________
> Philippine Linux Users' Group (PLUG) Mailing List
> http://lists.linux.org.ph/mailman/listinfo/plug
> Searchable Archives: http://archives.free.net.ph
>
--
Michael F. Mondragon
GPG Key ID: F3892203
M: +63 929 232 5070
W: http://michaelmondragon.wordpress.com
E:
- iam [at] michaelfmondragon [dot] info
- mmondragon [at] phcert [dot] org
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
