Hot:

Really? A FREE YEAR of Broadband?!? Nobody gives away a free year…

Recently I’ve received copies of a Phishing Attempt that looks like it’s from Shaw (a cable/internet/telephone service company in Canada). This phishing attempt is congruous to the Ebay and banking phishes of the recent past, in that it actually does NOT resemble a ‘real’ email, rather a fictional email to get people excited, in this case instead of warning the user it attempts a positive reaction from “getting free internet for a year”. Whoopie! A years worth of internet from Shaw isn’t that expensive. Phishing attempts are typically NOT viral or malware orientated but certainly can and do use such methods. In this case it looks like a standard email spam sent via exploited web sites.

This is a sophisticated method. It uses a similar style as Shaw uses in their correspondence and uses a legit; if inappropriate, email address. The email was generated and sent using multiple methods so tracking it will be harder to accomplish. Additionally, I shall show the details of the spam and my analysis. Our whois data will be included in the rest of the article.

First off, I will advise of the RED FLAGS in this phishing attempt

#1- “A Free Year of Broadband” – This doesn’t make sense. Shaw has trademarks and service marks that it would use to advertise it’s broadband internet service. Only someone ignorant of Shaw’s trademarks would say this. It’s really unlikely anyone who really works for Shaw would make this error.

#2 – Canadian Law states that any ‘contest’ or ‘giveaways’ contain details of said event. In most cases it’s prudent to disclaim whether or not the contest is allowed in Quebec, since the law is vastly different, and Quebec law generally does NOT allow this type of Contest. (disclaimer: I’m in no way a lawyer, but I am aware of consumer rights.). Missing the disclaimer is a definite flag

#3 – The email that is seen in the From: header is not a normal Shaw correspondence email account.

#4 – The link clearly shows a ‘secure’ link, but in no way is it going to a ‘secure’ site.

#5 – Typical email headers (on email from Shaw) missing

So just upon a quick review of this email we can deduce that it’s not a valid email. To get more pertinent details I’ll analyze these email in detail. I won’t paste the email headers in entirety, any ambiguity will be displayed by ‘XXXXXXXX’, to avoid email harvesting, but I will show you what details were more noteworthy.

The return-path was interesting. One was:

apache@utel16.besthosting.com.ua

, the other one was:

nobody@omega.omc.net

This would indicate to me that the web server sent this email, and in typical hosting fashion, it would be doing so via script on one of the hosts or virtual hosts on the system.

None of the received headers would indicate anything unexpected here, “omega” even has SSL/TLS

enabled but verify set to no.

The header in one of the emails is very interesting:

Date: Thu, 08 Nov 2007 20:49:28 +0200

From: “Shaw Communications Inc.” service@shaw.ca

Subject: Win a year of free broadband

To: XXXXXXX@shaw.ca

Reply-to: service@shaw.ca

Message-id: XXXXXXXXXXXXXXXXX@utel16.besthosting.com.ua

MIME-version: 1.0

Content-type: text/html

X-PHP-Script: 213.186.117.120/~loveterra/indexzz.php for 82.208.212.146

Date and time indicates a East European Time zone. I know Shaw doesn’t have any servers in Europe…

The X-PHP-Script header shows a very interesting detail of where this email came from. We’ll come back to this IP in a bit. But this is a key indicator of an exploited web site on a hosting company or something similar. This IP definitely hosts a web server, and with the above mentioned user account, but at time of checking this link generated a error.

The for address 82.208.212.146 is interesting as it resolves to:

whois -h whois.geektools.com 82.208.212.146 …

GeekTools Whois Proxy v5.0.4 Ready.

Final results obtained from whois.ripe.net.

Results:

% This is the RIPE Whois query server #1.

% The objects are in RPSL format.

%

% Rights restricted by copyright.

% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.

% To receive output for a database update, use the “-B” flag.

% Information related to ’82.208.212.0 – 82.208.212.255′

inetnum: 82.208.212.0 – 82.208.212.255

netname: ITSOLUTIONSNET

descr: ITSolutions, Obrenoviceva 124 4/10

descr: 18000 Nis

descr: Serbia and Montenegro

country: CS

admin-c: IS1188-RIPE

tech-c: AZ919-RIPE

status: ASSIGNED PA

mnt-by: PTTSRBIJANET-MNT

source: RIPE # Filtered

person: Ivan Stankovic

address: ITSolutions

address: YU

e-mail: i.stankovic@my-its.net

phone: +38118512796

fax-no: +38118512797

nic-hdl: IS1188-RIPE

source: RIPE # Filtered

person: Aleksandar Zakic

address: ITSolutions NET

address: CS

e-mail: a.zakic@my-its.net

phone: +381-63-222-361

fax-no: +381-18-512-797

nic-hdl: AZ919-RIPE

source: RIPE # Filtered

% Information related to ’82.208.192.0/19AS13091′

route: 82.208.192.0/19

descr: JP PTT Srbija

descr: PTT Srbija Net

origin: AS13091

mnt-by: PTTSRBIJANET-MNT

source: RIPE # Filtered

Results brought to you by the GeekTools WHOIS Proxy

Server results may be copyrighted and are used with permission.

Reviewing the other IP address of the X-PHP-Header gives us this info:

whois -h whois.geektools.com 213.186.117.120 …

GeekTools Whois Proxy v5.0.4 Ready.

Final results obtained from whois.ripe.net.

Results:

% This is the RIPE Whois query server #3.

% The objects are in RPSL format.

%

% Rights restricted by copyright.

% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.

% To receive output for a database update, use the “-B” flag.

% Information related to ’213.186.117.0 – 213.186.117.143′

inetnum: 213.186.117.0 – 213.186.117.143

netname: UTEL-DC5

descr: Utel DataCenter networks. Colocation

country: UA

admin-c: UNOC-RIPE

tech-c: UNOC-RIPE

status: ASSIGNED PA

mnt-by: AS6877-MNT

remarks: INFRA-AW

source: RIPE # Filtered

role: Utel NOC

address: 101, Volodymyrska str.

address: 01033, Kyiv, Ukraine

phone: +380 44 2359001

fax-no: +380 44 2304560

e-mail: noc@utel.net.ua

admin-c: OLE-RIPE

tech-c: BES100-RIPE

tech-c: OLE-RIPE

tech-c: JIM-RIPE

tech-c: ALT-RIPE

tech-c: UHM-RIPE

nic-hdl: UNOC-RIPE

mnt-by: AS6877-MNT

source: RIPE # Filtered

% Information related to ’213.186.112.0/20AS16124′

route: 213.186.112.0/20

descr: Utel DataCenter, Ukraine

origin: AS16124

mnt-by: AS6877-MNT

source: RIPE # Filtered

Results brought to you by the GeekTools WHOIS Proxy

Server results may be copyrighted and are used with permission.

So, it looks like someone possibly in Serbia and Montenegro, ran a cross site script residing on a server in the Ukraine, against utel16.besthosting.com.ua which sent the email. One would actually have to test this out, which I have not done to confirm this. This is a dangerous step I decided to avoid for brevity.

[page_break]

Looking at another similar email we see:

Date: Tue, 06 Nov 2007 23:24:54 +0100 (CET)

From: “Shaw Communications Inc.”

Subject: Win a year of free broadband

To: XXXXXXXXX@shaw.ca

Reply-to: service@shaw.ca

Message-id:

MIME-version: 1.0

Content-type: text/html

X-Authentication-warning: omega.omc.net: Host localhost.omc.net (127.0.0.1)

claimed to be omega.omc.net

But we can see the authentication warning from this server. No detail unfortunately.

Regardless, the viewable content of these two emails is identical, including an ‘offical’ Shaw footer to further reinforce it’s legitimacy, but it’s futile. These are NOT from SHAW.

The content included in plaintext: However to ensure not even ‘google’ browses the evil link from our site I have sanitized it so it breaks. Details to fix will be below the actual email content:

Content-Transfer-Encoding: 8bit

209.85.15.18 is the address removed above with “Removed.example.com”. This address resolves to:

11/09/07 14:19:19 whois 209.85.15.18@whois.geektools.com

whois -h whois.geektools.com 209.85.15.18 …

GeekTools Whois Proxy v5.0.4 Ready.

Final results obtained from whois.arin.net.

Results:

OrgName: Everyones Internet

OrgID: EVRY

Address: 390 Benmar

Address: Suite 200

City: Houston

StateProv: TX

PostalCode: 77060

Country: US

ReferralServer: rwhois://rwhois.ev1servers.net:4321/

NetRange: 209.85.0.0 – 209.85.127.255

CIDR: 209.85.0.0/17

NetName: EVRY-BLK-15

NetHandle: NET-209-85-0-0-1

Parent: NET-209-0-0-0-0

NetType: Direct Allocation

NameServer: NS1.EV1SERVERS.NET

NameServer: NS2.EV1SERVERS.NET

Comment:

RegDate: 2005-12-14

Updated: 2006-11-28

RAbuseHandle: ABUSE477-ARIN

RAbuseName: Abuse Department

RAbusePhone: +1-713-579-2850

RAbuseEmail: abuse@ev1servers.net

RNOCHandle: NOC1445-ARIN

RNOCName: Noc

RNOCPhone: +1-713-579-2850

RNOCEmail: noc@ev1servers.net

OrgAbuseHandle: ABUSE271-ARIN

OrgAbuseName: Abuse

OrgAbusePhone: +1-214-782-7802

OrgAbuseEmail: abuse@theplanet.com

OrgNOCHandle: NOC1445-ARIN

OrgNOCName: Noc

OrgNOCPhone: +1-713-579-2850

OrgNOCEmail: noc@ev1servers.net

OrgTechHandle: VST3-ARIN

OrgTechName: Stinson, Valarie

OrgTechPhone: +1-713-579-2850

OrgTechEmail: admin2@ev1servers.net

# ARIN WHOIS database, last updated 2007-11-08 19:10

# Enter ? for additional hints on searching ARIN’s WHOIS database.

At this point this site seems to be up. Anyone receiving any email similar to this should simply delete it.

If you think it really is legit, call Shaw directly and ask them BEFORE you click on the link. I feel this analysis is accurate and is limited in it’s conclusions. However I hope it serves to help or assist any other who seeks to eliminate phishers, and other scammers.

Hot:

To be quite frank no language is secure, no language was built from a security perspective.

 

So….

Many people these days seem to get it in their head that there are secure designs in the world, and I digress, no their isn’t. Nobody thinks deeply about security except those with a great deal to lose, and they pay very heavy for it.

Your bank is not really that secure.  Your data is not really secure.  Your personal government files are not secure.  Your home is not secure.  Your business is not secure, your car is (phht a joke!) not secure.  What does this tell you?

Well what did September 11, 2001 tell you?  What did Hurricane Katrina tell you?  

I think it’s telling us, that no ‘system’ or ‘process’ is secure by design.  Security is something we thought about afterwards, generally speaking when someone else quite distinctly shows you the insecurity.

When it comes to software, we cannot think that ‘security’ is job #1.  We’d be lucky if they even considered it in a fleeting moment, let alone design with it in mind.

So why would we think anything we do on computers or online, is secure?  It isn’t,  it’s even worse.  Online banking/payment systems are not secure, our Media players are not secure, our email and IM is not secure, our web browsing is not secure, nothing in our software is secure… 

…unless we want it secure. 

So if we want to think about secure design, what should we use as a language, and is there any languages we should avoid.  Well a ton of FUD is being generated towards PHP, like it’s the first language to have a high degree of problems.  Probably Microsoft detractors trying to suck people disillusioned by PHP info thinking that Visual Studio will be the holy grail for secure programming.  Only a total idiot could have that type of an epiphany.  Anyways, my thoughts on this subject have been heightened by a recent thread on Bugtraq by a group you’d think knew what they were talking about.  But it shows that its all opinion with little fact.  I question some of this and downright disagree with vast sums of it.

Let me quote:

> —–Original Message—–

> From: Thomas M. Payerle

> Sent: Thursday, February 23, 2006 1:38 PM

> To: Christine Kronberg

> Cc: Gadi Evron; bugtraq@securityfocus.com

> Subject: Re: PHP as a secure language? PHP worms? [was: Re:

> new linux malware]

>

> >> 1. PHP is the “serious” or at least open-source/Linux/security

> >> freak’s choice for web development. Mine as well (although as many

> >> still say, Perl does a better job).

> While PHP is extremely popular, especially in open-source and

> Linux communities,I am not sure it qualifies as the defacto

> choice of “serious” web developers.

 

What language is ranked the ‘defacto choice of “serious” web developers’? 

When I talk to them I typically hear three answers, Javascript, PHP, and ASP. When I look on google to see if there are any trends out there I find most ‘serious’ web developers typically use PHP and a lot of the design houses use ASP.

For developers in general (app, web, etc.)

 

Which programming languages are currently in use at your company for development?

C – 32%

C++ – 54%

C# – 72%

Delphi – 7%

Java – 66%

JavaScript – 50%

PHP – 16%

Perl – 34%

Python – 8%

Ruby – 1%

TCL – 6%

Unix shell scripts – 42%

Visual Basic – 62%

Other interpreted languages – 33%

 

Pasted from <ComputerWorld>

 

According to this I would rank PHP as #3.

Javascript, Perl, then PHP, followed by Python and TCL.

ASP didn’t even qualify (probably a chunk of that ‘other’). 

So what about web developers specifically?  Do they simply use Dreamweaver and frown on the rest?  It’s really up in the air.  A lot of choices out there.  Lets pick a couple examples.

The US  (GAO) General Accounting Office decided that PHP was the choice over java for such reasons as (gasp) security! 

Infoworld

Then there is this guy who thinks the sky is falling.

Nut Case Against PHP

May as well say Windows is a growing target for trojans and worms.  How about Mountains are a growing target for rain?  Taxi drivers are a growing target for passengers?  Runways are a growing target for airplanes (literally!)?  See how foundless this type of comment is?  Javascript has so many holes in it, they cannot realistically be patched, so the best solution is restricting what sites can use javascript, again another solution that has never worked, but at least allows us the whitelist-approach to the solution.

So it’s fairly obvious something with a HUGE penetration into the server market, cost is nil, and developers are abundant around the world,  is to be considered a ‘growing target’ for something!!  If peanut butter became the next language and used by a growing group, guess what?  It too will experience this type of exploitation, it’s part of life.  It’s what we as people do. 

Anyways, lets get back to our bugtraq discussion.

> And I did not think it was as popular in the security

> community (when I occasionally scan one of the reports on the

> frequent PHP based applications that grace this list, I

> thought exploit code is as often as not given in

> Perl:)

Ridiculous and nonsensical comment.  Perl is typically used because it’s easier to write PoC or exploits in.  I personally prefer Python.

Remember, we are here because nobody thinks about the ‘right’ way, just the fast or simple way. What difference does the PoC source mean?

 

> >> 2. Developing secure applications in PHP is difficult, as one of

> >> PHP’s creators said recently – even to him after years of trying.

> The number of PHP applications getting reported on bugtraq

> would seem to support this, although likely also contributed

> to the fact that it is popular, and perhaps that it is (or at

> least has the reputation of being) of being easy to program,

> leading to programs written by people without understanding

> of security implications.

Again, just like any other language or ‘code base’ when we learn from our mistakes we explore new avenues and not necessarily like what we see.  PHP was the least designed to do only a trifle amount of what it has turned into.  It went from being a very simple ‘scripting home pages language’ to a very ‘sophisticated server side language’ in better course of a few years.  In that very short time frame a LOT has been learned about writing secure code in PHP, and the next generation of stuff will be leaps and bounds better, however; a LOT of old code (some no longer supported) needs to be fixed and the fact that the community is working to fix it is king.

But that doesn’t mean that the ‘need’ for secure code is present in all cases.  A Good example of this is ACID, for the longest time the only front end for the popular IDS called Snort used by a security analyst to gather information.  Simply said, one of the worst written apps in PHP probably ever “from a security perspective”. My analysis would be to chuck the whole thing out and rebuild, something a lot of people are currently doing and/or considering, or in the least, aware of the reality.

But in fairness to the author he did not design it ‘for secureness’ he designed it to view insecure data.  He did not think the average ‘user’ would ‘need it’ secure. Again, if the need for something in the software is not perceived, why would you waste time designing it.

The latest push has been into BASE development which has improved, is still nothing secure or even remotely close.  This team still is trying to grasp rewriting the application.  I personally think this was written this way for a reason, but I digress.

These were developed BY SECURITY PROFESSIONALS yet even they failed to account for writing secure code.  What does this tell you, I know what it tells me.  That nobody understands secure code in the first place, so how can they write it? Do people today still think that BASE needs to be written securely?  Back to our discussion:

 

> >> 3. Staying on top of new PHP vulnerabilities has become

> impossible,

> >> popping around everywhere.

> While I concede I am less than happy about the frequency with

> which patched versions of php come out, and most versions

> include some security related patches, I do not think it is

> impossible.  Furthermore, most of the “security”

> patches have been rather localized, and affect only a small

> number of functions and often only in rather specific

> circumstances, and with some knowledge of the PHP

> applications running on your system you can often leap frog

> over some of the versions.

 

 

I’m not quite following this statement, but it would certainly be the one I agree mostly with.  Most patches are good at fixing the issue with the function.  Typically has to do with no longer trusting some data source, and viola it more secure. But it’s similar to patching C functions also.  Or Perl, or Javascript, so why is PHP being singled out?

If you understand the C code, you can fix the problems when they are pointed out to you.  It seems silly to say, but it’s true.  But what is the likeliness of the developer being able to see the problems in his own code.  I think it’s stupid to comment on, but people are inherently egotistical, and programmers even more so.  When it comes to being honest with themselves and seeing their flaws for what they are we seem to emit a hormone that allows our senses to ignore our own, and home in on other peoples.  So, it’s quite unlikely the average developer is going to notice his or her own security flaws.  They will require someone  less in tune with their code, or picks up their hormone.

 

> Most bugtraq messages with PHP in the subject appear to be

> holes in specific applications, usually due to programming

> errors on the part of the application author.  This does not

> mean the language is inherently insecure; although it may

> indicate that it is difficult to write secure PHP code.  It

> could also mean that PHP is easy enough to program that a lot

> of people without knowledge of how to program securely are

> writing PHP code.

Again, I don’t understand what you would define a secure vs. insecure authoring language.  It’s difficult to write secure C code.  It’s difficult to write ANY code, if your not familiar with it, let alone expert with.  So…back to reality…

No language is secure to start with, so your choice is either defined by:

• Application
• Usage
• Availability
• Cost

 

Even if ‘Secure’ was in there, how would you measure it?

Some people never grasp this. 

Then what comes along…I see this fellow has figured this out:

 

On 22/02/06, Kevin Waterson wrote:

> This one time, at band camp, Gadi Evron wrote:

>

> > 3. Staying on top of new PHP vulnerabilities has become impossible,

> > popping around everywhere.

>

> What vulnerabilities in PHP?

> Are implying the fault is within the language itself?

 

I think Gadi meant vulnerabilities in PHP applications; though the language doesn’t make it particularly easy to write secure code.

 

> This is akin to saying C has vulnerabilites because some script kiddie

> wrote a poor application.

 

Like this ?

 

“We can give you advice on how to write good cryptographic code. Avoid any programming language that allows buffer overflows. Specifically:

don’t use C or C++” — Practical Cryptography, Schneier and Ferguson,

(p149 in my copy).

 

It’s a point of view that has
something to be said for it. You *can* write secure code in C and PHP, but it takes a lot of care and most programmers don’t take that care. I’ve been told privately that one penetration tester could gain system privileges on the majority of webservers he checked; that used to surprise me, but doesn’t any longer. I don’t whether that’s a ‘vulnerability’, ‘disadvantage’ or ‘feature’ of PHP and other scripting languages.

cheers,

Jamie

–

Jamie Riden

 

Agreed.  That doesn’t surprise me anymore either .  Why aren’t we surprised by this?  Simple.  We understand that servers are built with money, and nobody wants to spend more money than they have to.  LAMP (Linux, Apache, MySQL, PHP) is a very common web server setup and can be rolled out quickly, easily, and cheaply.  They need little maintenance, and if they aren’t harmed by the users or the guests, then they can stay running for a long time.   If they get infected or hacked, or whatever, they dump the site, and recreate it somewhere else.  If they need to, they can revert back to a old backup of the site once patching a particular hole. 

Why worry about secure software“it doesn’t exist”.

I think this is the mentality that needs to be changed now.

When people think security in their applications they realize that 100% success isn’t going to happen, and that maybe all they can truly offer is 10% or maybe 20% towards that goal.  So they give up or don’t bother.  I hazard that adding that portion will allow us all to get closer and maybe allow the next person to see how to achieve the next 10%.

PHP 5 is showing its progress at dealing with security, but like most good apps, it also relies heavily on the developer to use the tools properly.  PHP has always been a hacker-friendly languange, and there are not a lot of low level design tools to assist in this.  In this regard it allows poorly written apps to be built, but then so does any other language.

We have to judge it on it’s accomplishments with secure design inherit to the language. 

But we shouldn’t think any particular language is “out to get us”.  And this highlights the importance of not relying on any ONE language thinking it’s solutions are the best.  If that was the case we’d never have matured passed FORTRAN.  Maple is so much better to use.

Recently Visual Studio 9 was being released and as I uncovered from the opinionated source ‘eweek’, Peter Coffee mentions about this new developer tool:

I get a queasy feeling, though, from a combination of comments by Visual Studio Team System Lead Program Manager Jeff Beehler, who told us all on his blog last week that (i) “we’ve been fixing tons of bugs” and (ii) “we’re only fixing the most critical of issues to help prevent regressions.”

Does that give anyone else a sense of “uh-oh”? There’s plenty of room for debate about the precise behavior of bug discovery rates as the number of remaining defects in code shrinks down, but I don’t know of any model that estimates a sharp and sudden cutoff between “tons of bugs” and “good to go.”

 

Pasted from <http://www.eweek.com/article2/0,1895,1914426,00.asp>

So, yes in order to reduce costs (regressions) microsoft will concentrate on the critical issues.  No statement that they will fix them, just concentrate efforts towards them.

I too am skeptical about the cutoff point and where that occurs.  But that won’t change the fact that (i) it will happen and (ii) there will be issues and (iii) there will be supporters and defectors as a result. 

Oh I almost forgot, (iv) a holy war.

I’d normally start this paragraph out with ‘in conclusion’ or some such official closing remark, but is this really concluded?  Not by a long shot.