Cisco IOS Software contains a vulnerability in the Smart Install feature that could allow an unauthenticated, remote attacker to cause a reload of an affected device if the Smart Install feature is enabled. The vulnerability is triggered when an affected device processes a malformed Smart Install message on TCP port 4786.
Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability.
This advisory is available at the following link:
- Cisco Security Advisory: Cisco Small Business SRP 500 Series (netsecurityit.wordpress.com)
- Cisco: Multiple Vulnerabilities; ASA 5500, Catalyst 6500 (netsecurityit.wordpress.com)
- Cisco Security Advisory: Cisco NX-OS (netsecurityit.wordpress.com)
- Cisco Security Advisory: Multiple Vulnerabilities in Cisco Wireless LAN Controllers (netsecurityit.wordpress.com)
A new Request for Comments is now available in the online RFC libraries.
RFC 6528: Defending against Sequence Number Attacks:
(ID Tag: draft-ietf-tcpm-rfc1948bis-02.txt)
This document specifies an algorithm for the generation of TCP
Initial Sequence Numbers (ISNs), such that the chances of an off-path
attacker guessing the sequence numbers in use by a target connection
are reduced. This document revises (and formally obsoletes) RFC
1948, and takes the ISN generation algorithm originally proposed in
that document to Standards Track, formally updating RFC 793.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
IETF-Announce and rfc-dist lists:
Search: RFC series, see http://www.rfc-editor.org/rfcsearch.html.
Download: RFCs, see http://www.rfc-editor.org/rfc.html.
- WebSockets RFC is now official (ietf.org)
- Deprecating Use of the “X-” Prefix in Application Protocols (IETF Draft) (tools.ietf.org)
- J.D. Falk – In Memorium (cauce.org)
- IPsec (acordocoletivo.org)
- HTTP Access to Email Stores (tools.ietf.org)
- RFC 1855 – Netiquette Guidelines (mellormedia.wordpress.com)
Critical flaw discovered in Symantec’s pcAnywhere
Symantec has issued a warning about a critical vulnerability in pcAnywhere, the remote control application for PCs. The vulnerability could allow an attacker to remotely inject code into a system running pcAnywhere and then run it with system privileges. This attack works because a service on TCP port 5631 allows user input during the authentication process which is not adequately checked.
According to Symantec, this port should, under normal conditions , only be reachable by authorised network users, so an attacker would have to first gain access to the network or another computer on the network to compromise other systems. In practice though, overly lax firewall configurations mean that such ports are always available somewhere on the internet.
Symantec is also correcting a vulnerability which meant that files installed during pcAnywhere’s installation process were marked as writable by everyone. This would allow an unprivileged user with local access to overwrite these files, possibly with code which could grant elevated privileges.
LoJack for Laptops Standard, boxed software, 1 year – 20% OFF. Was $39.99 – Now $31.99 Click Here
Further details of the two holes are still being kept under wraps by Symantec and exploits are reportedly not in circulation. As the flaws were reported by security researchers Tad Seltzer (via ZDI) and Edward Torkington (of NGS Secure) it is probable that the discovery of the flaws is not related to the recent theft of source code for an older version of pcAnywhere.
pcAnywhere 12.5.x is vulnerable to the flaws, as are versions 7.0 and 7.1 of the company’s IT Management Suite Solution. Symantec has released a hotfix which can be installed either manually or automatically with Symantec’s LiveUpdate system.
Symantec has admitted that blueprints for current versions of its pcAnywhere software were stolen in 2006 and that all users are at risk of attack and should pull the plug.
That includes users of both current and past iterations as well as those bundled with Altiris and the pcAnywhere Thin Host packaged with backup and security products.
The theft came to light when an Indian hacking group calling itself the Lords of Dharmaraja threatened to publish the source code.
The gang’s apparent spokesperson, who goes by the name of “Yama Tough,” posted code from the 2006 version of Symantec’s Norton AntiVirus to PasteBin and subsequently wrote about the breach on Google+.
It was originally unclear whether the breached source code was relevant to up-to-date installations of Symantec’s anti-virus products.
The confusion has lifted, showing that the danger to users of current products is all too real.
Symantec’s investigation so far hasn’t found increased risk of exposure to customers using any product, with the marked exception of pcAnywhere, which allows for direct PC to PC communication.
Here’s what the security firm had to say about the pcAnywhere-specific risks, as paraphrased from its white paper:
- The encoding and encryption elements within pcAnywhere are vulnerable, making users susceptible to man-in-the-middle attacks, depending on the configuration and use of the product. If a man-in-the-middle attack should occur, the malicious user could steal session data or credentials.
- A secondary risk: If a malicious user obtains the cryptographic key, they can launch unauthorized remote control sessions and thus access systems and sensitive data.
- If the cryptographic key itself is using Active Directory credentials, it is also possible for attackers to perpetrate other malicious activities on the network.
- In an internal pcAnywhere environment, if a network sniffer was in place on a customer’s internal network and the attacker had access to the encryption details, the pcAnywhere traffic could be intercepted and decoded. This implies that a customer either has a malicious insider who planted the network sniffer or has an unknown Botnet operating in their environment. As always, security best practices are encouraged to mitigate this risk.
- Since pcAnywhere exchanges user login credentials, the risk exists that a network sniffer or Botnet could intercept this exchange of information, though it would still be difficult to actually interpret the data even if the pcAnywhere source code is released.
- For environments with remote users, this credential exchange introduces an additional level of exposure to external attacks.
Company spokesman Cris Paden told Reuters that Symantec has fewer than 50,000 customers using the stand-alone version of pcAnywhere, which, Reuters reported, was still on sale on its website for $100 and $200 as of early Wednesday afternoon.
Symantec recommends in the white paper that customers disable the product until the company can release a set of updates to deal with the currently known vulnerability risks.
- Symantec: Anonymous stole source code, users should disable pcAnywhere (arstechnica.com)
- Symantec pcAnyware is not safe to use for now, says company (news.consumerreports.org)
- PSA: Disable your Symantec pcAnywhere software ASAP (slashgear.com)
Intrusion Detection System Evasion.
Evasion is defined as such: You can use evasion methods to bypass IDSs by submitting a packet to the IDS, which will be denied. The packet, however is accepted by the host. However, because the IDS denied the packet, it didn’t verify it’s contents, enabling the illegal packet to obtain access to the host.
This confuses me on two levels.
One, what type of IDS would be used in this case? Allowing a denied packet to go through is a bit of an oxy moron, no? And two, how can the IDS deny a packet it does not verify? Doesn’t the verification come after inspection?
I throw these questions out to you, please be kind and respond. Looking for a detailed example of how the illegal packet makes it to the host if it is denied.
My previous post above (posted 4 days ago) and the mystery packet that can defy evil? Well it has been demistified and the answer is below: Thanks to a mentor!
An example of one of the potential evasion techniques would be using packets that do not adhere to protocol standards. It is possible for a packet to be crafted in such a way that it will be handled differently by an IDS than by a host. Resulting in the packet being dropped by the IDS, but processed by the client.
Regarding your question, “Allowing a denied packet to go through is a bit of an oxy moron, no?”; an IDS is a passive device that is used to monitor traffic. It will inspect a copy of a packet that is traversing a network, but the IDS is not positioned in the traffic stream and therefore it cannot prevent a packet from reaching its destination. It is an Intrusion Prevention System (IPS) that is an active device positioned in line of the traffic flow and can take active steps to stop an attack, not an Intrusion Detection System (IDS).
Regarding your question, “And two, how can the IDS deny a packet it does not verify?”; A packet that is denied by an IDS would be discarded. Whether the IDS logs the packet activity would depend on how the IDS is configured, and the type of packet that was received. For example, if a packet is deemed to be corrupt or malformed by the IDS it could be simply dropped without logging the event. Since the packet was deemed to be corrupt, the contents would not be inspected by the IDS, but the client may process the packet differently.
- IDS Evasion Part I (jeffsoh.blogspot.com)
- IDS Evasion Part II (jeffsoh.blogspot.com)
- It’s Time To Think Like A Hacker (prweb.com)
- DEEPSEC: Reassemble or GTFO! (c22.cc)
- Question for Hacker or InfoSec Pro….Evading the IDS (netsecurityit.wordpress.com)