13 ms·
CloudFlare's Heartbleed challenge cracked
- tectonic 13y agoAh crap.
- bigiain 13y agoOn the other hand, if anyone asks me to justify all that "unproductive time" this week, I don't need to handwave and explanations any more.
- girvo 13y agoI was lucky, my boss understood pretty quickly how big a deal it was. My project manager didn't, though, but he did pretty quick when I cracked our dev server and told him his password for a couple of services. It was fun playing pen tester and getting paid for it this week :)
- bmadden 13y agoDo you guys store passwords in plain text? Shouldn't you only be able to get password hashes from a vulnerable server? I might be reading too much into your statement, but I'd like to know if I'm misunderstanding the situation.
- insom 13y agoIf the passwords were POSTed over and left on the heap, then they were vulnerable to being scooped up via Heartbleed, even if they are stored hashed in the database.
- deleted 13y ago[deleted]
- ephemeralgomi 13y agoHeartbleed doesn't give you access to storage - it gives you access to the raw heap of the process that's linked to OpenSSL. Passwords are typically transmitted unhashed, albeit encrypted by TLS, and the application decrypts the TLS stream to heap, which means an unhashed version of the password is in process memory for some amount of time. An attacker using Heartbleed has a chance to see that memory, and could therefore see hashes OR unhashed passwords.
- patcheudor 13y agoExample from a memory dump on a vulnerable server (username & password changed to protect the innocent): `..?...t?.R...t> ...ned....userna me=0000000+0ew+0 user&password=my passw0rD.~Jt.... .3z..a.......... One of the things that caught me off guard, but isn't surprising is that some hosting companies don't use VM isolation, thus it was possible to pull memory from other sites which may have been patched. Hopefully hosting vendors that don't have isolated VM's don't also allow users to install their own OpenSSL as this would become a vector to compromise neighboring hosts. Of course allowing any custom software install in such an environment is just asking for it.
- canadev 13y ago"[H]osting vendors that don't have isolated VM's don't also allow users to install their own OpenSSL as this would become a vector to compromise neighboring hosts." Could you explain this please? Here's a possible scenario... I root virtual machine X running on host Z (using heartbleed). Another machine running on Z is virtual machine Y. Because X and Y are not isolated, and I am running whatever I want on X, I can find some uncleared memory (somehow -- how?) that was previously used by Y, thus giving me access to Y. (Seems a bit handwavy, and I'm not sure this is what you meant, so any details would be helpful.) -- For some context, I looked up "VM isolation" and found this article which I think sums it up pretty nicely: http://blogs.msdn.com/b/rsa2008/archive/2008/04/07/isolation-of-virtual-machines.aspx http://blogs.msdn.com/b/rsa2008/archive/2008/04/07/isolation...
- justincormack 13y ago
- barkingcat 13y agoyou are underestimating the severity of the bug. The bug leaks server memory - in which case unencrypted passwords are being sent to the server by the user's browser in order to be hashed to be compared to the hashed versions in storage. Normally this is protected by tls, but as you can see, for servers that suffer from this hole, it's as good as naught. Note that this occurs for "any" connections hitting the vulnerable server, meaning that the patient attacker can just run this in a script and scoop up passwords, credit card #'s, form information POST'ed in by all users of the web service all day long until the hole is closed. and even then there's a good chance that the private keys were already exposed, in which case the attacker can now masquerade as the server.
- tvilot 13y agoI don't think I have come across a more succinct explanation of the problem. Thank you.
- klapinat0r 13y agoThis is why I always make sure to GC, delete or NULL input variables (you must include the request; body et al.) after encrypt/hash/<mechanism>. I basically take the stanze that I want as little to do with your real password as possible.
- mdda 13y agoPerhaps you should over-write them with garbage before doing this. Simply deallocating them (or assigning them to new objects) could leave them hanging around in memory until something else overwrites the same memory space.
- ErrantX 13y agoFortunately, I picked this week to muck up some of our HTTPS endpoints... ready made excuse!
- balls187 13y agoSadly I too had to claim Heartbleed on my weekly status report.
- orblivion 13y agoI was unaware that this was even in question. Didn't the heartbleed.com security researchers already demonstrate this in the lab?
- tptacek 13y agohttps://twitter.com/indutny/status/454767565991325697 https://twitter.com/indutny/status/454767565991325697 How do you not love this guy.
- mbesto 13y agoCore node.js dev, based in Moscow, commits open source almost daily, works at Voxer, cracks security for fun. I love the internet.
- kevinwuhoo 13y agohttps://twitter.com/indutny/status/454783660886360064 https://twitter.com/indutny/status/454783660886360064 Just awesome. Only 3 hours to rip out the key!
- deleted 13y ago[deleted]
- jaredpisas 13y agoWhat's his favorite food?
- deleted 13y ago[deleted]
- fletchowns 13y agoWorked for me running Firefox 28.0 on Linux, no security warnings. Yikes!
- alex_marchant 13y agoCan someone elaborate on what's going on here? If i replace his IP with some other random IP I get a 400 bad request error, so it's obvious that it works, but curious how that resolves.
- gojomo 13y ago
- deleted 13y ago[deleted]
- badusername 13y agoSo this does mean that I need to change my passwords on every damn site on the list? Oh bollocks, those passwords were a work of art.
- spindritf 13y agoNo. This means you need to change keys for every ssl service you run. Passwords were known to be leaked earlier.
- sitkack 13y agoNew PRIVATE KEY, then new certs with that key.
- just2n 13y agoReally it means (as everyone assumed in the first place) that anything a web server might have in its heap needs to be totally thrown away. Private keys. Passwords. Credit card numbers. Security questions/answers. Sessions. Anything you'd send to a web server or receive from a web server is presumed compromised.
- Asparagirl 13y agoSeen on Twitter a few days ago: "Heartbleed is the Red Wedding of the Internet". Thought it hyperbolic at the time, but not any more...
- d0ne 13y agoWe have reached out via twitter to this invidiual as to coordinate the delivery of the $10,000 bounty we offered. If anyone is already in contact with them please direct them to https://news.ycombinator.com/item?id=7572530 https://news.ycombinator.com/item?id=7572530
- danielweber 13y agoSomehow I totally missed your bounty offer. Not that I was going to win if I had seen it, but where was it mentioned?
- nolok 13y ago(at least) in a comment near the top in the hn annoncement thread for the challenge
- nodesocket 13y agoLove to see a post on how it was done and the tools he used.
- danielweber 13y agoSame here. I was trying other ways in instead of Heartbleed, and made no progress. On the positive side, I wasn't expecting Cloudflare to be vulnerable to a timing attack anyway. EDIT He won't reveal it for a week. Good on him. https://twitter.com/indutny/status/454790640078176256 https://twitter.com/indutny/status/454790640078176256
- wrs 13y agoWell, so much for wishful thinking.
- djjaxe 13y agoHow could this security hole be any worse? Passwords, Credit Cards, Personal Information, Private SSL Certificates!??? And without anyone knowing at all. This is just crazy. Bravo to indutny for pulling it off in 3 hours.
- danielpal 13y agoThe important thing to know here is that you not only have to change your current certs you ALSO HAVE TO REVOKE THE OLD ONE. If you only change your current cert to get a new key but you don't go through the revocation process of the old certificate if someone managed to get the old one they can still use it for a MiTM attack - as both certs would be valid to any client.
- gojomo 13y agoAlso, cert revocation just barely works, in some browsers, with EV certificates, after old CRLs expire over a course of months: http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html http://news.netcraft.com/archives/2013/05/13/how-certificate...
- pixl97 13y agoTime for every browser to change that behavior.
- btown 13y agoIs there a tutorial (for multiple browsers/platforms) for browser users to manually initiate downloading and processing of the latest CRL? Is this even exposed by most modern browsers, i.e. as part of the "clear cache" functionality? If so, I'd want to tell my [self/family/friends/coworkers] to do this in the coming weeks to minimize the amount of time they might happen to send private information to a MITM attacking, say, an e-commerce site. Specifically, I'd be most interested for such a walkthrough for Google Chrome on OS X, which most people I know use.
- gsnedders 13y agoChrome doesn't check revocations by default. See "Check for server certificate revocation" in settings, which has for a while been disabled by default.
- nodesocket 13y agoWith GoDady, when you rekey, it automatically revokes the old cert after 72 hours.
- ademarre 13y agohttps://twitter.com/eastdakota/status/454792635279220737 https://twitter.com/eastdakota/status/454792635279220737 Pic of the CloudFlare team reviewing the attack. Ten guys crowded around one monitor.
- fletchowns 13y agoHah! That's awesome. Gotta love the Sierra Nevada on the desk too :) edit: now why in the world is my comment being downvoted?
- dfc 13y agoUsual Suspects: Someone fat fingered an upvote or HN is not always enthusiastic about "Me too!/That's awesome!" no-op comments. Backup Suspect: Teetotaler/Brogrammer-hater. Doesn't like beer on the desk at work.
- rubiquity 13y agoBecause HN readers only drink Pliny the Elder and mentioning any other beer is down vote criteria.
- bbq 13y agoWish I could see what's on the monitor!
- pinaceae 13y agoto be that guy: that's a bunch of kids. goes to show that we're far from being a mature industry when critical pieces of internet infrastructure are being run by bright, but inexperienced people. and of course they're inexperienced, no one really is, the whole thing is in its infancy. but imagine this being "the team" in charge of mission critical stuff on a 777. experience cannot be gained through shortcuts or pure intelligence. case in point, this very situation.
- nilved 13y agoSay no to age discrimination.
- tomkwok 13y ago* From https://www.cloudflarechallenge.com/heartbleed https://www.cloudflarechallenge.com/heartbleed * So far, two people have independently solved the Heartbleed Challenge. The first was submitted at 4:22:01PST by Fedor Indutny (@indutny). He sent at least 2.5 million requests over the span of the challenge, this was approximately 30% of all the requests we saw. The second was submitted at 5:12:19PST by Illkka Mattila using around 100 thousand requests. We confirmed that both of these individuals have the private key and that it was obtained through Heartbleed exploits. We rebooted the server at 3:08PST, which may have contributed to the key being available in memory, but we can’t be certain.
- tomkwok 13y agoMore details added on the page: "... by Illkka Mattila [of NCSC-FI] ..." (The National Cyber Security Centre Finland).
- danielweber 13y agoI wonder if the trick is to just send so many things that memory wraps around to a place where the key is exposed.
- chadillac 13y agoThat was my plan of attack, I left my machine at home sniffing, wonder if I caught it. Had bleed running in a while loop with no sleep and ab running on a loop as well sending connections to the server hoping to get the mem jostled around enough to cause something like that you described. I was unsuccessful as of 9:30AM... now I'm really curious to get home and see if I actually caught it... even though I already missed the $10k boat :(
- jneal 13y agoI probably hit the server only a thousand times thinking that could be enough, I was far off.
- specto 13y agoConsidering he just pulled a shadow file as well, it's not pretty.
- danielweber 13y agoI think someone else found that, although he linked to their pic. Remember, lots of people are pushing up bogus stuff into the heap, so just because you see something there doesn't mean Cloudflare leaked it.
- alexkus 13y agoAnd who runs their webserver as root? (Or who changes the permissions on /etc/shadow to allow it be read by a non-root process). Having to be root to be able to bind to a TCP port <1024 is no longer necessary on a modern OS.
- capcah 13y agoI am not sure how those guys did it, but I was talking to a friend of mine today, and I guess that it had something to do with forcing the server to use its private key to check for information sent to it. Then you use the heartbleed bug to intercept the intermediate forms on the information you sent to be decrypted/authenticated. Since you know the plaintext, the ciphertext and the intermediate forms, it should be possible to recover the key. As I said, I am not sure that is right or if that was the method used to exploit cloudflare, as I didn't had the time nor the knowledge of openssl implementation to test it out, I am just throwing my guess out there before the official exploit comes about. edit: formatting
- StavrosK 13y agoYou can't recover keys with known plaintext attacks in most encryption algorithms used nowadays, plus, as far as I know, they don't even use the private key to encrypt your request. They only use it for a DH handshake, which establishes the session key you are going to use.
- diakritikal 13y agoHubris is ugly.
- guelo 13y ago"We rebooted the server at 3:08PST, which may have contributed to the key being available in memory, but we can’t be certain.". https://www.cloudflarechallenge.com/heartbleed https://www.cloudflarechallenge.com/heartbleed That doesn't make sense to me, seems like the key needs to be in memory all the time, or at least during every session.
- kentonv 13y agoYes, but if you read the original article [1], they discuss the fact that on Apache servers it is much easier to bleed the key if you manage to make the first request to a newly-started server, because Apache moves the key through some temporary structures early on that then get freed, and after a few requests the freed memory is overwritten. I think they're speculating that a similar thing might occur in nginx. [1] https://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed https://blog.cloudflare.com/answering-the-critical-question-...
- zuado 13y agoIt seems that someone is doing some requests with RSA keys as a parameter. It doesn't make sense at all to me doing such request in order to get the server private key. Anyone seeing the same?
- aboodman 13y agoIt probably took longer to compose that blog post than it took @indutny to disprove it.
- zuado 13y agoIt seems that someone is doing some requests with RSA keys as a parameter. It doesn't make sense at all to me doing such request in order to get the server private key. Anyone seeing the same?
- tszming 13y agoSo @indutny sent at least 2.5 million requests, should we start to think more on the practical prevention techniques?
- pixl97 13y agoA different person achieved retrieving the key in 100,000 requests, which is well within a practical and cheap botnet attack. The next question is how much of the key did they receive in the requests that revealed the key. If it was most or all of the key, a single attack node could query 100,000 different servers with the high probability of retrieving a key at least once with a low probability of being blocked by any of the servers. TL:DR, patch OpenSSL and revoke and rekey all your certs.
- yp_maplist 13y agoIMO, CloudFlare is lame. Kudos to this guy for reminding me just how much so.
- nikcub 13y agoReading Cloudflare's blog post[0], they keep referring to the exploit having a length of 65,536 bytes, and how an allocation of that size is unlikely to find itself lower in the heap. That is true - but this exploit doesn't depend on setting a length of 65,536. The server takes whatever length the client gives it (which is, afterall, the bug). Most of the early exploits just happen to set the maximum packet size to get as much data out (not realizing the nuances of heap allocation). You can set a length of 8bytes or 16bytes and get allocated in a very different part of the heap. The metasploit module for this exploit[1] supports varied lengths. Beating this challenge could have been as simple as running it with short lengths repeatably and re-assembling the different parts of the key as you find it. edit something that I want to sneak in here since I missed the other threads. Cloudflare keep talking about how they had the bug 12 days early. Security companies and vendors have worked together to fix bugs in private for years, but this is the first time i've ever seen a company brag about it or put a marketing spin on it. It isn't good - one simple reason why: other security companies will now have to compete with that, which forces companies not to co-operate on bugs (we had the bug 16 days early, no we had the bug 18 days early!, etc.). As users you want vendors and security companies co-operating, not competing at that phase. [0] Cloudflare - Can You Get Private SSL Keys Using Heartbleed? http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed http://blog.cloudflare.com/answering-the-critical-question-c... [1] see https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb#L130-L149 https://github.com/rapid7/metasploit-framework/blob/master/m...
- dpweb 13y agoHow do you know when you've found a piece of a key?
- nikcub 13y agostore everything, reconstruct it all later by trying to work out which part of the heap each request is from. there is likely some sort of efficiency calculus you can do here (i'm not good at math so I have no idea what i'm talking about) where you could calculate for heap size x and probabilities y and z etc. just how many requests and what size they should be to cover the entire process heap. edit: OpenSSL wraps malloc, so it is different on different systems. You could find out what the probabilities are by looking at the source. For some reason FreeBSD's malloc gave up private keys with the default exploit length and not much effort. It was only a matter of time before other platforms were also figured out. Note that the FreeBSD exploit worked on a fresh server after boot, which might have also been the case here. Note that in the heap there are the intermediate values that and are used when constructing the connection and doing the encryption, you aren't exactly looking for '------BEGIN PRIVATE KEY------' or base64 string, you'd be looking for those - each which have a unique data type.
- bitsteak 13y agoWhy did anyone need this challenge in the first place? Couldn't someone have justed ASKED a good exploit developer what they would do and what the impact is? No, I guess we're all up for wasting people's time and creating potential false negatives.
- maccard 13y agoBecause good idea in theory != good idea in practice. Showing that this actually works in practice (albeit on an isolated incident) shows that the bug is dangerous in practice, not just theory. Look at all the research in timing attacks etc on TLS, some of which are theoretically feasible, until you consider real world possibilities of remote servers, such as "Their ISP is fiddling with routing so I have varying latency", or "They're using different server configurations and I don't get connected to the same one every time". This has been PROVEN to steal someones private key, which is worse than giving someone the keys to your house, It's like giving them a blank passport with your name on it, letting them put their photo on it, and with that taking your car keys and hosue keys, and everything that identifies you. Luckily, the fix is easy, just upgrade, revoke, and force password changes for everyone.
- brokenparser 13y agoYeah, I bet that fix is real easy.
- mvshop9111 13y agohttp://trachanhquan.com.vn/ http://trachanhquan.com.vn/ TRÀ CHANH QUÁN là mạng xã hội – Game online theo lượt dành cho các bạn Teen trên nền điện thoại di động và Smart Phone. nơi chia sẻ cảm xúc, chat chit, video, đăng ảnh, viết tường, chơi game,… game đã nhanh chóng thu hút được hàng triệu lượt bạn trẻ tham gia trên khắp mọi miền đất nước. Ngoài chức năng giống như một mạng xã hội tra chanh quan còn là 1 địa điểm vui chơi giải trí của các bạn trẻ, Thỏa thích chơi các Game Bài cùng bạn bè: Liêng, Phỏm, Tiến lên miền Nam, 3 cây, Tiến lên miền Bắc, 3 cây gà, poker, xito…
- alexkus 13y agoDidn't have any spare time to have a go at this, here's how I was going to do it:- 1) Create a VM with the same version of Linux, nginx, openssl. 2) Create a self-signed SSL certificate for the server 3) Verify that the HTTPS server is vulnerable to heartbleed 4) Run a few HTTPS requests against the server 5) Use gcore (or just send SIGABRT) to get a core file of the nginx process 6) Write a tool to check the memory image for remnants of the private key (since I know what it looks like). This may be encoded in several forms: as is from the ssl key file, hex encoded modulus, binary encoded modulus, however the BigNum stuff in OpenSSL stores the modulus, intermediate values used in calculations, etc. I can also check for partial matches since I know what the full key looks like. 7) Run the heartbleed client against the site to extract some chunks of memory, there are various strategies for this:- a) Repeatedly grab the largest (65535) bytes of memory each time b) Repeatedly grab different sizes (8KB, 16KB, etc) depending on the bucket sizes for OpenSSL's freelist wrapper around malloc. c) Vary the request size (lots more headers, etc) to try and get different chunks of memory returned. d) Occasionally restart nginx 8) Once I can reliably (for whatever value of reliably that is) get the key from my own server, I then modify the test for success from a comparison against the known private key, to a test which involves decrypting a string that was the result of encrypting some known plaintext with the known public key. That'll be slower, but still possible. 9) Run that analysis against real data retreived from the challenge server. The data (using the various strategies in #7) can be obtained in the background whilst I'm developing #1-#8. You can't rely on having sole access to the server so whatever strategy you use may be perturbed by other people performing requests. 10) Repeat #1-#8 for Apache and any other web server that is vulnerable to heartbleed. This does work on the assumption that the key (in whatever form it is in) will be returned as a contiguous block of memory. Trying to patch together chunks of memory to look for the key will be much much harder unless there's significant overlap and it's easy to detect what/where a key is somehow.
- benmmurphy 13y agoi think cloudfare's version of nginx is a lucky version or my code is bugged or time after restart is important or you need to do some heap-fu by sending different payload sizes. so i booted up a micro vm on amazon aws and was able to dump the private key in one request. Ubuntu Server 13.10 (PV) - ami-35dbde5c sudo add-apt-repository ppa:nginx/development sudo apt-get update sudo apt-get install nginx sudo apt-get install ssl-cert modify /etc/nginx/sites-enabled/default uncomment ssl server and change certs: ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; sudo /etc/init.d/nginx restart curl -O https://gist.githubusercontent.com/benmmurphy/12999c91a4d328b749e3/raw/9bcd402e3d9beec740a61a1585e24c36dea80859/heartbeat.py chmod u+x heartbeat.py ubuntu@ip-10-185-20-243:~$ ./heartbeat.py localhost /etc/ssl/certs/ssl-cert-snakeoil.pem Using modulus: C30FB990C6C1EE4EE4524A724BDF10DCDC735C9BCCED84B38796584DCE9F7CB1027CCF63A0E604882AE9B8639CD0955C207BE641943AE38AC4DAE63ECCE7E79ACE7EB9EB5D92F55761924C35A00EB5AE4759CB6DC938DBD48ED34685BC32B3193FEF55F081BB2BFC33494F26E556803FD2506F94301DFD688A63F9F3572C540F3F5E7679D5454E532503636ABFCB95AC5674D47C2B23C4418E04BE1D36AECF6BFEA81FC38FCA3E72A3EACD0BFD4E07FDC3BFA8E70E002ECA68FE8E0621F56081D90A3724A1BED6B5E3BDCDCC02B4EDEAFD0EC4D60C7DEC95BF7756CD82442915EE1AB6738F38B3BA932C8D27B34E94205C84AB64ACC34487ED2FF3804332AB63 Using key size: 128 Scanning localhost on port 443 Connecting... Sending Client Hello... Waiting for Server Hello... Got length: 66 ... received message: type = 22, ver = 0302, length = 66 Message Type is 0x02 Got length: 750 ... received message: type = 22, ver = 0302, length = 750 Message Type is 0x0B Got length: 331 ... received message: type = 22, ver = 0302, length = 331 Message Type is 0x0C Got length: 4 ... received message: type = 22, ver = 0302, length = 4 Message Type is 0x0E Server sent server hello done Server TLS version was 1.2 Sending heartbeat request... Got length: 16384 ... received message: type = 24, ver = 0302, length = 65551 Received heartbeat response: Got result: 154948185083822336433702373602285084550034029190596792283600073258494868382158852796844241764405565518400264295279959791461705192749666707538790201985451035410116800023040704455951541838840288378897688943017357577574672157589664822948047455855119173651635078033464041188274590174256703712210173285385390714209 found prime: 0xdca74e63a186d60a9de3c8211e21a5b165c6d86d285c1d6eece2ad7a2505890ebae513e3013c3602f148e2112eaa99edd8ff5922494c4db47156727f93ab0f35a298553a82dfbd91e5e8aff2e969f31db31263bce9a89d95b64ff38ff5b86d47fa2e70aac5198d2ea967eb952f48b7264e824bd03b1c955294fb9caeed02ed61L you can check the prime by doing: ubuntu@ip-10-185-20-243:~$ sudo openssl rsa -in /etc/ssl/private/ssl-cert-snakeoil.key -text .. prime1: 00:e2:4e:eb:f7:88:3a:d4:ad:61:2c:ef:6f:b2:a6: 3b:dd:c4:99:89:f1:b4:6e:6b:ce:76:51:c3:23:f7: 7a:37:69:f9:6c:eb:65:3d:cd:6a:f7:c9:97:96:b0: f6:39:72:8a:ca:f7:45:3c:ff:25:b0:dd:a9:c1:08: c3:aa:53:41:22:20:df:74:cb:1d:ad:ce:67:1d:11: 00:15:33:65:1f:d4:b9:a8:2b:27:50:da:7c:a7:e1: 88:d1:2c:d8:d9:32:07:ba:23:e1:40:fa:fa:94:46: 7f:9b:35:a1:d2:e4:91:86:f6:f3:79:2f:53:fd:95: 4d:99:56:b3:c0:be:97:6b:43 prime2: 00:dc:a7:4e:63:a1:86:d6:0a:9d:e3:c8:21:1e:21: a5:b1:65:c6:d8:6d:28:5c:1d:6e:ec:e2:ad:7a:25: 05:89:0e:ba:e5:13:e3:01:3c:36:02:f1:48:e2:11: 2e:aa:99:ed:d8:ff:59:22:49:4c:4d:b4:71:56:72: 7f:93:ab:0f:35:a2:98:55:3a:82:df:bd:91:e5:e8: af:f2:e9:69:f3:1d:b3:12:63:bc:e9:a8:9d:95:b6: 4f:f3:8f:f5:b8:6d:47:fa:2e:70:aa:c5:19:8d:2e: a9:67:eb:95:2f:48:b7:26:4e:82:4b:d0:3b:1c:95: 52:94:fb:9c:ae:ed:02:ed:61 .. so the exploit is the most stupid one possible. i took the POC code and changed it to read all 64k. The version i had was reading only 14kb from the server. Then just check all the 128 byte strings to see if they divide the modulus evenly.
- ig1 13y agoSo I didn't manage to crack the challenge (I used around 10k heartbeats), but I suspect it may have just been a case of brute-force (i.e asking for enough heartbleeds). Other people may have got the key without realizing that had done so because they were looking for the wrong thing (i.e. normal cert text representation). I took the approach of using two fingerprints to search the data: 1) The hex sequence "30 82 .. .. 02 01 00" which would indicate the ASN.1 private key encoding which OpenSSL uses. 2) The modulus which I extracted from the public key (which would also be in the private key structure) I didn't find any instance of the first, the second I found lots of instances of (because the modulus is also in the public key). I then filtered out all the instances of the public key by searching for the public key header ("30 82 .. .. 30 82"). This actually left me with two unique instances of the modulus in memory which weren't in a public key structure. I then tried to overlay the private key structure over the data and extracted what should have been the prime numbers and ran a primality test on them (to verify; another way would have been to just feed the structure into openssl). Both failed, so it wasn't the private key structure. But there's a reasonable chance that those two instances represented a cryptographic calculation in progress; so while recovering the key wouldn't be as trivial as if you grabbed the full private key structure from memory (which I suspect is what the successful attackers did) I think it definitely represents another attack angle.
- carmaa 13y agoThat's the way to do it - you can also use the tool interrogate: https://github.com/carmaa/interrogate https://github.com/carmaa/interrogate /shameless plug
- dogsky 13y agoI was unable to replicate. Can someone give more details, maybe the heartbleed script updated and some instructions to replicate it? Thanks.
- athoik 13y agoAn error occurred during a connection to www.cloudflarechallenge.com. Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate) Game over...
- deleted 13y ago[deleted]
- mvshop9111 13y agohttp://iwin270.com/ http://iwin270.com/ Nhửng thay đổi trong lần cập nhât phiên bản này - Cập nhật game Liêng . - Fix lỗi lag ở game Xì Tố - Cập nhật các tính năng rung , tính năng mời bạn qua facebook . - Hỗ trợ tối đa các dòng điện thoại Java ( J2ME ) - Các tình trạng lag , disconnect được khắc phục phần lớn . - Chặn các nick auto treo tài khoản . - Và còn rất nhiều tính năng mới đang đợi bạn khám phá
- mvshop9111 13y agoiWin sau gần 4 năm phát triển đã cho rất nhiều phiên bản để đem lại lợi ích tốt nhất cho người dùng . trong tháng 10 – 2013 này iWin đã ra cho ra đời phiên bản iwin 280. dành cho hệ điều hành J2ME, hay còn gọi là Java. cập nhật thêm Game Tiến Lên Miền Nam Solo game dành cho 2 người. Nâng tổng số trò chơi trong iwin lên 17 trò, với chức năng solo giúp cho cuộc chơi thêm gây cấn và mang đậm dấu ấn cá nhân. Bạn có thể mời bạn mình cùng chơi với tính năng mời bạn cùng chơi của iWin nhé. http://iwin280.com/ http://iwin280.com/