Re: Hack attemps on Joomla
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]
<drexxl@...> wrote:
> 03Nov2008 (UTC +8)
>
> On 11/2/08, Christian Masancay <csmasancay@...> 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
<moralesphilip@...> 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
RSS Feed