Entry tags:

security

iGive, you receive insecurity
I've been delaying the posting of this blog entry, but since there haven't been any new developments I thought I should finally post it...

iGive.com is a website that allows people to shop at popular e-commerce retailers and have a small percentage of the purchase sent to a charity that you nominate. In theory it's a nice idea, however I've noticed a few problems with their implementation, particularly in regard to the security and confidentiality of the personal information of members that sign up. distributed.net has been using iGive since 1997, though my opinion of them has been lowered as a result of this (and other actions that are not covered here).

iGive elected to belong to the TRUSTe "web privacy seal" program, which has the goal of providing some assurance to internet users that their privacy can be safely entrusted to a website. Most of TRUSTe's assurance comes from requiring websites to pay a certification fee and have a privacy policy that complies with TRUSTe requirements, but they don't actually seem to do their own auditing unless someone makes a complaint. There are other critics that claim that TRUSTe does not take a proactive role in monitoring or punishing organizations.

Issue #1: unauthenticated autologin URLs

I noticed that their periodic email newsletters included a URL to view a HTML version of the newsletter as a webpage (in case your email client does not display full HTML). Unfortunately, the URLs were of the form "http://www.igive.com/html/igivenews.cfm?mid=xxxxxx" and the "mid" is an integer that references your personal Member Identifier. The newsletter is customized to including your name and some statistics, and also automatically log you into your iGive account so that you will receive credit for any subsequent shopping activity.

Of course the flaw with this is that anyone can compose an equivalent URL with any random Member Identifier, become logged in as that user, and then use the iGive account management features to view the personal details of that person (such as full name, mailing address, phone number, what charity they are supporting, and their full shopping history of store names, order invoice numbers, and shopping amounts).

• 9/14/2006 -- email iGive support notifying them of details of the vulnerability
  
• 9/14/2006 -- receive email response stating "Thanks for your note, we've passed it along to the appropriate people."
  
• 1/17/2008 -- email iGive support notifying them that the issue is still unresolved after 17 months
  
• 1/17/2008 -- receive automated email response acknowledging receipt.
  
• 1/17/2008 -- separately send initial email to TRUSTe watchdog notification regarding issue
  
• 2/1/2008 -- receive email from iGive with the response "Your ticket ... has been closed. ... No action is required on your part."
  
• 2/1/2008 -- email iGive support disputing their arbitrary closure of the ticket
  
• 2/5/2008 -- receive email response from iGive saying "it does appear that your ticket was inadvertently closed. Please resubmit your initial query and we will promptly attend to it."
  
• 2/5/2008 -- confirm TRUSTe watchdog submission to permit forward progress, and supply additional details
  
• 2/5/2008 -- reply to iGive support to reopen issue
  
• 2/5/2008 -- receive response from TRUSTe asking for details to reproduce
  
• 2/5/2008 -- send details to TRUSTe about issue
  
• 2/7/2008 -- receive email from iGive acknowledging that they are being investigated by TRUSTe and they will work with them rather than me
  
• 2/25/2008 -- receive email from TRUSTe notifying that the issue has been resolved.
  

iGive resolved the issue by making the webpage version of the newsletter ignore the "mid" variable and rely on you being logged into iGive already. If you are not already logged in, then you are sent to a login page.

Issue #2: insecure cookie logins

As I was confirming that the above issue was corrected, I realized that iGive was relying on a Cookie that contained my Member Identifier to decide whether I was logged in. By simply typing a line of javascript in my browser address bar, I could change that "MID" cookie to be any other integer Member Id and I would be considered logged in. I could then perform all of the iGive account management functionality that I described in Issue #1 above.

• 2/27/2008 -- notify TRUSTe of the additional entry-point to the vulnerability. Suggest an external security audit.
  
• 2/28/2008 -- receive reply from TRUSTe indicating they are pursuing the new issue. "due to the complexity of the issue, this may take some time"
  
• 3/27/2008 -- request status from TRUSTe, receive response saying nothing new.
  
• 3/31/2008 -- receive response from TRUSTe about other questions
  
• 4/2/2008 -- receive response from TRUSTe notifying that the Cookie issue is resolved.
  

The resolution by iGive was to introduce additional cookies containing session identifiers. The "MID" cookie is maintained, but apparently ignored.

Issue #3: insecure charity details

While looking through other parts of the iGive website, I noticed that anyone can view the full contact details of any charity that has registered with iGive (including the name of the charity officer, his mailing address, the charity's phone number, contact email address). As with issue #1, the URL of the vulnerable page simply accepted an integer Charity Identifier as an argument: http://www.igive.com/html/body_editlisting3.cfm?cid=1100

• 4/14/2008 -- notify TRUSTe of the vulnerability
  
• 4/18/2008 -- receive response from TRUSTe asking more questions about how to repro the issue
  
• 4/19/2008 -- send response to TRUSTe with details and screenshots of the issue
  
• 4/21/2008 -- receive response from TRUSTe indicating they have received the details and are verifying the claims
  
• 4/22/2008 -- receive response from TRUSTe indicating that they have confirmed the claim.
  
• 6/6/2008 -- receive response from TRUSTe indicating that iGive has improved the security of charity editing pages.
  

iGive resolved the issue by deleting the specific page. I've not yet attempted to verify whether the new equivalent pages fully eliminate the original problem.

Issue #4: Insecure member listing

iGive permits charity operators to see the list of members that have contributed towards that charity. Charities are not supposed to be able to see members that are only affiliated with other charities, or those members that have opted to remain invisible.

However, I found a way for anyone to view the full list of contributors that are supporting a cause/charity and seeing their first/last names, their email, and their contributed amount. You do not even need to be a charity operator to do so--only have a standard iGive contributor/member account. All you had to do was set a cookie with some Javascript and then access a URL:

javascript:document.cookie="SUPPORTERLISTOK=1100"
http://www.igive.com/causetoolbox/html/supporterlist2008.cfm

• 4/14/2008 -- notify TRUSTe of the vulnerability
  
• 4/18/2008 -- receive response from TRUSTe asking more questions about how to repro the issue
  
• 4/19/2008 -- send response to TRUSTe with details and screenshots of the issue
  
• 4/21/2008 -- receive response from TRUSTe indicating they have received the details and are verifying the claims
  
• 4/22/2008 -- receive response from TRUSTe indicating that they have confirmed the claim
  
• 6/6/2008 -- receive response from TRUSTe indicating that iGive has improved the security of charity editing pages.
  

I've not yet attempted to verify whether the new equivalent pages fully eliminate the original problem.

Issue #5: Tracking images

iGive sends out periodic newsletters by email that includes the use of "clear gif" tracking images to determine if/when members actually read the newsletters. Although this is not a unique practice, all members of the TRUSTe program are required to disclose that they make use of this technique in their privacy policy, and iGive's policy did not do this. Apparently all iGive newsletters have contained tracking pixels since 2003.

• 4/14/2008 -- notify TRUSTe of the non-compliance issue
  
• 4/18/2008 -- receive response from TRUSTe confirming the requirement, and asking for an example email
  
• 4/19/2008 -- send response to TRUSTe with an example email that contains "clear gif" images
  
• 4/21/2008 -- receive response from TRUSTe indicating they have received the details and are verifying the claims
  
• 4/22/2008 -- receive response from TRUSTe indicating that they have confirmed the claim
  
• 5/21/2008 -- receive response from TRUSTe indicating that iGive has updated their privacy policy to disclose the tracking images
  
• 6/17/2008 -- iGive updates their privacy policy again to more clearly describe tracking images and remove references to TRUSTe, but does not remove the TRUSTe logos from all parts of their website
  

Other general developments

As a result of my reports of these security issues, it appears that TRUSTe has taken the rare action of terminating the membership of iGive into the web privacy seal program. Technically, I wasn't able to get any official confirmation that their membership had indeed been terminated or whether iGive chose to discontinue their membership, but the result is similar. Here are a few key statements that I did receive:

• 4/22/2008 -- "We are escalating this issue within TRUSTe to determine next steps ... We really appreciate the help you've provided in alerting us about this and the prior issues."
  
• 4/22/2008 -- acknowledge response, indicate similarity of vulnerability, ask about notification to members, ask at what point certification status might be revoked
  
• 4/23/2008 -- receive response from TRUSTe acknowledging the concerns
  
• 6/17/2008 -- iGive removes some references to TRUSTe, but not all TRUSTe logos from other parts of their website
  
• 6/23/2008 -- receive response from TRUSTe indicating "iGive is no longer a member of our program and we have no further enforcement capability relative to their site. We were unable to resolve the audit issue during this time."
  
• 6/24/2008 -- receive response from TRUSTe regarding the specifics of why they are no longer a member: "We are unable to disclose whether ending the certification was mutually agreed or similar issues. Our standard license agreement limits what we can disclose."
  

According to TRUSTe's fact sheet, as of today only 3 companies have ever been terminated from their program. If you use the archive.org wayback machine, you can see that the number of terminated companies was still only 1 as recently as November 22, 2007. I suspect iGive might be one of the two recently terminated companies--I don't know who the other company might be.

I haven't decided whether TRUSTe's handling of iGive was adequate or not. Perhaps they do deserve the criticism that they do not act quickly or proactively enough. It's a little disappointing that both iGive and TRUSTe do not seem to have adequate security resources to evaluate website implementations on their own.


TRUSTe recently made a blog post warning that "encoding an ID# in the URL or relying on another mechanism that can be changed by the user risks exposing data". I don't know if iGive qualifies as a "major consumer web site ... [that exposes] passports", but I'm sure they were at least attempting to aggregate the lessons from iGive's problems in that post.