Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 4 min 7 sec ago

Metasploit Update Alert, (Fri, Jul 11th)

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)

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)

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)

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)

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)

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)

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)

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

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

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

Adobe Flash Player patches: http://helpx.adobe.com/security/products/flash-player/apsb14-17.html, (Wed, Jul 9th)

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

Who inherits your IP address?, (Wed, Jul 9th)

Wed, 07/09/2014 - 01:33

Somewhat similar to the typo squatting story earlier, the recent proliferation of cloud service usage by enterprises has led to a new problem. For a project at a community college, we needed a couple servers, and didn't want (or have the funds) to build them on-site. In view of the limited duration of the experiment, we decided to "rent" the boxes as IaaS (infrastructure as a service) devices from two "cloud" providers. So far, all went well. But when we brought the instances live, we discovered to our surprise that three (out of 24) public IP addresses that we were assigned still had "afterglow", meaning they were receiving productive traffic that was intended for the former owner/holder of these IPs. Two of the IPs received DNS queries, one was receiving email. Researching through the passive DNS logs, I confirmed that yes, the three IP addresses had indeed been used accordingly. One of the DNSes had been active only for a week, obviously for nefarious purposes, because it had lots of random .ua and .pw domain names delegated to it. The other seems to have been the DNS+EMail of a midsize company that had been hosted with that IaaS provider for two years, and had been migrated elsewhere earlier that same week.

To make a long story short, for all services where the Internet has an extended memory and caching, make sure you hold on for a couple of weeks or months to the corresponding IP or domain name after you no longer need and use them, and let them "cool off". Otherwise, if the IP address is immediately reassigned, or the domain name immediately repurchased, someone else *will* end up with some of your web traffic, DNS requests, or even email.

 

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

Who owns your typo?, (Wed, Jul 9th)

Tue, 07/08/2014 - 17:18

Here's one way how to get at sensitive data that seems to be making a comeback. Already in the olden days, it was popular with the crooks to register domain names that only differed by a typo from the name of a legitimate high traffic site. Googl.com, for example. The crooks would then run web pages with lots of advertisements on these domains, and live happily ever after from the ad revenue that the misdirected typo traffic alone brought their way.

Google put a stop to this by registering, for themselves, pretty much all typos of their brand that you can imagine.  Not all companies have done so, and with the increased use of smart phones with annoyingly fumbly keyboards (and often autocorrect, as well), typos are making a comeback. As do the typo harvesting sites. This time though, it looks as if they are not after ad clicks -- instead, we see an increase of typo domains that publish an MX record, and thus receive all the mail that was meant for the attacked company, but where the @domain portion of the address contained a typo.

I was recently participating in the analysis of data taken from such a server that the crooks had used to collect other people's mail. One thing that particularly stood out was that a lot of the harvested emails actually came from within the attacked real estate company, and contained rather sensitive internal mails.  In other words, say, an employee @samplecompany.com had wanted to send something to a coworker, but typed coworker@smaplecompany.com instead on her (not-so)smartphone. As a result, instead of getting delivered internally, the email took the Internet route, and ended up on the server that the crooks had set up.

For every email address with a typo that came from a customer or other external sender, we found a dozen or so of mails that were intended to be from and to an internal employee. What made matters worse is that some of the mobile phones that the company employees used were helpfully "remembering" previously typed email addresses, so once a typo had been made, the fix was in, and the problem persisted until/unless the user noticed that his colleague never answered.

If you don't own the most likely permutations and typos of your main email domain for yourself, you might want to check who does. And if they publish an MX record for these domains, you might want to check your outbound email log to see how much of your intended internal email has typos, and is leaking out.

Update: ISC reader Jerry points out that according to RFC 5321, if no MX record is returned, the A record will be tried instead. So don't count only on the presence of MX records in typo squatting domains to determine if your email is being siphoned off, if in doubt, check their port 25 as well.

 

 

(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 9th 2014 http://isc.sans.edu/podcastdetail.html?id=4053, (Tue, Jul 8th)

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

Microsoft Patch Tuesday - July, (Tue, Jul 8th)

Tue, 07/08/2014 - 10:06

Overview of the July 2014 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS14-037 Cumulative Security Update for Internet Explorer Microsoft Windows, Internet Explorer

CVE-2014-1763 CVE-2014-1765 CVE-2014-2785 CVE-2014-2786 CVE-2014-2787 CVE-2014-2788 CVE-2014-2789 CVE-2014-2790 CVE-2014-2791 CVE-2014-2792 CVE-2014-2794 CVE-2014-2795 CVE-2014-2797 CVE-2014-2798 CVE-2014-2800 CVE-2014-2801 CVE-2014-2802 CVE-2014-2803 CVE-2014-2804 CVE-2014-2806 CVE-2014-2807 CVE-2014-2809 CVE-2014-2813 CVE-2014-1763 CVE-2014-1765 CVE-2014-2783 CVE-2014-2785 CVE-2014-2786 CVE-2014-2787 CVE-2014-2788 CVE-2014-2789 CVE-2014-2790 CVE-2014-2791 CVE-2014-2792 CVE-2014-2794 CVE-2014-2795 CVE-2014-2797 CVE-2014-2798 CVE-2014-2800 CVE-2014-2801 CVE-2014-2802 CVE-2014-2803 CVE-2014-2804 CVE-2014-2806 CVE-2014-2807 CVE-2014-2809 CVE-2014-2813 KB 2975687 Yes! Severity:Critical
Exploitability: 1 Critical Important MS14-038 Vulnerability in Windows Journal Could Allow Remote Code Execution Microsoft Windows

CVE-2014-1824 KB 2975689 No Severity:Critical
Exploitability: 1 Critical Critical MS14-039 Vulnerability in On-Screen Keyboard Could Allow Elevation of Privilege Microsoft Windows

CVE-2014-2781 KB 2975685 No Severity:Important
Exploitability: 1 Important Important MS14-040 Vulnerability in Ancillary Function Driver Microsoft Windows

CVE-2014-1767 KB 2975684 No Severity:Important
Exploitability: 1 Important Important MS14-041 Vulnerability in DirectShow Could Allow Elevation of Privilege Microsoft Windows

CVE-2014-2780 KB 2975681 No Severity:Important
Exploitability: 1 Important Important MS14-042 Vulnerability in Microsoft Service Bus Could Allow Denial of Service Microsoft Server Software

CVE-2014-2814 KB 2972621 Yes! Severity:Moderate
Exploitability: 1 Less Urgent Less Urgent We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY (*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
    • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.

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

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

Hardcoded Netgear Prosafe Switch Password , (Tue, Jul 8th)

Tue, 07/08/2014 - 07:23

Update: Cert.org corrected it's advisory. The GS105PE is affected, not the GS108PE as indicated earlier. The NVD CVE entry still lists the old model number [2]. 

Yet another hard coded password. This time it's Netgear's Prosafe Switch (GS105PE) running firmware version 1.2.0.5 and earlier [1]. The pre-configured username is "ntgruser" and the password is "debugpassword". If you have any Netgear equipment, it may be worthwhile checking for this username and password even if your device isn't listed as vulnerable.

Sadly, at this point there doesn't appear to be a solution to the problem, other then returning the switch to the store and buying another one if you can.

CVE Number: CVE-2014-2969 [2]

 

[1] http://www.kb.cert.org/vuls/id/143740
[2] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2969

---
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 Tuesday, July 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4051, (Mon, Jul 7th)

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

Multi Platform *Coin Miner Attacking Routers on Port 32764, (Mon, Jul 7th)

Mon, 07/07/2014 - 13:43

Thanks to reader Gary for sending us in a sample of a *Coin miner that he found attacking Port 32764. Port 32764 was recently found to offer yet another backdoor on Sercomm equipped devices. We covered this backdoor before [1]

The bot itself appears to be a variant of the "zollard" worm sean before by Symantec [2]. Symantec's writeup describes the worm as attacking a php-cgi vulnerability, not the Sercomm backdoor. But this worm has been seen using various exploits.

Here some quick, very preliminary, details:

The reason I call it *Coin vs. Bitcoin is that in the past, we found these miners to mostly attack non-Bitcoin crypto-currencies to make use of the limited capabilities of these devices. I do not have sufficient detail yet about this variant.

Interestingly, Gary found what looks like 5 binaries with identical functionality, but compiled for 4 different architecture providing for larger coverage across possible vulnerable devices. The binaries are named according to the architecture they support.

Name Size "file" output arm 86680 ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped armeabi 131812 ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped mips 140352 ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped mipsel 141288 ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped x86 74332 ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

The binary appears to do the following among other things:

  • delete and then recreate the /tmp directory (to have an empty one for download)
  • create a directory /var/run/.zollard
  • firewall port 23 (telnet) and 32764 (trying to avoid re-exploitation. Port 23 is odd ...)
  • start the telnet demon (odd that it also firewalls port 23)
  • it uses this user agent for some outbound requests: Mozilla/5.0 (compatible; Zollard; Linux)
  • setup a php file with a backdoor (simple php "exec") 

It also looks like there are many other variants for different architectures based on string in the file Gary sent us.

[1] https://isc.sans.edu/diary/Port+32764+Router+Backdoor+is+Back+(or+was+it+ever+gone%3F)/18009
[2] http://www.symantec.com/connect/blogs/linux-worm-targeting-hidden-devices

---

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

Physical Access, Point of Sale, Vegas, (Sun, Jul 6th)

Sun, 07/06/2014 - 08:37

Physical Access [1], as most of us know, is the final point of control. While in Las Vegas (on a well earned vacation) my wife and wandered all over. It only took around a day of being completely unplugged before my mind wandered back to 'security' land. While scoping out places to eat my partner drug us into a 'pricey' looking place (will attempt to remain nameless to protect the 'really' not so smart, however I am not a photo editor so if something slipped, I tried).

When we get into this place, at first in tourist-mode, had a lot of things designed to take my money. After spending a little bit more time in the place, I was most curious about the point of sale suite. Then I noticed, where it was placed, convenient on the floor, but the attendant not that close, distracted from the clients. It get’s worse, when I spending more time by the counter the attendant did even notice (as expected sadly) [2].

 

At this point I suspected that I could easily drop a USB key or a leave behind device and decided to take a quick picture of all the ports accessible.


If you look at the photo closely:

 

  1. I was not challenged by anyone
  2. I had plenty of time to snap a shot
  3. Easy access to a USB port
  4. Well known Point of Sale System
  5. Premium Las Vegas location
  6. Printed and taped details near device

 

Conclusion? I paid cash (Not that it helps much, but sure did make me feel better)! Physical security and awareness of your staff regarding it cannot be missed. Reduce your attack surface anyone?

Are you picky about PoS locations now? What things have changed in your shopping habits?

 

References:

[1] http://www.sans.edu/research/security-laboratory/article/281

[2] http://www.police.psu.edu/physical-security/what-is-physical-security.cfm

 

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

Malware Analysis with pedump, (Sat, Jul 5th)

Sat, 07/05/2014 - 08:20

Are you looking for a tool to analyze Windows Portable Executable (PE) files? Consider using pedump a ruby win32 PE binary file analyzer. It currently support DOS MZ EXE, win16 NE and win32/64 PE.

There are several ways to install the ruby package; however, the simplest way is to execute "gem install pedump" from a Linux workstation. You can also download the file here or use the pedump website to upload your file for analysis. This example shows the output from the pedump website.

You can obtain the same results as this output with the command line version by executing "pedump --all  SetupCasinoRoyal.exe".

The command line version doesn't currently have foremost, hexdump or the disassembler function. However, you can get the same hexdump output by executing "hexdump -C SetupCasinoRoyal.exe" from your Unix system.

guy@seeker:~/malware/casino$ hexdump -C SetupCasinoRoyal.exe |more
00000000  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 10 01 00 00  |................|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |.............!Th|
00000050  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000060  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
00000070  6d 6f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |mode....$.......|

This tool provides an easy way to dump headers, find packers and resources used by exe and dll, in the end providing a quick look inside suspicious PE file.

[1] http://pedump.me/
[2] http://pedump.me/89c10738fb44f9a529092bfa3c15dcf9/#resources    
[3] https://github.com/zed-0xff/pedump
[4] https://rubygems.org/gems/pedump
[5] https://github.com/zed-0xff/pedump/archive/master.zip
[6] http://en.wikipedia.org/wiki/Portable_Executable

-----------

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

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

Java Support ends for Windows XP, (Sat, Jul 5th)

Fri, 07/04/2014 - 16:56

Oracle is no longer supporting Java for Windows XP and will only support Windows Vista or later. Java 8 is not supported for Windows XP and users will be unable to install on their systems. Oracle warns "Users may still continue to use Java 7 updates on Windows XP at their own risk" [1]

[1] https://www.java.com/en/download/faq/winxp.xml
[2] http://www.oracle.com/us/support/library/057419.pdf

-----------

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

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