 Good morning everyone. Okay. So a simple disclaimer here. I'm bad at designing presentations So there will be lots of text Be aware of it. There will be text okay, so the title that I chose was when the internet bleated because Bleeding was the word which was used to explain a bug which was recently found which is hard bleed and Like we had a show of hands. Everyone knows about heart bleed okay now Besides open SSL. Is there any other software which is vulnerable to heart bleed? Anyone has idea about it? Or is it just the open SSL, which is vulnerable? One F exactly Now that is where the internet word is not sufficient. It's not the entire internet We always keep bashing about some competitors or some proprietary softwares, but in this case it was only the open source open SSL package, which was vulnerable neither the GNU TLS nor any other package at all so Besides heart bleed of what I basically wanted to cover up here was a brief understanding a brief overview of The various bugs which were shown recently these bugs these six bugs have popped in recently in various SSL stacks various SSL cipher suits or in various SSL versions now those bugs What it means for a developer what it means for an administrator. That's what I wanted to convey out So we'll start with basic idea about what these bugs are We'll cover heart bleed in detail because that's the recent one we'll cover up some demos and There's a hands-on so if someone has laptop available with Python installed because that's the only requirement you can actually Try it out live. We have a server setup where you can actually see heart bleed in action Now this is a bold statement, but it's kind of a truth at this era where we have seen lots of Disclosures from a lot of Outside world countries claiming that they have capabilities to snoop on traffic we have seen Disclosures where companies are shown to have received money to weaken their algorithms and The six bugs that I'm going to discuss about All this means that the security protocols which are there We can assume that most of them are broken Either someone has found a flaw or someone has bribed to get a flaw So SSL has in terms Now turned into insecure socket layer So I'll just give you a thousand feet view. This is not the technical view This is the high-level overview of the six bugs So hot bleed this picture is courtesy courtesy xkcd. How many of you know xkcd? Okay, those who don't know about it. I would suggest to visit that site It's an awesome site especially for someone who is an IT industry So this basically summarizes heart bleed in a very quick glimpse. So open SSL around 2011 Close to the new year time introduced a feature which was known as hard beat Basically a request would be sent from client to server or from one end to the other end Requesting if you are alive send me a response back So just like in this case server. Are you still there reply me with potato and He mentioned it's a six-letter word So the server saw it so I saw the request Responded back with six letters, which is potato Now He again sent a request reply bird four-letter word Server sees it responds back bird four-letter word. Now. This is where In security domain what we generally tell everyone is never trust user input and this is what was the flaw See the next request Server are you still there if yes reply with hat? It's a three-letter word, but he gave a input 500 letters and the response came back with not just hat But the next consecutive memory segments up to 500 characters All of that came back Now this looks like okay. Yes. It's a buffer overflow a normal simple flaw. What can happen? So when we deep dive into it, I'll talk about what exactly our people are able to extract including your server private key The SSL private key is also exploitable here the other two bugs. I hope these two diagrams are clear No Okay, looks better Okay, so this particular Screenshot is actually the GNU TLS patch log they recently patched a particular flaw Wherein they were actually using a go-to function to go to clean up instead now they are good shifting to go to fail This particular patch was in response to another flaw which was discovered in Apple Now how many of you are developer here Okay, everyone understands how if condition works in C Okay, can anyone spot a flaw there's already a comment which says what is the flaw? So there are a large number of if conditions. That's what you can see now The funny thing that you'll realize is the if condition these statements after if conditions are not enclosed within brackets so the Yes, exactly. So the general assumption that C language makes is if there's no bracket The next preceding statement is within if condition not the statement after that and this is where This kind of mistake would have happened with a lot of people While typing some word you press the random keystroke and the line get copied just below it Similarly, there's a go-to fail two times exactly it This place Now what happens is? This condition is checked if this condition is true go-to-fail If this condition is not true then go-to-fail. Otherwise go-to-fail so the last condition is not checked at all and These certificates even if they were not valid even if they were not working properly They were accepted as valid certificates. So this was a Apple bug a Proprietary source code someone found a flaw in this then GNU TLS Looked at its own code and they corrected their own code also innocent mistakes Which go-to statement to use? Now, let's not get into a debate that if by using Python. This would not have occurred or Any other language we have to stick to see because of n number of reasons One of them primarily being the large number of code ways that we have right now so If someone wants to know the deep dive technical details, they can just use these URLs These are for the specific bugs GNU TLS is extensively covered in this extensual dot-com blog and Apple bug at Impovia wallet and Go-to-fail.com is a site where you can check your Apple Products, okay another question that came in mind. How many of you have Apple devices out of those? How many have jailbroken devices? Okay, and that jailbroken device have you updated it or not because of losing jailbreak Not updated so a jailbroken device You will not update because a jailbreak will not work with the latest version Now by that you actually get some facilities, but you're losing on fixes like these Which is kind of crucial at this point? Okay, now this is I've just combined three four bugs here the first one beast in SSL 3.0 and onwards We have been using cipher suits one of the commonly used cipher suits for CBC ciphers Now CBC cipher works on chain. Now those chain Had predictability. That's what beast try to exploit if you're using CBC ciphers You may be vulnerable to beast because the Total encrypted package could be enumerated out and identified What is the actual encryption key and the whole data could be decrypted using this particular bug Now all these four why have combined all these four at this place? because although they are proven There are white papers. They are academic researchers around it, which says that this is possible Supercomputers can do it a normal person or A normal adversary might not be able to do it very quickly, but these are still relevant attacks Which do happen? Now the same person the same group which found beast the next year they found crime crime was associated with compression So Google was banking a lot on spd y spd y protocol by default works on compression mode Now that as well as if you're using HTTPS compression This was again vulnerable to Enumeration and identification because of the compression algorithms that were used Lucky 13 another timing attack. So these three four attacks are largely in the academia not Actually exploited too much, but they're still there RC for how many of you know about RC for? Okay, and So there are a lot less people so RC for is another Cypher suit which is used in SSL communication Known to be vulnerable for a large time line, but when beast came up That was a point when version 3.0 of SSL or TLS 1.0 had two main Cypher suits RC for CBC CBC is vulnerable most of the pen testing organizations or the security companies reverted to recommending that turn off CBC and Switch to RC for and that was the recommendation that went in a Lot of people do implemented it out, but the problem is RC for in itself is not a secure protocol So this particular link basically it talks about three four different attacks on RC for So this particular thing you can look at now My primary focus is on hardbleed so if the time permits will look into these but otherwise the primary focus will be on hardbleed so the current state TLS 1.0 or SSL 3.0 all Cypher suits Everything on SSL 3.0 is broken either an exploit is available or it is possible conceptually Now just like I said If you protect against beast you are vulnerable to lucky 13 or RC for related attacks So it's a cash-22 situation right now and the funny part about it is TLS 1.1 TLS 1.2 have been in system I think for a large number of years People are working on RFC for 1.3. However, we still do not have 1.1 and 1.2 enabled on HTTPS servers How many of you are you were still using Windows XP till it went end of life? anyone Okay, that had its own set of I Related applications which were installed in it IE 6 IE 7 now these older versions of browsers They do not support TLS 1.1 1.2 that have been the primary reason why websites were not Kind of willing enough to enable 1.1 and 1.2 but now This basically the the current range of attacks which are there. This is basically Shown that okay now is the time you have to move ahead You have to make sure that you have better algorithms better encryption standards available and Use them proactively so getting back to hard bleed so The hard bleed the interesting part about hard bleed was not that much into the technical part But more often to the marketing section This was The first bug in past five to eight years. I would say which was marketed very well Before public disclosure before anyone got a whiff of it the company the one of the company which found it Had a domain registered for it So hardly dot-com was registered first and then parties were informed that okay such kind of a flaw exists and then People started patching things So there was a very effective marketing which basically helped in one way most of the attacks that happen They are generally limited to security industry Even developers and admins get that only via There is a patch available which fixes some security issues related to CVE xxx yy y and Admin or a developer will see okay some security fix has happened. I'll just update it and I'm done with it But this bug was marketed properly. So everyone keeps talking about it. That's why we have so many hands saying yes We know about hardly the simplest definition or a simplest abstract of This is it's a lucky draw You ask for some data You may get any kind of a data and data is not equal to information. You may get valuable information You may not get valuable information Now this actually invoked a lot of Twitter reactions. So I am an avid follower on Twitter. So I just cataloged some reactions which were there The first reaction very accurate very true, but still disheartening It's a memory disclosure blog bug people were cribbing about it, but it's not the end of world It's an open-source code. Anyone can look at it. Anyone can try and find more such flaws The last year has shown you're safe as long as you don't use SSL Apple devices GNU TLS NIST standards emails or cell phones That basically covers up everyone one or the other thing then someone came up with a T-Shark based Query which can actually detect if hard bleed is happening if someone is trying to query hard bleed on your server Now this guy Troy Hunt Had a very interesting thought about it The trick is not about patching servers. The trick is about identifying where else open SSL 1.0.1 till 1.0.1 F is used and We'll see where else it is used another similar reaction Let's patch things What about your routers switches? How many of you have networking components on your network and Probably end-of-life products or your support has expired anyone here Because I've seen cases where the support has expired because of one or the other policy reason and now they hang up with not having an update So your VPNs gateways wafts ESX servers and number of other devices. They all rely on open SSL Freely available code anyone can copy it anyone can use it. So everyone is using it Start SSL. How many of you know about start SSL? I think has geek also uses start SSL Yeah, so start SSL Provides you a free certificate for first year Now in this particular scenario hard bleed since there was a potential chance that the private key might be disclosed It was suggested that you revoke your certificate and create a new certificate with new passwords new keys The certification revocation from start SSL was costing something around $24 then the last one Microsoft OCSP Takes 24 hours to mark a certificate as revoked OCSP is a method by which you can basically identify if the certificate is revoked or not and Browsers basically query it and see okay. Yes, this certificate is revoked and if it is revoked it shows an error Now that takes 24 hours. So even if you have done all the work on your end Your certificate is still valid for 24 hours Okay, now this is what I have actually Configured right now. There's a live server at hard bleed dot uninsured or info It's an amazing hosted image So The demo I'll try to see if I can show you the video demo if that does not works We'll try to do it live and those who have the laptops with them. They can basically use these two scripts test.txt is a shell script and hbtest.txt is a Python file Like I said, I'm a lazy presenter. I'm also a lazy coder So this hbtest.txt is not my original creation. It was a Publicly available source code. I just took it modified it a bit to make it look a bit beautiful And then the shell script basically runs this Python file 9,000 times To just make sure you get as much data as possible Now on this server I've configured two login pages login underscore post dot html Login dot html, which is basically login pages underscore post obviously goes via post and dot html is the normal login where you have a get request. I Know the login pages would look like ridiculously stupid because there's no PHP language and no server-side language here It's just two html pages sending post request or get request to each other What we'll see Okay, so I Hope this works Okay, this looks like ridiculously stupid right now because I've inverted colors Because I had an assumption that black background with white text looks absolutely brilliant on presentations but It proved wrong. So we'll just see so this is one particular page which I've configured login underscore post dot html I have obviously not configured the actual certificate is a self-signed certificate now. This is I Know for the people in back. It's three White blobs, but I'll just try to explain what exactly it is With the help of a little zoom okay so this is one screen which is basically capturing the Access log on the server the actual server where hard bleed is possible Now you can see I've done a tail minus F and you can see to get requests login underscore post dot html and fabric on the Tyco and the host name is Hard bleed dot an entry dot info now the other one This is another server which is available online Which I'm using to attack now The machine which I have here is the client trying to access the server and this client bleed dot Ananshi dot info is the attacker it is trying to get the username and password used here and This is just a simple watch Overgrip just to see if I've got the username or not if you proceed forward Like I said about that shell script Test dot txt on hardly dot Ananshi dot info. This is nothing But a wrapper over the actual Python file running at 9,000 times Now I agree we can do that inside Python. I was not a brother I was short of time on that and skill set to So I went with a shell script. So I'm starting the shell script on this window Which basically will be Running the Python file continuously for 9,000 times and extracting the output from server Now if you look closely in this Trying 48 attempt Connecting sending client. Hello client request sent a connection established hard bleed request sent now received hard bleed response And you can see some garbage text here. Now what I've done is you basically are receiving 64 kb of data But I've extracted out only the ASCII character set out of it. So it's just the ASCII output that is there. So this guy is basically Trying to extract whatever it can from the server at that same point I Went back to the login page and I've tried a username password username being rootcon 2014 and a password. We'll just see what exactly is the password Once you submit this request It's a post request you get a message Some request response submitted and you can see here There's a post request received by the server Now the logs will not have a value username password because it's a post request Supposedly this should only be visible between the client and the server. No one else should have this value No one else should be able to extract this value now Since it's a lucky draw, I'm just spending some time trying to see if some other password just submit one or two more requests So this was rootconf rocks and By the time the second request went in if you look closely here is this text visible username rootconf 2014 password root underscore conf underscore 2014 Post data over HTTPS Supposedly only visible between client and server a third server or a third box is able to extract this data That's the minimal impact of hard bleed extraction of sensitive information from the server memory Which is related to session. So just like you have this Username password combinations. You'll have keys. You'll have API keys. You will have cookies Any damn data that is traveling between server and client and is available in the memory adjacent memory to hard bleed request You'll be able to extract that out So now this was all talk talk and talk. So how much time is over yet? Okay, so All right, I've exceeded the time limit any questions from anyone or If there's no question, I'll just like to show one more demo which is like five minutes max Which is related to client attack? Okay, so in this the two screens one is actually showing you an Android emulator Where the Android version is four point one point one, which is again a vulnerable version using this open SSL the other window is From the other server, which is client bleed server, and I'll just show How you can actually extract data from a client memory. So I've made some search queries here Rootcon some rootcon related entries came up. I've opened one or two websites here has geek I've opened I've opened rootcon again So now these all requests which I'm making are over HTTPS because we are targeting HTTPS memory here rootcon for opens Another HTTPS base site I can try login does anyone remembers what was the first site that opened Google.com and Android browsers have a notorious habit Whenever you open Google.com they first try to log you in Using the credential whatever is available on the device So just keep that in mind when we look at the output now. I've tried two three combination of usernames and passwords For one it said username is not correct for the other it said incorrect password which in itself is a different class of issues Yeah, I know Yes So now I'm trying to access this client bleed on entry.info which will be running a well exploiting server What this means is on this box? I have this pacemaker software I'll show I'll give you the URL the pacemaker software the pacemaker python script is actually a Server side exploitation. So this will exploit a client When you run this You go back to your client you refresh the page now you see here this bucket load of data that is coming in and Anyone can see at the bottom last second last line Google account Test log in and pass equals to password. This was the username password Which was there in the device for my Google account Plus you can see the server certificates for root con and has geek whatever sites we opened up the server certificate information the public component as well as other information is visible plainly in The server so whatever data was there with the client be it for that particular site or be it for any site at all That can again be extracted out. So that's another component where People have not given a lot of thought Okay, how many of you own a website here have your own website and To have more usability you have some kind of a place where you can input a URL and the content of the URL will be fetched Like an image can be Used via a URL as your profile picture Kind of facility that generally sites have Now if that URL is kind of this kind of a server URL and The internal component which is actually fetching the URL is vulnerable. You will bleed out the memory from that particular server those are some of the potential impacts now We can start the questions if anyone has and This is the pacemaker Python file you can download it from JTOP Yeah, so just want to confirm. So what you've got is not the server's private certificate But the public certificate from the client from the client So public certificate is one part like you saw the Google account login is what we got So anything that that is there in the client memory. I can extract that out Okay, but you need to basically be able to talk to the client which means the client should have IP that you can access No Client is sending a request right, but how do you get anything out of the client's memory? So you so you're essentially making a heartbeat request to the client. So the heartbeat is two way It's not one way. So the server can get this out of the client. Yes But in this case, I'm curious about how you do this make this for a work for a third party Can you for instance listen on the network? Find all clients that are currently on the land and go get information out of them for what they're doing No, the client first has to make a request. Okay, client has to establish a connection So this is essentially a way for a server to go break into all the clients connecting to it. Yes Or Let's say you have a web page which has an image tag with an SRC pointing to an Attacking server so automatically client will make a connection and you can then extract the information. Okay So just like you basically exploit an XSS attack or a CSRF attack any other questions Since I'm Just like I said to this guy earlier. I tend to just Go in the flow and miss out the timelines. So I missed out the timeline. This is what I wanted to discuss more but Since the time is out. So any other question that is there three more minutes Okay, so Now the basic question that was there in everyone's mind. What is there for an administrator? What is there for a developer in short words for administrator? You have to make sure your patches are up to date you're monitoring properly and In olden days, it was like, okay, there's large chunk of log files I cannot monitor all the logs with big data in place with Massive computation power that is there. You can do a lot of correlation co-reference Just do that build a system where you do correlation You try to find out anomalies like a person logging in from India and within five minutes of that person logging in from India He's logging in from us Although concurrent logins might be disabled should be disabled They are not disabled in most of the sites and that might actually trigger a warning for you that okay That there is concurrent logins happening You might want to look at it now for the developers How many of you Distribute packaged softwares where you have all the dependencies packaged into the same executable Alright, I think largely there'll be web developers Okay, how many of you use jQuery Self-hosted version okay, and do you religiously update that? Do you know that with jQuery there are large number of CVs available with? Vulnerabilities including Dom accesses and a lot of other issues So similar to this particular thing where you are using a self-hosted jQuery a JavaScript library If you are distributing packaged dependencies like open SSL you have to make sure you update that also because There are 75 Cisco devices not the Number of devices but the type of devices which are vulnerable and they have to update because they had a packaged dependency and that dependency is vulnerable Yesterday or today early morning CA has said that there are large number of CA products which are vulnerable and They are releasing advisories around it Now the technical solution is to enable TLS 1.1 1.2 enable perfect forward secrecy revoke SSL certificate obviously there's a cost involved make sure you're not using any of the existing Secrets neither the password nor the key You're secure till no one finds another flaw policy-based solutions Like those are questions at the start. How many of you actually changed your passwords? So that's the second point first password reset. Don't ask them to change the password Lock all the accounts ask them to have a new password and then log in Fail hard fail early if you see some discrepancy in the network some problem react React immediately inform them if you see it's a login related stuff block login request for some time monitor it and then continue The other part is API keys We have those beautiful rest API is where you have get requests with the API keys in them That or the post request with those API keys. Those are all vulnerable with this particular thing so overall I Think leaving aside Nothing in this everything is vulnerable via one or the other attack Windows XP out of support Sunworks station's out of support media PC Depending on Windows or Linux, whatever it is laptop again depending on OS wireless transport ATM router modem switches Those devices Depending on what are the dependencies that they have included Sun Solar is again support cell phones PDS depending on what kind of new OS you're using Android iOS Firefox OS, whatever that is So the entire landscape if you look at everything is vulnerable So a caution has to be taken from everyone The understanding has to be there that yes, this problem is there and the solution is not easy It is not just a technical solution that you upgrade everything and you're done You buy a new product and you're done. There's also some policy that you have to follow There is also some approach that you have to follow a large number of companies are Profiting via open source softwares, but they're not contributing back I think on this red hat actually does a lot of good work. They contribute back But there are very less organizations which are doing that and that is one of the core reason of such kind of flaws Going unnoticed even though the source code is publicly available So that's kind of the end of my boring long presentation if anyone has Any question if they are still not sleeping I Think it's definitely a wonderful talk. I'm sure our heart is bleeding now, right? Any interesting one last question we have we are so tempted to you know, the time is up But we still wanted to see such an interesting talk, you know, there is a one interesting question from the audience The heart is really bleeding, huh? Everyone's bored. There is one here I'm a basic operations person. Yeah, I'm having a very dumb question here What happens to layers where the application server is talking to a database system where there's it's an encrypted password But what we had to update across the fleet, but I still don't I still I try to understand what happens to that Database layer with something like this because it's just the app connecting JDBC connectivity passwords Yes, we encrypt all of that's fine. But why okay now on that You remember I gave you an example where a person can actually give you a URL and your application is basically trying to fetch some content from it Now those kind of requests now a database and app server connectivity I am actually shot of examples right now But in general even if it's an internal network device you have a front load balancer Which is terminating SSL point and you may have whatever kind of connections inside The termination point is the external attack point where someone can directly talk to the server and extract data The other way of extracting data would be Forcing your server to make a connection to someone either as a client or as a server So if your server is making external connections, you still have a point of vulnerability there Just like the client piece which I showed that's make sense. Thank you Thanks, Anand wonderful talk Thanks a lot