Message-ID: <AANLkTin7K_5rJkp794Xr8zYZeAmdU+LEYuLU3nyKrkum@mail.gmail.com>
Date: Mon, 21 Mar 2011 17:50:45 +0000
From: Cal Leeming <cal@...whisper.co.uk>
To: huj huj huj <datskihuj@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Using Twitter for Phishing Campaign / Spam /
	Followers?

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