Information Security all in one place!

Posts tagged “Transmission Control Protocol

Cisco Security Advisory: Cisco IOS Software Smart Install Denial of Service Vulnerability


 

 

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:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-smartinstall

 

 

Advertisements

Network Scanning: Concerns and Countermeasures


 

Network Scanning Concerns and Countermeasures

Daniel Saucier (Student of the InfoSec Industry, March 2012) – Network vulnerability scanning can not be more important than it is, right now in this day and age of internet computing. As technology grows the architectures are not catching up quite as fast as most would like. This article written below assumes you have basic networking knowledge, and assumes no responsibility for actions taken from this article. It’s sole purpose is to educate the savvy portion of the internet community with different protection types and threat preventive measures for today’s networking environments.

Different IP network scanning methods allow you to test and effectively identify vulnerable network components. Here is a list of effective scanning techniques and there applications: These options can be found in most advanced configuration options on most downloadable network scanners.

ICMP scanning and Probing:

>| By launching an ICMP ping sweep, you can effectively identified poorly protected hosts ( as security conscious administrator such as myself, filter inbound ICMP messages) and perform a degree of OS fingerprinting and reconnaissance by analyzing responses to the ICMP probe.

Half-open SYN flag TCP port scanning:

>| A SYN port scan is often the most effective type of port scan to launch directly against a target IP network space. SYN scanning is very fast, which allows large networks to be scanned rather quickly.

Inverse TCP port scanning:

>| Inverse scanning types (particularly FIN, XMAS, and NULL) take advantage of idiosyncrasies in certain TCP/IP stack implementations. This scanning type is not useful for large networks. Use this scan type for testing individual host or small network segments‘ security. Make sure your code is as up to date as possible and apply any manual workarounds to protect gear from this type of scan. Some if not all of these type of scans identify weak components because of the cost of business.

Third-party TCP port scanning:

>| Using a combination of vulnerable network components and TCP spoofing, third-party TCP port scans can be effectively launched. Scanning in this fashion has two benenfits: hiding the true source of the TCP scan and assessing the filters and levels of trust between hosts. Although time-consuming to undertake, this can be proved to be very effective when applied correctly.

UDP port scanning:

>| Identifying accessible UDP services can be undertaken easily, only if ICMP type 3 Code 3 (“Destination port unreachable”) messages are allowed back through filtering mechanisms that protect target systems. UDP services can sometimes be used to gather useful data or directly compromise hosts (the DNS, SNMP, TFTP, and BOOTP services in particular). Make sure you are locking these down!!

IDS evasion and filter circumvention:

>| Intrusion detection systems and other security mechanisms can be rendered ineffective by using multiple spoofed decoy hosts when scanning or by fragmenting probe packets using Nmap or fragroute. Filters such as firewalls, routers, and even software (IPsec) can sometimes be bypassed using specific source TCP or UDP port, source routing, or stateful attacks.

Using the different scanning methods mentioned above you can harden you network pretty well, however. Change is always a factor, what if you need to undertake a major network overhaul and start exposing different types of protocols to the network. The following list will help you when considering modifications to your components and minimize risk of re-exposing vulnerable services.

>| This list could be used as a baseline, guideline in some cases on any network configuration.

  1. Filter inbound ICMP message types at the border, or perimeter if you DMZ any servers on any routers and firewalls. This will force an attackers to use full-blown out TCP scans against all of your IP addresses to map effectively.
  2. Filter all outbound ICMP type 3 “unreachable” messages at the edge routers and firewalls to prevent UDP port scanning and firewalking from being effective. Firewalking – process of identifying firewalls in the scanning enumerations
  3. Consider configuring Internet firewalls so they can identify ports scans and throttle the connections accordingly. You can configure such as Check Point, NetScreen, and Watchguard appliances to name a few to prevent fast port scans and SYN floods from being launched against your network. However, this can back fire if the attacker is using a spoofed source address, resulting in DoS. PortSentry as an Open Source option is pretty effective as well in identifying scanns against your network.
  4. Asses the way that your network firewall or IDS devices handle fragmented IP packets by using tools such as fragtest and fragroute. Such devices can be taken down by being flooded with high volumes of fragments being processed. Bring your findings to the vendors attention……
  5. Ensure that your routing and filtering appliances (both routers and firewalls) can’t be bypassed using specific source ports or source routing techniques.
  6. If you run FTP services; ensure that your firewalls aren’t vulnerable to stateful circumvention attacks relating to malformed PORT and PASV commands
  7. If a commercial firewall is being used, ensure the following:
  • Latest code is installed, consider replacement is you can not comply
  • Antispoofing rules have been correctly defined so that the device doesn’t accept packets with private spoofed source addresses on its external interfaces

8.  Investigate the use of reverse proxy services if high security is a must. Fragments and malforms are not getting  by these guys, thus mitigating low level recon.

Wrapping up this article I would like to mention; be aware of your own network configurations and its publicly accessible ports by launching TCP and UDP port scans along with ICMP probes against your own IP address space. It really is surprising how many companies large and small still do not undertake proper scanning exercises.

Happy Hardening!

-DS


RFC 6528: Defending against Sequence Number Attacks


A new Request for Comments is now available in the online RFC libraries. 

RFC 6528: Defending against Sequence Number Attacks:

Internet Engineering Task Force

http://www.rfc-editor.org/rfc/rfc6528.txt

(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:
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
RFC Sources:
Search:  RFC series, see http://www.rfc-editor.org/rfcsearch.html.
Download:  RFCs, see http://www.rfc-editor.org/rfc.html.


In the round file cabinet goes; PCAnywhere


LoJack for Laptops

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.

Image representing Symantec as depicted in Cru...

Image via CrunchBase

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 revealed the news in a white paper[PDF] published on Wednesday, along with a customer advisory on its website.

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.

 

LoJack for Laptops


Question for Hacker or InfoSec Pro….Evading the IDS: UPDATED!


Intrusion Detection System Evasion.

I am in the middle of my CEH training and the topic of IDS (Intrusion Detection Systems) bypassing is on the agenda. Currently I am covering the topic of “Evasion” when it comes to bypassing an IDS.

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.

Alarm System Sign