Re: Again! SpamCop cuts off phishing URL

Patto wrote:
>
http://www.spamcop.net/sc?id=z1710064090z5fc6071a8b03c03d7c83b8abe03ed36dz

This notify sez

If reported today, reports would be sent to:

Re: 66.58.184.181 (Administrator of network where email originates)
security@gci.net
postmaster@gci.net
abuse@gci.net

Re: http://0x7b.0x8f.0xd75/manual/faq/ (Administrator of network hosting
website referenced in spam)
security@bora.net
abuse@bora.net
spamcop@kisa.or.kr

> URL:
>
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php

Yes.

> SC reports:
> http://0x7b.0x8f.0xd75/manual/faq/

SC sez more than that.  SC sez;

Fixing hex/octal/overflow ip:0x7b.0x8f.0xd75 = 123.143.13.117
Resolves to 123.143.13.117
Routing details for 123.143.13.117
[refresh/show] Cached whois for 123.143.13.117 : dkapqk7@bora.net
security@bora.net shkim082@chol.com
Using abuse net on security@bora.net
abuse net bora.net = security@bora.net, abuse@bora.net,
spamcop@kisa.or.kr
Using best contacts security@bora.net abuse@bora.net spamcop@kisa.or.kr

> It is absolutely, perfectly, 100% useless!

I disagree.  Explain yourself, your opinion.

> How can the recipient go
> and fix the problem with this incorrect information?

Do you mean how can boranet the spamvertiser provider go do something
about this spamvertiser provided with this evidence?  Answer, if
motivated, easily.

> Why is this not worth the little effort to fix the problem?

What (SC) problem?

It isn't clear to me what you are debating.  Are you debating the
'quality' of information which SC is feeding/handing/providing to
boranet?  Boranet is a (sometimes/often)  unresponsive .kr provider.

Spamhaus is currently listing 4 listings of various sizes for boranet,
one of which is a ROKSO, and 2 of which are /24 & /26 blocks since 2005
Dec and 2006 Feb which isn't the epidemy of responsiveness.

SC didn't fail to deobfuscate the spamvertiser IP.  SC didn't fail to
notify the appropriate spamvertiser, even tho' that was probably a waste
 of time.  But you are complaining that SC isn't doing a good enough job
of notifying.

-- 
Mike Easter
kibitzer, not SC admin

Patto wrote:
> Mike Easter wrote:
>> Patto wrote:
>>
http://www.spamcop.net/sc?id=z1710064090z5fc6071a8b03c03d7c83b8abe03ed36dz

> The "spamvertized" URL is in fact a "phishing" URL. I
am much more
> concerned about taking down "phishing" pages than ordinary spam
pages.

Taking down phishing pages would be good.  LE lawenforcement doesn't
seem to think it very important.

> What SC's problem is that it cuts off the URL where it finds a blank
> directory.  Here is the original full URL:
>
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php
>
> But SC reports only a truncated URL, until the %20 blank:
> http://0x7b.0x8f.0xd75/manual/faq/
>
> which is equivalent to:
> http://123.143.13.117/manual/faq/

I agree that 'we' (SC & reporter) should try to help out the desk as
much as possible.  However, the actual concept is that the desk /should/
be able to take the evidence, ie the spam, as a 'package' wrapped up
from headers thru' body and find the spamvertised link, deobfuscate it,
including 'de-hexing' and also including unraveling any errored
constructions which some browsers might not 'de-error' and determine
that either their client or even not their client but perhaps someone
who has taken over/ hijacked/ the site's content is performing a phish.

OTOH, if SC is going to 'display' only a part of the link in this
instance and the reporter wants to help out the desk, then the reporter
can display the full link and include the blank directory part of the
URL and the dehexing as well by placing that additional information in
the note section which the reporting process provides.

> If an abuse desk is going to look at this truncated URL, s/he will
> find that there is nothing "phishy" at this location, and will
> probably dismiss the report. If the abuse desk is really curious,
> s/he may find the full URL in the message body. But I think SC should
> give the full, untruncated URL in the specific message for the report
> address.

FWIW forwhatitsworth currently there is no webserver answering at
123.143.13.117

Initiating server query ...
Looking up the domain name for IP: 123.143.13.117
(The domain name for the specified IP address could not be found.)
Connecting to the server on standard HTTP port: 80
No response was received from the machine and port at that IP. The
machine may be offline or the connection port may be stealthed.
Query complete.

> All I want is that SC stops truncating URLs.

I suspect that 'the coder' probably hates to muck in some parts of the
code, such as that related to deobfuscating URLs, for the fear that
changing that part of the code may break something else.  In this case
the deobfuscation correctly and accurately leads to the provider, altho'
the deob does truncate the URL.

-- 
Mike Easter
kibitzer, not SC admin

http://www.spamcop.net/sc?id=z1710064090z5fc6071a8b03c03d7c83b8abe03ed36dz

URL:
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php

SC reports:
http://0x7b.0x8f.0xd75/manual/faq/

It is absolutely, perfectly, 100% useless! How can the recipient go and 
fix the problem with this incorrect information?

Mike Easter wrote:
> Patto wrote:
> http://www.spamcop.net/sc?id=z1710064090z5fc6071a8b03c03d7c83b8abe03ed36dz
> 
> This notify sez
> 
> If reported today, reports would be sent to:
> 
> Re: 66.58.184.181 (Administrator of network where email originates)
> security@gci.net
> postmaster@gci.net
> abuse@gci.net
> 
> Re: http://0x7b.0x8f.0xd75/manual/faq/ (Administrator of network hosting
> website referenced in spam)
> security@bora.net
> abuse@bora.net
> spamcop@kisa.or.kr
> 
>> URL:
>>
>
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php
> 
> Yes.
> 
>> SC reports:
>> http://0x7b.0x8f.0xd75/manual/faq/
> 
> SC sez more than that.  SC sez;
> 
> Fixing hex/octal/overflow ip:0x7b.0x8f.0xd75 = 123.143.13.117
> Resolves to 123.143.13.117
> Routing details for 123.143.13.117
> [refresh/show] Cached whois for 123.143.13.117 : dkapqk7@bora.net
> security@bora.net shkim082@chol.com
> Using abuse net on security@bora.net
> abuse net bora.net = security@bora.net, abuse@bora.net,
> spamcop@kisa.or.kr
> Using best contacts security@bora.net abuse@bora.net spamcop@kisa.or.kr
> 
>> It is absolutely, perfectly, 100% useless!
> 
> I disagree.  Explain yourself, your opinion.
> 
>> How can the recipient go
>> and fix the problem with this incorrect information?
> 
> Do you mean how can boranet the spamvertiser provider go do something
> about this spamvertiser provided with this evidence?  Answer, if
> motivated, easily.
> 
>> Why is this not worth the little effort to fix the problem?
> 
> What (SC) problem?
> 
> It isn't clear to me what you are debating.  Are you debating the
> 'quality' of information which SC is feeding/handing/providing to
> boranet?  Boranet is a (sometimes/often)  unresponsive .kr provider.
> 
> Spamhaus is currently listing 4 listings of various sizes for boranet,
> one of which is a ROKSO, and 2 of which are /24 & /26 blocks since
2005
> Dec and 2006 Feb which isn't the epidemy of responsiveness.
> 
> SC didn't fail to deobfuscate the spamvertiser IP.  SC didn't fail to
> notify the appropriate spamvertiser, even tho' that was probably a waste
>  of time.  But you are complaining that SC isn't doing a good enough job
> of notifying.

Mike - thank you for responding. Maybe I have not made myself very clear

The "spamvertized" URL is in fact a "phishing" URL. I am
much more 
concerned about taking down "phishing" pages than ordinary spam
pages.

What SC's problem is that it cuts off the URL where it finds a blank 
directory.  Here is the original full URL:
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php

But SC reports only a truncated URL, until the %20 blank:
http://0x7b.0x8f.0xd75/manual/faq/

which is equivalent to:
http://123.143.13.117/manual/faq/

If an abuse desk is going to look at this truncated URL, s/he will find 
that there is nothing "phishy" at this location, and will probably 
dismiss the report. If the abuse desk is really curious, s/he may find 
the full URL in the message body. But I think SC should give the full, 
untruncated URL in the specific message for the report address.

Patto wrote:
> Mike Easter wrote:
>> Patto wrote:
>>> Mike Easter wrote:
>>>> Patto wrote:
>>>>
>>
http://www.spamcop.net/sc?id=z1710064090z5fc6071a8b03c03d7c83b8abe03ed36dz 
>>
>>
>>> The "spamvertized" URL is in fact a "phishing"
URL. I am much more
>>> concerned about taking down "phishing" pages than
ordinary spam pages.
>>
>> Taking down phishing pages would be good.  LE lawenforcement doesn't
>> seem to think it very important.
>>
>>> What SC's problem is that it cuts off the URL where it finds a
blank
>>> directory.  Here is the original full URL:
>>>
>>
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php 
>>
>>> But SC reports only a truncated URL, until the %20 blank:
>>> http://0x7b.0x8f.0xd75/manual/faq/
>>>
>>> which is equivalent to:
>>> http://123.143.13.117/manual/faq/
>>

What's so hard about adding the correct url to the *notes* section for the 
offending source?

You spent more time on this then it is to just add...

Please see the url 
http://123.143.13.117/manual/faq/%20/www.paypal.com/cgi-bin/webscrcmd=_login-run
/update.php 
for the correct spam report

To the notes? I do that and it's much faster then wasting hours on this since 
SC already knows of this weakness in the parsing.