.comment-link {margin-left:.6em;}
Xavier's Security Post
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:
Governments, Non-profit organizations, Financial firms, Educational institutions, and countless other groups of sites are vulnerable.

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?
Comments: Post a Comment

Links to this post:

Create a Link

<< Home
This public blog will be a place for me to output any Security findings, both technological and physical, that I have come about. I will post Security advisories I was apart of, and also other interesting bits of knowledge. email: xavier [at] tigerteam.se

Rocks Clusters <=4.1 mount-loop local root
Rocks Clusters <=4.1 umount-loop local root
TSEAD-200606-6 - Rocks Clusters <=4.1 local root
xorgmodroot.py - Xorg-server 1.0 / <=X11R6.9.0-7.0 local root
TSEAD-200509-5 - Multiple Netscape.com vulnerabilities.
TSEAD-200512-3 - Multiple vulnerabilities in KISBG <=v5.1.1
fsigk_exp.py - FSIGK for Linux <=2.10-431 local root
TSEAD-200510-4 - FSIGK for Linux <=2.10-431 advisory
ritk.php - remote inclusion pentest tool
owm_exp.py - openwebmail <=2.51+ local root
perliodebug_exp.py - perlIO_debug 5.8.* local root
bankfix.py - bank card number lookup tool
TSEAD-200412-2 - AOL XSS/file read vuln
TSEAD-200412-1 - AOL redir vuln

September 2005 / October 2005 / November 2005 / December 2005 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / September 2006 / October 2006 /