Re: Recommendation on PHP encoder please

On 05/02/2004 at 10:46 Adam Bregenzer wrote: >On Thu, 2004-02-05 at 08:13, Harry Sufehmi wrote: >> So there's a reasonably easy way to decrypt those encoded files then ? >(despite those vendors' claim...) >There isn't a program to revert encoded files to their original state, >but there is a disassembler[1]. However, assuming your encryption key >is a string all one would need is to do strings <filename> on the >encoded php file to get your encryption key. >[1] http://www.derickrethans.nl/vld.php Interesting :-) much thanks. >The real problem you are facing here is security through obscurity is >not security. First of all, your method of encrypting these files and >decrypting them before serving up pages is just going to slow down your >web server. My manager reckons that it's worth it. And it's causing very little traffic anyway. >The key is stored in a file somewhere and therefore easily >accessible if someone gained access comparable to the web server. Since >the key is readily available the data is not really encrypted, just >obfuscated. The key should be contained within the script itself, so it'll be scrambled by the encoder. >I assume you are not transmitting these pages over the Internet and even >within your intranet are using SSL? If not then that is a much bigger >security hole. It's transmitted over the Internet using SSL. >If you are really dedicated to encrypting these files I have a possible >suggestion (see below for big caveats!). Continue with your encryption, >however do not store the password anywhere on the server. You could >either require the password be typed by users to view the pages (and >*don't* cache it in any way anywhere!) Hmm... the users shouldn't know the password to the key really, they have problems already remembering just one password :-) more than that and they'll start writing it down on post-it notes... hehe >or write an extension to apache >(or whichever web server you use) to request the password when apache >starts. It would then securely store it in ram and use it to decrypt >pages, similar to how encrypted SSL certificates are handled. This >would not be a php based solution, if php were to have access to the >password then all that would be required to retrieve it would be the >ability to execute custom php on the system by the hacker. This is the best solution I think, but unfortunately I don't think we have the resources to develop this. >You could >try writing a php extension that would handle this however you may have >a few problems: >1.) Depending on the web server used the php library's lifetime in >memory may be shorter than the web server, or there may be multiple >copies of the php library in ram. This would require typing the >password more than once per web server restart. That's why I'm planned to store it in the encoded script instead. >2.) You need to make sure it is not possible to access arbitrary parts >of php's memory using documented or undocumented php functions, etc. If >so a cracker could write a php script to obtain the password. >3.) You would need to disable the dl() function so a custom extension >could not be loaded to grab the password, though php.ini could be >modified and the web server restarted. Then all the cracker would need >to do would be to wait for you to re-type the password. >Additionally make sure core dumps are disabled on the server, otherwise >forcing the web server to crash could put the password in the core file. >You know, after writing all that I realized something else: these are >web pages being served. If the attacker has root access to the system >what would prevent him from just using lynx to view the pages directly >form the web server? SSL won't stop him/her and usernames and passwords >will most likely be available if you use web based authentication. Your >best method would be to require the password be typed every time a page >is viewed, which has its own set of problems. Bingo ! :-) Nice one Adam, you've found the hole in this scheme. >Hopefully this gives you something to think about. Indeed... so for now looks like there's no elegant solution to this problem. I'll have to rethink everything now - well better now than later after the server's been cracked open :-) Thanks, it's been a very interesting discussion. cheers, HS -- Kampanye open-source Indonesia - http://www.DariWindowsKeLinux.com Solusi canggih, bebas ikatan, dan bebas biaya v0sw6Chw5ln3ck4u6Lw5-2Tl6+8Ds5MRr5e7t2Tb8TOp2/3en5+7g5HC - hackerkey.com