Neal Poole

Summary

eBay has changed its responsible disclosure policy for security researchers. The older policy asked researchers to “Allow us a reasonable amount of time (at least 30 days from when we receive your disclosure under this process to respond to the issue before disclosing it to others.” The new policy asks researchers to “wait until notified that the vulnerability has been resolved before disclosing it to others.” This new policy means that eBay can ignore vulnerabilities reported by researchers with no repercussions.

Backstory

I just published a post about two security vulnerabilities I found in my.ebay.com. I first reported these vulnerabilities to eBay in May 2012. While I was never told when the vulnerabilities would be patched, eBay’s responsible disclosure policy provided the following guidelines:

• Share the security issue with us before making it public on message boards, mailing lists, and other forums.
• Allow us a reasonable amount of time (at least 30 days from when we receive your disclosure under this process to respond to the issue before disclosing it to others.
• Provide full details of the security issue, including Proof-of-Concept URL and the details of the system where the tests were conducted.

You can see these guidelines in their original form thanks to the Internet Archive.

In February, I contacted eBay to try and figure out why the vulnerabilities had not been patched. I also informed them that, per their responsible disclosure policy, I was planning to publish the details of the vulnerabilities I had discovered. They sent me the following email back:

Hi Neal,

We thank you for your work and your dedication to keeping the eBay community secure. We ask that you wait until we’ve fixed the reported vulnerability before disclosure, as per our Guidelines for Responsible Disclosure. Although this issue has not been fixed, it is in the queue and scheduled to be fixed. As a token of appreciation, we would like to send you some eBay branded gifts and acknowledge you on our Security Researcher’s Acknowledgment page once this vulnerability is fixed. Please send us your address if you’d like us to send you a few eBay goodies.

Thanks,

eBay Security Research

At that point, their responsible disclosure policy was identical to the one I presented above. I sent back the following reply:

Hey,

Just to be clear, your guidelines for responsible disclosure say the following:

“Allow us a reasonable amount of time (at least 30 days from when we receive your disclosure under this process to respond to the issue before disclosing it to others.”

This report was originally filed and acknowledged on May 11th, 2012. Over 30 days later (June 12th, 2012) I asked for an update and was told there was no update. It is now February 11th, 2013, many months beyond 30 days. Under your policy I am fully within my rights to disclose the issue to others without fear of reprisal.

As a courtesy I will hold off publishing details of this issue until March 14th, which is 31 days from today.

Best,
 Neal

And received a response from eBay:

Hi Neal,

We appreciate your patience in this process and your continuous support in keeping eBay secure. We will keep you updated on the progress.

Thanks,
eBay Security Research

I received no further emails from eBay.

Shifting Policy

After publishing my post today, I returned to the responsible disclosure page and found the following new set of guidelines:

• Share the security issue with us before making it public on message boards, mailing lists, and other forums.
• We request that you wait until notified that the vulnerability has been resolved before disclosing it to others. We take the security of our customers very seriously, however some vulnerabilities take longer than others to resolve. There are several teams involved in working on these vulnerabilities depending on which site has the vulnerability and what function is being exploited.
• Provide full details of the security issue, including Proof-of-Concept URL and the details of the system where the tests were conducted.

The second guideline, which changes the disclosure timeline for a vulnerability from “at least 30 days” to “whenever eBay decides to patch an issue,” is the only difference. The guideline is designed to sound reasonable and responsible; it reminds us that eBay takes security seriously, it points out the complexities of coordinating patches between many teams, etc. But while some security vulnerabilities may take a long time to be patched, many are fairly straightforward and should not need to take more than a month from disclosure to patch.

In addition, it is the job of eBay’s security team to manage the expectations of outside security researchers. While researchers may have been entitled to release details of a vulnerability after 30 days under the old policy, in general many researchers are happy to hold off on public disclosure if the company is working actively to address the issue. Personally, I have reported plenty of vulnerabilities where I have had to wait months for a patch to be released. As long as the vendor provides some assurances that a patch is in the works, I am more than happy to withhold public disclosure.

Conclusion

The fact that the guideline was (silently) changed between when my email was sent and when my post was published speaks volumes about security at eBay. It tells me that someone at eBay saw my email and decided it was easier to change the responsible disclosure policy and send me “eBay goodies” than it was to follow up on my report. If that’s how eBay feels about responsible disclosure, I won’t be searching for any vulnerabilities on their sites in the future.

When I was browsing /r/programming earlier this morning, I came across a link to a web application named Tweeter. I played around with it for a while and I think it’s a really awesome application, so I figured I’d write a post about it.

Tweeter is a web application designed for a single purpose: to give people a chance to apply their knowledge of SQL injections to a “real” site. The attacker’s goal is to use his/her knowledge of SQL injections to post as an existing user named agentgill. Once the “hack” is complete, the attacker is directed to a new version of the website, designed with more safeguards and security measures that need to be circumvented. I don’t want to delve into the specifics of the different versions, but there are a total of four levels, each with their own set of challenges that must be overcome.

Screenshot of Tweeter Level 1

I really enjoyed playing with Tweeter. It was a fun challenge and it gave me a chance to reuse some basic SQL injection knowledge I haven’t used in a while. It reminded me a little bit of Jarlsberg, a similar application created by Google to teach people about possible attack vectors in web applications (but which does not demonstrate SQL injections, since it does not use SQL). I believe tools like Tweeter are integral in teaching web application security; learning about SQL injections in class is nowhere near the same experience as being able to exploit them properly on a real website. I’ll definitely be adding it to my bookmarks.

If you’d like to try it out for yourself, you can click on this link to create a new instance on the author’s site.

More information about Tweeter (including a link to download the source) can be found on the author’s blog.

Note: This post was originally written in August 2009

Over the past week or so, I’ve been working on converting some legacy MySQL databases from their original character set to UTF-8. Although the process sounds easy enough, at least a few issues tend to crop up with every conversion. Whether it’s fields getting randomly truncated, tables containing data with multiple character sets, or data displaying as pure gibberish, something unexpected is bound to happen.

In this case, I was converting the data from a semi-large forum hosting site. This site had multiple language packs, each with its own character set. All of the data in the database tables was stored using the latin1 character set. In essence, although each forum had its own character set, the database treated the data as if it was using a single character set.

As expected, when the conversion was done and I asked for feedback, I was informed that one of the forums was displaying gibberish. Upon researching the problem, I discovered a few facts:

• The forum was using the Polish language pack, which used the ISO-8859-2 character set.
• All of the data appeared to be present on the site; it was just improperly encoded and thus looked like gibberish.

My first instinct was to try skipping the actual data conversion (for certain languages, including Polish, I was using MySQL’s charset support to convert the data from latin1 to UTF-8: it was easier than using an outside tool). Unfortunately, that resulted in fields being truncated and data going missing on import.

Thinking that the truncated data was due to an incorrect character set, I tried using iconv, an extremely useful tool for converting between character sets. I took the backup and told iconv to convert it from ISO-8859-2 to UTF-8:

1

iconv -f ISO-8859-2 -t UTF-8 < input-file.sql > converted-file.sql

Unfortunately, the fields remained truncated.

Upon further investigation, I realized the source of the problem: the original backup I had from the forum host was in UTF-8, not latin1! mysqldump, the tool I had used to generate the backups, uses UTF-8 by default: you need to specify if you want to use a different character set. In this case, since the tables were latin1 but the backup was supposed to be in UTF-8, MySQL was converting the data itself. Since not all of the data was latin1 to begin with, certain information was being lost in translation.

Once I realized my mistake, it was easy enough to correct. I made a new backup with the correct character set indicated:

1

mysqldump --default-character-set=latin1 -u username -p -h example.com database_name > backup.sql

and then I converted the file using iconv:

1

iconv -f ISO-8859-2 -t UTF-8 < backup.sql > converted-file.sql

Finally, with the data itself properly converted to UTF-8, the only remaining step was to update the database schema; I manually edited the database backup and changed mentions of latin1 to UTF-8. The import was a breeze and the forum was up and running in no time.