Cupfighter.net

Looking forward to our in depth discussion on storage behaviors in a virtualized world, including server and desktop in large enterprise environments. Unique is that Randy Kerns is willing to lead our discussions @Schuberg Philis.

Sneak preview on the topics May 30:

- Storage/VDI performance considerations and measurement
- VDI I/O and workloads, boot storms
- Storage disk virtualization
- Architectural change with pooling
- Thin provisioning
- Forward error recovery and data integrity
- IDA based systems
- SSD economics
- Big data analytics

…and more

VDI is usually justified on a €/user basis. This really requires a lot of intelligence…and it almost always comes back to the storage system.

Lets get ready to rumble

psiepel@schubergphilis.com

In order to allow the STT tunnel (http://tools.ietf.org/html/draft-davie-stt-00) through a firewall you need to bypass the SYN/ACK security.
STT uses a header that looks just like the TCP header to the NIC. The NIC is thus able to perform Large Segment Offload on what it thinks is a TCP datagram.

The Cisco ASA is able to bypass this on specific interfaces with an ACL.

access-list tcp-bypass-syn-ack extended permit tcp src_network-host dst_network-host
access-list tcp-bypass-syn-ack extended permit tcp dst_network-host src_network-host

class-map tcp_bypass_syn_ack
match access-list tcp-bypass-syn-ack

policy-map tcp_bypass_syn_ack_policy
class tcp_bypass_syn_ack
set connection advanced-options tcp-state-bypass

service-policy tcp_bypass_syn_ack_policy interface ingress_interface
service-policy tcp_bypass_syn_ack_policy interface egress_interface

Verify the connections to show the bypassed connections: show connections | include flags b

When configuring your NetApp MetroCluster Fabric switches there are two ways to calculate the necessary amount of Buffer Credits on the ISL’s:

• The NetApp and Brocade best practices state the “desired distance” of a ISL port should be set to 1.5 times the actual distance. This will then set the buffer credits to a certain amount.
• This article from NetApp also describes a second method: calculating the average frame rate to determine the needed amount of buffer credits.

Depending on the average frame size of your ISL traffic the difference between these two methods can be significant.

Use the following  to  calculate if your buffer credit settings might be a problem:

portstats64show <port> – This gives the amount of frames send (stat64_ftx) and amount of BB_credit zero occurrences (tim64_txcrd_z).

stat64_ftx      3           top_int : Frames transmitted
                970578587   bottom_int : Frames transmitted

tim64_txcrd_z   0           top_int : Time BB_credit zero
                46631371    bottom_int : Time BB_credit zero

The total amount of frames sent is (2^32)*<top_int>+<bottom_int>.
The total amount of BB_credit zero is (2^32)*<top_int>+<bottom_int>.
The percentage of BB_credit zero is (<BB_credit zero>/<frames sent>)*100.

According to Brocade some BB_credit zero is allowed, but no more than 15% (which still seems high).

Use the following to calculate the average frame size:

portstats64show <port> – This gives us the amount of words sent (stat64_wtx), which translates to bytes send.

stat64_wtx      1485        top_int : 4-byte words transmitted
                4108584283  bottom_int : 4-byte words transmitted

total amount of bytes sent = ((2^32)*<top_int>+<bottom_int>)*4.
average frame size = <bytes sent>/<frames sent>.

Use the following to calculate the desired distance which is used by the Brocade switch to set the buffer credits:

desired distance = (real distance*2112) / average frame size.

Set this distance on the Brocade switches using:

portCfgLongDistance <port> LS 1 <desired distance>

To see how the buffer credits are configured for each port and how many your switch still has available:

portbuffershow

If you want you can calculate how the switch will translate the desired distance to buffer credits:

buffer credits = <desired distance>*(<link speed>/2) + 6

If QoS is enabled on the port it will allocate another 14 buffer credits. By default QoS is enabled, but no QoS zones are configured. In effect this does nothing except consume an extra 14 buffer credits per port. Unless you are going to really use QoS by configuring QoS zones it is best to disable QoS on all ports. This will give you more buffer credits to use where they are really needed.

An example comparison of the two methods:

Real distance: 50km
Average frame size: 1016 bytes
Link speed: 4GB

NetApp best practices method desired distance: 50km*1.5 = 75km. This will configure the switch to use 75*4/2+6 = 156 buffer credits.
Average frame size method desired distance: (50*2112)/1016 = 104km. This will configure the switch to use 104*4/2+6 = 214 buffer credits.

In this example 214 buffer credits will be needed, while using best practices only 156 buffer credits would be configured..

Real world:

Using the average frame size method the BB_Credit zero percentage on one of our ISL’s dropped from 22% to 2%. On another ISL it dropped from 16% to 0.3%!

The differences will not always be this dramatic, and in a lot of cases the best practices method will ensure there are more buffer credits configured then needed. Which is a good thing. There is no advantage to having a lot of buffer credits available, so use them to get the maximum throughput between your switches!

As a next step in how to define a system for data protection, we released a Backup Recovery policy that helps out the industry to set the minimal requirements on their ‘corporate insurance policy’. Tooling will support the definition of Recovery Point Objectives and Recovery Time Objectives for critical business processes or applications. How cool is that to fix the misconception that when something which is called ‘backup is installed’, the organisation is protected from disasters.

psiepel@schubergphilis.com

The upcoming of IPv6 -the new internet communication protocol- is inevitable.

On June 6th, 2012, IPv6 will permanently be enabled by many web sites like Facebook, Yahoo, Google and the likes.

Schuberg Philis is also part of this movement where per this date we will be running all our public services on IPv6; www.cupfighter.net being our first. Actually, it is already publicly available via IPv6 internet address 2001:67c:20c8:aa00::20. How cool is that!?

Read about what IPv6 will mean to Mission Critical businesses in our white paper. It addresses what it is and what it will mean to you and (your) online business(es).

IPv6; The future is forever… The future is now.

When you have certificates installed on a FortiGate firewall and you need to renew a certificate, you need the private key and password which you got when creating the csr.
In case you lost the password or the private key, you simply can’t import the certificate.

On the FortiGate gui or cli, there are options to export the certificate but it only exports the public key part.

It’s pretty simple to retrieve this information because the private key part is stored in plain text in the configuration, go to the cli and edit the certificate:
conf global
conf vpn certificate local
edit <certificate_name>

When you lost the password, you can set a new password:
unset password
set password <new_password>

Display the certificate so you can copy&paste the private key part to a keyfile:
show full-configuration

—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,
……
—–END RSA PRIVATE KEY—–

Lego - A CC NC ND image

by Nikhal Mittal

Nikhal has written a tool call Kautilya which uses Teensy a programmable USB development board to mimic a keyboard. The good (or bad) thing about mimicking a HID (Human Interface Device)  is that HID devices are explicitly trusted by most modern operating systems. Kautilya is a tool that makes the use of Teensy in Penetration  Tests easy.

Teensy is a small board and thus is can be disguised as a USB toy, lost USB stick or something else clever and left in e.g. a parking lot or a smokers area.

Nikhal showed demonstrations in which he used Teensy to type out command line code that:

• Download a program and execute it
• Create a Windows administrative user
• Dumped system password hashes to pastebin
• Logged keystrokes to pastebin
• Bound a meterpreter shell to TCP port 444
• Created a metasploit reverse shell using a signed java applet
• Connect a computer to a hotspot and download a program from it

Kautilya makes a lot of these actions relatively easy for any pentester (and hacker) to perform.

Nikhal has used this in the past to get access to different targets.

• At a large media firm they used this to backdoor a library system and thus gain access to the network.
• At a telecom company they were able to gain access by enabling telnet access and adding an administrative user by selling the teensy’s as cheap pendrives

So how do you protect against this?

• Endpoint protection can help, but can be circumvented
• A GPO that prevens installation of hardware devices

Limitations of Teensy/Kautilya?

• Not much storage on the devices
• Many payloads require administrative privileges
• Inability to clear the payload after a run.
• Lots of traffic is generated to Pastebin
• Not very stable yet as it not well tested

Future extensions:

• Improved payloads
• SD card on teensy
• Support for non-english keyboards

Nikhil Mittal

Nikhil Mittal is a hacker, info sec researcher and enthusiast. His area of interest includes penetration testing, attack research, defence strategies and post exploitation research. He has over 3 years experience in Penetration Testing of many Government Organizations of India and other global corporate giants at his current job position.

He specializes in assessing security risks at secure environments which require novel attack vectors and “out of the box” approach. He is creator of Kautilya and Mareech. In his free time, Nikhil likes to scan full IP ranges of countries for specific vulnerabilities, writes some silly Metasploit scripts and does some vulnerability research. He has spoken at Clubhack’10, Hackfest’11, Clubhack’11 and Blackhat Abu Dhabi’11

No More Sake - A CC ND Image

By Antonios Atlasis

Antonios starts by giving us an overview of fragmentation attacks in IPv4. Attacks via IP packet fragmentation is not new, in fact the first attacks were documented in 1998. And many uses are currently documented:

• OS fingerprinting
• IDS/IPS insertion/evasion
• Firewall evasion
• Even remote code execution

So what does changes in packet fragmentation with the introduction of IPv6?

• IPv6 headers are limited to 40 bytes
• Extension Headers have been added
• The do not fragment bit has been removed

IPv6 attempts to minimize fragmentation. If the MTU is too small to handle an IPv6 packet it is up to the lower layers in the network stack to handle fragmentation and reassemblation. In IPv6 only the sending host is allowed to fragment a packet.

The IPv6 specification also tries to protect against overlapping fragments. If overlapping fragments are received the entire dataram should be discarded.

Antonios tested how well different operating systems handle fragmented IPv6 packets.

First attack tested: small fragments – All tested OS answer IPv6 echo request that was fragmented smaller then the IPv6 specification allows.

Why is this important? If we can use very small segments we may be able to split the IPv6 destination block in up to 32 fragments which forces a firewall to spend a lot of CPu cycles in reassemblation.

Read more…

Jeni sells us XPath - CC image

By Sumit Siddharth & Tom Forbes

XPath is a language to query XML data.Sometimes XPath is used to query the backend data of web applications in stead of a database. XPath injection is a vulnerability that can be compared to SQL injection. An attacker can inject something that has a XPath ‘meaning’ into the string (e.g. ‘ or ’1=1) and get different results then the designer of the application intended.

Sumit and Tom show different examples of these injections.

But, XPath can also be used to get to metadata of the document. By creatively manipulating the query you can get the entire XML document without much trouble.

Tom has written the tool XCat that automates blind XPath injection to get the contents of the entire XML file.

XPath 2.0 adds loads of features. These functions speed up Xpath injection. But, it also has functions that allow you to access so called ‘cross file joins’ which allows an attacker to load any XML that is on the system. Also this function can be used to connect to external websites so more data can be exfiltrated and data extraction can be speeded up. Or, if outgoing HTTP is limited, you can append that data to a domain name and watch the logs of the authoritive DNS server of that domain.

In summary if you use XPath 1.0, sanitize any user input before inserting it into you XPath statement or make sure there is no sensitive data in the XML document you are querying.

If you use XPath 2.0 make sure you sanitize your XPath satements or all XML files on your system are at risk.

Some sites use XQuery, which is a super set of XPath. This allows an attacker even a greater attack surface.

Tom and Sumit found XPath injection vulnerabilities in eXist-DB which is used by databases in the wild. Using these vulnerabilities the entire content of the eXist-DB can be exfiltrated.

The mitigation of XPath/XQuery injection are the same as for any injection attack:Escape and validate any data that is passed to you by a user. XPath allows you to parameterize in the same way as prepared SQL statements and bound variables.

Read more…