May 27 2016

Sucuri Security Doesn’t Like the Truth To Be Exposed

When it comes to bad security companies Sucuri Security is certainly up their for a variety things we have seen them do over the years. In just a few of those cases we have written up blog post about those. The company clearly don’t like that we exposed some of their bad practices, as something we just ran across today shows. Someone had posted a review for one of their WordPress plugins, which linked to several of our posts. The review has now been edited, but from the Google cached version you can see what was there and response from Sucuri’s CEO:


The part relevant to our previous posts was (our emphasis added):

Those articles have absolutely nothing to do with the issue you experienced or this ability of this plugin, they are inflammatory and now you’re crossing into the line of social harassment unnecessarily. It’s a shame, seeing your social presence that you’d stoop so low. They are also inaccurate and completely out of context.

So what were these articles they claim are inaccurate and inflammatory.

The third article linked to discussed the poor state of Sucuri’s scanner several years ago, which was accurate then and based on what we have seen more recently the scanner still seems to be quite poor.

The second article discussed an attempt by Sucuri to astroturf a comment on that third article, which they admitted to in the comments of the second article. That comment came from the same person now claiming that the articles are inaccurate, but in his attempt at astroturfing he didn’t actually point out any real inaccuracy in the third article (if any of are articles actually contained inaccuracies we would want to correct them as soon as possible).

The first article discussed how Sucuri uses bad data to try scare people into using their service, so that would make them, not us, the inaccurate ones and probably inflammatory as well.

May 27 2016

Armed FBI agents raid home of researcher who found unsecured patent data

(credit: DailyDot)

FBI agents armed with an assault weapon raided the home of a security professional who discovered sensitive data for 22,000 dental patients was available on the Internet, according to a report published Friday.

Justin Shafer, who is described as a dental computer technician and software security researcher, reportedly said the raid happened on Tuesday at 6:30am as he, his wife, and three young children were sleeping. He said it started when his doorbell rang incessantly and someone banged hard on his door. According to Friday's report:

“My first thought was that my dad had died,” Shafer told Daily Dot in a phone interview, “but then as I went to the door, I saw all the flashing blue and red lights.”

With the baby crying in fear from the racket, Shafer opened the door to find what he estimated to be 12 to 15 FBI agents. One was “pointing a ‘big green’ assault weapon at me,” Shafer told Daily Dot, “and the baby’s crib was only feet from the door.”

The agents allegedly ordered Shafer to put his hands behind his back. As they handcuffed him, his 9-year-old daughter cried in terror, Shafter said, and his wife tried to tell the agents that there were three young children in the house.

Once handcuffed, Shafer was taken outside, still in his boxer shorts, still not knowing what was going on or why.

Over the next few hours, the agents seized all of Shafer’s computers and devices—“and even my Dentrix magazines,” Shafer said. “The only thing they left was my wife’s phone.” The seized property list, a copy of which was provided to Daily Dot, shows that federal agents took 29 items.

Enter Eaglesoft

A FBI agent told Shafer the raid stemmed from an incident in February, when Shafer discovered a file transfer protocol server operated by Eaglesoft, a provider of dental practice management software. The FTP server reportedly stored patient data in a way that made it easily accessible to anyone. Shafer contacted and asked for help privately notifying the software maker, and once the patient data was secured, the breach notification site published this disclosure. In a blog post of his own, Shafer later discussed the FTP lapse and a separate Eaglesoft vulnerability involving hard-coded database credentials.

Read 3 remaining paragraphs | Comments

May 27 2016

Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes

Darkleech is an Apache module on the dark web that distributes malware. This tool, which appeared in 2012, was first used to infect many Apache servers and later sites running Microsoft IIS. The campaign infecting IIS sites was named pseudo-Darkleech because it resembles the Apache infector module. (In this post, we will use the term Darkleech to refer to both Apache and IIS campaigns.)

In early 2012, Darkleech scripts redirected users and led them to Blackhole exploit kit pages. After the Blackhole kit disappeared in October 2013, Darkleech moved to Fiesta exploit kits. From mid-2015 to today, Darkleech scripts switched occasionally between Neutrino and Angler exploit kits to deliver ransomware. Darkleech mostly redirects to Angler landing pages. (A detailed history of Darkleech can be found here.)


Finding Darkleech 

Since late 2015, Darkleech scripts have evolved drastically. They are now highly obfuscated, and we can’t easily determine the URLs they redirect to.

In this post we offer a quick hack for security researchers to find iframes and redirecting URLs from these heavily obfuscated scripts, which are injected into web pages. We will focus only on finding the iframe and URL; we will not discuss the functionality of the scripts or how they work. This hack does not require any special security tools. Using only Notepad and a browser (Firefox in this case), we can see the final iframe and its redirecting URL. This technique makes use of the browser’s “alert box” (message box) feature.

Warning: Do not directly run these scripts on a machine. Use VirtualBox or another virtual machine instead. Also, take caution while making use of the URLs in these scripts. They are usually exploit kit landing pages, which if active exploit vulnerabilities in users’ systems and download malware (mostly ransomware) to infect your system.


Find the sample

For our demonstration, we will use a Darkleech sample we found on VirusTotal that has a low detection rate.

SHA-256: 7ea431ca9980d5f1d92fc105cd89bc897774bbe970db5a8a32dcd6e73ef400ae


This sample has a block of data between <span> tags. The data in this block is highly useful for decoding the final iframe. This data block is decoded using a script that is present just below the <span> block. This heavily obfuscated script lies within the <script> block of the HTML page:



Follow these steps

Near the end of the script, you will find a function call with the following format:

  • Function_name(variable_name)();

In the script, the function appears like this:


The variable_name is always a variable used to concatenate the entire script.


First step

Replace the function_name (in this case, fileUploadSetTimeout) with “alert” and remove the function call (the parentheses).


After saving the file and opening this page in a browser, you will see the concatenated script string from this obfuscated code. The script will be displayed in a pop-up alert box.


Copy and clean up the script:



Second step

Append this discovered script to the current HTML sample page just below the first step. These scripts are designed to run only on Internet Explorer. So after appending the script, we need to tweak the script to make it run smoothly on Firefox (and other browsers). Change the script thus:

Modify the original statement at line 12 by changing the value of variable “i” to zero.

Original statement:        i = (+[window.sidebar]) + (+[]);

Modified statement:      i = 0;

Also, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][c][c](String.fromCharCode.apply(null, a))();

Modified statement:      temp = [c][c](String.fromCharCode.apply(null, a));



Save this modified script into same sample. Running the sample again now gives us two alert pop-ups. The second pop-up outputs the concatenated script, which is itself a new deobfuscated script.


Copy this script and clean it:



Third step

Similar to the second step, append this script to the sample just after the second step script. Again, we tweak the script, four times, to make it run in Firefox or other browsers.

Modify the original statement at line 20 by replacing the value of variable “ArrayTry” to zero.

Original statement:        ArrayTry = (+[window.sidebar]) + (+[]);

Modified statement:      ArrayTry = 0;

Change the if statement on line 23 to make the condition true:

Original statement:        if (navigator.userAgent.indexOf(pkcs11Typeof[throwImage]) > ArrayTry) {

Modified statement:      if (true) {

Also change the if statement on line 28 to skip the condition:

Original statement:        if (navigator.userAgent.indexOf(“MSIE 10”) > ArrayTry) {

Modified statement:      if (false) {

Finally, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][“constructor”][“constructor”](setIntervalInfinity)();

Modified statement:      tempA = [“constructor”][“constructor”](setIntervalInfinity);



Save this modified script into the same sample. Running the sample again now gives us three alert pop-ups. The first two are the same as before. The third pop-up contains the final malicious iframe and URL that redirects the user.


Copy and clean up the script:


We can now easily see the document.write function call with iframe and URL.



With this simple three-step hack, anyone can easily analyze any Darkleech-injected obfuscated scripts to find the redirecting URLs. With the URLs, we can see which exploit kit landing page the script redirects to. Usually, these URLs are active for only a very short time.

The post Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes appeared first on McAfee.

May 27 2016

wildpwn – UNIX Wildcard Attack Tool

wildpwn is a Python UNIX wildcard attack tool that helps you generate attacks, based on a paper by Leon Juranic. It’s considered a fairly old-skool attack vector, but it still works quite often. The simple trick behind this technique is that when using shell wildcards, especially asterisk (*), the UNIX shell will interpret files beginning...

Read the full post at