Graham Sutherland: Breaking Binary Protocols and Bad Crypto

this is me uh yeah i'm a penetration tester for port collis i've been there for about about 14 months now one of my specialities is uh messing around with uh binary protocols messing around with network protocols messing around with uh flat files uh windows reverse engineering windows internal stuff um windows binary applications so that's the kind of stuff that i really enjoy doing um so i'm going to talk to you today about uh some sort of generic techniques into breaking these binary protocols from from the ground up so yeah these are all my contact details um this is all the corporate information which i am required to tell you about so read them if you want

right so yeah quick introduction there'll be a quick introduction we'll go over some background information to the talk um some general analysis techniques for uh digging into these binary network protocols identifying bad implementations of cryptography so often you'll find that people who've implemented their own uh binary protocols will have also done silly things with the crypto they won't have just tls wrapped it with a decent implementation they'll have gone and put their own things in there and then we're gonna put things together and come up with some conclusions basically this this entire talk is uh based around some issues that i found in a very popular piece of networking equipment so uh how many of you

saw the abstract and saw the little disclaimer at the bottom saying oh we're not quite sure what we're going to be talking about uh whether we can tell you or not and uh came here in the hopes of getting some zero day well it's gonna be good

i'm particularly proud of some of these animated gifs so the subject of this today is a load balancer um anybody know what that is somebody said it it's a citrix netscaler so in reality it'll probably look more like that so it's a little less shiny these are the older style ones i'm not quite sure which revision this is um but yeah these things are essentially well i'll tell you what they're in a minute so this is what it says on their website that first lot is loaded way too much for me to read but my these second two quotes here are absolute gold like marketing material is brilliant uh combines a comprehensive attack detection database to immediately

identify and block known security threats along with a positive security model that blocks zero a day attacks i'm sure that really works oh by the way does anyone here work for citrix nobody well when this goes out if anybody from districts is watching sorry i know they've already spoken to me but sorry uh of course blocking 100 of attacks yeah i'm sure so there's the reality it's 90 [ __ ] so it's a load balancer it's an ssl endpoint it's a vpn endpoint it's available as a physical device which you've seen you can get it as a virtualized appliance it has the various citrix stuff so you've got ica which is the remote desktop style thing

zen app and all the other various things and standard security features which is basically a firewall but they've got some particular things that matter to it in terms of it being a necessary endpoint and things like that so the history of this is essentially the uh the second week i started at port cullis uh tim the guy sat there handed me this big black box and said mess with that so i said okay that'll be interesting so i started digging around in it um spent a couple of weeks playing with it uh found some very interesting things stopped reverse engineering various bits of it and worked out that there were quite a few things wrong with it um

so we well i compiled all of this research into a paper and we sent it off to citrix about seven months ago and it's now been seven months and they've now patched two of the issues we actually had a conference call with them yesterday at 4 30. um finally going over but we've essentially decided that um it's been a long time uh the contact level has not been brilliant so therefore we've uh gone ahead and decided that we're going to disclose this stuff um how that being said uh citrix have uh apologized for not being in contact with us quite as much as they as we would have liked them to be and they're going to go we're working with

them going forward to uh try and improve the secur the security of their products as as well as their sort of handling of further issues so they're doing pretty well so the initial approach to looking at the device first thing look at the physical parts because i like playing with hardware hardware is fun you can find all sorts of crazy [ __ ] and hardware um so the first thing i did was spin it around take the cover off have a look see what i can find unfortunately not a whole lot but we'll go into that in a minute uh analyzing the net footprint so that's a posh way of saying end map basically poking around having a look at

what it exposes on different ports because obviously you're going to have with it being an enterprise networking piece of equipment you can have different ports that are set up for different things so you can access management over these ports and these are external these are internal blah blah blah so yeah probing the services for interesting things so connections to them trying to work out what they are what they do whether they maybe say something really silly and you go oh okay what's that doing that and then sniffing traffic using normal during normal operation so digging while it's just actually doing its job and then sniffing the traffic uh whilst it's doing administrative tasks so for example if you're logged into the

admin panel what's it doing there so the physical ports as i said weren't actually that interesting there's a serial port so it's standard db9 and fn rj45 so there's there's not a whole lot to look around in there so the zero port as i said standard db9 connector we go through to that on a standard 9600 board connection drops you to a management shell um you can manage the device reset passwords blah blah blah physical requirement obviously it's designed for if you walk into the dc walk up and you need to fix something on it you can go in and directly configure it but we did discover a special logon there's a special logon that

is kinda documented it's you can find out about it on the citrix forums and some of the citrix support guys do talk about it but i don't believe it's in the the main reels of documentation that they publish um so it's kind of interesting but uh you can't do a whole lot with it really so then we start looking at the network level so it's got tcp ports open port 22 for ssh 18443 for the configuration utility over http or https the user can go to either uh 3008 for the uh this is a java applet within the configuration utility so the configuration utility is basically just like a web page with a java applet

embedded in it and it doesn't really do anything else you use the java applet to configure the whole thing if you visit it over port 80 then the java applet talks over port 3010 and does everything in the clear if you visit it over https then it talks over 308 and does that racked in ssl port 4001 for citrix rta so that's a standard port 766 sorry 7776 runs an unknown service um if you connect to it it just immediately kills your connection i don't know what that's for i never worked out uh 2700 sorry 27 000 and five two three three four is the flex net licensing stuff that they use on there um

not a whole lot interesting with that so the main thing that we're gonna be digging into is the stuff on 3008 and 30 30 now 10. console management when you connect via ssh you log in with a username and password as you normally would but instead of there's a default which is ns root ns root um you can just log straight into that if they haven't changed it it's not very smart to do ns recover is the alternative one that we were talking about a minute ago so the unusual one it seems to be that you so that one doesn't appear in uh etc password um it seems to be like some sort of special

account that's built into the sshd um not entirely sure how it all works there's no obvious way to change the password for it but on a few of the devices that we looked at the passwords were changed so it may well be that citrix can change it or there is some sort of documented way i've just not found it um but when you log in you don't get an ssh prompt you don't you don't get a standard you know bash shell or whatever what it actually drops you to is a menu-based configuration system so what they've done is they've taken this sshd and then pipe basically piped this management utility into it so that when

you log in you just drop into that so you can't there's no real sort of like breakout from that well there is but um essentially you do this menu-based configuration so they have a set of it's a little bit like using uh don't you have used uh disc part or something like that so you type this part and then you go into certain sub-menus and sub-menus and you can go back and use your kind of thing but if you have admin rights you just type shell and it drops you to a shell prompt as root which is quite nice now reversing the java applet how many of you here have reversed the java applet at least had a look or a try right so i

found on you basically java is a uh just in time compiled language um it's quite similar to net so if you compile the application because it's such a reflective language um it's actually relatively trivial to get the almost original source code back bar comments um like everything basically gets compiled in because it's uh it's essentially a machine readable description of the code that you've put in there so you can reverse engineer that quite easily there's lots of tools to do it i use jd gui it's quite a nice tool um you literally just drop the executable in there or the jar in there and it literally just tells you all the sauce when you just go

through and read it all it's like being back in an ide and you can export it all out as text so you can grip through it or whatever and as i said use grep to find interesting things certain things that you might discover quite easily with grep some things are a bit more contextual and the documentation gives you a bit of context as to which bits of code are important and which bits aren't and what they might be doing so you might grep for something and then go i have no idea what that's doing and then you start to trace it back and then look through the documentation and that gives you a better idea

now spot the fail number one who here actually knows java who here can tell me what's wrong with that or why that's stupid if you can read it i know you know tim yeah so basically the validation of the certificate is just returned true so i hand you a certificate and instead of validating it you just go okay and just accept it blindly so i could hand you an expired code signing certificate for the wrong ip address um everything can be wrong with it and it will just go yeah that's fine as long as you give it a certificate as long as it's well formed so that's kind of bad so that's in their code

so yeah the problem with that obviously being that you can use that to man in the middle the connection next one same thing dot net so this is uh this is originally from their documentation so they have an api that you can talk to and they recommend using that it's not very bright however it also turns out if you google a little bit of that code like it turns out it doesn't appear very often that people write that so if you google a bit of it um some other people have put out open source stuff why i say open source stuff reverse engineered stuff from other citrix products and that's in another citrix product somewhere

interesting well it's still related to the next but yeah so issue number one i told you i was proud of the animated gifs so there's no certificate validation on the ssl uh communications with the applet so that ssl is when you go over port 3008 when you've gone to the website over https the java app loads up and then talks back over port 3.08 with the tls wrapping but if you can run in the middle that connection back it didn't matter it went over https their browser it means nothing you can just go through and pop those communications and see what's going on uh between between the user's java applet and the device itself so uh who here knows what diffie-hellman

is right so diffie-hellman key exchange protocol it's a bit of interesting cryptography um essentially it's a way for two parties to securely exchange a secret uh without an observer being able to work out what that secret is so there's two types of diffie-hellman adh and dh adh is anonymous so i know nothing about you you know nothing about me there's no prior um authentication and the problem with that is if you man in the middle that i might end up talking to somebody else so i might end up going okay i'm going to exchange this with you but actually i'm exchanging it with somebody else and they do another exchange with them and then they man in

the middle and get between diffie-hellman normally uses an authenticated version of that which essentially the initial uh handshake stuff that goes across is authenticated with the uh with some sort of prior exchanged or agreed upon authenticity information so when you normally do it you might sign it with a long-term public key that's right long-term private key and then somebody else can validate it with that public key now the implementation that they use in order to generate the random prime i use java.util.random now java.util.random is just a prng it's like libsy random there's no guarantee of it being cryptographically secure in fact i can tell you flat out it is not cryptographically secure don't use it

for that um so there's a 32-bit seed on older systems on newer ones it's 48-bit which kind of makes it hard to brute force the seed um because the random generation isn't like a trivial bit of computation it's a little bit more difficult to brute force but it's still possible but the problem is that because it's a prng it's not a true it's not a cryptographically secure random number generator it's a pseudo-random function it's not designed to be cryptographically secure if you take a bunch of outputs from this there are what's called predictor algorithms that people have written which will tell you what the seed is based on like five outputs from the random number generator so it's really

bad to use that kind of thing for uh cryptography and the seed is also based on the time stamp so that really narrows your uh narrows down your values because if you know that the applet started up roughly when you just saw somebody download a big bit of https data off the off of the netscaler you can kind of guess roughly the time stamp is going to be within this range and therefore you've just cut the number of seeds down massively so then all you need to do is guess that have enough guesses have enough outputs be able to roughly work out uh what potential value what potential seed values there could be until you get

them within this window and then suddenly you know what the seed is and then you can work out every random number generator random number that it will generate and therefore you can work out what the diffie-hellman private information was and then you get the secret which means you win so sorry there's a lot of maths in this particular bit i say a lot uh so the way definitely hellman works is that you have um a prime p and a base g um these values are sort of picked beforehand and uh then in all in the way that it was implemented in their code is as follows you pick prime p base g then you pseudo randomly select

a candidate secret value so a apostrophe which is the candidate secret value i.e i think i'm going to use this one i need to check that it's all right first such that it's less than the max so imagine i picked the number three as my uh p value now three in terms of the number of bits you need to store the number three you need what two bits it's my my brain is not working today a number of bits now given that candidate number p basically using the same sort of idea how many bits do i need to store this number so that's the the maximum value that this will be so basically what it does is it loops

through and goes okay i need to pick another number that's smaller than this one so if i pick a number such that it's it's got that number of bits there's a good chance that i'm going to be somewhere around the right maximum value so then it next checks that it's actually less than that value and if it has if it's if that doesn't if that condition doesn't match it loops around again try to pick another number so what it's essentially doing is saying okay pick a random number does that random number satisfy these things if it does hooray let's use that if it doesn't pick another one now this is kind of interesting because the upper bound for that value is

something that you know because it's a public piece of information so if i hand out this public piece of information and say to you okay i'm going to pick a bunch of i'm going to pick a random number but i don't know whether it's going to satisfy these conditions i'm going to loop around until i do it what happens if you work out how long it took me to do that based on that piece of information you know you can start to work out how many iterations i might have done in order to hit that value so by knowing this public value and knowing how long it took me to generate the private value part

you might be able to start working out some more information about how the about what that value might be or more importantly about which values i discarded now if you know that i discarded a whole bunch of values you can know that those values have a certain property like for example that they were too big so if i say okay here's the number one thousand i'm going to pick a bunch of random numbers until i find one that's less than a thousand so if you know that it probably took me about 20 iterations before that happened you know i had 20 numbers that were bigger than a thousand coming out of my random number generator which means that

you start to build this sort of model of okay we had about this many values we know that therefore we might be able to build a predictor for that random number generator such that i can tell it okay i picked 60 random values that were larger than this find me a sequence so find me a seed whereby this sequence is likely to have occurred and then when we start to tie all this information together we can start to look at you know for example oh if the p value is quite high um and has uh like a lot of its early bits set to one you know that all of the discarded ones must have always also had

its those bits set to one because in order for it to be larger it must also therefore have those bits set to one so you can start to work out these little things and start to unravel information about the discarded values and then start to work out this information about what the random number generator output now there's also a function called munge in there which made me laugh because it's a completely ridiculous name for a function so they have this function called munch and literally what it does is it takes an input value of some bytes and repeatedly xors these fixed values these static keys over that information and then outputs them again so it's like a really crap encryption

algorithm and it turns out that these byte values are these strings here now the first one uh look like they look like landmarks in india i'm not i don't know whether anybody recognizes those i don't know what they are um and the bottom one uh is a company that used to make hard drive controllers so i'm not really quite sure what that's all about but anyway um yeah so uh we've got two issues there issue number one is the weird diffie-hellman stuff badly implemented and issue number two is the static crypto things we'll go into what they were used for in a bit so as i say we have issues incidentally that is my favorite gift

ever this is so weird so you remember how i said to uh anybody who from citrix who's watching sorry things like this that right i'm lazy like really lazy i really can't be asked to float so like breaking dh is hard breaking r g's is hard it hurts my head i have to do maths my beard isn't big enough to talk about probability theorem um so yeah i'm i'm lazy let's break it easy in an easier way so the binary protocol digging around in that and you'll see why that other stuff is relevant in a minute uh analyzing the traffic on port 3010 which is the plain text stuff it's easy to look at however

there's a there's a clear text header which has a bunch of stuff in there that i look at and go okay yeah that looks like clear text to me followed by something that's quite high entropy so that looks either compressed or encrypted or both um so a bit of guessing so as i started to look at the protocol look at how things changed you can sort of see values that look like uh encoded integers so like uh for example if you get um one zero zero zero zero zero zero zero so you've got four bytes there you kind of think well okay well that looks like an integer whose value is 16 because one zero

in hex is 16 and then you've got a bunch of zeros after that it looks like a four byte in so you can kind of guess certain things so then you go okay well what does that number represent well what about the length of the packet so you work out how long the packet the data blob was and go oh look that matches up then you get another packet and you look at the two and they both match up and then you've worked out that that's the length field so then you look at other things like values that are stay static like for example the second field in there which is a magic number it's just um

not x a5 a5 which is just designed to identify this is actually the traffic you're looking for a reserved value which is zero because it was always zero so i'm just going to guess that it's probably reserved some kind of packet type or code so what i was saying was a lot of when you log in you see a lot of different types and then periodically you just see this this value stay the same for certain ones and then you start doing management uh management uh tasks and then more packets come through with different values in this field and that kind of says to me well it's probably like some kind of command code so

as i guess then some kind of flag kept like it didn't really correlate to being a different type of function it seemed to have different it just seemed to be set slightly differently in different ones of the same type the the same uh like packet type the same function um it's it's kind of guesswork you have to try and build up this sort of pattern in your mind of what's going on by looking at all the different types of traffic that's going through there and keep in mind yes i could have gone through and looked through the java source code at the time i hadn't actually found the bit where they defined the packets quite a big

source tree so i was still digging around for that but so in the meantime i did that then the unknown 16-bit integer and unknown 32-bit integer couldn't work out what they were so the payload data is the stuff that came after this so that was the clear text header now the payload data after that is all encrypted and stuff um so you can see there this is one of these packets that kept repeatedly being sent now i thought probably a heartbeat packet say hi i'm still here i'm still connected don't drop my session the same repeated pattern but if you start a new session that pattern completely changes you get the same sort of repeating pattern

but you get different values but for the same session every packet same values and the first bit would sort of change a little bit but then the rest would be all right it would be all the same so that to me is evidence of a repeated xor cipher i'll say that in the loosest terms so essentially they're looping some value repeatedly xoring it over it and as you can see at the bottom you've got this looped string i don't even quite tell but it's like eight hc dc two nine eight c dc two nine and it just carries on repeatedly but the first bits are kind of have a little bit of that and then a

little bit that's changed so it's like huh okay so what's being sent over there now i just want to talk quickly about some crypto classification now if you if i throw you a binary protocol it's got some a bunch of data and you want to work out okay well what kind of crypto is being used over this data you want you want to without looking through the source code let's say you don't even have the source code let's say you can't even look on the device it's some web app somewhere and it's just black box and you want to work out what exactly are they doing in terms of the crypto are they doing something

smart are they using something custom are they using a block cipher are they using a stream cipher are they using something that is considered good like aes but implemented badly like have they have they set it up badly so the first thing you want to look for is patterns if you see patterns you know they're doing something wrong because proper encrypted data you should never see patents it should all just look like purely random gibberish so if you start to see these sort of repeated blocks of data or like repeated little sequences of bytes you can start to work out that maybe they're doing something a little bit wrong now one of these other things is if you

maybe change a value slightly uh in your plain text input so you you can control the input and it gives you this encrypted output so it's what's called it's a form of uh differential crypto analysis because you're essentially taking what's coming in and comparing it what's coming out and working out what those changes are so essentially you want to make a small change in your input and see how that changes the output now if you just see that this tiny little linear change in your input just makes this tiny little change in the output then you know that they're doing something kind of unusual either it's a stream cipher or it's something like repeated xor

because if you change one bit and one bit changes on the output you know that they're doing something linear that's going across for example an exclusive or operation uh so if you've got a single byte input change gives you a single byte output change you've either got stream cipher or something crap like repeated xor but then if you cycle to a new session and then try and do the same and you see different values it might either be that they've changed the key uh yeah they've probably changed the key but if they don't then you know it's probably a static key which is interesting um or if you know it's the same key somehow um

then they might be using something like an initialization value initialization vector which then will also change the output of the value so if you see that a single input byte change changes the whole block of output so like maybe 16 bytes or something or eight bytes you know that they're probably using a block cipher so the way a block cipher works is uh given a block of input a fixed length size of input it's not only does it alter the values but it also permutes the information around there's two concepts one's called confusion the other one's called diffusion confusion is about taking a value and making it a different value diffusion is about taking that value and

moving it around in the block so or splitting it out into its individual bits and then flipping those all around and then messing with them more and more and more so by mixing confusion and diffusion you get a half-decent block cipher so it's uh i think um claude shannon is the one who came up with that terminology i think he's a smart guy um so yeah if you see this chunk of output changing then it's probably a block cipher but if you do see that it's a block cipher but you know they've done it wrong because if they did it right they would you be using a block cipher mode that causes all of that other information to change

once you change one bit changes in a block should always permute sorry always sort of cascade across to the rest of the blocks and change the information more so electronic codebook mode ecb is the most basic block cipher mode which is essentially take every individual block of data using the key encrypt each one separately using the transform the crypto transform which is like for example aas or serpent or something like that uh ds you go through and uh and uh encrypt each block separately but you don't cascade them together you just leave them all separately now there's a great image of this um which you may have seen if you've ever looked on the wikipedia page for uh

block cipher modes if you encrypt a bitmap image with aes 256 in ecb mode and then you look at the output you put the bitmap header back on so it can actually be rendered and you load it up you can still tell it's that picture you can still tell like this they use the uh these tucks the linux penguin as an example you can actually see that image you can you can still tell what it is the colors are all messed up but the reason that is is because the same bytes of input for a block will always produce the same bytes of output for a block if you use the same key so if you've got consecutive blocks

that have the same plain text you'll get the same cipher text which means you know something about that place which is a bad idea so because these pictures have the same sort of color information for a block so if you've got a big chunk of white you can actually see that all of these are the same and then when you get a line you get this transition where they're all different and it all kind of looks a bit messy and then it goes back to being saying same patterns over and over again so the patterns of data between blocks don't change in ecb mode there's a way around that and it's using a different mode for example cipher

block changing cbc which is a much better way of doing it so you know it's cbc mode if you change it and then only one block changes you know it's ecb mode if you change it that block changes and all of the blocks after it change but the ones before don't so if you can put something like a big string of a's and then you flip one to a b and you see that everything after that gets changed you know it's probably something like ecb mode where you get this cascading effect so that's what i mean there by single byte input change is a current chunk plus all subsequent chunks all the blocks after that change because you get

this propagating thing that still means they did it wrong because it still should just all be completely random so yeah if you put in a single byte change and everything changes that probably means they're doing something right because what that means is they're using an initialization vector in there which is the idea is that for every message you choose this unique value this unique iv which then causes everything after that to become permuted completely randomly you can't work out what's going on in there so as i said with the cbc mode it chains these together the way it does that is it take for every plain text block it xors it with the previous ciphertext block for the first

one because there isn't the previous one you use the iv which then causes that to cascade across so essentially what what's happening is you it's a little bit like a nonce value it's a little bit like assault as long as it's unique everything will always appear to be random so if they do that right you'll never know what's going on you won't be able to work out whether there's a stream cypher block cipher what because it'll all just look like gibberish but if you can see these changes these behaviors of the cryptography when you change small amounts of information you can start to get a picture of what's happening in in that implementation so you can start

to work out that maybe they're using ecb mode maybe they're using cbc but they've got a static iv so it's not changing so that this you get that cascade effect where you change one thing everything after changes but the values before stay the same so the whole kind of uh idea behind it is you treat it as a black box start sending it information map how it changes as you change things and you start to work out what's going on and the final thing there is the block size of the chunk so if you flip one bit and a whole block changes by working out how much of that how much data changed you can see the

block size which means you can narrow that down to okay well how many block ciphers do i know that have a 64-bit block size or a 128-bit block size so then you can start to work out maybe maybe they're using aas maybe they're using blowfish maybe using ds you can start to work out what's going on now decrypting the actual payload so as i said before it looked like repeated xor so i just took those bytes at the bottom and guessed that maybe there were like null bytes so if there were null bytes and then you xor them with a key the result would just be the key so they would be just transmitting the key inside the packet in in the

glitter you could just see it so when i did it and export everything with it get a bunch of zeros and then get stuff that looks like an actual proper packet header and that to me went oh okay yeah they're definitely doing repeated xl so i eventually found the packet structure in the code had a look around did some more intuitive analysis to get the fields worked out what was going on this is what it said in the actual packet structure so packet length magic number reserved command flag error code and dev number so you remember i said there was a 16 bit and a 32 bit integer that i didn't know it's those two at the end now this

is a login packet and uh the username and password were looked encrypted i couldn't work out what was going on now remember i said that those two functions called munge and those two static crypto keys inside there well it turns out that if you xor the username with the first one and you xor the password with the other one you get the clear text your name and password so you can actually go through and decrypt all that information so the high level overview here oh yeah and close enough i got pretty close to working out without looking at the source so i'm happy about that so high level overview so the handshake packets at the start

use dh to exchange a key for the session that key is then used to encrypt the subsequent packets so it's using this repeated xor so called cipher and then the login packet is sent contains the username and password obscured with that munching function and the username and password whilst they are ascii they're quite clearly obviously there they're not the ones that we entered which is a little bit weird and turns out we can do some interesting things with that basically it comes out as a bunch of hexadecimal in ascii and it looks kind of odd so the impact here is if the user views over http we can use the traffic on port 3010 which is in the clear

but encrypted with their custom algorithm we can pop that crypto off quite easily just by watching for a single ping packet which then actually contains the damn keys inside the packet because it's xor with zero which gives you that value then you can decrypt everything decrypt all of the traffic all the way back and you get the username and password they do it on 3008 so if they visited the applet that and gone on by https it goes all right best use best use port 3008 best best be secure and then they go through and uh just let any ssl certificate through so you can just man in the middle that pop the crypto off again

you win but what are those logins the the weird ones that we couldn't actually quite that they didn't look right well they're not your everyday login so the accounts on the wire are like session ids so the username so-called username is two hashes a bunch of hex and then a null byte and the passwords are just a bunch of hex again now if you log into those you log those in to the uh the normal ssh so basically you log in over the panel and you've and you've sat there and sniffed somebody's connection and you've decrypted that traffic you then take those those bits of information and use them to log into the netscaler over

uh over ssh and it drops you straight in so you just stole somebody's session and you got and if they've got if the one if the person that you were monitoring the person whose traffic you were stealing was a super user you type shell you get root so that's your money shot right there you you win by sniffing the traffic or by man in the middle england

any questions and more animated gifs yes um just clear up you said this is obviously occurring when logging in over the open java ports so it's only the citrix java client vulnerable is the default desktop client secure against this and right i don't know about any of the other clients these are the java one was the only one i looked at um it may well be that the other clients are vulnerable it may well be that they're not that i would imagine the ht the html5 one probably wasn't because it's probably just doing like ajax calls back into it i would imagine that's in one of the newer netscalers because they have got some slightly

different admin panel stuff on there but the java the java stuff uh yeah definitely vulnerable well was vulnerable they have now released uh a patch which fixes the uh ssl validation and uh fixes well apparently fixes the the uh the diffie-hellman stuff we haven't reviewed this yet they've said that they've released it and they said that there's a patch out we haven't actually had time to go back and look at it because we only had the comp call with them at 4 30 yesterday to verify all of this so yeah and wheels what kind of tools do you use to do the analysis and capture the data and replay and things so uh mainly just wireshark

um and then in order to like mess with the data again i just wrote some custom stuff uh just to open up ccp sockets and start sending data to them um there are tools that you can use to do like binary like on the wire manipulation i've not found a good one yet the one that i would use if i had to uh echo mirage is a windows one so basically it binds to the um the packet functions and lets you mess with stuff as they're coming in and out there are a couple of ones that do that but echo mirage can also detect if you're using standard ssl wrappers and then give you the stuff before the ssl

which is quite nice i like that feature it doesn't work with everything but it works with like the windows standard api for doing ssl it works for um i think a couple of standard like open source libraries as well it detects those and goes okay i'm going to hook before that rather than hooking the packet send function which is quite nice

um the exo encryption how did you where did you find the key for that so the xor encryption is inside the uh so the ping packets that were getting sent um because it's uh because of the way xor works if you xor a value with zero you just get that value so because the ping packets that were being sent had encrypted payloads and those payloads were always zero it just meant that they were sending the key in the packet because you could literally just see it essentially it if but though if it was still a static value and it wasn't zero it still wouldn't matter because you just xor it with whatever static value you've got in

the packet if you know the data is there you just xor it back against uh so you get the ciphertext xor it with the plain text and that just gives you the key so you can just recover the key through doing that and then by getting that key you can go back and decrypt everything else

sorry so just quick special thanks uh first off to tim for just throwing this at me and putting me in the deep end my second week into the job um and also to uh aaron dalton uh he's uh the guy who handles uh our vendor disclosure stuff he's done a lot of hard work over the citrix stuff keeping keeping in touch with them managing that he's done a really good job and obviously the b-sides organizers for making this possible and everybody who voted for my talk mr awesome