Alerts

ISC StormCast for Thursday, July 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4065, (Wed, Jul 16th)

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

Keeping the RATs out: an exercise in building IOCs - Part 1, (Wed, Jul 16th)

Latest Alerts - Tue, 07/15/2014 - 23:35

Reader Jake sent us an awesome bundle of RAT-related mayhem collected during performance of his duties while investigating the unfortunate and prolonged compromise of a company we'll fictitiously call Hazrat Supply.
Guess what?  The RAT that was plaguing the Hazrat Supply environment was proxying traffic back to a Chinese hosting company.
This is my shocked face.

Really, I'm shocked, can you tell?

With the plethora of malicious files shared with us in this package it represents a huge opportunity to create some related IOCs with Mandiant's IOCe as well as run some of this evil through my preferred toolkit with which to identify then build said IOCs. We'll do this in three parts as I'm handler on duty for the next three days (lucky you); there's lots here to play with (lucky me).

Let me give you a quick manifest first:

bybtt.cc3    MD5 c2f0ba16a767d839782a36f8f5bbfcbc
Backdoor:Win32/Zegost.B

mylcx.exe    MD5 4984fd547065ddcd781b068c4493ead6
HackTool:Win32/Zeloxat.A

PwDump7.exe    MD5 d1337b9e8bac0ee285492b89f895cadb
HackTool:Win32/PWDump

svchost.exe    MD5 20a6310b50d31b3da823ed00276e8a50
VirTool:Win32/Obfuscator.BL

Ironically the RDP server the attackers used, RemoteMany3389.exe, is not flagged as malicious by AV detection. Apparently it's a legitimate tool...in China. :-)
Seemingly so too is the file locker they used, xlkfs.sys, courtesy of XOSLAB.COM (signed by Yang Ping). Hey, thanks for signing it, I trust it more.
I'm going to go out on a limb here (not really) and say treat these files as flagrantly hostile.
Hit the big red button if they happen to be on your systems along with their malicious compatriots cited above.
Here are their hashes regardless:
RemoteMany3389.exe    MD5 c9913698afc7288b850f3af602f50819
xlkfs.sys        MD5 4aa2d2975d649d2e18440da0f3f67105

Building IOCs with Mandiant IOCe is in many ways straight forward for simple logic, you'll need to understand AND and OR substructures to build more complex logic branches.
Read the user guide that's installed with the editor.
I took just a few attributes (MD5, SHA1, file size) to start my IOC file for HackTool:Win32/Zeloxat.A as seen in Figure 1.

Figure 1

I'll be populating this further and sharing the full IOC file set for each of these samples upon request after Friday's shift.
Tweet me for them @holisticinfosec or email me via russ at holisticinfosec dot org.

Tomorrow, I'll run Jake's dump file for svchost.exe through Volatility to see what we can further learn and use to create additional IOCs.
Stay tuned.

Russ McRee | @holisticinfosec

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

ISC StormCast for Wednesday, July 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4063, (Tue, Jul 15th)

Latest Alerts - Tue, 07/15/2014 - 14:35
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Oracle July 2014 CPU (patch bundle), (Tue, Jul 15th)

Latest Alerts - Tue, 07/15/2014 - 14:29

In addition to the Java vulnerabilities that I covered earlier, there is at least one more vulnerability that warrants attention. CVE-2013-3751, a problem in the XML parser of Oracle Database. Reading the description, I had a bit of a déjà-vu, also because of the CVE number from last year. And digging into past alerts, I found that, yes, this has indeed been patched before:

 


Looks like the Oracle 12 code was forked before the 11g patch went in, and nobody ported it over, so Oracle 12 remained exposed to the same bug until now. This speaks volumes about Oracle's software development life cycle and security processes... Dear Larry Ellison: how about writing a "Trustworthy Computing" memo for your staff, and then following through on it? I'm sure Bill Gates won't mind much if you simply copy his from 2002 and do a little search-and-replace.

For other untrustworthy computing features brought to you by this month's CPU patch bundle, see https://blogs.oracle.com/security/ and http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html

 

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

Oracle Java: 20 new vulnerabilities patched, (Tue, Jul 15th)

Latest Alerts - Tue, 07/15/2014 - 12:09

Welcome to the n-th iteration of "patch now" for Java on Workstations. Oracle today published their quarterly patch bulletin, and Java SE is once again prominently featured. This Critical Patch Update (CPU) contains 20 new security fixes for Oracle Java SE.  Most of the vulnerabilities are remotely exploitable without authentication, and CVSS scores of 10 and 9.3 indicate that they can be readily exploited, and lead to full compromise. Which means that keystroke loggers, ebanking trojans, etc, will soon follow.

Oracle/Java is probably by now one of the most successful charities in the world, it continues to do an outstanding job at enabling significant wealth transfer to support poor cyber criminals and their families. Except that the sources of the funds usually have no idea, and didn't agree to donate directly from their bank accounts ...

After the past three years of repeated gaping holes in Java, we hope that by now you have found a way to remove Java from your computers entirely, or to at least no longer run the Java plugin within the web browser.  Otherwise, it is back to the hamster wheel, to yet again re-test all your applications that still require Java, to check for the inevitable incompatibilities with this latest release, and then to expedite the roll-out. This is definitely a patch that you don't want to skip or delay.

The full Oracle patch bulletin is available here: http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA  .

The other Oracle patches (for database, etc) released in today's patch CPU are still under analysis here at SANS ISC. I'll post about them later, if warranted.

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

AOC Cloud, (Tue, Jul 15th)

Latest Alerts - Mon, 07/14/2014 - 16:08

In matters of food and wine, the Europeans have this concept of "AOC", based on the originally French "Apellation d'origine contrôlée". It means that, say, Bordeaux wine actually comes from there, and is not re-bottled Malbec from Patagonia. The point I'm trying to make, albeit poorly, is that it is sometimes important to know where things are coming from, which implies traceability to the source.

In matters of IT, we are currently losing this AOC. Only three years ago, we likely knew exactly, down to the server room cabinet and shelf, where our mail server was located. These days, with "cloud" services proliferating rapidly, we might know who *sold* us the service, but we only have a vague idea of its real origin or location.

The question recently came to light again when Codespaces (http://www.codespaces.com/) went down after a hacking attack back in June. As they say on their web page "In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted". I wonder how many (if any) of Codespaces' customers had actually done the due-diligence, while signing up, to determine that all of Codespaces' services were hosted at Amazon EWS, *including* the backups. That's AOC!  You might know from where you buy your SVN or GIT hosting, but - unless you negotiate hard, forbid any sub-subcontracting, and ruthlessly enforce your right to audit - you might never learn where your SVN/GIT hoster actually hosts the service. And, not even with your right to audit, will you ever find out where *that* hoster draws their services from. Because you don't have a contract relationship with the hoster (only with the SVN service on top), and if the hoster, at their discretion, decide that they can operate more cheaply by re-selling Virtual Machines from Patagonia instead of running their own .. that's what's going to happen.

If you like this concept, I have a stellar 1961 Bordeaux that I'm willing to part with for a good price. Please don't worry about the penguins and the Spanish language on the label :).

In all seriousness though - it is overdue that "cloud" providers provide a bit less cloud, and a bit more sunlight. It might hurt their bottom line a little, but the kind of "AOC" end-to-end transparency, with traceability to the source, is vital and paramount for the customer to assess and mitigate any resulting risk.

If you have any stories on how you determine the "AOC" of your penguin wine (or not), please share below.

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

ISC StormCast for Tuesday, July 15th 2014 http://isc.sans.edu/podcastdetail.html?id=4061, (Mon, Jul 14th)

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

E-ZPass phishing scam, (Mon, Jul 14th)

Latest Alerts - Mon, 07/14/2014 - 11:45

Over the last couple of days, we have been seeing a number of quite credibly looking phishing emails that impersonate toll-road providers in the US. The agency affected by the current wave is E-ZPass, a toll charging system used mainly in the Northeast. Adapting the template to match the colors and fonts of other organizations, like Florida's SunPass, would be easy to accomplish for the scammers though, so chances are that we will see more of this.

Since toll road agencies can impose stiff fines for violations or if road and bridge charges are not paid in time, people might fall for it and click on the link just to make sure. In the samples at hand, the link was pointing to www . ruckon . pl (spaces added to de-fang), and returned a ZIP with an EXE or directly an EXE. Hat tip to ISC reader Wayne for providing the latest sample.

 

If you receive similar emails that impersonate other toll road providers, please let us know.

 

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

Oracle July 2014 Update Pre-Notification, (Sun, Jul 13th)

Latest Alerts - Mon, 07/14/2014 - 06:34

Oracle has released a preview of patches to be released, seen here, on Tuesday, July 15, 2014, and includes updates to business critical systems, such as Oracle Database, WebLogic server, and Fusion.  The most concerning aspect of the majority of vulnerabilities discussed is the one phrase “may be exploited over a network without the need for a username and password”.  The most critical update, imho, that is being released Tuesday is the Java fixes that are being released (20 security fixes!), which give the vulnerability a pristine CVSS Base Score of 10!!  Woohoo, way to go Oracle and Team Java!

But please don’t take my word for all of this, go take a look for yourself, and see what the week ahead has in store.

tony d0t carothers --gmail

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

The Internet of Things: How do you "on-board" devices?, (Mon, Jul 14th)

Latest Alerts - Mon, 07/14/2014 - 01:43

Certified pre-pw0ned devices are nothing new. We talked years ago about USB picture frames that came with malware pre-installed. But for the most part, the malware was added to the device accidentally, or for example by customers who later returned the device just to have it resold without adequately resetting/wiping the device.

But more recently, more evidence emerged that everything from network gear [1] to inventory scanners [2] may be infected deliberately in order to penetrate otherwise hard to reach networks. Typically, there is little a customer can do to verify that a device is not infected. Standard practices, like malware scanners and verifying installed software doesn't always work if you don't have "shell access" or the ability to install software on the device. 

This leaves careful network monitoring as one option to  detect and disrupt command and control channels used by these devices. However, in order to do so accurately, it is important to characterize "normal" network traffic from the device, which can be challenging in particular if the device connects to cloud services for updates or intentional data exchange.

The large number of these devices entering our networks asks for a scalable solution. We can't add security devices and personal proportional to the number of devices deployed. The security features included in these devices (host based firewalls, encryption technologies, ability to manage and limit installed software/"apps") varies widely and frequently there are no enterprise configuration tools available. 

What kind of network segmentation and on-boarding procedure do you apply to new devices introduced into the network? 

[1] http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/
[2] http://www.trapx.com/news/press/trapx-discovers-zombie-zero-advanced-persistent-malware/

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

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

ISC StormCast for Monday, July 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4059, (Sun, Jul 13th)

Latest Alerts - Sun, 07/13/2014 - 15:15
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, July 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4059, (Sun, Jul 13th)

Latest Alerts - Sun, 07/13/2014 - 15:15
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Metasploit Update Alert, (Fri, Jul 11th)

Latest Alerts - Fri, 07/11/2014 - 07:27

Update your metasploit instances to take advantage of the new "Reverse HTTP Hop Stager" for meterpreter payloads.  Because any day you can pivot is a good day, and if you can pivot through native web services, that's an awesome day!  Hop adds the ability to use any basic PHP host as a hop point for meterpreter by adding a new reverse_hop_http payload.

Details here ==> https://community.rapid7.com/community/metasploit/blog/2014/07/10/weekly-metasploit-update
Video here ==> http://youtu.be/FktILE206z0

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

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

Egress Filtering? What - do we have a bird problem?, (Fri, Jul 11th)

Latest Alerts - Fri, 07/11/2014 - 06:48

One of the major tools that we have in our arsenal to control malware is outbound filtering at firewalls and other network "choke points".  
Over the years, it's become obvious that "enumerating badness" on the internet is next to impossible, it's generally much easier to enumerate "known good" traffic, and simply deny the rest as bad or at least suspect.  Often the management response is "we trust our people", but that's not really the point.  While maybe you can trust all of your people, you can't trust the malware they may have, or all the links they might click.  But let's be honest, it's likely that you can't trust all of your people to never install a bittorrent client or other higher-risk program.

So, as they say in the circus - "This Way to the Egress!"

An egress filter is generally put on your firewall, allowing known good traffic, and denying everything else outbound (and logging those attempts - hopefully you're monitoring your logs right?).  So, how do you go about setting up an egress filter?  You can't just list 10 protocols that you know are good and deny the rest - that's a good way to find out what OTHER protocols your business requires when you break those business processes - in other words, that's the hard way to do this.

We'll use the approach in the previous story to figure out what exactly we're running through the firewall, so we can then make go/no-go decisions about each one.

We can take a big chunk out of this by:
allowing DNS only from DNS Servers
Allow mail only from mail servers (permitted mail servers)
allow browser web traffic (either just from a proxy, or from all permitted workstations, depending on the organization)

So we can list the tcp protocols in play with:
D:\syslog\archive\2014-07-03>type SyslogCatchAll.txt | grep outbound | grep TCP | sed s/\t/" "/g | cut -d " " -f 12 | cut -d "/" -f 2 | grep -v 80 | grep -v 443  | grep -v 25 | sort | uniq -c | sort /R

This gives us the following output, listing the remaining protocols, in descending order.

    118 22
     81 1935
     80 8080
     79 993
     68 445
     66 843
     39 5228
     34 53
     28 5223
      4 52223
      3 135
      2 52165
      1 52222
      1 40009

Hmm - that gives us something to work with.  We can use the techniques covered in yesterday's story (https://isc.sans.edu/forums/diary/Finding+the+Clowns+on+the+Syslog+Carousel/18373) to dig deeper into these.

It turns out that the 135 and 445 traffic was drive maps through an inbound vpn session - no problem there.
The tcp/22 was sftp outbound - two business processes involving a transfer of financial information.  
For one, we allowed the outbound from the designated transfer host.  for the other, we allowed the outbound traffic to the designated destination.  Then denied 22 from others.
The "8080" protocol was an application (not a browser) using an outside proxy server.  This could as easily have been malware using a proxy, or someone using an "anonymizer" proxy or a "make it look like I'm in the US" proxy (we get some of that in Canada).

.. and so on.

Of course, you'll have to do the same for UDP also, and also the other protocols that aren't either tcp or udp.

So you'll have a list (in pseudo english / cisco speak) like:

ip access list extended ACL_INSIDE_OUTBOUND
permit dns from known dns servers, to the permitted dns forwarders only (we turned root hints off at the servers)
deny dns from anything else, and log the attempt
permit mail from the mail servers
deny mail from anything else, and log the attempt
permit http
permit https
permit tcp/22 from the one transfer client to anything
permit tcp/22 from anyone else to the second transfer server
deny tcp/22 from anything to anything else, and log the attempt
deny ip protocol 41 and log the attempt  (remember from yesterday that this is IPv6 Teredo tunneling)
 and so on
permit ip any any log

The last line is the critical one.  With that entry, you can then use the log mining techniques we've been discussing to mine the logs for just the entries that trigger that last line - the "permit ip any any log" line.  Eventually, you'll find that after whittling down the protocol list, you'll have a shorter and shorter list each day. At some point, you'll need to change that last line to a "deny any any log" at the bottom of the list.  Be sure that you've gone through a month end, and maybe even a year end before you add that last line. (the year end might be stretching it, unless your accounting year matches up with this project for you)

In answer to "we trust our people" - Those high port numbers in our initial list turned out to be bittorrent traffic - the giveaway was that it was from odd high ports to other odd high ports.  After digging through the logs a bit more, we identified the IP address that was running the protocol, and thought we'd be dealing with one of those uncomfortable "people problems".  Even better though - the source of this traffic turned out to be in the server IP range.  After some digging, it turned out to be a QNAP NAS that was used to store laptop images.  After cracking the manual, we found this box shared everything out via bittorrent via default.  At that point we were both saying - really?  This whole "collaboration / sharing" thing can go to far, and this was in fact too far!  Who's idea was it to make these NAS devices a "share all my data with the world" devices?

So maybe you can trust your people, but you can't trust them to read the manual !  And you can't trust them to always think about security before they plug new gear in.

Egress filters aren't 100% effective, but the are a critical part of your "defense in depth" strategy.  For instance, lots of malware (and bittorent clients and other apps too) will "hunt" until they find an open outbound port - so you'll often see them using ports like tcp/80, 443 or udp/53.  But with a proper egress filter, you'll quite often catch even this "port hunting" behaviour in the logs also.  If you are able to stand up a proxy server, often it's possible to deny almost all direct communication from the workstations, but really, that's just moving the same problem to the proxy server.

In newer architectures (those NGFW's we're all talking about), you'll find much more effective controls, but the concepts of filtering outbound traffic, and how to implement this, remain very much the same.  For instance, at home I've got a time-based ACL that allows my kid to play minecraft only in certain time windows (what can I say, it was fun to code that up). 

If you are doing egress filtering, what have you found in the process of putting them in?  What's the coolest thing you've caught after you've had it in place?   Let us know in our comment form.

If you're not doing egress filtering, why not?

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

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

Egress Filtering? What - do we have a bird problem?, (Fri, Jul 11th)

Latest Alerts - Fri, 07/11/2014 - 06:48

One of the major tools that we have in our arsenal to control malware is outbound filtering at firewalls and other network "choke points".  
Over the years, it's become obvious that "enumerating badness" on the internet is next to impossible, it's generally much easier to enumerate "known good" traffic, and simply deny the rest as bad or at least suspect.  Often the management response is "we trust our people", but that's not really the point.  While maybe you can trust all of your people, you can't trust the malware they may have, or all the links they might click.  But let's be honest, it's likely that you can't trust all of your people to never install a bittorrent client or other higher-risk program.

So, as they say in the circus - "This Way to the Egress!"

An egress filter is generally put on your firewall, allowing known good traffic, and denying everything else outbound (and logging those attempts - hopefully you're monitoring your logs right?).  So, how do you go about setting up an egress filter?  You can't just list 10 protocols that you know are good and deny the rest - that's a good way to find out what OTHER protocols your business requires when you break those business processes - in other words, that's the hard way to do this.

We'll use the approach in the previous story to figure out what exactly we're running through the firewall, so we can then make go/no-go decisions about each one.

We can take a big chunk out of this by:
allowing DNS only from DNS Servers
Allow mail only from mail servers (permitted mail servers)
allow browser web traffic (either just from a proxy, or from all permitted workstations, depending on the organization)

So we can list the tcp protocols in play with:
D:\syslog\archive\2014-07-03>type SyslogCatchAll.txt | grep outbound | grep TCP | sed s/\t/" "/g | cut -d " " -f 12 | cut -d "/" -f 2 | grep -v 80 | grep -v 443  | grep -v 25 | sort | uniq -c | sort /R

This gives us the following output, listing the remaining protocols, in descending order.

    118 22
     81 1935
     80 8080
     79 993
     68 445
     66 843
     39 5228
     34 53
     28 5223
      4 52223
      3 135
      2 52165
      1 52222
      1 40009

Hmm - that gives us something to work with.  We can use the techniques covered in yesterday's story (https://isc.sans.edu/forums/diary/Finding+the+Clowns+on+the+Syslog+Carousel/18373) to dig deeper into these.

It turns out that the 135 and 445 traffic was drive maps through an inbound vpn session - no problem there.
The tcp/22 was sftp outbound - two business processes involving a transfer of financial information.  
For one, we allowed the outbound from the designated transfer host.  for the other, we allowed the outbound traffic to the designated destination.  Then denied 22 from others.
The "8080" protocol was an application (not a browser) using an outside proxy server.  This could as easily have been malware using a proxy, or someone using an "anonymizer" proxy or a "make it look like I'm in the US" proxy (we get some of that in Canada).

.. and so on.

Of course, you'll have to do the same for UDP also, and also the other protocols that aren't either tcp or udp.

So you'll have a list (in pseudo english / cisco speak) like:

ip access list extended ACL_INSIDE_OUTBOUND
permit dns from known dns servers, to the permitted dns forwarders only (we turned root hints off at the servers)
deny dns from anything else, and log the attempt
permit mail from the mail servers
deny mail from anything else, and log the attempt
permit http
permit https
permit tcp/22 from the one transfer client to anything
permit tcp/22 from anyone else to the second transfer server
deny tcp/22 from anything to anything else, and log the attempt
deny ip protocol 41 and log the attempt  (remember from yesterday that this is IPv6 Teredo tunneling)
 and so on
permit ip any any log

The last line is the critical one.  With that entry, you can then use the log mining techniques we've been discussing to mine the logs for just the entries that trigger that last line - the "permit ip any any log" line.  Eventually, you'll find that after whittling down the protocol list, you'll have a shorter and shorter list each day. At some point, you'll need to change that last line to a "deny any any log" at the bottom of the list.  Be sure that you've gone through a month end, and maybe even a year end before you add that last line. (the year end might be stretching it, unless your accounting year matches up with this project for you)

In answer to "we trust our people" - Those high port numbers in our initial list turned out to be bittorrent traffic - the giveaway was that it was from odd high ports to other odd high ports.  After digging through the logs a bit more, we identified the IP address that was running the protocol, and thought we'd be dealing with one of those uncomfortable "people problems".  Even better though - the source of this traffic turned out to be in the server IP range.  After some digging, it turned out to be a QNAP NAS that was used to store laptop images.  After cracking the manual, we found this box shared everything out via bittorrent via default.  At that point we were both saying - really?  This whole "collaboration / sharing" thing can go to far, and this was in fact too far!  Who's idea was it to make these NAS devices a "share all my data with the world" devices?

So maybe you can trust your people, but you can't trust them to read the manual !  And you can't trust them to always think about security before they plug new gear in.

Egress filters aren't 100% effective, but the are a critical part of your "defense in depth" strategy.  For instance, lots of malware (and bittorent clients and other apps too) will "hunt" until they find an open outbound port - so you'll often see them using ports like tcp/80, 443 or udp/53.  But with a proper egress filter, you'll quite often catch even this "port hunting" behaviour in the logs also.  If you are able to stand up a proxy server, often it's possible to deny almost all direct communication from the workstations, but really, that's just moving the same problem to the proxy server.

In newer architectures (those NGFW's we're all talking about), you'll find much more effective controls, but the concepts of filtering outbound traffic, and how to implement this, remain very much the same.  For instance, at home I've got a time-based ACL that allows my kid to play minecraft only in certain time windows (what can I say, it was fun to code that up). 

If you are doing egress filtering, what have you found in the process of putting them in?  What's the coolest thing you've caught after you've had it in place?   Let us know in our comment form.

If you're not doing egress filtering, why not?

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

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

Apple pushes OS X update to block out of date Flash versions - http://support.apple.com/kb/HT5655, (Fri, Jul 11th)

Latest Alerts - Fri, 07/11/2014 - 06:09

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

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

Apple pushes OS X update to block out of date Flash versions - http://support.apple.com/kb/HT5655, (Fri, Jul 11th)

Latest Alerts - Fri, 07/11/2014 - 06:09

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

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

ISC StormCast for Friday, July 11th 2014 http://isc.sans.edu/podcastdetail.html?id=4057, (Thu, Jul 10th)

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

Certificate Errors in Office 365 Today, (Thu, Jul 10th)

Latest Alerts - Thu, 07/10/2014 - 12:04

It looks like there's a mis-assignment of certificates today at Office 365.  After login, the redirect to portal.office.com reports the following error:

portal.office.com uses an invalid security certificate.

The certificate is only valid for the following names: *.bing.com, *.platform.bing.com, bing.com, ieonline.microsoft.com, *.windowssearch.com, cn.ieonline.microsoft.com, *.origin.bing.com, *.mm.bing.net, *.api.bing.com, ecn.dev.virtualearth.net, *.cn.bing.net, *.cn.bing.com, *.ssl.bing.com, *.appex.bing.com, *.platform.cn.bing.com

 

Hopefully they'll have this resolved quickly.  Thanks to our reader John for the heads-up on this!

======================================================
UPDATE (4pm EST)

Looks like this has been resolved - note from Microsoft:

Closure Summary: On Thursday, July 10, 2014, at approximately 3:57 AM UTC, engineers identified an issue in which some customers may have encountered intermittent certificate errors when navigating to the Office 365 Customer Portal. Investigation determined that a recent update to the environment caused impact to a limited portion of capacity which is responsible for handling site certificate authorization. Engineers reconfigured settings to correct the underlying issue which mitigated impact. The issue was successfully fixed on Thursday, July 10, 2014, at 5:54 PM UTC.

Great job guys - thanks much !

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

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

Finding the Clowns on the Syslog Carousel, (Thu, Jul 10th)

Latest Alerts - Thu, 07/10/2014 - 08:39

So often I see clients faithfully logging everything from the firewalls, routers and switches - taking terabytes of disk space to store it all.  Sadly, the interaction after the logs are created is often simply to make sure that the partition doesn't fill up - either old logs are just deleted, or each month logs are burned to DVD and filed away.

The comment I often get is that logs entries are complex, and that the sheer volume of information makes it impossible to make sense of it.  With 10's, hundreds or thousands of events per minute, the log entries whiz by at a dizzying speed.  Just deciding to review logs can be a real time-eater, unless you use methods to distil how you find the "clowns" on the carousel so you can deal with them appropriately.


(not to scale)

The industry answer to this is to install a product.  You can buy one of course, or use free tools like  Bro, ELSA, Splunk (up to a certain daily log volume) which can all do a good job at this.  Netflow solutions will also do a great job of categorizing traffic up pictorially.

But what if you don't have any of that?  Or what if you've got a few hundred gigs of text logs, and need to solve a problem or do Incident Handling RIGHT NOW?

Let's look at a few examples of things you might look for, and how you'd go about it.  I'll use Cisco log entries as an example, but aside from field positions, you can apply this to any log entry at all, including Microsoft events that have been redirected to syslog with a tool such as snare.

First, let's figure out who is using DNS but is NOT a DNS server?
type syslogcatchall.txt | grep "/53 " | grep -v a.a.a.b | grep -v a.a.a.c

Where a.a.a.b and a.a.a.c are the "legit" internal DNS servers. We're using "/53 ", with that explicit trailing space, to make sure that we're catching DNS queries, but not traffic on port 531, 532, 5311, 53001 and so on.

That leaves us with a bit of a mess - wa-a-ay too many records and the text is just plain too tangled to deal with.  Let's just pull out the source IP address in each line, then sort the list and count the log entries per source address - note that we're using a Windows Server host, with the Microsoft "Services for Unix" installed.  For all the *nix purists, I realize this could be done simpler in AWK, but that would be more difficult to illustrate.  If anyone is keen on that, by all means post the equivalent / better AWK syntax in our comment form - or perl / python or whatever your method is  - the end goal is always the same, but the different methods of getting there can be really interesting!

Anyway, my filtering command was:

D:\syslog\archive\2014-07-03>type SyslogCatchAll.txt | grep -v a.a.a.b | grep -v a.a.a.c | grep "/53 " | sed s/\t/" "/g | cut -d " " -f 13 | grep inside | sed s/:/" "/g | sed s/\//" "/g | cut -d " " -f 2 | sort | uniq -c | sort /R

This might look a little complicated, but let's break it up.

grep -v a.a.a.b | grep -v a.a.a.c remove all the records from the two "legit" DNS Servers grep "/53 " We're looking for DNS queries, which includes traffic with destination ports of TCP or UDP port 53.  Note again the trailing space. sed s/\t/" "/g convert all of the tab characters in the cisco syslog event line to a space.  This mixing of tabs and spaces is typical in syslogs, and can be a real challenge in splitting up a record for searches. cut -d " " -f 13  using the space character as a delimeter, we just want field 13, which will look like  "interface name/source ip address:53" sed s/:/" "/g | sed s/\//" "/g  change those pesky ":" and "/" characters to spaces cut -d " " -f 2 pull out just the source address sort | uniq -c finally, sort the resulting ip addresses, and count each occurence sort /R sort this final list by count in descending order.  Note that this is the WINDOWS sort command.  In Linux, you would use "sort -rn"

 

The final result is this, the list of hosts that are sending DNS traffic, but are not DNS servers. So either they're misconfigured, or they are malicious traffic using UDP/53 or TCP/53 to hide from detection

  525 10.x.z..201
   182 10.x.y.236
   115 10.x.z.200
    40 10.x.y.2
    34 10.x.y.38
    20 10.x.y.7
    20 10.x.y.118
     2 10.x.x.138
     2 10.x.x.137
     2 10.x.x.136
     2 10.x.x.135
     2 10.x.x.133
     2 10.x.x.132
     2 10.x.x.131

So what did these turn out to be?    The first few are older DNS servers that were supposed to be migrated, but were forgotten - this was a valuable find for my client.  The rest of the list is mostly misconfigured in many cases they were embedded devices (cameras, timeclocks and TVs)  that were installed by 3rd parties, with Google's DNS hard coded.  A couple of these stations had some nifty malware, running botnet C&C over UDP port 53 to masquerade as DNS.  All of these finds were good things for my client to find and deal with!

What else might you use this for?  Search for tcp/25 to find hosts that are sending mail directly out that shouldn't (we found some of the milling machinery on the factory floor that was also happily sending SPAM), or tcp/110  for users who are using self-installed email clients

If you are using a proxy server for internet control, it's useful to find workstations that have incorrect proxy settings - in other words, find all the browser traffic (80, 443, 8080, 8081, etc) that is NOT using proxy.

SSH, Telnet, tftp, ftp, sftp and ftps are other protocols that you might be interested in, as they are common protocols to send data in or out of your organization.

VPN and other tunnel traffic is another traffic type that you should be looking at for analysis.  Various common VPN protocols include:
IPSEC is generally some combination of:
ESP - IP Protocol 50.  For this you would look for "ESP" in your logs - it's not TCP or UDP traffic at all.
ISA udp/500
IPSEC can be encapsulated in UDP, commonly in udp/500 and/or udp/4500, though really you can encapsulate using any port, as long as the other end matches.  You can also encapsulate in tcp, many VPN gateways default to tcp/10000., but that's just a default, it could be anything.

GRE (Cisco's Generic Routing Encapsulation) - IP Protocol 47
Microsoft PPTP - TCP/1723 plus IP protocol 47

What else might you look for?  How about protocols that encapsulate IPv6?Teredo / 6to4 is the tunneling protocl that Microsoft uses by default - IP protocol 41 (see  https://isc.sans.edu/diary/IPv6+Focus+Month%3A+IPv6+Encapsulation+-+Protocol+41/15370 )

If you've got a list of protocols of interest, you can easily drop all of these in a single script and run them at midnight each day, against yesterday's logs.

Using just CLI tools, what clowns have you found in your logs?  And what commands did you use to extract the information?

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

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