Sunday, May 14, 2006
Security through Compression...?
While messing around with Flash/ActionScript generating products, I ended up at CoffeCup's Password Wizard product page. Several things came to mind; first: the product claims it can password "protect" unlimited pages, second: it contains absolutely NO warnings about lax in security, and three: it seems to have been downloaded by a large number of people.
The idea behind using a third party language and/or object/application to do password protection client side instead of server side is very dangerous. In this case in order for your password 'protection' to work, a user's browser ends up downloading the .swf file as an object and executes it under the web browsers flash plug in. Once the object is executed, you'll see a login window.
The problem lies in the fact that the authentication handling is done inside that .swf file/object. All an attacker has to do is download the flash file and he/she has the opportunity to see whats inside. It is understandable that the common user doesn't have concepts of security in mind, and sees such products as useful tools for their personal web sites. That is where the things turns ugly.
Imagine a situation where an attacker is aiming to break into a server; he spends his time mapping out the target, scanning for common vulnerabilities, and somehow in the mix discovers a loan password.swf in a users directory. He downloads the file, uses GNU strings to simply gather the logins within.
According to some sites you can secure your flash password protecting file by simply compressing it! I found several other sites claiming the same thing -- but lets just note that compressing the file will simply stop one form of seeing the logins. The other form is simply to decompile the flash file. Read my previous posts to get an idea of what kind of damage a that can do.
Back to the hypothetical story though. By now the attacker has either found the logins he was looking for by using his favorite text editor or GNU strings, or he's gone and decompiled the file. Now with logins at hand, he can extend his penetration by gathering the usernames and passwords, and use them towards his advantage if those same logins happened to be used on the server as well.
With free time I looked through Google for password "protected" sites. Surprisingly I was faced with a rather surprising number of hosts hosting these insecure files. Here are a few I found to be interesting:
Who is to blame? the company who sells a product which contains no warnings of its own insecurities, or the user herself for relying on third party applications? ¶ 5/14/2006 12:15:00 AM
The idea behind using a third party language and/or object/application to do password protection client side instead of server side is very dangerous. In this case in order for your password 'protection' to work, a user's browser ends up downloading the .swf file as an object and executes it under the web browsers flash plug in. Once the object is executed, you'll see a login window.
The problem lies in the fact that the authentication handling is done inside that .swf file/object. All an attacker has to do is download the flash file and he/she has the opportunity to see whats inside. It is understandable that the common user doesn't have concepts of security in mind, and sees such products as useful tools for their personal web sites. That is where the things turns ugly.
Imagine a situation where an attacker is aiming to break into a server; he spends his time mapping out the target, scanning for common vulnerabilities, and somehow in the mix discovers a loan password.swf in a users directory. He downloads the file, uses GNU strings to simply gather the logins within.
According to some sites you can secure your flash password protecting file by simply compressing it! I found several other sites claiming the same thing -- but lets just note that compressing the file will simply stop one form of seeing the logins. The other form is simply to decompile the flash file. Read my previous posts to get an idea of what kind of damage a that can do.
Back to the hypothetical story though. By now the attacker has either found the logins he was looking for by using his favorite text editor or GNU strings, or he's gone and decompiled the file. Now with logins at hand, he can extend his penetration by gathering the usernames and passwords, and use them towards his advantage if those same logins happened to be used on the server as well.
With free time I looked through Google for password "protected" sites. Surprisingly I was faced with a rather surprising number of hosts hosting these insecure files. Here are a few I found to be interesting:
http://oal.ohio.gov/Board.swfGovernments, Non-profit organizations, Financial firms, Educational institutions, and countless other groups of sites are vulnerable.
http://www.wwfpak.org/images/password.swf
http://www.infoaserca.gob.mx/mexbest/password.swf
http://www.iamb.it/en/password.swf
Who is to blame? the company who sells a product which contains no warnings of its own insecurities, or the user herself for relying on third party applications? ¶ 5/14/2006 12:15:00 AM