Deceptive site question

Question asked by Jay Altemoos - 7/25/2016 at 12:47 PM

Answered

Good day everyone.

Today I started receiving calls from my users that when they go to our login page for SM they get an error that this website has been flagged as deceptive. This big red screen populates on their screen. I tested it from Firefox and Google Chrome using their latest versions and I got the same results. I even tested it from my android phone using FireFox. Same big red screen populates. Currently we are using SM Enterprise Version 14.5.5907. I started a Google webmaster account and verified the website through their search console. According to Google the login.aspx has been flagged as having harmful content. I looked at the file itself with a text editor and nothing looks out of place or anything added to the file since our last upgrade back in March 4,2016. Modified date is the same as well. So why all of the sudden did Google flag our site as being deceptive? I can't find a reason why.

I did some research and found that as of late last year Google started their "Safe browsing" initiative targeted against deceptive social ads. We don't have any ads on our site or our websites. We host our own equipment so it's not a matter of a service provider being flagged. Anyone else run into this?

18 Replies

Reply to Thread

Matthew Titley Replied

7/25/2016 at 4:53 PM

Might it be, as Google defines it, a matter of "autonomous system" info depending upon the IP range assigned to you by your ISP?

Matthew Titley Replied

7/25/2016 at 4:54 PM

If you're willing to give your server URL a few of us are happy to look into. I mean, it's already a public server so why not post it here?

Matthew Titley Replied

7/25/2016 at 4:56 PM

I think I found your site and the URL in question fairly easily...

Matthew Titley Replied

7/25/2016 at 5:50 PM

I can see why this is frustrating to you. I compared the code in your login.aspx to mine and it's nearly identical. My Avast software also flagged your site as a phishing site when I browsed to it. However, all the various security test sites I visited have your site marked as clean and unflagged in any way. I even ran a whole bunch of realtime security scans from a bunch of different security vendors and they all report the same. Jeez, not sure what to say.

It is possible that if you use this same server for more than SmarterMail there might a sub web site running on the server which is compromised?

Jay Altemoos Replied

7/26/2016 at 6:20 AM

Our mail server address is mail.herodata.com.

Jay Altemoos Replied

7/26/2016 at 6:35 AM

Hey Matt. Appreciate the input. It's been driving me crazy. I scanned the server as well and that came up as clean. This server only houses our mail and that's it. According to Google they flagged the login.aspx from what their webmaster panel shows. We have a separate server for web, etc. and they all obviously have different IP's.

Here's something else that's weird, if I go to the address by name resolution is when I get that nasty red screen. If I go to the same login screen using our direct IP address no nasty red screen. It makes no sense. I am looking into the possibility that we might have to get a security certificate because of requiring credentials on the webmail portion, but it makes no sense as to why all of the sudden now? We have been running SM this way for years without issues.

Matthew Titley Replied

7/26/2016 at 7:37 AM

The lack of SSL might be it, no idea, but it is a really good idea to get an SSL cert anyway. They don't cost much.

Jay Altemoos Replied

7/26/2016 at 12:01 PM

Google finally got to our submissions for false positive on our webmail site. So the nasty red screen doesn't populate any longer. Took about 24 hrs. for that to go through. Anyways, the certificate is also on our radar to have implemented. I appreciate the assistance.

Sérgio Rocha Replied

4/5/2017 at 8:22 AM

Hi,

Today we had the same problem with one of our gateways. We don't have any user on the gateway, and the web interface its only used do admin the gateway. We have https on the web interface but we didn't force the https, so it was possible to visit be http.

Maybe it this code at the end of the page, that use a similar technique used in infected Websites:

<script type="text/javascript">
//<![CDATA[
if (top.location.href.indexOf("Login.aspx") == -1) {top.location.href = "Login.aspx";}InjectInfo("", "Login to XXXXXXXXX");WebForm_AutoFocus('ctl00_MPH_txtUserName');//]]>
</script>

Regards,

Sérgio

Jay Altemoos Replied

4/5/2017 at 9:05 AM

So just to updated this thread with anyone else that might be going through this, our fix was to buy a SSL certificate and configure it on our server. Google stopped flagging the site even before we purchased the SSL certificate, but users may still get warnings on Firefox, Google Chrome etc. on the password box not being a secure connection. At least the red screen didn't show any longer once Google unflagged the site.

We didn't have to change any code in any of the files in SmarterMail. All you needed to do is report your website to Google as not being deceptive and they would crawl your site to be sure. Now with that said, just a heads up on this, Google's secure internet campaign is gaining steam. Firefox starts to warn users when they go to log into a website on the password box that someone could potentially capture what you are typing into the password field if that website doesn't have a SSL certificate installed.

Sérgio Rocha Replied

4/5/2017 at 10:20 AM

We did the same, we force the https and reported as secure site.
I share with everyone the rewrite rule we use for a while:

<rewrite>
<rules>
<rule name="Smartermail Force SSL" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTPS}" pattern="Off" />
</conditions>
<action type="Redirect" url="https://sslwebmail.com/{R:1}" />
</rule>
</rules>
</rewrite>

Put this after the </staticContent> and before the </system.webServer>

Remember that the rewrite module must be installed on IIS.

Employee Replied

4/5/2017 at 3:08 PM

Employee Post

Hello Jay. Typically these listings will arise if/when the aspx, html, or other code pieces have been maliciously edited, or when a user mistakenly shares an infected file via file storage within SmarterMail. We're glad to hear you were able to get this resolved, and likely this was an infected file that had been shared previously. Our first recommendation on issues like this is to leverage the tools available via Google to crawl your site and check for malicious content. Typically when listed in Google's autonomous systems, there is an associated reason stored with it that can be accessed via the Google Webmaster Tools or the link below:

https://support.google.com/webmasters/answer/6350487?hl=en

Being that your scans are coming back clean at this point, I think you should be good to go with this. Adding the SSL certificate will further protect your server as well, so thats great news!

Jay Altemoos Replied

4/6/2017 at 8:17 AM

Hi Kyle,

That's the odd part here, we did not edit any of the aspx or any code for SM. We also don't have file storage turned on for any of our users either, so the only thing left is the possibility of malicious attachments in emails, which for the most part ClamAV should be catching. Any of the scans from the Google webmaster tools and also a scan from isithacked.com showed nothing suspicious even though Google claimed we were attempting to deceive users.

Any of the research I did when the red screen appeared had to do with Google directly. Their crawl bot thought our webmail was attempting to deceive users when in fact we were not. After submitting a report to the webmaster tools section on Google the red screen stopped. Still the underlying issue remains with the warnings you will get from browsers like Firefox and Chrome on the password field that the site is not encrypting this page and could be compromised. In fact the portal here in smartertools does that same exact thing when I log in to reply to a post. I use Firefox and I get the same warning.

Here's a post from Mozilla about the warning if anyone is interested in reading through it:

https://support.mozilla.org/t5/Protect-your-privacy/Insecure-password-warning-in-Firefox/ta-p/27861

So the proper route to go with here, is to get an SSL certificate from one of the many suppliers out there and secure your site. Not only does it protect you but also the user logging in. That way you do not get warnings from whatever browser you are using about the password box and you don't potentially get the red screen issue we dealt with last year. We never had the red screen issue prior to last year and everything I researched led to the campaign Google has been spear heading for a more secure internet. It's the intent that any website wanting a username and password to log into a site should have a SSL certificate installed to protect the user.

Here's a link to Google's security blog on the subject:

https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

Eventually from what I gather is that eventually any website requiring information from the user like passwords, personal information, etc should have a SSL certificate installed.

Lakshan Salgado Replied

5/1/2017 at 10:28 AM

So today we got the lovely red screen as well and teh help desk is flooded with calls. I'm sure hoping SM16 will automatically do SSL redirection. We've had a SSL for a while but been reluctant to mess with IIS redirection. If its not in SM16, I hope Tim U hears this loudly, its been needed for a long while now, delay SM16 release if you have to to get it done.

Cheers!

Employee Replied

5/1/2017 at 3:23 PM

Employee Post

Hi Lakshan, good news! SmarterMail 16 does include a setting to force webmail traffic to use HTTPS. This setting can be found when you log in as a System Administrator. Click on the Settings icon > General Settings > Server Info card > Force webmail to use HTTPS.

Jose Gomez Replied

5/8/2017 at 11:00 AM

SmarterTools - you guys need to be aware that this has nothing to do with our login pages being infected or compromised. All of our SmarterTools servers are now being flagged along with all client subdomains. Google is finding something in your code that is causing this flagging. It's a new phenomenon, I admit. But, it's start to happen to everyone. Either (1) something needs to change in your code or, (2) SmarterMail has a vulnerability that is causing this issue. Either way, this should be of serious concern to you guys.

Employee Replied

5/8/2017 at 12:46 PM

Employee Post Marked As Answer

Hi everyone!

From my understanding, this influx in Google flagging has to do with recent changes that Google implemented regarding what they consider "secure." In most cases, I believe implementing and forcing an SSL connection will resolve that red screen. Learn more here and let me know if this helps out!

https://portal.smartertools.com/kb/a3245/google-safe-browsing-warning-and-smartermail.aspx

Thanks,

Cliff Hammock Replied

8/14/2017 at 6:16 AM

I just received this on one of my mail domains. But it specifically references a domain "betatotal" that is not the mail domain and I have no idea what site it goes to. So does that mean there is some malicious code that is redirecting this site to another site? I have looked but cannot find anything that has changed on my SM install or at the mail domain level. I only host mail for a few personal domains on this box. Thanks for any ideas on troubleshooting this. Honestly I don't plan on buying SSL for these few domains at this point, so I am not sure what direction to proceed in.

Attackers on www.betatotal.com may trick you into doing something dangerous like installing software or revealing your personal information (for example, passwords, phone numbers, or credit cards).

Back to Community Threads

Please leave this box unchecked

18 Replies

Reply to Thread

Tags

Related Knowledge Base Articles