Re: [Fwd: [user-support] Req #14348 - {redacted}- Cannot access issue]

[Arshad Noor <arshad.noor@strongauth.com>]

I believe the pain point that everybody's focused on is SSN, CCN and the
like, Allen; that's the low-hanging fruit for attackers.  However, once
they've realized that that avenue is shut down through encryption or
elimination, they will seek other avenues of attack.  Cookies, e-mail
addresses, IP addresses, physical mailing addresses, etc. will be the
tools by which they will attempt to compromise systems.

I personally know at least one e-commerce site that can be shut down by
simply changing the e-mail address of customers through one SQL update
query.  I have to believe that all e-commerce sites currently do not
encrypt e-mail addresses (or maintain message digests on database
records to indicate unauthorized changes) and thereby have the same
vulnerability.

In time, businesses will learn that they need to encrypt more than just
SSN, CCN, DOB, medical data, etc.  While browser cookies are generally
encrypted today, the decryption algorithm/key is probably simple and
well-known to internal engineering employees of those companies.

All the more reason why an enterprise key-management is critical for a
company's data-protection strategy, and Application/Data architects
need to start thinking about how they're going to deal with far more
encrypted data than what PCI-DSS, HIPAA and Breach Disclosure laws
demand.  Security practitioners can help them by getting them to start
addressing the issue for new applications before the application gets
implemented.

Arshad Noor
StrongAuth, Inc.


Allen wrote:
> Hi everyone,
> 
> Got this message from a well known IT organization. What is particularly 
> interesting is the very last line where they have attempted to grab 
> cookies from my machine. I would think that this would be a vector for 
> some sort of exploit, especially if the exploiter worked at the company 
> and had access to the files collected for support.
> 
> The other point of interest is that my IP address was included in plain 
> text e-mails. I would think that there would be a better way to do 
> support tickets. One would not normally think of this type of ticket as 
> requiring cryptographic protection, I sure didn't, but it is clear that 
> enough of this type of collection would make it open to exploitation in 
> some, as yet unknown attack.
> 
> What might you suggest?
> 
> Allen
> 
> 
> -------- Original Message --------
> Subject:     FW: [user-support] Req #14348 - {redacted} -
> Cannot access issue
> Date:     Tue, 29 Apr 2008 16:18:01 -0400
> From:      <{redacted}.org>
> To:     <netsecurity@{redacted}.com>
> References: <4F1DDD1C51793F4EB14A2C692FF934E102FAA255@I{redacted}.org>
> 
> Not sure what the issue is with this, but we'll look into it. Meanwhile, 
> please try this link:
> 
> http://www.{redacted}.org/xxx.html
> 
> 
> 
> -----Original Message-----
> From: {redacted}
> Sent: Monday, April 28, 2008 11:42 AM
> To: {redacted}
> Subject: Fwd: [user-support] Req #14348 - {redacted} -
> Cannot access issue
> 
> HI,
> Here is another subscriber who has a problem with logging in.
> {redacted}
> 
> ----- Forwarded Message -----
> From: "Digital Support Web Form" {redacted}
> To: "User Support List" <user-support@{redacted}>
> Sent: Friday, April 25, 2008 7:03:31 PM (GMT-0500) America/New_York
> Subject: [user-support] Req #14348 - {redacted} - Cannot access issue
> 
> Digital support request received:
> 
> Request #: 14348
> Name: {redacted}
> Email: netsecurity@{redacted}.com
> Phone:
> Nature of problem: Cannot access issue
> Details:
> It keeps looping back to the login page.
> 
> (BTW, captchas are *not* at all secure and should be avoided as they 
> give a false sense of security.)
> 
> Full subscriber url: http://www.{redacted}.com/{redacted}/2008spring/
> Subscriber ID:
> u1: {redacted}
> Collection: {redacted}
> Collection ID: 6692
> Document: {redacted}
> Document ID: 29222
> Ticket Number: 49072
> IP address: {redacted}
> Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 
> Gecko/20080404 Firefox/2.0.0.14
> Cookies: