Likely every reader out there, their friends and family, even their pets with email accounts, have received Black Friday SPAM or phishing attempts today. Our own Dr. J sent the handlers an Amazon sample for One Click Black Friday Rewards. Of course, that one click goes no where near Amazon and directs you to the likes of Black Fiday (yes, it's misspelled) at hXXp://www.jasbuyersnet.com/cadillac/umbered/sedatest/styes/coleuses/unterrified.htm. Can't speak to the payload there, don't bother, just use it at as ammo for heightened awareness and safe shopping on line during these holidays, and...well, all the time. Be careful out there. :-)

Cheers and happy holidays.

A number of online services were impacted by what has been referred to by multiple sources as a redirection attack by Syrian Electronic Army (SEA) emanating from the Gigya CDN. The issue was described as follows: "Gigya explained that earlier today at 06:45 EST, it noticed “sporadic failures with access to our service”. The organization than found a breach at its domain registrar, with the hackers modifying DNS entries and pointing them away from Gigya’s CDN domain, instead redirecting to their own server, which distributed a “socialize.js” file, namely the pop-up seen by everyone." Affected sites included Verizon, The Telegraph, The Independent, Forbes, Time Out, PC World, The Evening Standard, CNBC, and others.

The resulting pop-up simply stated "You've been hacked by the Syrian Electronic Army." Sadly, attacks of this nature are commonplace, and SEA has chosen the holidays in previous years to step up its activities so be prepared with your response plan and recovery procedures.

Adobe has released an out of band security update for the Adobe Flash player. This is an additional update for CVE-2014-8439. Everyone either update or double check that Flash either is not installed or cannot be invoked via Internet web sites. 

http://helpx.adobe.com/security/products/flash-player/apsb14-26.html

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Following vulnerabilities discovered in tools many Linux and Information Security enthusiasts use such as the 'strings' command and the bash shell, a new series of issues have been discovered in the 'less' command. Less is used to paginate output, and can be used to view the text contents of a file one page at a time. It can also receive data from a pipe. Examples: 'less myfile.txt' and 'xxd mybinfile | less'. One of the most attractive features of less is that you can move forwards and backwards through the output. It would not be unusual to use less to view files downloaded from the Internet for example. The problem is that less on some versions of Linux run a lesspipe script that invokes other utilities to actually view the contents of the files. Many of these should not be used to view files from an untrusted source. So local arbitrary code execution is possible if less is run on a malformed file. Back to using more?

References:
http://seclists.org/fulldisclosure/2014/Nov/74
http://linuxcommand.org/man_pages/less1.html

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

If you apply classic hardening rules (keep the patch level, use an AV, enable the firewall and use them with due diligence), modern operating systems are more and more difficult to compromise today. Extra tools like EMET could also raise the bar. On the other side, networks are more and more populated with unknown/personal devices  or devices which provide multiple facilities like storage (NAS), printers (MFP), VoIP, IP camera, ...

Being easily compromised, they became a very good target to pivot into the network. They run out-of-the-box, just plug the network/power cables and they are ready to go! A classic vulnerability management process will detect such devices but you still have the risk to miss them if you run a monthly scan! To catch new devices on the fly and to have an immediate idea of their attack surface (example: is there a backdoor present), I'm using the following toolbox: Arpwatch, Nmap and OSSEC as the conductor.

Arpwatch is a tool for monitoring ARP traffic on a LAN. It can detect new MAC addresses or pairing changes (IP/MAC). Nmap is the most known port scanner and OSSEC is a log management tool with many features like a built-in HIDS.

A first good news is that Arpwatch log entries are processed by default in OSSEC. It has a great feature called "Active-Response" which allows to trigger actions (read: execute scripts) in specific conditions. In our case,  I just created an active-response configuration to trigger a Nmap scan of any new device reported by Arpwatch:

The above configuration specifies that nmap-scan.sh will be executed with the argument 'srcip' (reported by Arpwatch) on the agent '001' when the rule 7201 or 7202 will match (when a new host or a MAC address change is detected). The nmap-scan.sh script is based on the existing active-response scripts and spawns a Nmap scan:

nmap -sC -O -oG - -oN ${PWD}/../logs/${IP}.log ${IP} | grep Ports: >>${PWD}/../logs/gnmap.log

This command will output interesting information in grepable format to the gnmap.log file: the open ports (if any) of the detected IP like in the example below. One line per host will be generated:

Host: 192.168.254.65 (foo.bar.be)  Ports: 22/open/tcp//ssh///, 80/open/tcp///,3306/open/tcp/// ...

OSSEC is a wonderful tool and can decode this by default. Just configure the gnmap.log as a new events source:

And new alerts will be generated:

2014 Oct 27 17:54:23 (shiva) 192.168.254.1->/var/ossec/logs/gnmap.log
Rule: 581 (level 8) -> 'Host information added.'
Host: 192.168.254.65 (foo.bar.be), open ports: 22(tcp) 80(tcp) 3306(tcp)

By using this technique, you will immediately detect new hosts connected to the network (or if an IP address is paired with a new MAC address) and you'll get the list of the services running on it as well as the detected operating system (if the fingerprinting is successful). Happy hunting!

Xavier Mertens

Hello Dear Readers,

This diary comes to you by way of 'the real world' and was taken very recently. Has anyone seen anything like this before? This handler was stunned into silence before the years of cynicism took over and I started breathing again. I was about to leave the convenience store, as I had passengers and they were in a hurry, but instead got out and took this picture. There were no cameras monitoring it, the position as you can tell, was around the side of the store, the placement in the area was convenient for drivers to use but terrible for monitoring. I could see someone driving up to use this, and then perhaps making a modification to it for say 'skimming' or repeat after me boys and girls? Can we say 'pivot' ???

Quick poll for the comments: I would never use this (Agree/Disagree) This is risky (Agree/Disagree)

===

Richard Porter

@packetalien

rporter at isc dot sans dot edu

We were notified this evening by Matt H. that Craigslist is suffering an outage of some sort.  Briefly checking the site from the west coast I am finding web access basically unavailable, and access via their app intermittent.  The website downdetector.com shows a period of outage reports increasing over the last 5 hours.  We will continue to monitor, and ask if anybody has information on what is happening, we'd appreciate getting the word out.

tony d0t carothers --gmail

The "Internet of Things" is turning against us once more. Rapid 7 is reporting how Hikvision DVRs are vulnerable to at least 3 different remote code execution vulnerabilities. Metasploit modules are available to take advantage of them, a patch is not available.

All three vulnerabilities were found in the code dealing with RTSP requests. The vulnerabilities are simple buffer overflows.

Hikvision DVRs were already in the news earlier this year, when we found many of them being exploited by "The Moon" worm, bitcoin miners, and code scanning for Synology disk stations. Back then, the main exploit vector was the default root password of "12345" which never got changed.

At this point, device manufacturers just "don't get it". The vulnerabilities found in devices like the Hikvision DVRs are reminiscent of 90s operating systems and server vulnerabilities. Note that many devices are sold under various brandnames and Hikvision may not be the only vulnerable brand.

[1]  https://community.rapid7.com/community/metasploit/blog/2014/11/19/r7-2014-18-hikvision-dvr-devices--multiple-vulnerabilities
[2] https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633/

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

Today, Wordpress 4.0.1 was released, which addresses a critical XSS vulnerability (among other vulnerabilities). [1]

The XSS vulnerability deserves a bit more attention, as it is an all too common problem, and often underestimated. First of all, why is XSS "Critical"? It doesn't allow direct data access like SQL Injection, and it doesn't allow code execution on the server. Or does it?

XSS does allow an attacker to modify the HTML of the site. With that, the attacker can easily modify form tags (think about the login form, changing the URL it submits it's data to) or the attacker could use XMLHTTPRequest to conduct CSRF without being limited by same origin policy. The attacker will know what you type, and will be able to change what you type, so in short: The attacker is in full control. This is why XSS is happening.

The particular issue here was that Wordpress allows some limited HTML tags in comments. This is always a very dangerous undertaking. The word press developers did attempt to implement the necessary safeguards. Only certain tags are allowed, and even for these tags, the code checked for unsafe attributes. Sadly, this check wasn't done quite right. Remember that browsers will also parse somewhat malformed HTML just fine.

A better solution would have probably been to use a standard library instead of trying to do this themselves. HTML Purifier is one such library for PHP. Many developer shy away from using it as it is pretty bulky. But it is bulky for a reason: it does try to cover a lot of ground. It not only normalizes HTML and eliminates malformed HTML, but it also provides a rather flexible configuration file. Many "lightweight" alternatives, like the solution Wordpress came up with, rely on regular expressions. Regular expressions are typically not the right tool to parse HTML. Too much can go wrong starting from new lines and ending somewhere around multi-byte characters. In short: Don't use regular expressions to parse HTML (or XML), in particular for security.

[1] https://wordpress.org/news/2014/11/wordpress-4-0-1/
 

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

Google has released a "Firing Range" for assessing various web application scanners, with what looks like a real focus on Cross Site Scripting.   The code was co-developed by Google and Politecnico di Milano

Targets include:

•     Address DOM XSS
•     Redirect XSS
•     Reflected XSS
•     Tag based XSS
•     Escaped XSS
•     Remote inclusion XSS
•     DOM XSS
•     CORS related vulnerabilities
•     Flash Injection
•     Mixed content
•     Reverse ClickJacking

Source code is on github at  https://github.com/google/firing-range

App Engine deploy is at http://public-firing-range.appspot.com/

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

When the fine folks at Portswigger updated Burp Suite last month to 1.6.07 (Nov 3),  I was really glad to see NoSQL injection in the list of new features.  

What's NoSQL you ask?  If your director is talking to you about "Big Data" or your Marketing is talking to you about "customer metrics", likely what they mean is an app with a back-end database that uses NoSQL instead of "real" SQL.  

I'm tripping over this requirement this month in the retail space.  I've got clients that want to track a retail customer's visit to the store (tracking their cellphone's using the store wireless access points), to see:

• if customers visit store sections where the sale items are?
• or, if customers visit area x, do they statistically visit area y next?
• or, having visited the above areas, how many customers actually purchase something?
• or, after seeing a purchase, how many "feature" sale purchases are net-new customers (or repeat customers)

In other words, using the wireless system to track customer movements, then correlating it back to purchase behaviour to determine how effective each feature sale might be.

So what database do folks use for applications like this?  Front-runners in the NoSQL race these days include MongoDB and CouchDB.  Both databases do cool things with large volumes of data.  However, while both are making huge strides in securing the database app, their current versions both still need quite a bit of TLC in the security space - and of course nobody deletes the old instances, so the original-original problems are still all there.

Luckily, both databases have good (and relatively honest!) security documentation, and both of them explicitly call this situation out.

MongoDB states this nicely at http://docs.mongodb.org/manual/administration/security-checklist/ :

"Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available."

CouchDB has a similar statement at http://guide.couchdb.org/draft/security.html "

"it should be obvious that putting a default installation into the wild is adventurous"

So, where do I see folks deploying these databases?  Why, in PUBLIC CLOUDs, that's where!  Because what better place to put a database that has all kinds of customer data than outside your IPS and other security controls?

And what happens after you stand up your almost-free database and the analysis on that dataset is done?  In most cases, the marketing folks who are using it simply abandon it, in a running state. What could possibly go wrong with that?  Especially if they didn't tell anyone in either the IT or Security group that this database even existed?

Given that we've got hundreds of new ways to collect data that we've never had access to before, it's pretty obvious that if "big data" infrastructures like these aren't part of our current plans, they likely should be.  All I ask is that folks do the risk assessments tha they would if this server was going up in their own datacenter.  Ask some questions like:

• What data will be on this server?
• Who is the formal custodian of that data?
• Is the data covered under a regulatory framework such as HIPAA or PCI?  Do we need to host it inside of a specific zone or vlan?
• What happens if this server is compromised?  Will we need to disclose to anyone?
• Who owns the operation of the server?
• Who is responsible for securing the server?
• Does the server have a pre-determined lifetime?  Should it be deleted after some point?
• Is the developer or marketing team that's looking at the dataset understand your regulatory requirements?  Do they understand that Credit Card numbers and Patient Data are likely bad candidates for an off-prem / casual treatment like this (hint - NO THEY DO NOT).

Smartmeter applications are another "big data" thing I've come across lately.  Laying this out end-to-end - collecting data from hundreds of thousands of embedded devices that may or may not be securable, over a public network to be stored in an insecurable database in a public cloud.  Oh, and the collected data impinges on at least 2 regulatory frameworks - PCI and NERC/FERC, possibly also privacy legislation depending on the country.  Ouch!

Back to the tools to assess these databases - Burp isn't your only option to scan NoSQL database servers - in fact, Burp is more concerned with the web front-end to NoSQL itself.  NoSQLMAP (http://www.nosqlmap.net/) is another tool that's seeing a lot of traction, and of course the standard "usual suspects" list of tools have NoSQL scripts, components and plugins - Nessus has a nice set of compliance checks for the database itself, NMAP has scripts for both couchdb, mongodbb and hadoop detection, as well as mining for database-specific information.  OWASP has a good page on NoSQL injection at https://www.owasp.org/index.php/Testing_for_NoSQL_injection, and also check out http://opensecurity.in/nosql-exploitation-framework/.

Shodan is also a nice place to look in an assessment during your recon phase (for instance, take a look at http://www.shodanhq.com/search?q=MongoDB+Server+Information )

Have you used a different tool to assess a NoSQL Database?  Or have you had - let's say an "interesting" conversation around securing data in such a database with your management or marketing group?  Please, add to the story in our comment form!

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

Microsoft November out-of-cycle patch

Note: MS14-066 was also updated today to fix some of the issues previously discussed with the introduction of the additional TLS cipher suites.  Folks running Server 2008 R2 and Server 2012 are urged to reinstall

Update (2014-11-18 19:45 UTC) - After reading Microsoft's further explanation, the ISC ratings have been adjusted.

Ref: http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

Overview of the November 2014 Microsoft patches and their status.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Today, Microsoft will release MS14-068. This is one of the bulletins that was skipped in November's patch Tuesday update. 

The bulletin fixes a privilege escalation vulnerability and Microsoft rated it Critical.

It does however appear that Microsoft still has process issues with releasing updates. For example, the "Monthly Bulletin Summary" for November now only lists this one bulletin [1]. The bulletin page itself is still blank, but will likely be released around 1:30pm ET.

We will update/replace this diary once the full bulletin is released.

[1] https://technet.microsoft.com/en-us/library/security/ms14-nov.aspx

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

Apple today released updates for iOS 8 and OS X 10.10 (Yosemite) . Here are some of the highlights from a security point of view:

OS 10.10.1

(approx. listed in order of severity)

iOS

Apple TV

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

Microsoft updated MS14-066 to warn users about some problems caused by the additional ciphers added with the update [1]. It appears that clients who may not support these ciphers may fail to connect at all. The "quick fix" is to remove the ciphers by editing the respective registry entry (see the KB article link below for more details).

One user reported to us performance issues when connecting from MSFT Access to SQL Server, which are related to these ciphers.

Sadly, MS14-066 hasn't been Microsoft's best vulnerability announcement. The initial bulletin omitted important details (like the impact of the certificate bypass vulnerability). So far, a total of 3 vulnerabilities are being discussed in conjunction with MS14-066, while the bulletin only lists one CVE number. How the bug was disclosed has also caused confusion, with some Microsoft publications listing external discovery (but private disclosure) and others indicating internal disclosure. 

[1] https://support.microsoft.com/kb/2992611 

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

Just a quick update on the SChannel problem (MS14-066, CVE-2014-6321). So far, there is still no public available exploit for the vulnerability, and details are still sparse. But apparently, there is some progress in developing a working exploit. For example, this tweet by Dave Aitel :

​

Overall: Keep patching, but I hope your weekend will not be disrupted by a major new exploit being released.

Emerging Threats also released some public/free snort rules that promise to cover the various vulnerabilities patched by MS14-066. (http://emergingthreats.net/daily-ruleset-update-summary-11132014/)

I also got a VERY experimental scanner that may be helpful scanning for unpatched hosts. This scanner does not scan for the vulnerability. Instead, it scans for support for the 4 new ciphers that were added with MS14-066. Maybe someone finds it helpful. Let me know if it works. It is a bash script and uses openssl on Unix. You will need at least openssl version 1.0.1h (and you need to connect directly to the test server, not a proxy).

See: https://isc.sans.edu/diaryimages/MSFT1466test.sh  (sig: MSFT1466test.sh.asc)

feedback welcome.

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

When auditing a company for their malware defense savvy, you are likely used to be presented with colorful pie charts of all the malware that their Anti-Virus (AV) product of choice "successfully" intercepted. Odds are that your auditee can show statistics for the past five years, and related "trends" of doom and gloom.

The problem is, we aren't really interested in that. Counting what the AV caught is like counting the number of hits on the final "drop" rule of the Internet firewall: It shows scary numbers, but who cares, given that this is stuff that was STOPPED.  Way more interesting is stuff that managed to sneak by and was missed ... but how do we find it?

One approach that I like to use involves "Perl Compatible Regular Expressions" (PCRE).  You likely encountered PCREs before - Perl has one of the most versatile sets of regular expression language that can be used to match any text pattern imaginable. Snort, for example, supports PCREs in its rule language. Amazing Perl, of course, supports PCRE natively. And .. lo and behold, the lowly Unix "grep" command, on many Unix flavors, supports a "grep -P", which gives it alien PCRE powers.

What to do with them powers, you ask?  Well, in an audit, obtain the last 10 days or so of proxy server logs. Most companies have them, and be prepared that they are HUGE. Plunk them onto a Unix system of your choice that supports "grep -P". Then, if you are reading malware blogs like Kafeine's http://malware.dontneedcoffee.com and Brad's http://malware-traffic-analysis.net, you have an ample reservoir of URLs for currently active threats. If you "speak" PCRE, turning these URLs into "patterns" is no big deal, and provides good fresh intel. If you don't speak PCRE, you (well, should learn!!) can make use of the "current events" ruleset of Emergingthreats, for example http://rules.emergingthreats.net/open/snort-2.9.0/rules/emerging-current_events.rules. Look for recently added rules that cover trojan activity.

Then, for the analysis, piece the various PCREs together into one big bad*ss PCRE, and run it in a "grep -P" command, like thusly:

daniel@debian$ grep -P "(http:\/\/[^\x2f]+\/[a-z0-9]{6,}_[0-9]+_[a-f0-9]{32}\.html|\/[a-f0-9]{60,66}(?:\x3b\d+){1,4}|\/\??[a-f0-9]{60,}\x3b1\d{5}\x3b\d{1,3}|\/[0-9a-z]{32}.php\?[a-z]{1,3}=[0-9a-z]{32})" bigproxylogfile.txt

Nov 10 11:43:18 local7.info squid[20791]: time='2014-11-10 11:43:18'; rc='TCP_MISS/200'; ip='10.17.22.91';  head_type='application/x-shockwave-flash'; size='10751'; req='GET'; url='http://tblwynx.ddns.net/cp9ne2q/65add93b06c4d0042d2fae8cc3585a400ccb629729ae981d3849b1bb7c26a1ec;130000;214';  referrer='http://tblwynx.ddns.net/nrll3fpihn5lzyvnrkk8klq88cnfyapoeivvkbieeeff';

Yes, it will take a while, but if you get any hits, like the "Fiesta" exploit kit hit shown above, I guarantee that it will be highly entertaining to ask the auditee if and whether they noticed anything amiss on the PC 10.17.22.91 on November 10. The "fresher" your PCRE, the better the results that you will pull out of the log. With a decently up to date PCRE, I have yet to see an auditee who doesn't have several "hits" in ten days worth of proxy logs.

If you have any cool PCRE malware detection tricks up your sleeve, please share via the comments below!

We had a number of users suggesting that we should have labeled MS14-066 as "Patch Now" instead of just critical. This particular vulnerability probably has the largest potential impact among all of the vulnerabilities patched this Tuesday, and should be considered the first patch to apply, in particular on servers.

Just like OpenSSL implements SSL on many Unix systems, SCHANNEL is the standard SSL library that ships with Windows. Expect most Windows software that takes advantage of SSL to use SCHANNEL .

Microsoft stated that this vulnerability will allow remote code execution and that it can be used to exploit servers. Microsoft also assigned this vulnerability an exploitability of "1", indicating that an exploit is likely going to be developed soon. But other then that, very little has been released publicly about the nature of the vulnerability.

There is some conflicting information if the bug was found internally or by a third party. The bulletin states: "This security update resolves a privately reported vulnerability" [1] . A blog post about the vulnerability states: "Internally found during a proactive security assessment." [2] . Finally, Microsoft's "Acknowledgement" page does not list a source for the vulnerability [3]. It is not clear how far outside of Microsoft the vulnerability was known prior to the patch release.

However, as soon as a patch was released, it can be used to learn more about the vulnerability. It is very hard these days to obfuscate a patch sufficiently to hide the nature of a vulnerability.

So what does this mean for you? 

My guess is that you probably have a week, maybe less, to patch your systems before an exploit is released. You got a good inventory of your systems? Then you are in good shape to make this work. For the rest (vast majority?): While you patch, also figure out counter measures and alternative emergency configurations.

The most likely target are SSL services that are reachable from the outside: Web and Mail Servers would be on the top of my list. But it can't hurt to check the report from your last external scan of your infrastructure to see if you got anything else. Probably a good idea to repeat this scan if you haven't scheduled it regularly.

Next move on to internal servers. They are a bit harder to reach, but remember that you only need one internal infected workstation to expose them. 

Third: Traveling laptops and the like that leave your perimeter. They should already be locked down, and are unlikely to listen for inbound SSL connections, but can't hurt to double check. Some odd SSL VPN? Maybe some instant messenger software? A quick port scan should tell you more.

You are doing great if you can get these three groups out of the way by the end of the week. Internal clients are less of an issue, but just like "traveling laptops", they may run some software that listens for inbound SSL connections. 

Stick with my old advice: Patching is only in part about speed. Don't let speed get in the way of good operations and procedures. It is at least as important to patch in a controlled, verifiable and reproducible way. Anything else will leave you open to attack due to incomplete patching. Don't forget to reboot the system or the patch may not take affect.  

Microsoft didn't mention any workarounds. But this may change as we learn more about the issue. So make sure that you know how to disable certain ciphers or certain SSL modes of operations. And please take this as an other opportunity to get your inventory of hardware and software sorted out.

Patch Now? Maybe better: Patch first / Patch soon. This vulnerability could turn into a worm like "slapper", an OpenSSL worm exploiting Apache back in the day.

I am not aware of any public IDS signatures for this problem so far, but it may make sense to check for SSL error even on non-Windows servers to spot possible exploit attempts. 

To make things more interesting (confusing?), the Cisco Talos blog states that "[w]hile it is covered by only a single CVE, there’s actually multiple vulnerabilities, ranging from buffer overflows to certificate validation bypasses". [4] It would be really odd from Microsoft to only use a single CVE number for various vulnerabilities only related by the common library they happen to be found in. But I do give Cisco some credibility here as they are working closely with Microsoft and may have gotten more details from Microsoft then what was published in the bulletin.

Cisco also published a number of Snort rules for MS14-066. If you have a VRT subscription, you should see these rules with an SID from 32404 through 32423.

PLEASE SHARE ANY ATTACK DATA / EXPLOIT SIGHTINGS YOU MAY HAVE ! ( handlers -at- sans.edu or our contact form)

[1] https://technet.microsoft.com/library/security/MS14-066
[2] http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx
[3] https://technet.microsoft.com/library/security/dn820091.aspx
[4] http://blogs.cisco.com/security/talos/ms-tuesday-nov-2014

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

Adobe today released a patch for Flash/Adobe Air which fixes 18 different vulnerabilities [1]. The Flash update is rated with a priority of "1" for Windows and OS X, indicating that limited exploitation has been observed. Please consult the advisory for details.

[1] http://helpx.adobe.com/security/products/flash-player/apsb14-24.html

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

Important: Please note that Microsoft released EMET 5.1 yesterday to address conflicts between EMET 5.0 / IE 11 and the patches released here (likely MS14-065)

We are aware that bulletin numbers are skipped below. Not sure if they will come later. It is possible that I used a version of the bulletin page that wasn't quite ready yet. I will update this page as needed.

Overview of the November 2014 Microsoft patches and their status.

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

Microsoft yesterday release EMET 5.1 . One particular sentence in Microsoft's blog post suggests that you should apply this update (if you are using EMET) BEFORE you apply the Interent Explorer patch Microsoft is going to release in a couple of hours:

"If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation."

For full details, and features added in EMET 5.1, see Microsoft's blog post [1]

[1] http://blogs.technet.com/b/srd/archive/2014/11/10/emet-5-1-is-available.aspx

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

A number of my fellow Handlers have discussed Kippo [1], a SSH honeypot that can record adversarial behaviour, be it human or machine. Normal behaviour against my set of Kippo honeypots is randomly predictable; a mixture of known bad IP ranges, researchers or from behind TOR scanning and probing, would be attackers manually entering information from their jump boxes or home machines.

What caught my eye was a number of separate brute force attacks that succeeded and then manifested the same behaviour, all within a single day.Despite the IP addresses of the scans, the pickup file locations and the downloaded file names being different the captured scripts from the Kippo logs and, more importantly in this case, the hashes were identical for the two files [2] [3] that were retrieved and attempted to run on Kippo’s fake system

“So what?” you may ask. I like to draw lessons learnt from this type of honeypot interaction which help provide some tactical and operational intelligence that can be passed other teams to use. Don’t limit this type of information gather to just the security teams, for example our friends in audit and compliance need to know what common usernames and passwords are being used in these types of attacks to keep them current and well advised. A single line note on a daily report to the stakeholders for security may being in order if your organisation is running internet facing Linux systems with SSH running  port TCP 22 for awareness.

Here are some of the one I detailed that would be passed to the security team.

1)    The password 12345 isn’t very safe – who knew? (implied sarcasm)
2)     The adversary was a scripted session with no error checking (see the script’s actions below)
3)    The roughly two hours attacks from each unique IP address shows a lack of centralised command and control
4)    The malware dropped was being reported in VirusTotal a day before I submitted my copies, so this most likely is a relatively new set of scanning and attacks
5)    The target of the attack is to compromise Linux systems
6)    The adversary hosting file locations are on Windows systems based in China running HFS v2.3c 291 [4] – a free windows web server on port 8889 – which has a known Remote Command Execution flaw the owner should probably looked at updating….
7)    Running static or dynamic analysis of the captured Linux binaries provided a wealth of further indicators
8)    The IP addresses of the scanning and host servers
9)    And a nice list of usernames and passwords to be added to the never, ever use these of anything (root/root, root/password, admin/admin etc)

I’d normally offer up any captured binaries for further analysis, if the teams had the capacity to do this or dump them through an automated sandbox like Cuckoo [5] to pick out the more obvious indicators of compromise or further pieces of information to research (especially hard coded commands, IP addresses, domain names etc) 

If you have any other comments on how to make honeypots' collections relevant, please drop me a line! 

Chris Mohan --- Internet Storm Center Handler on Duty

[1] Kippo is a medium interaction SSH honeypot designed to log brute force attacks and, most importantly, the entire shell interaction performed by the attacker.  https://github.com/desaster/kippo

[2] File hash 1 0601aa569d59175733db947f17919bb7 https://www.virustotal.com/en/file/22ec5b35a3b99b6d1562becb18505d7820cbcfeeb1a9882fb7fc4629f74fbd14/analysis/
[3] File hash 2 60ab24296bb0d9b7e1652d8bde24280b https://www.virustotal.com/en/file/f84ff1fb5cf8c0405dd6218bc9ed1d3562bf4f3e08fbe23f3982bfd4eb792f4d/analysis/ 

[4] http://sourceforge.net/projects/hfs/
[5] http://www.cuckoosandbox.org/

In almost every project I have ever worked the scope is defined as part of the scope/schedule/budget of the project (as it should be), and we have to work within that scope.  In most cases that scope is set in advance by management, with little or no input regarding the impact to the system’s security.  It is almost automatically assumed that if a commercial IT offering exists, and it appears successful, then it must be secure.  The thought is ‘if it/they were not secure, how could it/they be in business?’  I see this in almost every instance when it comes to third party integrations.  However it is not always limited to web integrations, and some of the next-gen attacks that are prevalent today.  It can be as simple as stealing a password off a keyboard in another business that has access to your system. (We train our employees, but that does not mean everyone does)

Home Depot announced recently a breach that was the result of credentials issued to, and stolen from, a third party vendor.  As with any third party integration or vendor support, security must be considered with the same regard as our own internal systems and processes.  In this case, it may have been as simple as a fleet vendor who maintains the Home Depot trucks, and needed access for parts and billing.  Or maybe it was a third-party vendor stocking the shelves, who needed access to inventory levels.  It is mostly irrelevant, as their access needs to be treated with the same accord as if they were setting up a workstation on your network, and quite probably something was overlooked.  

I cannot say this loud enough: Do not assume that because a company has been in business for “x” years, or they are the hottest product on the market, that it is backed by solid security.  That is an assumption that can cost.  Dearly.

I would like to hear what other ‘bad assumptions’ that you’ve encountered.  Speak up!

tony d0t carothers --gmail

[Guest Diary: Didier Stevens] [Shellcode Detection with XORSearch]

Frank Boldewin (http://www.reconstructer.org/) developed a shellcode detection method to find shellcode in Microsoft Office files, like .doc and .xls files. He released this as a feature of his OfficeMalScanner tool (http://www.reconstructer.org/code.html).

I consider this a very interesting detection method, and wanted to use this method on other file types like pictures. That’s what motivated to integrate this in my XORSearch tool.

XORSearch has been presented here before. It’s a string search tool that brute-forces the content of the searched file with simple encoding methods like XOR, ROL, … Say that you have a malware sample that downloads a file. You want to know the download URL, but the strings command will not find the URL, because it is encoded with XOR key 0xD1. XORSearch will find the URL like this: xorsearch malware.exe http

At the beginning of this year, I extended XORSearch beyond string searching: with option –p, it will find embedded PE-files (executables).

And now, shellcode is the next target.

Frank was kind enough to share his shellcode detector’s source code with me. But I wanted a flexible detector, one that can be tailored by the user without coding. So I developed a syntax for Frank’s shellcode detection rules and converted his source code with this new syntax. Let me explain with an example.

32-bit shellcode needs to establish its position in memory. A common method is known as “Get EIP” and uses these 2 instructions:

        call label

label:

        pop eax

The hex code for these instructions is: E80000000058

But another register than eax can be used, and then the hex code is not 58 but something else, for example 59. To handle different registers, my syntax supports bit wildcards: E800000000(B;01011???)

This will match E80000000058, E80000000059, …, E8000000005F. All with one pattern.

A pattern has a name and a score, this makes up a rule:

GetEIP method 1:10:E800000000(B;01011???)

The name of the rule is “GetEIP method 1”, the score is 10. Each time a match is found, the rule’s score is added to the total score.

To use XORSearch’s shellcode detector with Frank’s rules, you use option –W (wildcard).

(option –d 3 disables ROT encoding brute-forcing: ROT generates too much false positives with shellcode detection)

You can see from the screenshot that many detection rules triggered on this sample, and that the total score is 136.

To view all the rules I embedded in XORSearch, issue command xorsearch –L.

And if you want to provide your own rules, use option –w. I explain the rule syntax in detail in this blogpost:

http://blog.didierstevens.com/2014/09/29/update-xorsearch-with-shellcode-detector/

XORSearch is open source written in C, without OS-specific calls. I publish the source code and binaries for Windows, OSX and Linux.

Download XORSearch: http://blog.didierstevens.com/programs/xorsearch/

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center

Regular reader and contributor Gebhard sent us a pointer to Crypto 101, an "introductory course on cryptography, freely available for programmers of all ages and skill levels" by Laurens Van Houtven (lvh) available for everyone, for free, forever. It's a pre-release PDF read of a project that will be released in more formats later. 

The Crypto 101 course allows you to learn by doing and includes "everything you need to understand complete systems such as SSL/TLS: block ciphers, stream ciphers, hash functions, message authentication codes, public key encryption, key agreement protocols, and signature algorithms."

• Learn how to exploit common cryptographic flaws, armed with nothing but a little time and your favorite programming language.
• Forge administrator cookies, recover passwords, and even backdoor your own random number generator.

Lvh has written a fine book here, it's comprehensive yet accessible, robust but not overwhelming, and accomplishes its intended mission as a learning guide. And did I mention that it's free? Every aspect of the project is hosted on Github, and includes exercises for hands-on. It really is a 101 opportunity to learn and develop your skills, I highly recommend your immediate acquisition and review.

I have had a number of occasions lately to use or talk about vFeed from Toolswatch.org (@toolwatch). NJ's written a little gem here; a useful Python CLI tool that pulls CVEs and other Mitre datasets.

From the vFeed Github repo: "vFeed framework is an open source naming scheme concept that provides extra structured detailed third-party references and technical characteristics for a CVE entry through an extensible XML schema. It also improves the reliability of CVEs by providing a flexible and comprehensive vocabulary for describing the relationship with other standards and security references."

I was reminded of vFeed when @FruityWifi included a vFeed module in the latest FruityWifi release, a topic for my latest toolsmith column, Inside and Outside the Wire with FruityWifi & WUDS. Using vFeed is really straightforward, particularly now with its handy search feature. Change directories to your installation path, and as long as you have a Python interpreter available, simply type vfeedcli.py and it will dump its usage file as seen in Figure 1.

Figure 1: vFeed usage

You can use the likes of vfeedcli.py search CVE-2014-6271 to look for everyone's current fave, the Shellshock CVE (see also: CVE-2014-7169, the fix for the fix), resulting in Figure 2.

Figure 2: vFeed search

Note that vFeed recommend that I export that CVE for more information. Ok, I will! The result is an XML file that includes every facet of the vulnerability including all the reference URLs, cross references, vulnerable targets (CPE), risk scoring (CVSS),  patch management details, attack patterns, assessment data (exploits & vuln scanning), and even Snort & Suricata signature details. I love vFeed so much I even wrote a little R app to parse vFeed XML exports for quick summaries (will be sharing in December as part of a Linux Magazine article, Security Data Analytics & Visualization With R), so stay tuned.

Download and experiment with vFeed at your earliest convenience. So simple, so useful, just a cool little app. Remember to run vfeedcli.py update as you begin each session to ensure you have the latest dataset. Cheers and enjoy!

Newcastle (UK) University researchers claim to have found an exploit for the "contactless" payment feature of Visa cards. One of the fraud prevention features of these cards is that only small amounts can be charged in "touch mode", without requiring a PIN. But the researchers say that simply changing the currency seems to evade these precautions completely, and they built a fake POS terminal into a smart phone that apparently can swipe money from unsuspecting victims just by getting close enough to their wallet.

According to the press release, VISA's response was that "they believe that the results of this research could not be replicated outside a lab environment". Unfortunately, there ain't too many cases in security engineering history where such a claim held for more than a day or three. If this attack turns out to be true and usable in real life, Visa's design will go down into the annals of engineering screwups on par with NASA's "Mars Climate Orbiter", where the trajectory was computed in inches and feet, while the thruster logic expected metric information.

Needless to say that the latter episode didn't end all that well.

A couple of weeks ago, I already covered the situation where a "cloud" IP address gets re-assigned, and the new owner still sees some of your traffic.  Recently, one of our clients had the opposite problem: They had changed their Internet provider, and had held on to the old address range for a decent decay time. They even confirmed with a week-long packet capture that there was no afterglow on the link, and then dismantled the setup.

Until last week, when they got an annoyed rant into their abuse@ mailbox, accusing them of hosting an active spam operation. The guy on duty in the NOC didn't notice the IP address at first  (it was still "familiar" to him), and he triggered their incident response team, who then rather quickly confirmed: "Duh, this ain't us!"

A full 18 months after the old ISP contract expired, it turns out that their entire contact information was still listed in the WHOIS record for that old netblock. After this experience, we ran a quick check on ~20 IP ranges that we knew whose owner had changed in the past two years, and it looks like this problem is kinda common: Four of them were indeed still showing old owner and contact information in whois records.

So, if you change IP's, don't just keep the "afterglow" in mind, also remember to chase your former ISP until all traces of your contact information are removed from the public records associated with that network.

If you have @!#%%%! stories to share about stale whois information, feel free to use the comments below, or our contacts form.

Are you looking for another packet sniffer? justniffer is a packet sniffer with some interesting features. According to the author, this packet sniffer can rebuild and save HTTP file content sent over the network. "It uses portions of Linux kernel source code for handling all TCP/IP stuff. Precisely, it uses a slightly modified version of the libnids libraries that already include a modified version of Linux code in a more reusable way."[1] The tarball can be downloaded here and a package is already available for Ubuntu.

The binary execution is pretty straightforward, you can capture/read of the wire or replay captured pcap files. This example (using -l option for custom log format) will output the Time, Destination IP, Website and URL:

justniffer -l "%request.timestamp %dest.ip %request.header.host %request.url" -f file.pcap

11/01/14 17:31:42 208.65.75.22 www.blackberry.com /select/wifiloginsuccess/EN/
11/01/14 13:08:45 23.67.251.66 init.ess.apple.com /WebObjects/VCInit.woa/wa/getBag?ix=1
11/01/14 12:55:27 74.125.226.88 fonts.gstatic.com /s/droidserif/v6/0AKsP294HTD-nvJgucYTaOL2WfuF7Qc3ANwCvwl0TnA.woff2
11/01/14 12:55:26 74.125.193.95 fonts.googleapis.com /css?family=Droid+Serif:regular|Crimson+Text:italic

It also comes with a script justniffer-grab-http-traffic (a python script) that output the web content (html, javascript, images,etc) captured in the traffic to a directory. This is an example of running the python script against an interface, all the traffic gets saved in /tmp/web_traffic.

justniffer-grab-http-traffic -d /tmp/web_traffic -U nobody -i eth1

It can decode other protocols by reading them in "raw" format. For example, just reading an email without any options output the follow summary information:

root@sniffer:/tmp/justniffer -f mail_mime.pcap
192.168.37.202 - - [-] "" test.mail.ca 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] "HELO web88101.mail.re2.yahoo.com" mail.server.ca 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] "MAIL FROM:" 2.1.0 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] "RCPT TO:" 2.1.5 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:08 -0500] "DATA" Enter 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:10 -0500] "Received: (qmail 5457 invoked by uid 60001); 30 Dec 2008 00:35:02 -0000" 2.0.0 0 "" ""
192.168.37.202 - - [29/Dec/2008:19:35:10 -0500] "QUIT" 2.0.0 0 "" ""

Adding "raw" now to the output with -r and it decode the traffic in its entirety including dumping the raw base64 attachment:

root@sniffer:/tmp/justniffer -f mail_mime.pcap -r

220 test.mail.ca ESMTP Sendmail 8.13.8+Sun/8.13.8; Mon, 29 Dec 2008 19:35:08 -0500 (EST)

HELO web88101.mail.re2.yahoo.com
250 test.mail.ca Hello web88101.mail.re2.yahoo.com [206.190.37.202], pleased to meet you

MAIL FROM:
250 2.1.0 ... Sender ok

RCPT TO:
250 2.1.5 ... Recipient ok

DATA
354 Enter mail, end with "." on a line by itself

[...]

This is another tool alternative to capture and analyze traffic that can be added to your tool bag. Give it a try.

[1] http://justniffer.sourceforge.net
[2] http://justniffer.sourceforge.net/#!/justniffer_grab_http_traffic
[3] http://justniffer.sourceforge.net/#!/examples

-----------

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