Class in Session: IT Security

Using AnyConnect SSL VPN Client with Cellular Wireless Adapters

Published February 4, 2010 Cisco Security Leave a Comment
Tags: anyconnect, cell phone, wireless

During a visit to a client last fall I encountered an interesting default property of some of the popular cellular wireless adapters marketed by such providers as AT&T, Sprint, and Verizon. Before I reveal what that property is, let me “set the stage” to depict the problem that the client was having.

As the accompanying traces will show, this Cisco customer was attempting to use the AnyConnect SSL VPN Client using a cellular wireless adapter, in this case the AT&T Sierra card. While some laptops were able to connect successfully using the card, others regularly failed.

The ASA output below, resulting from a debug webvpn svc 255, did not definitively address the cause of the problem: (NOTE: hostname(s) and IP addresses have been changed to protect the client’s identity).

INFO: debug webvpn svc enabled at level 255.
ciscoasa# term mon
ciscoasa# Called vpn_remove_uauth: success!
webvpn_svc_np_tear_down: acl_id: 11
webvpn_svc_np_tear_down: ACL refcnt: 0
webvpn_svc_np_tear_down: no IPv6 ACL
np_svc_destroy_session(0x334000)
ATTR_FILTER_ID: Name: user-VPN-filter, Id: 11, refcnt: 1
webvpn_rx_data_tunnel_connect
CSTP state = HEADER_PROCESSING
http_parse_cstp_method()
...input: 'CONNECT /CSCOSSLC/tunnel HTTP/1.1'
webvpn_cstp_parse_request_field()
...input: 'Host: 1.1.1.1'
Processing CSTP header line: 'Host: 1.1.1.1'
webvpn_cstp_parse_request_field()
...input: 'User-Agent: Cisco AnyConnect VPN Agent for Windows 2.3.2016'
Processing CSTP header line: 'User-Agent: Cisco AnyConnect VPN Agent for Windows 2.3.2016'
Setting user-agent to: 'Cisco AnyConnect VPN Agent for Windows 2.3.2016'
……<output omitted>….
webvpn_cstp_parse_request_field()
...input: 'X-DTLS-CipherSuite: AES256-SHA:AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA'
Processing CSTP header line: 'X-DTLS-CipherSuite: AES256-SHA:AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA'
webvpn_cstp_parse_request_field()
...input: 'X-CSTP-Protocol: Copyright (c) 2004 Cisco Systems, Inc.'
Validating address: 0.0.0.0
CSTP state = WAIT_FOR_ADDRESS
webvpn_cstp_accept_address: 172.16.2.8/255.255.255.0
CSTP state = HAVE_ADDRESS
SVC: NP setup
np_svc_create_session(0x337000, 0xC7563400, TRUE)
webvpn_svc_np_setup
SVC ACL Name: user-VPN-filter
SVC ACL ID: 11
SVC ACL ID: 11
vpn_put_uauth success!
SVC IPv6 ACL Name: NULL
SVC IPv6 ACL ID: -1
SVC: adding to sessmgmt
SVC: Sending response
Unable to initiate NAC, NAC might not be enabled or invalid policy
CSTP state = CONNECTED
webvpn_rx_data_cstp
webvpn_rx_data_cstp: got message
SVC message: t/s=3/16: Failed to fully establish a connection to the secure gateway (proxy authentication, handshake, bad cert, etc.).
Called vpn_remove_uauth: success!
webvpn_svc_np_tear_down: acl_id: 11
webvpn_svc_np_tear_down: ACL refcnt: 0
webvpn_svc_np_tear_down: no IPv6 ACL
np_svc_destroy_session(0x337000)

As illustrated above, the debug message merely indicates that a proxy authentication, handshake or bad cert is seen but it isn’t more definitive. Undeterred, my client decided to investigate further using Wireshark activated on the Cisco SSL VPN Adapter. This can be an effective method to observe and troubleshoot packets which would otherwise be undecipherable due to encryption on physical adapters. The revealing trace is shown below:

Several items of particular interest can be noted in the trace above:

First, there is a query for a bmocbeacon.isp.mycingular.net which resolves to a private IP address, 172.18.144.65 in the provider network. (packet #31).
Second, is that the SSL VPN client switches over to communicating with this IP address as a proxy from the original outside IP address of the ASA security appliance during connection setup (packet #38). This was determined to be the cause of the “cert failure” noted above in the debug trace.

Further investigation to the forum (shown below) listed numerous end user recommendations to disable the default proxy accelerator used by the cellular card. When we found the software configuration area to do this, the bmocbeacon reference was listed as the proxy location. Disabling the use of this feature solved the connection problem.

Author: Doug McKillip

References

AT&T Wireless Forums – Phone and Device Support

Cyber Czar Worries about Smartphones and Social Networking

Published February 4, 2010 Hacking & Cybercrime Leave a Comment
Tags: Android, Apple, cell phone, hacking, iPhone, smartphones

In December, President Obama’s cyber czar commented on the rising threat of smartphone attacks. It seems that this may have been an accurate prediction as Apple iPhone users got a shock recently when researchers released information on flaws in the way Apple regulates and approves applications released for the iPhone. Apple does not generally require the source code; an application is submitted and then examined for inconsistencies and undocumented function calls, and once approved, it is signed and released.

Is this a real problem? Yes – this year’s Black Hat conference is focusing on the iPhone, Android and other smart phones and raising the alert that a simple application downloaded may do more than you bargained for. Code released at this year’s conference demonstrated how it is possible to harvest email addresses, phone numbers, keyboard caches, WiFi connections, and recent GPS positions.

Smartphone vendors are going to have to work harder at securing their platforms and hardening them against attack. Without stronger security controls, smartphones are poised to be a rising attack vector. The iPhone itself has been targeted with questionable programs and malware such as libtiff, SMS fuzzing, Aurora Faint, Ikee, and Storm8.

From Michael Gregg

IPS Signature Rate-Limit Action

Published February 2, 2010 Cisco Security Leave a Comment
Tags: IPS, rate limiting

One feature which receives just a mere mention, but nothing else, in the Cisco IPS 6.0 training class is IPS Rate-Limiting. Often mentioned within the same context as blocking, this signature action is also implemented in conjunction with an upstream device, in this case the Cisco IOS Router.

This article will focus on both how to configure the IPS sensor to trigger the rate limiting action as well as prepare the router to perform that action. The screenshot below depicts the area within IPS Device Manager (IDM) where Rate Limiting is configured; note that it is done underneath the Blocking section and does not have its own dedicated configuration subarea within IDM. Telnet was chosen as the communication mechanism (vs. a best practice of using SSH) so that we could investigate what the sensor deployed to the router by capturing the communication with a switch SPAN port and Wireshark.

Continue reading ‘IPS Signature Rate-Limit Action’

Earn Money from Google!

Published January 29, 2010 Hacking & Cybercrime Leave a Comment

Google is offering $500 to people who find security bugs in the Chrome browser and Chromium, their open-source codebase for Chrome. A couple of specifics:

“Google is looking for flaws in the Stable, Dev and Beta channels of the Chromium codebase, and said that the company will not pay for bugs that are disclosed publicly before they’re disclosed to the Chromium developers. However, the company will pay for bugs that are disclosed publicly after they’ve been fixed in Chromium.” (from threatpost.com)

Plugins and extensions that are part of the Google Chromium project by default (not third-party) are also eligible for public bug hunting.

Cost of Data Breaches

Published January 26, 2010 Uncategorized Leave a Comment
Tags: access control, hacking, leaks, network security, passwords, policies, Privacy

A recent study by the Ponemon Institute determined that the average security breach costs $203 per compromised record. So, if a company loses a hard drive that contains sensitive data on one million customers, they’re out $203,000,000. That’s a lot of items off the dollar menu at your local fast food joint.To compare – five years ago, the cost per compromised customer was just $183.00.

Image

Cisco Security Podcasts

Published January 26, 2010 Cisco Security Leave a Comment

Last fall SC Magazine and Cisco teamed up to deliver a series of 10 minute podcasts on the latest updates and recommendations on current security issues and trends. Presented by Cisco security experts, the topics covered

PCI Compliance Update
Secure Teleworking
Mobile Device Security
Business Continuity Planning
Wireless Security
Security Threat Landscape

Download and listen for free.

Cisco Security Devices Default IP Access Policies

Published January 25, 2010 Cisco Security Leave a Comment
Tags: access control, policies

A significant percentage of the students I teach manage multiple Cisco security devices: IOS routers/switches, ASA or PIX firewalls, IPS sensors and, yes, even the occasional VPN concentrator. While most of the official training courses offered provide at least one chapter which discusses “best practices” in managing each of these devices, they omit the comparison of the default IP-based access policies. That comparison is the subject of this article.

The table below shows a brief summary of two sharply-contrasting default access policies: a) An open one where an access-list is used to restrict access and b) A closed one where the access-list is used to permit access. The VPN Concentrator was added to this list due to its continued presence at many end-user locations despite the product being more than 2 years End-Of-Sale.

Default IP-Based Access Policy

Open (ACL restricts access) Closed (ACL permits access)

IOS router / switch ASA appliance / PIX firewall

VPN Concentrator IPS Sensor

IOS router/switch – Most network administrators know that although the default access policy for these devices is wide open, a CLI management session with telnet or ssh cannot be done to the device until a line password is configured. Following this implementation, it is highly recommended that an access-class into the vty lines referencing a standard access-list be added to restrict access. Additionally, a transport input ssh vty line configuration command can be added to restrict access exclusively by this protocol.

Continue reading ‘Cisco Security Devices Default IP Access Policies’

Cyber Crime Methodology

Published January 21, 2010 Hacking & Cybercrime Leave a Comment
Tags: cybersecurity, footprinting, hacking

One of the topics I spend time on in ethical hacking classes is the methodology of a hack. While platforms change, targets change and different tools are used, what stays consistent is the methodology. My point is that all attacks start with “footprinting,” move to “gaining access,” and end with “covering tracks.” For an example of this, let’s look at the TJMAXX credit card hack. If you are interested, the full indictment can be found here.

Footprinting
1.   The first thing the suspect did was to profile Fortune 500 Companies.
2.   These companies were targeted for data mining. The suspect used sites such as sec.gov and others to further refine the possible list of targets.
3.   The suspect did a physical assessment of the targeted companies. Visits were carried out at retail stores to examine their point of sale (POS) systems and identify any insecure wireless systems.
4.   Finally, the suspect examined back-end systems by surfing corporate web sites and analyzing payment process systems. These systems were to be scanned for potential vulnerabilities.

Gaining Access
5.   Using insecure wireless networks and vulnerable code on SQL servers, corporate servers were penetrated.
6.   Once the suspect had access to the company servers, further scans were performed to identify which servers contained credit card data.
7.   With the targeted servers identified, the suspect installed sniffer programs. These custom programs were designed to “phone home” with credit card numbers and other sensitive data. The specific program used was Injec-TOR.

Covering Tracks
8. To maintain access, the suspect modified programs and used custom malware to avoid detection by antivirus.
9. The suspect attempted to hide his real location by using proxies and encryption.

Notice these basic steps: footprinting, gaining access, and covering tracks. While several of the individuals believed responsible for this attack are unknown and believed to be in Russia, their US accomplice has been charged and is facing many years in prison.

Michael Gregg

Footprinting: The Financial Health of a Company

Published January 19, 2010 Uncategorized Leave a Comment
Tags: footprinting

Footprinting is something that you may think of when the topic of ethical hacking comes up. But this technique can also be used to explore the financial health of your current employer or of a potential employer. Footprinting is the process of gathering as much information about an organization as possible.

While footprinting can be done for many different reasons, one is employees wanting to find out the financial health of their current organizations. The objective of footprinting is to gather this information in such a way as to not alert the organization. What you are seeking to obtain is publicly available information. This can be available from third parties and from the organization itself. Here are some basic steps to explore:

1. The company’s website – Look for news, recent financial reports, updates, or other happenings.

2. Financial sources – These sites will have information about the financial health of the organization. As an example, www.sec.gov has the Edgar database, which holds copies of 10-K and 10-Q financial filings. Other sites include Hovers, Dun and Bradstreet, and Yahoo finance.

3. Social networks – These sites should be examined to see what the employees are saying. You will want to search by employee name or company. Some sites to check include: www.blogsearchengine.com (specific postings from bloggers) and www.wink.com (searches social networking sites).

4. Newspapers and court cases – The best place to start is www.topix.net (regional news) and www.pacer.uscourts.gov/natsuit.html for court records.

I hope this information gives you a better understanding of footprinting and that you find these resources valuable.

From Michael Gregg

Image

IOS 15.0 Security Enhancements and Improvements, Part 3

Published January 18, 2010 Cisco Security Leave a Comment
Tags: IOS, router

This post is the third of a series of articles on the new security features of IOS 15.0 code. The topic of our discussion here is Flexible Packet Matching (FPM). Some specific enhancements of this feature which debuted in the IOS release 12.4(4)T Advanced Security image will be discussed in this article, namely the use of encrypted Traffic Classification Definition Files (eTCDFs) and Packaging Support.

Let’s explore the fundamental operation of FPM before delving into the enhancements. First of all, FPM requires the use of Packet Header Definition Files (PHDFs). These are XML-formatted files which contain the fields appropriate to the protocol; each field consists of a field id, description, offset, and length in bits.

In the initial implementation of this feature, the router administrator would first specify a load protocol statement in the running configuration, next define the class-map, policy-map, and service policy statements to describe which field(s) must be present, and finally to define the exact pattern to match at a predefined offset into the packet.

IOS release 12.4(6)T introduced the concept of TCDFs (Traffic Classification Definition Files). With this addition, the modular policy commands (class-map and policy-map) can now be defined in the XML schema. To properly implement this added feature, an additional load classification statement is needed. Since the two modular policy commands just defined are now in the XML file, the administrator merely has to specify the interface to which the service-policy will be applied.

With the use of a TCDF, the capability exists for public distribution of mitigation of known attacks; however, the use of standard XML presents a security risk with the up-date process. To solve this problem, Cisco added encryption support – the use of eTCDF files. With the advent of this feature, for IOS15.0 Cisco also has announced Packaging Support for FPM, a capability which allows for the periodic updating of all IOS Routers from a centralized server containing the eTCDF files. All the administrator needs to do is specify the IP address of the server, the package name, the path, the periodic time interval in which to check for updates, the auto-load option, and whether or not to log any FPM update events.