http://isc.sans.edu en-us Sun, 29 Jan 2012 15:46:03 +0000 Fri, 27 Jan 2012 10:08:01 GMT (C) SANS Institute 2012 isc rss feed maker 30 handlers@sans.org (ISC Handlers) http://isc.sans.org/images/status.gif http://isc.sans.org http://isc.sans.edu/diary.html?storyid=12475&rss http://isc.sans.edu/diary.html?storyid=12475&rss If you are noticing the same in your logs and you can share some log lines please send some in as I'd be interested in taking a peek.
Mark H
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Fri, 27 Jan 2012 10:08:01 GMT http://isc.sans.edu/diary.html?storyid=12472&rss http://isc.sans.edu/diary.html?storyid=12472&rss To mitigate the risk (if you can't upgrade just yet) is to switch off telnet on the device and use SSHto manage it instead.
Mark H (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Fri, 27 Jan 2012 09:52:03 GMT http://isc.sans.edu/podcastdetail.html?id=2287 http://isc.sans.edu/podcastdetail.html?id=2287 Fri, 27 Jan 2012 04:15:17 GMT http://isc.sans.edu/diary.html?storyid=12460&rss http://isc.sans.edu/diary.html?storyid=12460&rss
Need to attribute information to ISC? Want to provide users with an avenue to visit the ISC site? Want to link directly to the ISC Stormcast, Infocon or other information? These methods and more are listed on out ISC Linkback Page! https://isc.sans.edu/linkback.html



Features

Various text only links and terms: ISC, Stormcast, Log Submission http://isc.sans.edu/linkback.html#text


Show an ISC image logo for your link back to ISC: Homepage, Stormcast http://isc.sans.edu/linkback.html#image


ISC Inforcon status image http://isc.sans.edu/linkback.html#other

Note

This works as DShield also. Just view the dshield.org url http://dshield.org/linkback.html


Don't see a link you'd like to use? Suggest in the comments section below or send any questions or comments in the contact form https://isc.sans.edu/contact.html



--

Adam Swanger, Web Developer (GWEB)

Internet Storm Center (http://isc.sans.edu) (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Fri, 27 Jan 2012 03:32:10 GMT http://isc.sans.edu/diary.html?storyid=12463&rss http://isc.sans.edu/diary.html?storyid=12463&rss Now, for last couple of weeks there have been a lot of rumors about source code of several Symantecs products that got stolen by yet unknown hackers. Besides a post that listed file names nothing else has been released in public yet, as far as we know.
However, Symantec also released a document (available here) that details security recommendations for pcAnywhere users. It is obvious that Symantec is aware of how critical published vulnerabilities are. It makes us wonder if there already have been active exploitation of the published vulnerabilities or Symantec is just extra careful?
Well keep an eye on this, and if you are a pcAnywhere user PATCH NOW.
Update
And a short update: according to DShield data it appears that someone started scanning around for services on port 5631 (pcAnywhere). While the number of sources is still relatively low (indicating a single scanner, or a small number of them), the number of targets is pretty high. See for yourself here.
Update 2


Just further to the information Bojan has already provided. Keep in mind that pcAnywhere is part of a number of Symantec products including backup, security and of course it is part of the Altiris management suite. - MH

--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Thu, 26 Jan 2012 04:51:20 GMT http://isc.sans.edu/podcastdetail.html?id=2284 http://isc.sans.edu/podcastdetail.html?id=2284 Thu, 26 Jan 2012 03:12:18 GMT http://isc.sans.edu/podcastdetail.html?id=2281 http://isc.sans.edu/podcastdetail.html?id=2281 Wed, 25 Jan 2012 03:21:08 GMT http://isc.sans.edu/diary.html?storyid=12454&rss http://isc.sans.edu/diary.html?storyid=12454&rss While I was almost certain that the old NetBIOS spoofing attacks do not work any more, I was stunned to see that even the latest and greatest Windows 7 still enable NetBIOS over TCP/IP by default.
In todays interconnected world, where we jump from one (wireless) network to another, this might have serious impacts on our security. The question is it time to get rid of NetBIOS sounds logical. Lets see whats happening here.

Starting with Windows 2000, all Windows operating systems (XP, 2003, Vista, 7, 2008) depend mainly on DNS to resolve network names. However, if DNS is not working, or the name cannot be resolved, Windows will try to use NetBIOS to resolve such network name.
Now, if a WINS server has been configured this should not be a problem, but in case when a WINS server is not present (or available), Windows will still try to use NetBIOS to resolve a network name. In such cases, Windows will send a NetBIOS Name Query packet, which is an UDP packet sent to a broadcast address. You can see one such packet in the screenshot below:

You can probably guess what an attacker can do since this is a broadcast packet, the attacker does not even need to perform other initial attacks such as ARP poisoning. He can simply send a NetBIOS Name Query Response with any contents he wants! As a matter of fact, even a Metasploit module exists that does this automatically (see auxiliary/spoof/nbns/nbns_response).
Now, the question that we have to think about is what attack scenarios are we dealing with here? Here come a few, judge for yourself how serious they are:

Whenever a user mistypes a network name, the attacker can spoof the response. Depending on what the user tries to access (i.e. a SMB share or a web page), the attacker can use another Metasploit module in order to catch exchanged credentials. Keep in mind, though, that only hashes are exchanged here so the attacker still needs to crack the original users password (or try to perform some relaying attacks).


One of the names that is particularly sensitive is WPAD. It is used by web browsers for automatic retrieval of proxy settings. In a scenario where we connect to an open wireless network, where the local DNS server does not have this name registered, an attacker can spoof the WPADs entrys IP address and further even serve a fake wpad.dat file. This would allow him to inspect the victims web traffic!


A lot of companies like to set their users home page in browsers (i.e. Internet Explorers home page). Now, when the user opens Internet Explorer on a malicious network, Internet Explorer will try to resolve that name. Since that name is usually something like intranet or intranetweb DNS will , of course, fail to resolve it. This gives the attacker an opportunity to fake this name. And whats even worse, Internet Explorer will automatically send users credentials to the resolved web page, since it will consider it to be in the Local Intranet zone. The picture below shows my fully patched Windows 7 machine falling prey for this attack and trying to retrieve wpad.dat as well as giving my test accounts credentials when I opened http://intranet:



As you can see from the scenarios mentioned above, this vulnerability can be extremely serious. To make things even worse, if you use an older operating system such as Windows XP, and you havent disabled LANMAN (LM) hashes, cracking them in such a case is trivial. Luckily, as you can see in the picture above, Windows Vista and above disable LANMAN hashes by default, so only much stronger NTLMv2 is used. Still, if your password policy is inadequate, an attacker can crack such passwords.
So what can we do to protect ourselves and our users against this? This is one of those times when auditors that bug you about settings and configuration are really right:

Unless you moved everything to Windows Vista or newer, make sure you disable LANMAN hashes. They are insecure and should not be used under any circumstances.


Disable NetBIOS over TCP/IP. I dont think that anything really uses this any more (if Im wrong let us know please!)

If you want to learn more about this attack, read the excellent post at http://www.packetstan.com/2011/03/nbns-spoofing-on-your-way-to-world.html and, once you get scared enough, take care of your network and users.



--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Tue, 24 Jan 2012 22:29:25 GMT http://isc.sans.edu/podcastdetail.html?id=2278 http://isc.sans.edu/podcastdetail.html?id=2278 Tue, 24 Jan 2012 04:03:10 GMT http://isc.sans.edu/diary.html?storyid=12442&rss http://isc.sans.edu/diary.html?storyid=12442&rss Last week's denial of service attack agains the Department of Justice (justice.gov), the FBI (fbi.gov) and other sites didn't just rely on Anonymous's favorite tool Low Orbit Ion Canon. Instead, a new method was employed to recruit denial of service clients.
The new method uses some pretty simple javascript to launch the attack. The folowers are usually requested to visit a particular web page. The page includes a simple form to adjust the denial of service attack parameters but just launches the attack with default parameters as the page is opened in the browser.

IMPORTANT: The script will start running as soon as the user vists the page.You do not have to press the fire button.

var requestedCtrNode = document.getElementById(requestedCtr),
succeededCtrNode = document.getElementById(succeededCtr),
failedCtrNode = document.getElementById(failedCtr),
targetURLNode = document.getElementById(targetURL)
...

// requests hash table, may come in handy later

Originally, I figured the attack may take advantage of XMLHTTPRequest.Instead, the code takes a simpler route. It just changes an image URL toa URL on the attacked page. I suspect that this method is more reliable asit does not require the client to implement XMLHTTPrequest Level 2 orXDomainrequest but should work with pretty much any client.
It will not necessarily retrieve an actual image,but just whatever URL was targeted, followed by an id parameter and amsg (which is also set by the user). This format should make it prettyeasy to filter the attacks at a web application firewall. Even other contentsensitive firewalls should be able to deal with this.
Sample weblog:


GET /?id=1327271393334msg=No%20A%20la%20CENSURA%20EN%20INTERNET%A1%A1%A1
HTTP/1.1 200 8395

In order to prevent crashing the browser, the script will limit the numberof outstanding requests.The script attempts to send 5,000 requests per second. I tested it directingmy requests to a lab web server across a pretty slow VPN connection. It managed to create about 5 requests per second. The referer for the request will be the URL of the attack page. The user's user agent is not altered.
Update: Spiderlabs did a nice analysis of this tool, including other LOIC variants just about a year ago: blog.spiderlabs.com/2011/01/loic-ddos-analysis-and-detection.html
------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.]]> Mon, 23 Jan 2012 18:16:34 GMT