Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 45 min 25 sec ago

Which NTP Servers do You Need to Patch?, (Sat, Dec 20th)

1 hour 53 min ago

While people generally know where their real NTP servers are, all to often they dont know that theyve got a raft of accidental NTP servers - boxes that have NTP enabled without the system maintainers knowing about it. Common servers on the network like routers or switches (often when these are NTP clients, they are also NTP servers), PBXs and VOIP gateways, mail servers, certificate authorities and so on.

In these days of auto-updates, you would think that most NTP servers would be patched against the vulnerabilities found by the Google team and described in story written up by Johannes earlier this evening.

However, it only took until the second host checked to find a very out of date server. Unfortunately, its the main NTP server of a large Canadian ISP (Oops). What I also found along the way was that many servers only report 4 as a version, and that from the -sV switch, not from ntp-info. So depending on your internal servers and how they are configured, it may be time for us to start using authenticated scans using tools like Nessus to get service versions for our NTP servers. Hopefully that">C:\">Nmap scan report for ntp.someisp.ca (x.x.x.x)
Host is up (0.0045s latency).
rDNS record for x.x.x.x: khronos.tor.someisp.ca
PORT STATE SERVICE VERSION
123/udp open ntp NTP v4
| ntp-info:
| receive time stamp: 2014-12-20T02:47:52
|">version: ntpd 4.1.1c-rc1@1.836 Thu Feb 13 12:17:19 EST 2003 (1)
| processor: i686
| system: Linux2.4.20-8smp
| leap: 0
| stratum: 3
| precision: -17
| rootdelay: 11.079
| rootdispersion: 33.570
| peer: 32471
| refid: x.x.x.x
| reftime: 0xd83f5fad.b46b9c30
| poll: 10
| clock: 0xd83f61d5.3a71ef30
| state: 4
| offset: -0.329
| frequency: 46.365
| jitter: 3.468
|_">Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 180.08 seconds

This server on the other hand, doesnt report the version in the ntp-info output. -sV reports version 4, but that">C:\ ">Nmap scan report for time.someotherserver.com (y.y.y.y)
Host is up (0.010s latency).
PORT STATE SERVICE VERSION
123/udp open ntp NTP v4
| ntp-info:
|_">Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 143.24 seconds

">Quick Addendum/Update (Johannes):

CentOS and other Linux distros did release updates. However, the version string may not change. Check the Build Date. For example, on CentOS6:
Before patch:ntpd 4.2.6p5@1.2349-o Sat Nov 23 18:21:48 UTC 2013 (1)
After patch:">">" type="cosymantecnisbfw">

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Critical #NTP Vulnerability in ntpd prior to 4.2.8, (Sat, Dec 20th)

2 hours 1 min ago

The Google security team discovered several vulnerabilities in current NTP implementations, one of whichcan lead to arbitrary code execution [1][2]. NTP servers prior to version 4.2.8 are affected.

There are some rumors about active exploitation of at least some of the vulnerabilities Google discovered.

Make sure to patch all publicly reachable NTP implementations as fast as possible.

Mitigating Circumstances:

Try to block inbound connections to ntp servers who do not have to be publicly reachable. However, be aware that simple statefull firewalls may not track UDP connections correctly and will allow access to internal NTP servers from any external IP if the NTP server recently established an outbound connection.

ntpd typically does not have to run as root. Most Unix/Linux versions will configure NTP using a lower privileged users.

According to the advisory at ntp.org, you can also:

Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with thecryptokeyword in yourntp.conf">A few Ubuntu and CentOS systems I tested, as well as OS X systems, do not seem to use autokey.

[1]http://www.kb.cert.org/vuls/id/852879
[2]">In the NTP code, a section of code is missing a return, and the resulting error indicates processing did not stop.

" type="cosymantecnisbfw">

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Bridging Datacenters for Disaster Recovery - Virtually, (Fri, Dec 19th)

Fri, 12/19/2014 - 14:43

Its been a while since we talked about Disaster Recovery issues - the last diary I posted on this was on using L2TPv3 to bridge your Datacenter / Server VLAN to the same VLAN at a DR site, over an arbitrary Layer 3 network (https://isc.sans.edu/diary/8704)

Since then, things have changed. Theres a real push to move DR sites from a rack in a remote office location to recognized IaaS cloud locations. With that change comes new issues. If you are using your own servers in a colocation facility, or using IaaS VM instances, rack space for a physical router may either come with a price tag, or if its all virtual, there might be no rack space at all.

In my situation, I had two clients in this position. The first customer simply wanted to move their DR site from a branch office to a colocation facility. The second customer is a Backup-as-a-Service Cloud Service Provider, who is creating a DR as a service product. In the first situation, there was no rack space to be had. In the second situation, the last thing a CSP wants is to have to give up physical rack space for every customer, and then deploy CSP owned hardware to the client site - that simply does not scale. In both cases, a VM running a router instance was clearly the preferred (or only) choice.

Virtual routers with enterprise features have been around for a while - back in the day we might have looked at quagga or zebra, but those have been folded into more mature products these days. In our case, we were looking at Vyatta (now owned by Brocade), or the open-source (free as in beer) fork of Vyatta - Vyos (vyos.net). Cisco is also in the game, their 1000V product supports IOS XE - their bridge L2 over L3 approach uses OTV rather than L2TPv3 or GRE. Youll find that most router vendors now have a virtual product.

Anyway, Working with Vyatta/Vyos configs isnt like Cisco at all - their configs look a whole lot more like you might see in JunOS. While Vyos supports the L2TPv3 protocol we know and love, its a brand new feature, and it comes with a note from the developer if you find any bugs, send me an email (confidence inspiring, that). Vyatta doesnt yet have that feature implemented. So I decided to use GRE tunnels, and bridge them to an ethernet interface. Since this tunnel was going to run over the public internet, I encrypted/encapsulated the whole thing using a standard site-to-site IPSEC tunnel.font-family:" times="">The relevant configs look like the one below (just one end is shown) Note that this is not the entire config, and all IP">Please - use our comment form and let us know if youve used a different method ofline-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">First, define the bridge interface. Not that STP (Spanning Tree Protocol) is disabled. You likely want this disabled unless youline-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">The ETH0 interface is on the server VLAN (or port group if you are using standard ESXi vSwitches) this is the VLAN that you are bridging to the DR site.line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">The GRE tunnel is also bridged, and also doesnt have an IP address. The encapsulation of GRE-bridge is the same as GRE (IP protocol 47), but the gre-bridgeline-height: normal">This stuff is all important for your security posture, but is not relevant to the tunneling or bridging, so Iline-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal"> line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal">line-height: normal"> line-height: normal">line-height: normal">line-height: normal">line-height: normal">mso-bidi-font-family:Symbol"> Note that the peer IP is the public / NATmso-bidi-font-family:Symbol"> IDs have to be created for each end - these routers use XAUTH when you define a pre-shared key, so to avoid having them use the FQDN, itmso-bidi-font-family:Symbol"> The traffic match for encryption is defined by the source prefix+destination prefix+protocol. In our case, its the management IP of the customer router AND the matching IP on the cloud router AND GREmso-bidi-font-family:Symbol">mso-bidi-font-family:Symbol"> Take some care in defining the pre-shared key. If a word occurs on your corporate website, facebook page, or linkedin (or in a dictionary), its a bad choice, LEET-speak or no.mso-bidi-font-family:Symbol"> We set both ends to initiate, which enables both init and respond. This allows either end to start the tunnel

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

What's Wrong with Bridging Datacenters together for DR?, (Fri, Dec 19th)

Fri, 12/19/2014 - 10:59

With two stories on the topic of bridging datacenters, youd think I was a real believer. And, yes, I guess I am, with a couple of important caveats.

The first is encapsulation overhead. As soon as you bridge using encapsulation, the maximum allowed transported packet size will shrink, then shrink again when you encrypt. If your Server OSs arent smart about this, theyll assume that since its all in the same broadcast domain, a full packet is of course OK (1500 bytes in most cases, or up to 9K if you have jumbo frames enabled). Youll need to test for this - both for replication and the failed-over configuration - as part of your design and test phase.

The second issue si that if you bridge datacenters to a DR or second (active) datacenter site, you are well positioned to fail over the entire server farm, as long as you can fail over your WAN connection and Internet uplink with them. If you dont, you end up with what Greg Ferro calls a network traffic trombone. (http://etherealmind.com/vmware-vfabric-data-centre-network-design/)

If you fail one server over, or if you fail over the farm and leave the WAN links behind, you find that the data to and from the server will traverse that inter-site link multiple times for any one customer transaction.

For instance, lets say that youve moved the active instance of your mail server to the DR Site. To check an email, a packet will arrive at the primary site, traverse to the mail server at site B, then go back to site A to find the WAN link to return to the client. Similarly, inbound email will come in on the internet link, but then have to traverse that inter-site link to find the active mail server.

Multiply that by the typical email volume in a mid-sized company, and you can see why this trombone issue can add up quickly. Even with a 100mb link, folks that were used to GB performance will now see their bandwidth cut to 50mb or likely less than that, with a comensurate impact on response times. If you draw this out, you do get a nice representation of a trombone - hence the name.

What this means is that you cant design your DR site for replication and stop there. You really need to design it for use during the emergency cases you are planning for. Consider the bandwidth impacts when you fail over a small portion of your server farm, and also what happens when your main site has been taken out (short or longer term) by a fire or electrical event - will your user community be happy with the results?

Let us know in our comment section how you have designed around this trombone issue, or if (as Ive seen at some sites), management has decided to NOT spend the money to account for this.

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, December 19th 2014 http://isc.sans.edu/podcastdetail.html?id=4283, (Fri, Dec 19th)

Thu, 12/18/2014 - 17:57
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Exploit Kit Evolution During 2014 - Nuclear Pack, (Thu, Dec 18th)

Thu, 12/18/2014 - 12:06

This is a guest diary submitted by Brad Duncan.

Nuclear exploit kit (also known as Nuclear Pack) has been around for years. Version 2.0 of Nuclear Pack was reported in 2012 [1] [2]. Blogs like malware.dontneedcoffee.com have mentioned version 3.0 of Nuclear Pack in posts during 2013 [3] [4].

This month, Nuclear Pack changed its traffic patterns. The changes are significant enough that I wonder if Nuclear Pack is at version 4. Or is this merely an evolution of version 3, as weve seen throughout 2014? Lets look at the traffic.

In January 2014, traffic from Nuclear Pack was similar to what Id seen in 2013. Here" />

2014 saw Fiesta exploit kit-style URLs from Nuclear Pack. Also, like other exploit kits, Nuclear sent Flash and Silverlight exploits. Here" />

The above example has Silverlight, Flash, PDF and IE exploits. In each case, a payload was sent to the vulnerable VM. The traffic consists of two TCP streams." />

These patterns are not far off from the beginning of the year. I only saw additional exploits from Nuclear Pack that I hadnt noticed before.

In December 2014, Nuclear Pack moved to a different URL structure. I first noticed this on a pcap from Threatglass.com [7]. Initially, Id mistaken the traffic for Angler exploit kit." />

Here" />

Since the change in URL patterns, Nuclear Pack is XOR-ing the malware payload. The image below shows an example where one of payloads is XOR-ed with the ASCII string: DvnQkxI

The change in traffic patterns is fairly significant for Nuclear Pack. I havent found any reason on why the change occurred. Is this merely an evolution, or do these changes indicate a new version of Nuclear Pack?

----------

Brad Duncan is a Security Analyst at Rackspace, and he runs a blog on malware traffic analysis at http://www.malware-traffic-analysis.net

References:

[1] http://blog.spiderlabs.com/2012/04/a-new-neighbor-in-town-the-nuclear-pack-v20-exploit-kit.html

[2] http://www.webroot.com/blog/2012/10/31/nuclear-exploit-pack-goes-2-0/

[3] http://malware.dontneedcoffee.com/2013/08/cve-2013-2465-integrating-exploit-kits.html

[4] http://3.bp.blogspot.com/-iqXmOKC5Zgk/UieYOEA8jPI/AAAAAAAAA_c/nlX2cgxhyZo/s1600/screenshot_2013-09-04_020.png

[5] http://malware-traffic-analysis.net/2014/01/24/index.html

[6] http://malware-traffic-analysis.net/2014/09/29/index.html

[7] http://threatglass.com/malicious_urls/firstliving-org

[8] http://malware-traffic-analysis.net/2014/12/12/index.html

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, December 18th 2014 http://isc.sans.edu/podcastdetail.html?id=4281, (Thu, Dec 18th)

Wed, 12/17/2014 - 18:29
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Is the polkit Grinch Going to Steal your Christmas?, (Wed, Dec 17th)

Wed, 12/17/2014 - 09:22

Alert Logic published a widely publizised blog outlining a common configuration problem with Polkit. To help with dissemination, Alert Logic named the vulnerability Grinch [1] .

In some ways, this isnt so much a vulnerability, as more a common overlypermissive configuration of many Linux systems. It could easily be leveraged to escalate privileges beyond the intent of the polkitconfiguration.

Lets first step back: In the beginning, there was sudo. Sudo served the Unix community well for many decades. I had to Google this myself, but looks like sudo initially was developed in 1986 [2]. Sudois relatively simple in its approach. A simple configuration file outlines who can run what command as what user. Of course, it isnt always as simple, as some software (e.g. many editors) allow the user to spawn shells, but for the most part administrators have found ways to fix these problems over the years. Most importantly, proper ly configured sudo requires the user to enter a password.

Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software.

The problem pointed out by Alert Logic is two fold. First of all, the default polkitconfiguration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the wheels group, which is commonly used for sudo users, to the polkit Admin. This gives users in the wheel group access to administrative functions, like installing packages, without having to enter a password.

The main risk is privilege escalation. With sudo, an attacker would have to enter the users password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool pkcon, which takes advantage of the loose polkit configuration to install packages.

What should you do? What is the risk?

First, have a relaxed christmas and enjoy it with your family. Next, take a look around your network and narrow down how is a member of the wheel group. Only administrators should be a member of the group (people who change system configurations and install software for a living). If you got some time between now and Jan 1st: Read up on Polkit and educate yourself as to what it does.

After new year: Make sure you understand how polkit action are logged, and start reviewing them. Polkit is still new, so many system administrators dont know about it and may ignore the alerts.

Of course, Shellshock and this Polkitissue make a great 1-2 punch to get root on a Unix system. But I doubt a system still vulnerable to Shellshock has no other privilege escalation vulnerability. So I dont think it this is such a huge issue. Fix Shellshock first if that is the case.

And as always, make sure to read the original Alert Logic document to get all the details.

[1] https://www.alertlogic.com/blog/dont-let-grinch-steal-christmas/
[2]http://www.sudo.ws/sudo/history.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Certified pre-pw0ned Android Smartphones: Coolpad Firmware Backdoor, (Wed, Dec 17th)

Wed, 12/17/2014 - 06:44

Researchers at Palo Alto found that many ROM images used for Android smart phones manufactured by Coolpad contain a backdoor, giving an attacker full control of the device. Palo Alto named the backdoor Coolreaper.

With Android, it is very common for manufacturers to install additional applications. But these applications are installed on top of the Android operating system. In this case, Coolpad integrated additional functionality into the firmware of the device. This backdoor was then used by Coolpad to push advertisements to its users and to install additional Android applications.But its functionality goes way beyond simple advertisements.

The backdoor provides full access to the device. It allows the installation of additional software, accessing any information about the device, and even notifying the user of fake over the air updates.

How important is this threat?

Coolpad devices are mostly used in China, with a market share of 11.5% according to the report. They are not found much outside of China. The phones are typically sold under brands like Coolpad, Dazen and Magview.

The following domains and IPs are used for the CC channel:

113.142.37.149, dmp.coolyn.com, dmp.51coolpad.com, icudata.coolyun.com, icudata.51coolpad.com, 113.142.37.246, icucfg.coolyun.com and others. Blocking and logging outbound traffic for these IPs will help you identify affected devices.

For details, see the Palo Alto Networks report athttps://www.paloaltonetworks.com/threat-research.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, December 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4279, (Wed, Dec 17th)

Tue, 12/16/2014 - 19:29
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, December 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4279, (Wed, Dec 17th)

Tue, 12/16/2014 - 19:29
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Some Memory Forensic with Forensic Suite (Volatility plugins), (Tue, Dec 16th)

Tue, 12/16/2014 - 10:17

In previous diaries we have talked about memory forensics and how important it is.

In this diary I will talk about a new volatility plugins called Forensic Suite written by Dave Lasalle.

The suite has 14 plugins and they cover different area of memory forensics

The Forensics Suite can be obtain from: http://downloads.volatilityfoundation.org/contest/2014/DaveLasalle_ForensicSuite.zip .

In this diary I will talk about some of the plugins

Firefox history:

To test this plugin first I browsed the internet using Firefox then I closed it to see how much data firefoxhistory plugin can obtain from the memory image that I acquired after closing firefox .

The firefoxhistory will parse the places.sqlite from the memory and show the output either on the screen or you can direct to csv file using output=csv option. If you use the output=csv option you will be able to play with your data using a spreadsheet software such as MS Excel">

vol.py --plugin=plugins/ --profile=Win7SP1x86 --output=csv -f sampleimage.raw firefoxhistory ">

vol.py --plugin=plugins/ --profile=Win7SP1x86 --output=csv -f sampleimage.raw firefoxcookies ">

vol.py --plugin=plugins/ --profile=Win7SP1x86 -f sampleimage.raw idxparser

">

Volatility Foundation Volatility Framework 2.4

Scanning for IDX files, this can take a while.............

--------------------------------------------------------------------------------

[*] Section 1 (Metadata) found:

Content length: 1624

Last modified date: Tue, 01 Feb 2005 18:28:24 GMT (epoch: 1107282504)

Section 2 length: 270

[*] Section 2 (Download History) found:

URL: http://java.com/jsp_utils/jreCheck.class

IP: 137.254.16.66

: HTTP/1.1 200 OK

content-length: 1624

last-modified: Tue, 01 Feb 2005 18:28:24 GMT

content-type: application/java-vm

date: Mon, 13 Feb 2012 04:21:28 GMT

server: Sun-Java-System-Web-Server/7.0

--------------------------------------------------------------------------------

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, December 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4277, (Tue, Dec 16th)

Mon, 12/15/2014 - 16:34
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Safari 8.0.2 Still Supporting SSLv3 with Block Ciphers, (Mon, Dec 15th)

Mon, 12/15/2014 - 14:30

In October, Apple released Security Update 2014-005, specifically with the intend to address the POODLE issue [1]. The description with the update stated:

There are known attacks on the confidentiality of SSL 3.0 when a cipher suite uses a block cipher in CBC mode. An attacker could force the use of SSL 3.0, even when the server would support a better TLS version, by blocking TLS 1.0 and higher connection attempts. This issue was addressed by disabling CBC cipher suites when TLS connection attempts fail.

However, even with the most recent version of Safari, I am still not able to prove this statement as true. Instead, I am able to connect to a test server that ONLY supports SSLv3 and block ciphers. [2] Multiple users of the site confirmed this observation, and the logs also confirm that current versions of Safari will happily ignore Apple"> SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 183
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 179
Version: TLS 1.2 (0x0303)
"> Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 90
Version: SSL 3.0 (0x0300)
...
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

The server offers AES, a block cipher (CBC) which is accepted by Safari.

Other issues we discovered with the poodletest.com website is the use of proxies. Some proxies still support SSLv3, and if they are configured as a trusted proxy terminating SSL connections, then they may downgrade a connection to SSLv3.

How serious is it? The POODLE attack is still a low probability attack. I am not aware of any active use of the attack. So no need to panic. But vendors like Apple arent helping with incomplete statements. It is possible that Safari is doing some form of downgrading protection. But this is not explained in the very brief advisory.

[1]https://support.apple.com/en-us/HT203107
[2]https://sslv3.dshield.org/vulnpoodle.png

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Customized Support Scam Supported by Typo Squatting, (Mon, Dec 15th)

Mon, 12/15/2014 - 13:11

This attack got it all, and shows how hard it can be for a non ISC reader to evade some of these tech support scams. The URL used, http://login.microsoftlonine.com is only one letter off from the legit Microsoft Office 365 login page (you noticed the extra letter?).

The content you will get back varies. But here is a screenshot submitted by our reader Daniel:

The user was redirected to warning.netsecurityalerts.com (the site appears down right now), and to bolster the sites credibility, it displays the users correct ISP (we all know this is an easy whois lookup, but a user confronted with this message is much more likely to fall for it then a recent message).

Calling the 800 number now will lead to a sales system trying to sell you a medial alert button if you are 50 years or older.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Customized Support Scam Supported by Typo Squatting, (Mon, Dec 15th)

Mon, 12/15/2014 - 13:11

This attack got it all, and shows how hard it can be for a non ISC reader to evade some of these tech support scams. The URL used, http://login.microsoftlonine.com is only one letter off from the legit Microsoft Office 365 login page (you noticed the extra letter?).

The content you will get back varies. But here is a screenshot submitted by our reader Daniel:

The user was redirected to warning.netsecurityalerts.com (the site appears down right now), and to bolster the sites credibility, it displays the users correct ISP (we all know this is an easy whois lookup, but a user confronted with this message is much more likely to fall for it then a recent message).

Calling the 800 number now will lead to a sales system trying to sell you a medial alert button if you are 50 years or older.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, December 15th 2014 http://isc.sans.edu/podcastdetail.html?id=4275, (Mon, Dec 15th)

Sun, 12/14/2014 - 16:40
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Worm Backdoors and Secures QNAP Network Storage Devices, (Sun, Dec 14th)

Sun, 12/14/2014 - 10:21

Shellshock is far from over, with many devices still not patched andout there ready for exploitation. One set of thedevices receiving a lot of attention recently are QNAP disk storage systems. QNAP released a patch in early October, but applying the patch is not automatic and far from trivial for many users[1]. Our reader Erichsubmitted a link to an interesting Pastebin post with code commonly used in these scans [2]

The attack targets a QNAP CGI script, /cgi-bin/authLogin.cgi, a well known vector for Shellshock on QNAP devices [3]. This script is called during login, and reachable without authentication. The exploit is then used to launch a simple shell script that will download and execute a number of additional pieces of malware:

emme [sha1611bd8bea11d6edb68ed96583969f85469f87e0f]:

This appears to implement a click fraud script against advertisement network JuiceADV. The userid that is being used is4287 and as referrer,http://www.123linux.it is used. The user agent is altered based on a remote feed.

cl [sha1b61fa82063975ba0dcbbdae2d4d9e8d648ca1605]

A one liner shell script uploading part of /var/etc/CCcam.cfg to ppoolloo.altervista.com . My test QNAP system does not have this file, so I am not sure what they are after.

The script also created a hidden directory, /share/MD0_DATA/optware/.xpl, which is then used to stash some of the downloaded scripts and files.

Couple other changes made by the script:

  • Sets the DNS server to 8.8.8.8
  • creates an SSH server on port 26
  • adds an admin user called request
  • downloads and copies ascriptto cgi-bin: armgH.cgi and exo.cgi
  • modify autorun.sh to run the backdoors on reboot

Finally, the script will also download and install the Shellshock patch from QNAP and reboot the device.

Infected devices have been observed scanning for other vulnerable devices. I was not able to recover all of the scripts the code on pastebin downloads. The scanner may be contained in one of the additional scripts.

[1] http://www.qnap.com/i/en/news/con_show.php?op=showonecid=342
[2]http://pastebin.com/AQJgM5ij
[3] https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Worm Backdoors and Secures QNAP Network Storage Devices, (Sun, Dec 14th)

Sun, 12/14/2014 - 10:21

Shellshock is far from over, with many devices still not patched andout there ready for exploitation. One set of thedevices receiving a lot of attention recently are QNAP disk storage systems. QNAP released a patch in early October, but applying the patch is not automatic and far from trivial for many users[1]. Our reader Erichsubmitted a link to an interesting Pastebin post with code commonly used in these scans [2]

The attack targets a QNAP CGI script, /cgi-bin/authLogin.cgi, a well known vector for Shellshock on QNAP devices [3]. This script is called during login, and reachable without authentication. The exploit is then used to launch a simple shell script that will download and execute a number of additional pieces of malware:

emme [sha1611bd8bea11d6edb68ed96583969f85469f87e0f]:

This appears to implement a click fraud script against advertisement network JuiceADV. The userid that is being used is4287 and as referrer,http://www.123linux.it is used. The user agent is altered based on a remote feed.

cl [sha1b61fa82063975ba0dcbbdae2d4d9e8d648ca1605]

A one liner shell script uploading part of /var/etc/CCcam.cfg to ppoolloo.altervista.com . My test QNAP system does not have this file, so I am not sure what they are after.

The script also created a hidden directory, /share/MD0_DATA/optware/.xpl, which is then used to stash some of the downloaded scripts and files.

Couple other changes made by the script:

  • Sets the DNS server to 8.8.8.8
  • creates an SSH server on port 26
  • adds an admin user called request
  • downloads and copies ascriptto cgi-bin: armgH.cgi and exo.cgi
  • modify autorun.sh to run the backdoors on reboot

Finally, the script will also download and install the Shellshock patch from QNAP and reboot the device.

Infected devices have been observed scanning for other vulnerable devices. I was not able to recover all of the scripts the code on pastebin downloads. The scanner may be contained in one of the additional scripts.

[1] http://www.qnap.com/i/en/news/con_show.php?op=showonecid=342
[2]http://pastebin.com/AQJgM5ij
[3] https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, December 12th 2014 http://isc.sans.edu/podcastdetail.html?id=4273, (Fri, Dec 12th)

Thu, 12/11/2014 - 19:09
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts