You loose



  • [url=http://img329.imageshack.us/img329/6807/librairieaw4.png]Screenshot[/url] live from website [url]http://www.librairie.be[/url]. Seems some AJAX is not very well working somewhere.



  • I hope you understand the difference between 'loose' and 'lose':

    lose = opposite of win
    loose = opposite of tight



  • @pinkduck said:

    I hope you understand the difference between 'loose' and 'lose':

    lose = opposite of win
    loose = opposite of tight

    I believe in this case, loose is the opposite of strict.  



  • Guess what, it's not even related to ajax. And when I look at the source I hope the author will stay away from it for a while.

    This document is composed of 1 main document and 10 iframes. Doh!

    Try to open the website on a 1024x768 screen you get an awful inside horizontal scrollbar.

    For the frames, source code is just retarded. Document's header being invalid, the document type shows up ... http://217.136.227.214/scripts/foxisapi.dll/MercatorIshop.MercatorIshop.sqlExec?sql=p_prevente&page=ph_prevente. Don't hit too hard, website must have been done by a poor student working at one of these night shops ... the software it relies upon is probably not responsible for this wtf, but still, I'd stay away from that mercator e-commerce thing ( and by the way, presenting a product using a powerpoint on a website is another wooden table variation to me )

    It's funny to see what all these iframes are used for. Look at this one. How cute, eh ? Enjoy the source code, now you know every clerk's birthday ;-)



  • A little update, being unfair to that mercator product. The wtf being it's an accounting software used as content management, well, you can expect suboptimal peformance.

    But then I saw something Wayyyyy too classic :

    http://217.136.227.214/scripts/foxisapi.dll/MercatorIshop.MercatorIshop.searchSqlItem?sql=select stock_x.* from stock_x where s_id_famil='N1PX0NSDNN' and s_cat3='DISTRI' and s_retour>=date() order by s_retour&n=25

    Duh. You know what, don't do it ;-) 



  • It doesn't work anyway:

    Sql token not allowed !



  • Well, what brings the more security around this site is that ... it's not worth the effort ;-)

    Anyway, there is also a user database ( you can replace the table name by 'users' ) ; and field names are available from subscription form. Then, you could just alias column names in the articles list query to display personnal information about users. Fortunately credit card numbers seem to be used only in a separate site. Clear passwords may be not avaiable but even if you get a hashed value, you can import them and bruteforce locally.

    Being business, that's not secure enough. Available SQL injections could be (criminally) profitable and there is at least a potential privacy leak.



  • @pinkduck said:

    I hope you understand the difference between 'loose' and 'lose':

    lose = opposite of win
    loose = opposite of tight

    Yes (and in this case as mentioned it's the opposite of strict for xhtml dtds)

    I just could come with a better subject line :p
     



  • @aikii said:

    Well, what brings the more security around this site is that ... it's not worth the effort ;-)

    Anyway, there is also a user database ( you can replace the table name by 'users' ) ; and field names are available from subscription form. Then, you could just alias column names in the articles list query to display personnal information about users. Fortunately credit card numbers seem to be used only in a separate site. Clear passwords may be not avaiable but even if you get a hashed value, you can import them and bruteforce locally.

    Being business, that's not secure enough. Available SQL injections could be (criminally) profitable and there is at least a potential privacy leak.

    Brute forcing properly salted MD5 could take quite some time, especially for good passwords.
     



  • @merreborn said:

    Brute forcing properly salted MD5 could take quite some time, especially for good passwords.

    For sure ... but what do you expect from this application and ultimately from its users ? ;-) In a couple of hours you'll get obvious passwords, and, a few days will be necessary for harder ones. I don't think it would take more than a week or two. Or does it ? I mean, if it takes years, we might as well publicize our password files, but this is not likely the case.

    One could make a little bot that searches google for other sites using that mercator e-commerce application and automate the exploit, getting information and most probably enabling some changes. Like turkish hackers did for PHPNuke portals. Fortunately, unlike PHPNuke this particular application doesn't seem to be much spreaded and most probably this website doesn't have many users. But unlike PHPNuke, it involves money, which makes these leaks rather serious.



  • @merreborn said:

    @aikii said:

    Well, what brings the more security around this site is that ... it's not worth the effort ;-)

    Anyway, there is also a user database ( you can replace the table name by 'users' ) ; and field names are available from subscription form. Then, you could just alias column names in the articles list query to display personnal information about users. Fortunately credit card numbers seem to be used only in a separate site. Clear passwords may be not avaiable but even if you get a hashed value, you can import them and bruteforce locally.

    Being business, that's not secure enough. Available SQL injections could be (criminally) profitable and there is at least a potential privacy leak.

    Brute forcing properly salted MD5 could take quite some time, especially for good passwords.


    Not really.  Four years ago, as part of preparations for an April Fools' prank, I used a modified copy of John the Ripper to do exactly that.  I was able to test six million passwords a second, enough to test all possible eight-character alphanumeric passwords in 421 days.  This is a highly-parallelizable task, so a modern quad-core computer could do it in less than three months.



  • This page lists mercator function (http://www.ineo.be/mercator/ishop/web_gen/home_f.html). Funny, you can really pass anything to searchSqlItem, like delet from stock?
     



  • @tchize said:

    This page lists mercator function (http://www.ineo.be/mercator/ishop/web_gen/home_f.html). Funny, you can really pass anything to searchSqlItem, like delet from stock?

     Ahah, they even document their own leaks ! For sure, it takes a "WTF?!" moment to realize those parameters are directly passed via the url.

    Like said previously, they seem to check if query is a select and nothing else. But the documentation gives out other tips. sqlExec only accepts predefined procedure names, and ... check out this example:

     <font color="#800000" face="Helvetica"><font size="-0">
    select date,str(piece,10) as doc,reference,nom as dev,


    '<TD ALIGN=RIGHT>'+padl(transform(tot_ttc_dv,('999 999 999.'+replicate('9',n_dec))),15)+'' as total_ttc


    from pieds_v,devises_x


    where (devises_x.id=pieds_v.id_dev)


    and (id_cli=cookies.id_cli) and (type=3)


    order by date
    </font></font>

    Yeah ! SQLHTML , here we are ! 



  • This one's not bad, too : 

    http://www.ineo.be/mercator/ishop/web_gen/Procedure-modifRemise.html

     You can set a 200% rebate and you get a negative total for you cart. But whatever I try ( cheating or not ), my session gets killed when I try to checkout. Website is either not in production, or it's not firefox compatible ...

     The real WTF is that, according to their unbelievably pixelized pdf-to-wooden-table-to-jpg-to-html pricing list, this ecommerce thing is worth €900 ( per mercator user, whatever it means. you probably first need  a license for their accounting software, a minimum of €500 if I get it right. )



  • @Carnildo said:

    @merreborn said:
    Brute forcing properly salted MD5 could take quite some time, especially for good passwords.

    Not really. Four years ago, as part of preparations for an April Fools' prank, I used a modified copy of John the Ripper to do exactly that. I was able to test six million passwords a second, enough to test all possible eight-character alphanumeric passwords in 421 days. This is a highly-parallelizable task, so a modern quad-core computer could do it in less than three months.
     
    And that's just assuming there is only 1 valid password in all the combinations, and that it's the last one in the list. Quad-core machines as you describe may start obtaining valid combinations within the first week.
     
    Statistical probability has never been my strong point and I was somewhat befuddled by the birthday "paradox", :), but if I'm right, the probability of finding 1 combo after N tries, assuming that the passwords are evenly spread, is
     
    A = all possible salted passwords
    S =  all passwords currently in the system
    1 / ((A / S) - N )
     
    Which is vastly greater than 1 / (A - N).
     
    (Bullshit detection greatly appreciated)


Log in to reply