Tip of the Day: Getting TFS to remember you each time you open Visual Studio

Because the TFS Server where I work is not on the domain, it will prompt you for credentials each time you log in (unless you’ve previously used the web access and checked the “Remember Me” option). If you don’t want to use the web access portal, you can still get TFS to remember your credentials and not ask you each time you log in.

Go in to the control panel and select “User Accounts”

In the next screen click “Manage Windows Credentials”

In the next screen click “Add Windows Credential”

Then type your details into the form, and press “OK”

You’ll see your new set of credentials appear in the Credential Manager page:

Now when you open up Visual Studio it won’t prompt you for your credentials all the time.

Tip of the day: How to tell why your app couldn’t log on to SQL Server

When you get a log in failure on SQL Server the message you get back from SQL Server Management Studio, or in a .NET Exception is vague for security. They don’t want to give away too much information just in case.

For example, the exception message will be something like “Login failed for user ‘someUser’.” which doesn’t give you much of a clue as to what is actually happening. There could be a multitude of reasons that login failed.

If you want more information about why a log-in failed you can open up the event viewer on the machine that SQL Server is installed on and have a look. You’ll find a more detailed message there.

The wider messages may be things like:

  • “Login failed for user ‘someUser’. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]”
  • Login failed for user ‘someUser’. Reason: Password did not match that for the login provided. [CLIENT: <local machine>]
  • Login failed for user ‘someUser’. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
    Note: This could be because the database doesn’t exist, or because the user doesn’t have permissions to the database.

If you really must do dynamic SQL…

I may have mentioned in previous posts and articles about SQL Injection Attacks that dynamic SQL (building SQL commands by concatenating strings together) is a source of failure in the security of a data driven application. It becomes easy to inject malicious text in there to cause the system to return incorrect responses. Generally the solution is to use parameterised queries

However, there are times where you may have no choice. For example, if you want to dynamically reference tables or columns. You can’t do that as the table name or column name cannot be replaced with a parameter. You then have to use dynamic SQL and inject these into a SQL command.

The problem

It is possible for SQL Server to do that concatenation for you. For example:

CREATE PROCEDURE GetData
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
	SET NOCOUNT ON;

	DECLARE @sql nvarchar(max) =
		'SELECT ' + @ColumnName +
		' FROM ' + @TableName +
		' WHERE Id = '+cast(@Id as nvarchar(20));
	EXEC(@sql)
END
GO

This is a simple stored procedure that gets some data dynamically. However, even although everything is neatly parameterised it is no protection. All that has happened is that the location for vulnerability (i.e. the location of the construction of the SQL) has moved from the application into the database. The application is now parameterising everything, which is good. But there is more to consider than just that.

Validating the input

The next line of defence should be verifying that the table and column names passed are actually valid. In SQL Server you can query the INFORMATION_SCHEMA views to determine whether the column and tables exist.

If, for example, there is a table called MainTable in the database you can check it with a query like this:

SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'MainTable'

And it will return:

INFORMATION_SCHEMA.TABLES

There is a similar view for checking columns. For example:

INFORMATION_SCHEMA.COLUMNS

As you can see, the INFORMATION_SCHEMA.COLUMNS view also contains sufficient detail on the table so that when we implement it we only have to make one check:

ALTER PROCEDURE GetData
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;

    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) =
            'SELECT ' + @ColumnName +
            ' FROM ' + @TableName +
            ' WHERE Id = '+cast(@Id as nvarchar(20));
        EXEC(@sql)
    END
END
GO

Formatting the input

The above is only part of the solution, it is perfectly possible for a table name to contain characters that mean it needs to be escaped. (e.g. a space character or the table may share a name with a SQL keyword). To escape a table or column name it is enclosed in square brackets, so a table name of My Table becomes [My Table] or a table called select becomes [select].

You can escape table and column names that wouldn’t ordinarily require escaping also. It makes no difference to them.

The code now becomes:

ALTER PROCEDURE GetData
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;

    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) =
            'SELECT [' + @ColumnName + '] ' +
            'FROM [' + @TableName + '] ' +
            'WHERE Id = '+cast(@Id as nvarchar(20));
        EXEC(@sql)
    END
END
GO

But that’s not quite the full story.

Really formatting the input

What if you have a table called Cra]zee Table? Okay – Why on earth would you have a table with such a stupid name? It happens, and it is a perfectly legitimate table name in SQL Server. People do weird stuff and you have to deal with it.

At the moment the current stored procedure will simply fall apart when presented with such input. The call to the stored procedure would look like this:

EXEC GetData 1, 'Cra]zee Table', 'MadStuff'

And it gets past the validation stage because it is a table in the system. The result is a message:

Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'Table'.

The SQL produced looks like this:

SELECT [MadStuff] FROM [Cra]zee Table] WHERE Id = 1

By this point is should be obvious why it failed. The SQL Parser interpreted the first closing square bracket as the terminator for the escaped section.

There are other special characters in SQL that require special consideration and you could write code to process them before adding it to the SQL string. In fact, I’ve seen many people do that. And more often than not they get it wrong.

The better way to deal with that sort of thing is to use a built in function in SQL Server called QUOTENAME. This will ensure the column or table name is properly escaped. The stored procedure we are now building now looks like this:

ALTER PROCEDURE GetData
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;

    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) =
            'SELECT ' + QUOTENAME(@ColumnName) +
            ' FROM ' + QUOTENAME(@TableName) +
            ' WHERE Id = '+cast(@Id as nvarchar(20));
        EXEC(@sql)
    END
END
GO

Things that can be parameterised

There is still something that can be done to this. The Id value is being injected in to the SQL string, yet it is something that can quite easily be parameterised.

The issue at the moment is that the SQL String is being executed by using the EXECUTE command. However, you cannot pass parameters into this sort of executed SQL. You need to use a stored procedure called sp_executesql. This allows parameters to be defined and passed into the dynamically created SQL.

The stored procedure now looks like this:

ALTER PROCEDURE GetData
	@Id INT,
	@TableName sysname,
	@ColumnName sysname
AS
BEGIN
    SET NOCOUNT ON;

    IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS
               WHERE TABLE_NAME = @TableName AND COLUMN_NAME = @ColumnName)
    BEGIN
        DECLARE @sql nvarchar(max) =
            'SELECT ' + QUOTENAME(@ColumnName) +
            ' FROM ' + QUOTENAME(@TableName) +
            ' WHERE Id = @Identifier';
        EXEC sp_executesql @sql, N'@Identifier int',
                           @Identifier = @Id
    END
END
GO

This is not quite the end of the story. There are performance improvements that can be made when using sp_executesql. You can find out about these in the SQL Server books-online.

And finally…

If you must use dynamic SQL in stored procedures do take care to ensure that all the data is validated and cannot harm your database. This is an area in which I tread very carefully if I have no other choice.

Try and consider every conceivable input, especially inputs outside of the bounds of your application. Remember also, that defending your database is a multi-layered strategy. Even if you have the best firewalls and security procedures elsewhere in your system a determined hacker may find a way though your other defences and be communicating with the database in a way in which you didn’t anticipate. Assume that an attacker has got through your other defences, how do you provide the data services to your application(s) yet protect the database?

Tip of the Day #14: A Step to PCI Compliance

If you have a public facing website that accepts credit card payments from customers they you?ll be looking to become PCI compliant. This means you need to improve the security of your website to prevent attack and to prevent data being intercepted by third parties.

SSL 2.0 is now seen as weak and insecure, yet IIS will by default accept connections from older browsers that want to use this. It can be turned off, but it isn?t obvious how to do that. Here?s how to turn off SSL 2.0 on IIS or Microsoft Support has a reference on How to disable PCT 1.0, SSL 2.0, SSL 3.0 or TLS 1.0 in IIS (Internet Information Services).

While many PCI auditing companies will tell you if you are using SSL 2.0 or any other weak techniques, the quick test to ensure the server is not serving pages using SSL 2.0 is to change the Advanced Options in Internet Explorer to only support SSL 2.0.

Internet Options 1 (SSL)

After that I went to a secure page in the site and got the following error message:

Internet Explorer cannot display the webpage

Most likely causes:
  • You are not connected to the Internet.
  • The website is encountering problems.
  • There might be a typing error in the address.

What you can try:

Diagnose Connection Problems
More information

This problem can be caused by a variety of issues, including:

  • Internet connectivity has been lost.
  • The website is temporarily unavailable.
  • The Domain Name Server (DNS) is not reachable.
  • The Domain Name Server (DNS) does not have a listing for the website’s domain.
  • If this is an HTTPS (secure) address, click Tools, click Internet Options, click Advanced, and check to be sure the SSL and TLS protocols are enabled under the security section.

For offline users

You can still view subscribed feeds and some recently viewed webpages.
To view subscribed feeds

  1. Click the Favorites Center button , click Feeds, and then click the feed you want to view.

To view recently visited webpages (might not work on all pages)

  1. Click Tools , and then click Work Offline.
  2. Click the Favorites Center button , click History, and then click the page you want to view.

To ensure the site was working normally, I reset the settings to allow only support SSL 3.0 and TLS 1.0 and tried again.

Internet Options 2 (SSL)

This time I got the page I was expecting.

Note: You cannot use FireFox to perform this quick test as it does not support SSL 2.0.

Internet Options 3 (SSL/FF)

Follow up on what not to develop

Back in May I wrote about a substandard website I attempted to use in an article entitled “What not to Develop”. I also sent the hotel an email at the same time telling them of the failing of their website, however, I never got a response.

When the post went live initially, I got asked on twitter to name and shame the company in question. I suppose publically decrying a company has the effect that if people start doing that then companies will be pressurised in to providing a better service or product. These days I do not to put in a blog post the name of the company in question until I’ve given them a chance to respond to any email I might have sent. I sent the email on 16 May 2009 at 17:21 (BST), I think that’s quite enough time for a response.

I’ve decided to publish some more details so that people can at least learn from the mistake and not repeat them elsewhere. Essentially, this is an extract of the email (slightly reformatted to fit this blog)

Hello,

I tried to book on your website last night and it didn’t work – it advertised a rate to me then refused to book it. I then tried to use your Contact Us page to send you a message and that also broke and said “The web site you are accessing has experienced an unexpected error. Please contact the website administrator. “

I don’t know who the web site administrator is, but I can guess it is someone employed by TIG Global given this news story: http://www.hospitalitynet.org/news/4036652.search. Personally, if that is the quality they are delivering I wouldn’t use them again as they are not very good and are at best turning away potential customers and at worst exposing you to needless risk.

In order to [help you to] track down the errors I’ve gone back and replicated the initial problem annotating the pages as I go. You will find a number of graphics files attached.

Southwark Rose Hotel Step 1

In [the above image] I show the initial details of my availability search. Check in Friday 31st July, check out Sunday 2nd Aug. 1 adult, 0 children.

Southwark Rose Hotel Step 2

In [the above image] I show the next page. This was a pop-up, so opened a new window. The details at the top are correct and match what I’d previously entered. The description of the “Weekend Advanced Purchase” sounds perfect “Valid Friday-Sunday throughout 2009″. I see that it is £150 for the “Total price of the stay”. I press the book button.

Southwark Rose Hotel Step 3

In [the above image] I show the next page. This was another pop-up, so opened a second window. I now have 3 windows open just for your hotel. (Is this really necessary?). I spot that the number of nights has increased to 3, so I go to change it back to two. I then get an unhelpfully terse error message that says “Minimum stay: 3″ [See the next image]

Southwark Rose Hotel Step 3 error

At this point I’m some what irritated by the experience so go hunting for your contact us page. I see that it is a form only without an email address. I fill in the form and when I’m ready I press the “Submit” button. At this point I get an error page back that includes the message “The following information is meant for the website developer for debugging purposes.” You might want to tell those developers that this information is also useful for attackers and they shouldn’t be displaying it to the public. If the developers were any good what they would have done is get the website to log the information internally and display a general message to the user. If they wanted to tie up a user’s experiences with what is in the log then they might also include a randomly generated (say a GUID – globally unique identifier) identifier that is put in the log and displayed so a user can refer to when explaining what problems they were having at the time.

The error message that should have never been displayed is [as follows].

Vomiting SQL for no good reason

The details in the error page also contain my original complaint. I think I now understand where the American formatting of culture specific information (e.g. dates) is coming from.The company that produced your website was American and in their arrogance just assumed everyone else was just as comfortable using MONTH/DAY/year. I suspect that same arrogance was also responsible for the other failings I’ve pointed out here.

Regards,

Colin.

So, there you are. The hotel is the Southwark Rose Hotel, and their website was produced by TIG Global. (I’ve recently noticed it actually says that at the bottom of the web pages and I need not have searched for relevant press releases!). Incidentally, you can click on any of the graphics to be taken to my Flickr account to see the full sized version.

BBC repeating mindless nonsense

I’ve just read a report from the BBC that simply repeats some mindless drivel about SQL Injection Attacks from a spokesman for the US Department of Justice. According to the BBC:

Edward Wilding, a fraud investigator, told the BBC that this method was “a pretty standard way” for fraudsters to try to access personal data.

It “exploits any vulnerability in a firewall and inserts a code to gather information,” he explained.

It, however, does not point out that Mr Wilding is incorrect. It simply regurgitates the standard patter about firewalls without question. SQL Injection attacks have absolutely nothing to do with firewalls. They are all to do with leveraging mistakes in the way the application communicates with the database. An application which already has valid rights to communicate with the database. Firewalls may be in place to stop direct access to the database, but a SQL Injection attack takes a secondary route to get there.

In short, SQL Injection Attacks are the result of poor software development practices. Something, the prevalence of which, I’ve blogged about previously. I’ve also blogged about how to reduce the attack surface of the application with respect to SQL Injection attacks. In fact, it is so mind-numbingly easy to reduce the ability for someone to launch a SQL Injection Attack on an application I’m surprised developers are still allowed to get away with it.

But back to the article:

Mr Wilding said that chip-and-pin did provide some protection against SQL attacks, but there was little consumers could do to protect themselves against this kind of fraud.

You have to be kidding me! Chip-and-pin also has nothing to do with a SQL Injection attack. It cannot protect you from one. A SQL Injection Attack is an attack on a database, not the actual physical card. All chip-and-pin can do is ensure that a person using a credit or debit card knows the pin. Chip and pin is not used in online transactions. It is not used in telephone transactions.

“The real vulnerability, I suspect, is internet and telephone transactions. But this is a failure in the configuration of [corporate] firewalls,” he said.

Back to the firewall nonsense again. I repeat that firewalls cannot protect against SQL Injection Attacks because the route to the database is a valid one via a third process. (My machine runs the first process, the database is the second process the application being attacked is the third process) However, the BBC is still blithely repeating this misattribution of blame.

If blame is to be placed anywhere then it must surely be at the door of the developers who wrote the payment system that could so easily be hacked in order to gain sufficient access to the database to get all this data. This, of course, is if you believe that it was a SQL Injection Attack. The BBC could have got that bit wrong too!

UPDATE (@ 19:30)

I’ve just noticed that the BBC have reworked the article and it was last updated an hour ago. It does now contain a side box that I didn’t see before that at least, in some small way, explains that a SQL Injection Attack are “weaknesses in companies’ programming which allows them to get behind firewalls”. The main article now contains the paragraph:

The method is believed to involve exploiting errors in programming to get behind compnay [sic]  frewall’s [sic] and accessing [sic] data.

As you can see by the spelling and grammatical mistakes it must have been rather hastily put together. One quote from Mr Wilding has also changed from being reported as:

“The real vulnerability, I suspect, is internet and telephone transactions. But this is a failure in the configuration of [corporate] firewalls,” he said.

to:

“The real vulnerability [for cardholders], I suspect, is Internet and telephone transactions using credit cards were most vulnerable, he said, though added it was a failure of corporations, not customers.

Yet again, this looks like it was hastily put together because of the poor punctuation.

Come on, BBC, this is not journalism but reactive rubbish! Do you even understand what you are actually reporting?

Are people really this gullible

I just got this in my email:

Let your email come to you.
With Yahoo! Mail Alerts, you’ll know
the instant you get one.
Account Alert
Dear Valued Member,

Due to the congestion in all Yahoo users and removal of all unused Yahoo Accounts,Yahoo would be shutting down all unused accounts,You will have to confirm your E-mail by filling out your Login Info below after clicking the reply botton, or your account will be suspended within 24 hours for security reasons.

UserName: ………………………………

Password:………………………………….

Date Of Birth: …………………………………..

Country Or Territory:..……………………….

After Following the instructions in the sheet,your account will not be interrupted and will continue as normal.Thanks for your attention to this request.We apologize for any inconvinience.

 

Are people really this gullible as to send their password unencrypted in a plain text email?! Not only that but in a manner that outwith the bounds of any previous interaction with the alleged company in question.

Well, I suppose if people are willing to hand over their passwords for £5 I shouldn’t be surprised.

THIS EMAIL IS A FAKE!
DON’T RESPOND TO IT!
YOU ARE ONLY HURTING YOURSELF!

Banking Scams

Just now I got a spam email purporting to be from my bank. In fact, I get lots of these because I obviously have accounts with Barclays, NatWest, HSBC, HBOS, RBS, CitiBank, WellsFargo, Clydesdale, Caja Madrid, ING, and a whole host of others.

Obviously some people are still fooled by them, otherwise they wouldn’t still be sending them out after all those years. In fact, the mails do look like they could be authentic. The from address appears to be from the right place, the wording looks like it could be from my bank, and it gives me a link that looks like the one I log on with. However, it is still a scam.

I’m guessing the normal readership of my blog, mostly software developers, would be able to spot a scam like this fairly easily, but for anyone arriving via Google direct to this page and are looking for some tips for spotting a scam here goes:

Here is the body of a scam email I received:

Dear Customer,
Royal Bank. always look forward for the high security of our clients. During our regularly scheduled account maintenance and verification procedures, we have detected a slight error in your account information.This might be due to either of the following reasons:
1. A recent change in your personal information.
2. Submitting invalid information during the initial sign in process.
Due to this, you are requested to please update and verify your information by clicking the link below:

https://www.rbsdigital.com/default.aspx?

*Important*
We have asked few additional information which is going to be the part of secure login process. These additional information will be asked during your future login security so, please provide all these info completely and correctly otherwise due to security reasons we may have to close your account temporarily.
We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience.


Security Advisor
Royal Bank Of Scotland.

Please do not reply to this e-mail. Mail sent to this address cannot be answered.
For assistance, log in to your Royal Online Bank account and choose the “Help” link on any page.
Royal Bank Email ID # 1009

 

I’ve highlighted some of the text in red, as I’m going to talk about it.

First off, “Dear Customer”, really?! – how impersonal, surely you already know who I am? If the email is so general that they’ve used “Dear Customer” then they’ve obviously sent it to everyone and they really haven’t a clue what there systems are doing. No bank should be that clueless.

Next is the dot after “Royal Bank”. That’s not the end of a sentence. It isn’t even a sentence (it contains no verb). Perhaps they are using the “.” to signify an abbreviation of sorts, but I’ve never seen any Royal Bank communication do that. In fact, I’ve never seen anybody do that for “Royal Bank”.

“Look forward for” is grammatically incorrect, you look forward to things, not “for” them. And why would they be looking forward to the high security of their customers. Surely that already exists. The bank has been around for about 300 years, I imagine after all that time they must be doing something right with regards to security.

You also have to ask yourself, why would the banks processes be so bad as to cause an error for the reasons stated?

Next is the URL (the web address) given to you in order to log in. Hover over it and look in your browser’s status bar. Did you notice that the status bar says something different to what you see on the page? I’ve altered the real address so people don’t inadvertently use it, but you can see it doesn’t match the bank’s real address.

Now, they are asking for additional security information during the log in process. Many banks only ask for random bits of information during the log in process. Like one time they’ll ask for your mother’s name, the next they’ll ask what the first school you went to was, and so on. The spammers obviously need to know all the information so that when they get presented with the real random question they’ll be able to answer correctly.

Finally, why would they close your account temporarily? A bank would never actually close an account for a potential security violation. They may suspend it, or remove access to it, but never actually close it.

So, here are some tips:

  • If you receive an email purporting to be from your bank, don’t click on any links in it.
  • If your banks log on procedure appears to be different from the previous time, check with the bank themselves. They may have updated their website, or it may be a scam, best to check.
  • When you log in, ensure that the address in your address bar is the one you expect, and that it is a properly secure connection. There will be a padlock on the address bar or in the status bar (depending on which browser you have)
  • Banks are generally fastidious about grammar and spelling in any communication they send out. It makes them look highly unprofessional if they weren’t. So check any emails for grammatical or spelling errors.
Technorati Tags: ,,,

Data Protection Muppets

I’ve mentioned this topic on my blog before with regard to the Royal Bank of Scotland and Intelligent Finance but this time it was related to an insurance claim. The insurance company put me in contact with a company that would do the repairs and all they had to do was arrange a time and date. However, it wasn’t that simple.

Initially things seemed to be going well until the company in question phoned me to change the date because they wouldn’t have the materials in time. However, first they wanted to go through security screening.

Now, the conversation to this point had gone something like this:

Me: Hello
Them: Hello, is that Colin Mackay [pronounced kae – I HATE that!]
Me: Mackay [pronounced correctly – its a diphthong, a sliding or gliding vowel that goes from ‘ah’ to ‘ee’] Yes.
Them: This is Martindales. We just need to ask you some security questions before we proceed.
Me: How do I know you are who you say you are?
Them: We are Martindales, your insurance company has appointed us…

The conversation went from bad to worse as I tried to explain that what they are doing is socially conditioning people to hand out sensitive information and was then told that they “had to” ask these questions because of the data protection act. The act makes no such requirement. What they have to do is ensure that they are speaking to the correct person so they don’t divulge potentially sensitive information to the wrong person. However, the way they are going about it, while technically in line with the act, is most certainly not within the spirit of the act.

What made it worst was that when I was asked how they could continue the conversation and I gave the solution they had to ask me no fewer than 3 times how they were going to continue the conversation even although I had given them a solution. After that incident they decided they must not have like my simple solution and refused to communicate with me at all for a while.

My solution, incidentally, was this. They would phone me and indicate that they need to speak to me. I would then get the phone number from existing documentation (i.e. a trusted source) and phone their switchboard and ask to be put through to the person that needed to talk to me. They can then go through the security questions as I will then know I am talking to the correct party. When they phone me I have no way of knowing who I am talking to. They could be making it up. If they give me a phone number to use I won’t use it. I will only use trusted sources like documentation from my insurance company, or from the booklet that the insurance assessor left me.

Anyway, Martindales eventually decided that they did need to communicate with me about yet another change in date and sent me a letter. Pity it didn’t arrive until two days after the guy was supposed to show up. In fact he did almost arrive, and I only knew about it because they phoned me just to say that he was running a little late. Muppets!

 

Aye! Right!

I just got this email purporting to be from PayPal. I don’t believe the email.

Dear valued PayPal member:

It has come to our attention that your PayPal account information needs to be
updated as part of our continuing commitment to protect your account and to reduce
the instance of fraud on our website.  If you could please take 5-10 minutes out
of your online experience and update your personal records you will not run into
any future problems with the online service.


However, failure to update your records will result in account suspension.
Please update your records on or before July 06, 2007.

Once you have updated your account records, your PayPal session will not be
interrupted and will continue as normal.

To update your PayPal records click on the following link:

http://72.189.180.57/updateusersonlinesecurity.html

Thank You.
PayPal UPDATE TEAM

What makes me think it is a fake? The URL does not contain PayPal’s domain name. It is a simple IP address.

So, who owns the IP Address?

OrgName:    Road Runner HoldCo LLC
OrgID:      RRSW
Address:    13241 Woodland Park Road
City:       HerndonState
Prov:       VA
PostalCode: 20171
Country:    US

And what about the real PayPal. Their IP Address is 216.113.188.64.

Also, the email didn’t have my address in the “TO” box (So I’m guessing all the recipients were BCC’d into the list) and the reply address is no-reply@google.com.

I have sent an appropriate email to Road Runner letting them know that someone is using their servers to host phishing sites. Hopefully it can be taken down promptly to prevent any less savvy people falling victim to this really quite amaturish attempt at a phishing scam.

Tags: