http://www.bbc.com/news/technology-29595214

Recently I decided to make sure that no online shopping site had a record of my credit card. Since I almost always sign-on as a guest, they shouldn't be keeping my card beyond the specific transaction. But I don't know if this is true.

Here's the troublesome situation. I tried to delete my credit card from Amazon. When I did, I was presented with a confirmation message saying (paraphrasing) "do you not want your credit card presented as a means of payment? Yes/No"

When I thought about this, I realized that I was not being given the choice to have my card number deleted, but only not to have it shown. This pi$$es me off.

Facebook has a record of my credit card as well. I tried to go through their process of deleting it from the site and received an error message every time. Followed their exact guidelines. It's kind of terrifying how all this data is just floating around.

Unless you're tuned into technology chances are you guys don't have a clue how bad the past 6 months have been from an IT security perspective..

(10-13-2014 12:35 PM)QuestionSocratic Wrote:  Recently I decided to make sure that no online shopping site had a record of my credit card. Since I almost always sign-on as a guest, they shouldn't be keeping my card beyond the specific transaction. But I don't know if this is true.

From a practical perspective, it's probably not true, but it's not even relevant. Target and the like were exploited from point-of-sales transactions (i.e. if you swiped your card in-store, you may have had your card stolen.

(10-13-2014 12:37 PM)JDTulane Wrote:  Facebook has a record of my credit card as well. I tried to go through their process of deleting it from the site and received an error message every time. Followed their exact guidelines. It's kind of terrifying how all this data is just floating around.

It's terrifying that of all web sites, you trusted Facebook with your card. They're jacking with security settings all the time (at least they were a couple of years ago. It wouldn't surprise me if they made a change and everyone's CC info was automatically posted as their status at one time...

(10-13-2014 12:41 PM)Bull_In_Exile Wrote:  Unless you're tuned into technology chances are you guys don't have a clue how bad the past 6 months have been from an IT security perspective..

Target didn't have a website hacked, they didn't really have stored data hacked. They had in-memory data stolen from their point-of-sale system. When that is possible, your credit card is only as secure as the MC and Visa purchase protections... you may as well have flicked your cards through the sunroof driving by capitol hill.

(10-13-2014 01:32 PM)I45owl Wrote:  

(10-13-2014 12:41 PM)Bull_In_Exile Wrote:  Unless you're tuned into technology chances are you guys don't have a clue how bad the past 6 months have been from an IT security perspective..

Target didn't have a website hacked, they didn't really have stored data hacked. They had in-memory data stolen from their point-of-sale system. When that is possible, your credit card is only as secure as the MC and Visa purchase protections... you may as well have flicked your cards through the sunroof driving by capitol hill.

Target was more than 6 months ago...

I'm talking about heartbleed, shell-shock, and a nasty little glibc vulnerability that have popped up since March... In 15 years of UNIX work I've never seen such a deluge of problems.

Keep in mind some of the POS attacks are meant as points of egress into a corporate network (hence the insanity of self checkout points and why every time $EMPLOYER brings it up I shoot it down). Once in the hope is to find one of the big vulnerabilities.

Heartbleed I can understand as a nightmare. Shellshock didn't affect us at all, and I'd be surprised if it affected production financial servers, as I think it would mean that you're running cgi scripts. None of the servers I work with were affected by those two, as we didn't use openssl or bash in production servers.

(10-13-2014 02:33 PM)I45owl Wrote:  Heartbleed I can understand as a nightmare. Shellshock didn't affect us at all, and I'd be surprised if it affected production financial servers, as I think it would mean that you're running cgi scripts. None of the servers I work with were affected by those two, as we didn't use openssl or bash in production servers.

I am beyond amazed that shell shock did not affect you. If you run Linux, ESX, or Solaris then you are one of the few orgs in the world than can say that.

Shell Shock was not just cgi scripts, it's an error in bash which allowed arbitrary execution of code to any service which could make a bash system call. That inlcudes java, php, jsp, (py/jy)thon, perl, and services like DNS, DHCP, and SMTP. Any time a developer said "F it, Ill ask the system what the time is, or Ill use the fopen for the file, they opened you up for this.

Heck my Bro-In-Law runs a lab with a Linux DHCP server. His admin walked with flipped open a clean laptop on their guest netowrk and changed the root password on half the systems in his infrastructure.

Shellshock is the only true 11/10 I have ever seen on the UNIX side of the house. Where heartbleed only effected rather recenter versions of openssl (1.0.1c-1.0.1f I think) the bash error has been sitting there for more than a decade. Funny enough heart bleed did not hit us at all because we were not running RHEL6.3/6.4/7beta at the time.

To be clear on the day it hit any UNIX machine running gnu bash (Linux, Solaris, along with some BSH/Aix/HPUX) were all impacted.

Besides UNIX operating systems you're also talking about linux/bsd based appliances (both real appliance like stoves and IT ones like SAN/NAS gear). It is also going to hit hypervisors like ESX and IBM's HMC's.

Heck I even saw a few advisories for CISCO networking gear, high end stuff. Lets just say that normally I have to beg to patch certain systems and when this one came out I got a blank check to patch whatever I wanted whenever I wanted. It took a few days but now everything I am responsible for is complaint.

If you have not re-mediated the patches you are sitting on a time bomb..

(10-13-2014 03:05 PM)Bull_In_Exile Wrote:  I am beyond amazed that shell shock did not affect you. If you run Linux, ESX, or Solaris then you are one of the few orgs in the world than can say that.

Shell Shock was not just cgi scripts, it's an error in bash which allowed arbitrary execution of code to any service which could make a bash system call. That inlcudes java, php, jsp, (py/jy)thon, perl, and services like DNS, DHCP, and SMTP. Any time a developer said "F it, Ill ask the system what the time is, or Ill use the fopen for the file, they opened you up for this.

By bash system, do you mean (in perl lingo):
as opposed to, say:
or, simply:

Sure, it can be done in java/php/jsp/py/perl ... I can't imagine DNS/DHCP being so naive as to do so, much less SMTP code (are you talking sendmail, or webserver interfaces to mail services?)

I've seen some really stupid shortcuts, but don't recall much java code that would make use of a system() call or the like. File management may be the one exception.

That said, we don't have a significant amount of gnu code on the platforms that we work with.

True system calls (as in "man 2 fopen") should be unaffected by shell shock ... higher level scripting language "system" calls I could see as a problem. The shellshock vulnerability itself is in the application level code.

(10-13-2014 03:45 PM)I45owl Wrote:  By bash system, do you mean (in perl lingo):
system("bash date");
as opposed to, say:
system("date");
or, simply:
$t=time();
($sec,$min,$hour,...) = localtime($t);

In Bold are the potential vectors.

Quote:Sure, it can be done in java/php/jsp/py/perl

And has..

Quote:... I can't imagine DNS/DHCP being so naive as to do so, much less SMTP code (are you talking sendmail, or webserver interfaces to mail services?)

All depends on the implementation not the specific protocol. Qmail was very hackable and the dchp server that ships with most *NIX variente also *TA-DA* sets environment variables. There have been documented DHCP exploits, they were the second wave right after CGI DOS attacks.

Quote:I've seen some really stupid shortcuts, but don't recall much java code that would make use of a system() call or the like. File management may be the one exception.

How is it do you think that weblogic and websphere track the process, log, and resource usage by the JVM's they spin up?

Quote:That said, we don't have a significant amount of gnu code on the platforms that we work with.

You would do very well to look at your storage appliances, network gear, and ESX systems (particularly if you're running ESX appliances)

Quote:True system calls (as in "man 2 fopen") should be unaffected by shell shock ... higher level scripting language "system" calls I could see as a problem. The shellshock vulnerability itself is in the application level code.

Even a normal sshd server ith the "command override" enabled in sshd_config could allow access to the machine.

This was a cern 10/10 for a reason. BEcause you did not need authorized access to the system in order to crack it.

That being said if you are mostly an AIX/HPUX shop your metal should be fine.

I didn't even realize K-Mart was still around

(10-13-2014 03:55 PM)Bull_In_Exile Wrote:  How is it do you think that weblogic and websphere track the process, log, and resource usage by the JVM's they spin up?

I would hope that they are using OS calls (fopen(), ) and not the "system" system call... it's a java based server and I'm not sure how they interface to it offhand. From Oracle Metalink, it's in badly named "products that do not include bash, and are therefore not affected list": http://www.oracle.com/technetwork/topics...17675.html

(10-13-2014 03:55 PM)Bull_In_Exile Wrote:  

Quote:That said, we don't have a significant amount of gnu code on the platforms that we work with.

You would do very well to look at your storage appliances, network gear, and ESX systems (particularly if you're running ESX appliances)

Quote:True system calls (as in "man 2 fopen") should be unaffected by shell shock ... higher level scripting language "system" calls I could see as a problem. The shellshock vulnerability itself is in the application level code.

Even a normal sshd server ith the "command override" enabled in sshd_config could allow access to the machine.

This was a cern 10/10 for a reason. BEcause you did not need authorized access to the system in order to crack it.

That being said if you are mostly an AIX/HPUX shop your metal should be fine.

One variant of a platform we may use generally runs linux on top of ESXi. Given where that is placed in the network, that could be a potential disaster. Appliances in general are potential security disasters, especially SMB that may not have adequate support.

I don't doubt that it's a serious vulnerability. Problems in either a shell or SSL certificates are bad... But, if there's an enterprise-level product that is vulnerable because of bash, it seems a fundamentally poor design. OpenSSL? **** happens ... it's embarassing, but it's hard to be perfect.

(10-13-2014 06:18 PM)WMD Owl Wrote:  I didn't even realize K-Mart was still around

Let alone that any of their shoppers actually have credit cards or debit cards.

(10-13-2014 03:55 PM)Bull_In_Exile Wrote:  

(10-13-2014 03:45 PM)I45owl Wrote:  By bash system, do you mean (in perl lingo):
system("bash date");
as opposed to, say:
system("date");
or, simply:
$t=time();
($sec,$min,$hour,...) = localtime($t);

In Bold are the potential vectors.

The second of these does not or should not invoke any shell (bash or otherwise). It's an inefficient and lazy way of getting the result, but there's no reason that should be a problem unless there were a vulnerability with the "date" program.

(10-13-2014 07:03 PM)Fort Bend Owl Wrote:  

(10-13-2014 06:18 PM)WMD Owl Wrote:  I didn't even realize K-Mart was still around

Let alone that any of their shoppers actually have credit cards or debit cards.

Where do you think all of the credit cards stolen from home depot are being used?

One point about removing "saved" or " stored" credit cards on a site; It is a blatant pci violation for a company to actually store your credit card number. A company should NEVER store the actual credit card information. What happens is that, if you want to save your card on the site, is that the site gets a "token" from the credit card processor when they process the card. The site would then submit the token to the credit card processor for future purchases you make. The credit card processor knows the credit card details associated with the token. The token is no good to anyone else. If the company gets hacked, the hacker would get a list of competent useless tokens. So basically, the company should never know or store your cc info. And as long as they don't, there shouldn't be a problem.

(10-13-2014 06:49 PM)I45owl Wrote:  One variant of a platform we may use generally runs linux on top of ESXi. Given where that is placed in the network, that could be a potential disaster. Appliances in general are potential security disasters, especially SMB that may not have adequate support.

The nice thing about ESXi is that you can patch the gnu components and reboot the console while all your vm's keep running..

Quote:I don't doubt that it's a serious vulnerability. Problems in either a shell or SSL certificates are bad... But, if there's an enterprise-level product that is vulnerable because of bash, it seems a fundamentally poor design. OpenSSL? **** happens ... it's embarassing, but it's hard to be perfect.

You are 100% right that code should not use shell but after 15 years working for (1) State Government, (2) Federal Government, (3) Financial Institution, (4) Health Care provider, and (5) Big Retailer I can tell you it's done literally everywhere...

Keep in mind though qmail and dhcp services were straight out compromised, no matter how well designed.

(10-13-2014 07:44 PM)I45owl Wrote:  

(10-13-2014 03:55 PM)Bull_In_Exile Wrote:  

(10-13-2014 03:45 PM)I45owl Wrote:  By bash system, do you mean (in perl lingo):
system("bash date");
as opposed to, say:
system("date");
or, simply:
$t=time();
($sec,$min,$hour,...) = localtime($t);

In Bold are the potential vectors.

The second of these does not or should not invoke any shell (bash or otherwise). It's an inefficient and lazy way of getting the result, but there's no reason that should be a problem unless there were a vulnerability with the "date" program.

You may be right, I'm not a Java guy and I know in some less interpreted languages the red statement would shell to the default system shell (which is BASH on Linux)...

(10-13-2014 07:49 PM)UofMstateU Wrote:  One point about removing "saved" or " stored" credit cards on a site; It is a blatant pci violation for a company to actually store your credit card number. A company should NEVER store the actual credit card information. What happens is that, if you want to save your card on the site, is that the site gets a "token" from the credit card processor when they process the card. The site would then submit the token to the credit card processor for future purchases you make. The credit card processor knows the credit card details associated with the token. The token is no good to anyone else. If the company gets hacked, the hacker would get a list of competent useless tokens. So basically, the company should never know or store your cc info. And as long as they don't, there shouldn't be a problem.

Tokenized data is considered PCI.. But the point of these attacks is to get it in transit and not via storage. Also the DQ and Home Dept breech involved compromising non-pci systems as an egress.