Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 57 min 27 sec ago

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

Microsoft Security Bulletin Advance Notification for July 2014, (Fri, Jul 4th)

Fri, 07/04/2014 - 06:36

Microsoft have published the 'heads-up' for this months patching party, with six bulletins two of which are flagged as being critical in nature.

 

For more details, go their notification, but for a quick look, I've reproduced their table below:

Bulletin ID

Maximum Severity Rating and Vulnerability Impact

Restart Requirement

Affected Software

Bulletin 1

Critical 
Remote Code Execution

Requires restart

Microsoft Windows, 
Internet Explorer

Bulletin 2

Critical 
Remote Code Execution

May require restart

Microsoft Windows

Bulletin 3

Important 
Elevation of Privilege

Requires restart

Microsoft Windows

Bulletin 4

Important 
Elevation of Privilege

Requires restart

Microsoft Windows

Bulletin 5

Important 
Elevation of Privilege

May require restart

Microsoft Windows

Bulletin 6

Moderate 
Denial of Service

Does not require restart

Microsoft Server Software

 

 

Steve Hall ISC Handler www.tarkie.net

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

Credit Card Processing in 700 Words or Less, (Thu, Jul 3rd)

Thu, 07/03/2014 - 11:06

When PF Changs published an update about it's breach earlier this week, a few readers asked about the use of "encrypted terminals". Aren't all credit card transactions "encrypted"? The quick answer is: yes. But not all transactions are encrypted all the time.

To answer some of these questions, I figured I will use this diary as a TL;DR edition to credit card processing. There are a number of terms that are often confused when it comes to credit cards, and how they are processed.

If you enter a credit card on a web site, the process is typically pretty straight forward if implemented correctly: The credit card reaches the web server via SSL. The web server then typically hands the card to a payment processor (again: via SSL) and receives a confirmation code back that can later be used to identify the transaction. The confirmation code is often shared with the customer and doesn't require an specific safeguarding. It may be used to void the transaction. But this would also require the merchants credentials in addition to the code, so the customer can't void it without the merchant's approval.

The merchant does not need to store the credit card number. As should not store it at all. However, the credit card number is still exposed in memory while it is being processed and careless coding often leads to data like credit card numbers being logged. So while the card can't be read off the wire, it can still be read off the server if the server is compromised.

Now what about repeat billing? Does your phone company need to store the number so it can charge your credit card once a month? No. In addition to a confirmation number, the credit card processor can hand a token back to the merchant. The merchant can now use this token to apply additional charges to the card. This token is only good for a particular merchant. If it is stolen, an attacker could charge the account, but any funds would go to the merchant the token was stolen from, not to the attacker. More interesting: The token is linked to your account, not your credit card number. If you receive a new credit card number (e.g. after your card was compromised), the merchant is still able to charge the account. This is very convenient for recurring payments like utility bills.

Where things get actually more interesting these days is retail scenarios. Many people still think that handing your card to a clerk is more secure then typing it into a website. However, what happens is essentially the same thing as when you type it into a website, with the exception that the clerk swipes the card at a PoS system, that may be compromised (just like your PC may be compromised when you type in the number). 

The best defense against a compromised PoS system is to encrypt the number in the reader, before it hits the PoS system. Some readers support this feature, and it requires that the reader be used with a specific processor who holds the decryption key. You (as owner of the PoS system) have no idea what card was used, neither has the pw0n3r of the PoS system. A popular implementation of this technique is the Square reader that can be plugged into the audio jack of a cell phone to turn it into a credit card reader. Since the phone is considered un-trusted, the CC data is encrypted inside the reader and then passed encrypted to Square. 

Why doesn't everybody do that? Two reasons: Some merchants like to "see" the CC track data to identify the customer and use it for purchase tracking. Secondly, this option is a bit more recent and older systems don't support it.

Where does "Chip-and-Pin" fit in? Chip and Pin does not encrypt any data. It just authenticates the terminal. In this case, if the card is stolen, an attacker can not produce a fake card that could be used at a chip and pin terminal, and skimmers will have a harder time reading the information. But a card number stolen from a compromised Chip-and-Pin PoS system can still be used online or to create a non Chip-and-Pin card.

I hope this clears up some of the questions regarding recent breaches.

---
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 Thursday, July 3rd 2014 http://isc.sans.edu/podcastdetail.html?id=4049, (Thu, Jul 3rd)

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

Simple Javascript Extortion Scheme Advertised via Bing, (Wed, Jul 2nd)

Wed, 07/02/2014 - 12:49

Thanks to our reader Dan for spotting this one.

As of today, a search for "Katie Matusik" on Bing will include the following result. The rank has been slowly rising during the day, and as of right now, it is the first link after the link to "Videos" 

Once a user clicks on the link, the user is redirected to http://system-check-yueedfms.in/js which loads a page claiming that the user's browser is locked, and the user is asked to pay a fine via "Moneypak", a Western-Union like payment system. Overall, the page is done pretty bad and I find it actually a bit difficult to figure out how much money they are asking to ($300??).


(click on image for full size)

The user is no not able to close the browser or change to a different site. However, just rebooting the system will clear things up again, or you have to be persistent enough in clicking "Leave this Page" as there are a large number of iframes that each insert a message if closed.

The link was reported to Bing this morning but the result has been rising in Bing's search since then. Respective hosting providers for the likely compromised WordPress blog have been notified. 

Quick update: For "katie matysik" (replace 'u' with 'y', the correct spelling of the ), Bing now returns the malicious site as #1 link. Both spellings are valid last names, so either may be the original target of the SEO operation.

---
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

Cisco Unified Communications Domain Manager Update, (Wed, Jul 2nd)

Wed, 07/02/2014 - 09:06

Yet another round of patches, this time for Cisco's Unified Communications Domain Manager [1].

The vulnerability that is probably going to be exploited first is the backdoor Cisco left behind for support access. In order to provide Cisco support with access to customer equipment, the company felt it was a great idea to equip all instances with the same SSH key. 

Having the same key on all systems is mistake number one, but wouldn't be fatal if the secret key would have been tugged away in Cisco's special safedeposit box. Instead, they left the secret key on customer systems as well. So in other words: If you own one of the systems, you got the key to access all of them.

Filtering SSH access to the device at your border is a good first step to protect yourself if you can't patch right away.

[1] http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140702-cucdm

---
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