Date: Wed, 23 Mar 2011 10:18:32 +0100
From: huj huj huj <datskihuj@...il.com>
To: Cal Leeming <cal@...whisper.co.uk>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Using Twitter for Phishing Campaign / Spam /
	Followers?

it works surprisingly well considering

2011/3/21 Cal Leeming <cal@...whisper.co.uk>

> Yeah, just noticed that. Soon as I get some spare time, I'll prob have a
> shot at making one. It'd be interesting to know what the success rate /
> latency / concurrency / hours of availability are when using decaptcher (due
> to it being human based), I can't imagine it'd be very good :S
>
>
> On Mon, Mar 21, 2011 at 12:32 PM, huj huj huj <datskihuj@...il.com> wrote:
>
>> decapther doesn't use ocr though
>> they use the indian workforce
>>
>> not sure about deathbycaptcha but i think its the same principle
>>
>> 2011/3/18 Cal Leeming <cal@...whisper.co.uk>
>>
>>> Lol, I didn't know about the commercial product 'decaptcher'.
>>>
>>> For shits and giggles, I was going to write a decaptcha myself and
>>> release as open source, never had time though :S
>>>
>>> One option would be to apply rate limitations to API calls per IP.
>>>
>>> Or, possibly some reallllllllly heavily obfuscated JS which does key
>>> calculation with a matching server side algo, and injects the value into the
>>> form upon submission. This is one of the methods we use on our paid adult
>>> sites. Unless the person is really determined (and has the patience to
>>> deobfuscate, then port to their own code), or their bots have spidermonkey
>>> built in, then it usually fends off most botters.
>>>
>>> To make it harder, we also have a library of about 500 of these (each
>>> with a different key build algo), which are cycled automatically lol.
>>>
>>> Example:
>>>
>>>  $(function() { var
>>> _0xafd3=["\x74\x20\x3D\x20\x22","","\x6A\x6F\x69\x6E","\x72\x65\x76\x65\x72\x73\x65","\x73\x70\x6C\x69\x74","\x72\x65\x70\x6C\x61\x63\x65","\x22"];eval(_0xafd3[0]+s[_0xafd3[5]](/ZPAK/gi,_0xafd3[1])[_0xafd3[5]](/\",\"/gi,_0xafd3[1])[_0xafd3[5]](/\"/gi,_0xafd3[1])[_0xafd3[4]](_0xafd3[1])[_0xafd3[3]]()[_0xafd3[2]](_0xafd3[1])+_0xafd3[6]);
>>> var
>>> _0x5bfa=["\x3C\x69\x6E\x70\x75\x74\x20\x2F\x3E","\x74\x79\x70\x65","\x68\x69\x64\x64\x65\x6E","\x61\x74\x74\x72","\x6E\x61\x6D\x65","\x73\x65\x65\x64\x6B\x65\x79","\x76\x61\x6C\x75\x65","\x61\x70\x70\x65\x6E\x64","\x23\x74\x68\x65\x66\x6F\x72\x6D"];_n=$(_0x5bfa[0]);_n[_0x5bfa[3]](_0x5bfa[1],_0x5bfa[2]);_n[_0x5bfa[3]](_0x5bfa[4],_0x5bfa[5]);_n[_0x5bfa[3]](_0x5bfa[6],t);$(_0x5bfa[8])[_0x5bfa[7]](_n);
>>> });
>>>
>>> Again, not perfect, but it's worked well for us :)
>>>
>>>
>>> On Fri, Mar 18, 2011 at 3:58 PM, huj huj huj <datskihuj@...il.com>wrote:
>>>
>>>> with services like decaptcher and deathbycaptcha this would not be a
>>>> hindrance anyway
>>>>
>>>> 2011/3/15 Cal Leeming <cal@...whisper.co.uk>
>>>>
>>>>> Agreed. These public API methods should have brute force protection at
>>>>> the very least. But, because they want instant in-line form validation for
>>>>> email address availability, this makes it difficult. In an ideal world,
>>>>> they'd have a CAPTCHA on the form,  and only validate upon submit with valid
>>>>> captcha.
>>>>>
>>>>>
>>>>> On Tue, Mar 15, 2011 at 3:02 PM, Reverse Skills <
>>>>> contact@...erseskills.com> wrote:
>>>>>
>>>>>> The problem is to allow unlimited access to that resource, not the
>>>>>> resource itself.
>>>>>>
>>>>>> 2011/3/15 Cal Leeming <cal@...whisper.co.uk>:
>>>>>> > This conceptual flaw exists in most web apps which have a "reset
>>>>>> password by
>>>>>> > email address" feature, as most will display an error if the email
>>>>>> address
>>>>>> > does not exist in their database.
>>>>>> >
>>>>>> > On Tue, Mar 15, 2011 at 12:19 PM, Reverse Skills <
>>>>>> contact@...erseskills.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Simple and easy way to get a list of email accounts used on
>>>>>> Twitter.
>>>>>> >> For Phishing campaigns, custom Spam...
>>>>>> >>
>>>>>> >> Twitter has been notified and I suppose someday be fixed if they
>>>>>> think
>>>>>> >> there should be filtered.
>>>>>> >>
>>>>>> >> When you create a new Twitter account, the form requesting a
>>>>>> mailing
>>>>>> >> address. Twitter verify that the email account is not being used,
>>>>>> but
>>>>>> >> does not check any user token or limit the usage (captcha/block).
>>>>>> >>
>>>>>> >> https://twitter.com/signup ->
>>>>>> >> http://twitter.com/users/email_available?email=
>>>>>> >>
>>>>>> >> We just need to automate it with a simple script , ***Everything
>>>>>> you
>>>>>> >> do will be your responsibility***
>>>>>> >> -------------------
>>>>>> >> #!/usr/bin/python
>>>>>> >> import sys, json, urllib2, os
>>>>>> >>
>>>>>> >> f =
>>>>>> >> urllib2.urlopen("http://twitter.com/users/email_available?email=
>>>>>> "+sys.argv[1])
>>>>>> >> data = json.load(f)
>>>>>> >> def valid()
>>>>>> >> ..
>>>>>> >> Email has already been taken" in data ["msg"] <-- reply
>>>>>> >> ..
>>>>>> >> -------------------
>>>>>> >>
>>>>>> >> We just need a list of users to test.. for example :
>>>>>> >> http://twitter.com/about/employees  (don't be evil is just an
>>>>>> >> example!)
>>>>>> >> Parsing the name/nickname and testing the {user}@...tter.com a few
>>>>>> >> minutes later we have a list of ~ 400 valid internal email
>>>>>> >> *@...tter.com. An attacker could probably.. a brute force attack
>>>>>> >> (Google Apps), would send Phishing or try to exploit some browser
>>>>>> bugs
>>>>>> >> or similar. #Aurora #Google. Most of these e-mail are internal, not
>>>>>> >> public..
>>>>>> >> There are also some that make you think they are used to such
>>>>>> >> A-Directory system users :
>>>>>> >> ..
>>>>>> >> apache@...tter.com
>>>>>> >> root@...tter.com
>>>>>> >> mail@...tter.com
>>>>>> >> ..
>>>>>> >>
>>>>>> >> But, if you download a database Rockyou / Singles.org / Gawker /
>>>>>> >> Rootkit.com or just a typical dictionaries and domains will be
>>>>>> quite
>>>>>> >> easy to get hold of a list of users large enough (*@...mail.com,
>>>>>> >> *@...il.com, etc).For example in my case I used to find user
>>>>>> accounts
>>>>>> >> in a pentest of a company that used Twitter. But probably not a
>>>>>> good
>>>>>> >> idea to allow unlimited access, a malicious user could use these
>>>>>> user
>>>>>> >> lists for Spam or Phishing.
>>>>>> >>
>>>>>> >> --
>>>>>> >> Security Researcher
>>>>>> >> http://twitter.com/revskills
>>>>>> >> --
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> Full-Disclosure - We believe in it.
>>>>>> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>> >> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Security Researcher
>>>>>> http://twitter.com/revskills
>>>>>> --
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>
>>>>
>>>>
>>>
>>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists