I'm sorry to hijack this conversation, but I felt I needed to bring up a
few pointers myself in light of what we do here at MU-SPIN utilizing PHP
4+ - PHP 5.0+ along with MySQL 4.1+
I should have brought this up at the meeting, but I figured that since
the majority of the GSFC web community uses Microsoft-based solutions,
our situation perhaps might be a more more of a "minority status" and
thus not to be brought up. Here at MU-SPIN it's all about open source
(LAMP) utilizing versions of PHP ranging from PHP 4.3.7 to PHP 5.0.4.
All versions of PHP 4+ do not always come standard with the Zend
libraries installed and/or enabled, thus, the ability to create a
prepared statement using PHP will depend on whether or not the Zend
libraries, or any other third-party library package that allows for
database prepared statement creation, allows you to do so. Because of
this, our SQL statements thus could not be utilized as prepared
statements, thus, what would you recommend short of an upgrade (assuming
an upgrade is not feasible at this time)? Also, stored procedures, by
the way, are only supported in MySQL 5+, which is worth noting.
Also, please see below comments, thanks
Phillip
LAROUCHE Francois wrote:
Hola Andres,
Sorry for that not making it clear. I have discovered that there were
multiple databases in the server so I tried to enumerate the tables and
columns in those too. It should say 'Database..syscolums'.
Ah ok gotcha!
I don't really understand the "res" field you mention. As I understand I
will only need to create the table with the fields the proc is >outputting...
hope you can explain this a bit more...
Sorry about that, I know it wasn't entirely clear. It's the name of the field
that I created in the table. I called it res to keep it cryptic in case
someone was doing some forensic after or looking during my pen tests. Yeah I
know... it's not really that cryptic but it's better than
OutputOfMySQLinjection... :)
Here are the steps you should do:
1. a) See if you have access to the database Pubs or Northwind and creation
rights (mea culpa to have said differently the last time, you have a lot of
rights on those databases but not the creation rights by default) But if you
have the rights, it's a safer place to mess up than the production database
b) If you don't, try to create a table in the database your user belongs to (a
big warning here, you have better to be sure of the consequences here...)
c) If you can't, try on a different database on your list (Again at your own
risk...)
d) If you still can't well sorry... I think there is no other way except those
already mentioned by the others (by the way to execute xp_makewebtask you need
to have high user privileges something you are obviously not)
2. So if you can create a table, create it with the fields you expect to
receive from your stored proc. What I usually do is to create a table with 6
nvarchar(4000) and 6 int, with this I cover most of my needs
3. Once the table created you fill it up with the data of your stored proc
during your SQL injection
Ex:
'; TRUNCATE table pubs.dbo.tmp; INSERT INTO pubs.dbo.tmp (res) EXEC
MyDB..TheStoredProc
4. Once this table filled, you can go read the data according to the SQL
injection method you used at the first place to read data in the syscolumns
table. Since you didn't confirm if it was by blind injection or not, I cannot
help you there.
Let's say it's the classic way:
aaa' UNION SELECT res FROM pubs.dbo.tmp--
Gotcha! Certain versions of MySQL do not support UNION, as I found out
the hard way. One of our instances has MySQL 3.23.58 and are currently
unable to upgrade, thus, you would have to do something like "CREATE
TABLE blah SELECT * FROM pubs.blah"
5. And after, you should drop the created table (dangerous manipulation if you
get the wrong one by accident)
I think it should be clearer now. I think I cannot go beyond with the syntax
than that without seeing exactly your web site. Hopefully it will be enough,
tell me if it helped.
Final note: everything that I stated are how things could be done, there are
some risks in doing some of them, especially the drop table operation. So I
won't be held responsible for any accident :)
Buena suerte
François Larouche
______________________________________________________________________________________________________________________________
This email, the information contained within and any files transmitted with it
(herein after referred as "the message")
are confidential. It is intended solely for the addressees and access to this
message by any other person is not permitted.
If you are not the named addressee, please send it back immediately to the
sender and delete it. Unauthorized disclosure,
publication, use, dissemination, forwarding, printing or copying of this
message, either in whole or in part, is strictly
prohibited.
Emails are susceptible to alteration and their integrity cannot be guaranteed.
Our company shall not be liable for this
message if modified or falsified.
