"Microsoft notification" leads to Pharma Redirector on Steroids

Today while investigating spam in the PhishMe spam collection, I started looking at a spam campaign that used two distinct subject lines:

Subject: Microsoft notification
Subject: Windows notification

The body of the email looked like this:

NOT Your Friend!

In true botnet style, every single email had a different "friend name."  The three links at the bottom, all go to "real" Microsoft locations, but the "View invitation" button is the place we need to be concerned about today.  While this delivery mechanism certainly COULD be used to deliver malware, right now, all we knew was that it was certainly not from Microsoft and was potentially dangerous.  With at least 310 different sending IP addresses sending us the spam, it seemed a deeper investigation was called for.

Since the spam did not have an attachment, the method to determine whether the URL may be malicious is normally to fetch the URL, but first we ran some statistics.  In this case of the 410 "Microsoft" and the 377 "Windows" versions of the spam there were 773 different redirection destinations, each a hacked website where the criminals placed a small .php program.

Here are just a few examples of the many hundred redirection URLs:

• lsa48.ru / populace.php
• longevidadeativa1.hospedagemdesites.ws / valences.php
• regionp.primor.biz / trowels.php
• vesinhxanh.net / wp-content / gillian.php
• nord-okna.pl / timeout.php
• serax.es / bustles.php
• nethraprophoto.com / i/wp-content/plugins / contour.php
• hassanstudio.com / muttons.php

Each PHP file is a program that will cause the visitor to be automagically redirected to an additional website! To determine what directions will occur, and what we might encounter at the ultimate "landing site" we visit the redirection pages to see where it sends our web browser.
Here's a sample redirection script from pro-kisti.ru / irving.php, which caused us to visit an illicit pharmaceutical sales website:


(meta name="keywords" content="crowds, nothing, mountains, fulfilld")
(title) ice32044 Pain. Era - ran earth heaven. Nigh spotted relief, found.(/title)

function palee() { palea=61; paleb=[180,166,171,161,172,180,107,177,172,173,107,169,172,160,158,177,166,172,171,107,165,
175,162,163,122,100,165,177,177,173,119,108,108,173,175,166,179,158,177,162,173,166,
169,169,179,158,169,178,162,107,175,178,100,120]; palec=""; for(paled=0;paled lessthan paleb.length; paled++) (palec+=String.fromCharCode(paleb[paled]-palea); return palec;
++++++++++++++++++
This code will subtract the number 61 from each value in the row of integers that begins with 180,166, and will then concatenate each character to the previous and convert it to a string.  Then it will wait 1.295 seconds, and forward the visitor to the website by using the document property "window.top.location.href".

We'll decode a bit of this one by hand:
180 - 61 =  119 which is 77 hex which is an ASCII "w"
166 - 61 = 105 which is 69 hex which is an ASCII "i"
171 - 61 = 110 which is 6E hex which is an ASCII "n"

Rather than do this by hand, I told Excel to separate values by the "," into columns and made a simple spreadsheet.  Update the "Shifter" value (in this case the "palea=61") and then paste the comma separated list into the "Values" portion of the spreadsheet.

the "pro-kisti.ru" redirector (Click for full-size)

Row one is the original values
Row two contains the same values, decremented by "Shifter"
Row three contains the same values, displayed in Hex
Row four contains the decoded to English values, in this case reading:

"windows.top.location.href = http : // privatepillvalue dot ru" (altered for safety)

The next URL we tried, zacpower dot com slash destined.php, had used  "unripea=78" for the Shifter value.  We cut and pasted the comma separated values in and see that it redirects to "healingdrugdeal dot ru".

the "zacpower.com" redirector (click for full-size)

The question though, was how many different sites did these 770 redirectors send us to? and were they all illicit pharmaceutical websites? or was it possible that some would redirect us to malware?  The only solution seemed to be to fetch and decode all of them!

A simple wget script took care of the fetching, and we soon had 559 unique .txt files, each containing the redirection program from one of the "still live" redirection sites. (As soon as a webmaster finds such a program, they hopefully delete it!  We were glad to see more than 100 of the websites, mostly ones from over the weekend, were not available any longer!)

Now for a small shell script to yank out the Shifter value and the comma separated integers for each.  There are certainly better shell scripters than me, but here was my quick-and-dirty script:

cat filelist |while read a; do printf '\n'; printf $a;printf ' Shifter:  '; grep -o '=[0-9][0-9]' $a|tr -d '\n'; printf ' values: '; grep -o '[0-9]*,[ ]*[1-9][0-9]*' $a |tr -d '\n'; done

After asking for a new line, I print the filename, which in this case was "domain.tld.txt", then I looked for a two-digit integer preceded by an equal sign, and declared it to be the "Shifter".  Then I searched for a list of comma delimited integers, and listed only the matches using "grep -o".  Because "grep -o" puts each hit on a new line, I piped the tr -d '\n' to remove the new line character and put them all back on one line as a long comma separated list.  Here are a few example results:

gameguideaz.com.txt Shifter:77 values: 196,182,187,177,188,196,123,193,188,189,
123,185,188,176,174,193,182,188,187,123,181,191,178,179,138,116,181,193,193,189,
135,124,124,185,194,176,184,198,175,178,192,193,192,178,191,195,182,176,178,123,
191,194,116,136

gavez.info.txt Shifter: 49 values: 168,154,159,149,160,168,95,165,160,161,95,157,
160,148,146,165,154,160,159,95,153,163,150,151,110,88,153,165,165,161,107,96,96,153,
150,146,157,154,159,152,149,163,166,152,149,150,146,157,95,163,166,88,108

gelecekdiyarbakirsigorta.com.txt Shifter: 22 values:
141,127,132,122,133,141,68,138,133,134,68,130,133,121,119,138,127,133,132,68,126,
136,123,124,83,61,126,138,138,134,80,69,69,130,139,121,129,143,120,123,137,138
137,123,136,140,127,121,123,68,136,139,61,81

genelev.net.txt Shifter: 23 values:
142,128,133,123,134,142,69,139,134,135,69,131,134,
122,120,139,128,134,133,69,127,137,124,125,84,62,127,139,139,135,81,70,70,131,140,122,
130,144,121,124,138,139,138,124,137,141,128,122,124,69,137,140,62,82

geniusetech.com.txt Shifter: 15 values:
134,120,125,115,126,134,61,131,126,127,61,123,126,114,112,131,120,126,125,61,119,129,
116,117,76,54,119,131,131,127,73,62,62,127,129,120,133,112,131,116,127,120,123,123,
133,112,123,132,116,61,129,132,54,74


Now that the files key values are separated out, it was simple to automate the decoding to learn which URL was recommended by each of the websites that were found in the  "View Invitation" links within our spam messages.

So How Many Redirectors were there?  

It APPEARS that there are four redirection destinations for this spam campaign.
By processing the results from all of the redirectors we visited, we found:

131 redirectors went to "privatepillvalue dot ru"
138 redirectors went to "luckybestservice dot ru"
165 redirectors went to "healingdrugdeal dot ru"
125 redirectors went to "bestgenericstore dot ru"

bestgenericstore dot ru

Caution with Redirectors!!

The problem with redirection sites such as were used in this spam campaign is that we can't be certain that others who visit the same results would be redirected in the same way.  Because we did not OBTAIN the redirection script, but merely observed the resulting html results when visiting the page from an automated script, we can't say at this time whether other visitors would be redirected in the same way.

For example, the script may have said "If you seem to be using automation, redirect to a pharma website, but if you seem to be on a regular PC on a regular browser, redirect to an Exploit Kit!" or the script may have said "Send every 50th visitor to be infected with Malware at this exploit kit, but send everyone else to a pharma website."  It is also possible for the script to say "If your IP address is from one of THESE countries, send to a pharma website, but if your IP address is from one of the OTHER countries, infect with malware!"  Until we get a copy of the script from one of the websites, it will be hard to say whether such a trap was present here.

FTC Takes Action Against Insecure IoT Devices from D-Link

I still love to listen to GRC's Steve Gibson on the program Security Now! A few weeks back, Steve said "The S in IoT is for Security" which made me laugh perhaps far too much. As we discover more with each passing day, it seems there is no Security in the Internet of Things.
All of my readers will be well familiar by now with the Mirai botnet, which has demonstrated the capability to cause enormous DDOS attacks, including the 665 Gbps attack against Brian Krebs and the Dyn DNS Attack which crashed a substantial portion of the US Internet.

Both of these attacks were caused by an assortment of Internet of Things devices that have default vulnerabilities or default userid and passwords that in many cases not only are not reset by the users who install these devices in their homes, but in many cases CANNOT be changed! When several people have asked me what I think the answer was going to be to this problem, I've replied that this seems like a Consumer Protection issue and that I hoped the Federal Trade Commission would intervene. While some companies have issued voluntary recalls, such as XiongMai Technologies of China, who makes many whitebox DVR and IP-connected webcam components that are embedded into devices made by other manufacturers, most are washing their hands of responsibility.

Sample: XM Camera components

XiongMai claims (in a Chinese press release) that in their case the widely abused telnet problem was fixed in April of 2015, but they already had many million devices installed before that date.  Their letter to the Chinese Ministry of Justice about the issue is on the same link.

The FTC's Carrot 

The FTC seems to be taking a Carrot and Stick approach. The Carrot came first.  First, all the way back in November of 2013, the Federal Trade Commission held a special Workshop on Security & Privacy in the Internet of Things, gathering formal comments (including tweets) about the presented materials.  This led to their release in January of 2015 of a 71-page report "Internet of Things: Privacy and Security in a Connected World", as well as a 12-page report for IoT system designers called "Careful Connections: Building Security in the Internet of Things"

https://www.ftc.gov/iot-home-inspector-challenge

The FTC is also offering a $25,000 prize in a contest they are calling the IoT Home Inspector Challenge for the best idea on how to remediate the millions of vulnerable devices currently being abused on the Internet.    The competition will officially launch in March 2017 and run through July 2017.

But as warned about in the Jan 2015 report, the FTC also has a stick.  And D-Link just became the next to get hit with it!

The FTC's Stick: D-Link Gets Hit

The FTC released a trio of news announcements about the lawsuit that they filed in California against D-Link:

1. D-Link case alleges inadequate Internet of Things security practices

This first article focuses on the fact that D-Link knew how important security was to their consumers, and they took extra effort to stress the security of their devices in their advertisement.  FTC reporter Leslie Fair says: 

"D-Link Corporation and D-Link Systems, Inc., develop and sell routers, IP cameras, baby monitors and other products designed to integrate consumers’ home networks. If the company’s ads are any indication, D-Link was well aware of consumers’ concern about keeping those networks secure. Promising “Advanced Network Security,” D-Link’s promotional materials assured buyers that their routers “support the latest wireless security features to help prevent unauthorized access, be it from a wireless network or from the Internet.” Other ads touted a D-Link product as “not only one of the finest routers available, it’s also one of the safest.” Even the package for D-Link’s Digital Baby Monitor featured a lock icon with the phrase “Secure Connection” next to a picture of an adorable baby. The company repeated many of those security promises in the interactive interfaces consumers used to set up their D-Link products."

This article says that the lawsuit is primarily because D-Link failed to take "reasonable steps to prevent well-known security flaws."  Some examples listed include:

• D-Link allegedly hard-coded login credentials into D-Link camera software that could allow unauthorized access to cameras’ live feed.
• D-Link allegedly left users’ login credentials for its mobile app unsecured in clear, readable text on consumers’ devices.
• D-Link allegedly mishandled its own private key code used to sign into D-Link software and as a result, it was publicly available online for six months.
• D-Link allegedly failed to take reasonable steps to prevent command injection, a known vulnerability that lets attackers take control of people’s routers and send them unauthorized commands.

2. FTC sues D-Link over router and camera security flaws 

In this article, Consumer Education Specialist, Ari Lazarus, offers some tips to consumers for before and after they buy their router:

• Before you buy or replace a device, do research online. Use search engines to find reviews, but be skeptical about the source of the information. Is it from an impartial security expert, a consumer, or the company itself?
• Download the latest security updates. To be secure and effective, update the software that comes with your device. Check the manufacturer’s website regularly for new software and updates.
• Change your pre-set passwords. Change the device’s default password to something more complex and secure.

3.  FTC Charges D-Link Put Consumers’ Privacy at Risk Due to the Inadequate Security of Its Computer Routers and Cameras

This is the main report of the legal actions taken by the FTC against D-Link, with links to all filed documents, including the 45 page FTC Complaint for Permanent Injunction and Other Equitable Relief, with a 14 page complaint, followed by thirty pages of supporting documentation, including pictures of packaging and marketing claims that promise security.

The complaint alleges that the company failed to take steps to address "well-known and easily preventable security flaws" and gives several examples (which I provide context for in the links for each):

• "hard-coded" login credentials in D-Link camera software, often the "guest/guest" userid and password (these devices were among those targeted by the Mirai botnet)
• a software flaw known as "command injection" that allow hackers to execute unauthorized commands on D-Link routers (see for example CVE-2015-2049, CVE2015-2050, CVE-2015-2051) - security researcher Pierre Kim advised consumers to throw the security-flawed DWR-932B router in the trash, after documenting 20 known vulnerabilities.
• mis-handling of a private key code used to sign in to D-Link software, leaving the code on a publicly accessible website for more than six months (as discussed in Ars Technica in September 2015)
• leaving users' login credentials for D-Link's mobile applications unsecured in clear, readable text on their mobile devices, even though there is free software available to secure the information (this refers to the "mydlink Lite" app

mydlink Lite mobile app stored userid and pass in plaintext on mobile device

 

 The actual complaint says that the FTC is bringing suit "to obtain permanent injunctive relief and other equitable relief against Defendants for engaging in unfair or deceptive acts or practices in violation of Section 5(a) of the FTC Act, 15 U.S.C. § 45(a), in connection with Defendant's failure to take reasonable steps to secure the routers and Internet-protocol cameras they designed for, marketed, and sold to United States consumers."

We'll have to wait to see what the outcome of this suit will be, however in other IoT cases, the defendant has settled.

Other Actions of FTC Swinging Its Stick

 The action against D-Link is the third taken by the FTC.  

In February of 2016, the FTC announced a settlement with ASUS over their deceptive and misleading conduct related to the security of their routers.  In the FTC complaint against ASUS

, the FTC points out that ASUS claimed their routers offered "SPI intrusion detection" and "DoS protection" and that its routers could "protect computer from any unauthorized access, hacking, and virus attacks."  But 918,000 of those routers had a userid and password of "admin/admin" and the AiCloud and AiDisk features were full of vulnerabilities that put the advertised "secure cloud storage" data at risk.  ASUS agreed to submit voluntarily to security audits FOR THE NEXT TWENTY YEARS as part of their settlement.

In February of 2014, TRENDNET, a company that makes IP-connected webcams, advertised that their cameras were secure,  claiming that their Direct Video Stream Authentication setting would secure their video streams if they set a personal userid and password, rather than using the default passwords.  Hackers quickly showed that they could access every TRENDNET camera and view their live video streams, without any userid or password being provided.  The FTC settlement required TRENDNET to contact all customers to let them know about a security patch that would correct the situation, and require them to provide two years of technical support.