On 04/10/14 21:41, Cristian Rodríguez wrote:

Also banks are not known for staying on top of technology, in fact quite the opposite, they are in an state of fossilization..I doubt many run reasonable updated openSSL versions that contain the vulnerability.

That banks don't run distributions with not-yet-settled technology is one thing. With customer-facing IT, they shall not be on top of technology. They shall be conservative and use proven technology that has settled. To call that fossilization is ridiculous. (Internally, that's completely different thing. I know quite some banks that have their own patched kernels, especially when HFT is involved.) That banks don't patch their systems and don't update critical security infrastructure is far from the truth. Responsible persons in IT wouldn't survive the next internal audit. Patch processes and documentation are regular and mandatory items on audit check lists. BEAST and other vulnerabilities have triggered updates of OpenSSL-based products and have introduced respective versions that are now vulnerable against heartbleed. If one is lucky, F5s were used as load balancers; they are not vulnerable. As somebody who spent the last few days to help several banks to mitigate that problem, I can assure you: banks are not in a state of fossilization, they run reasonable updated openSSL versions, (sadly) most of them were vulnerable, and checking/patching the problem was a high-priority C-level-attention thing for all of them. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 11/04/2014 10:46, Per Jessen a écrit :

Fortunately, my e-banking password is never transmitted over the net.

how can this be for an "e" account? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 11/04/2014 11:27, Per Jessen a écrit :

With some other sites, I use a one-time-pad, i.e. a list of pre-generated code-sequences. Unbreakable.

yes, I see this more and more (with number table that changes each time). Seemes good, but I don't know for sure thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-04-11 14:23, Per Jessen wrote:

jdd wrote:

I first heard of the challenge-response idea back in the 90s - it was already in use with several German on-line banking systems (maybe it was standard in the HBCI specification). I think my bank has been using their current setup it for 10 years or more. I'm on my third card-reader.

I've never seen it here (Spain), at least for "consumers". I have used it inside companies, to access the network by employees. The one I'm thinking of they also had antitempest windows, and WiFi was strictly forbidden (it is dismantled on the warehouse, to the dismay of the operators using the handled gadgetry they typically use on the store room or warehouses. I've seen one important bank using a table of codes for a challenge-response system, which is used only for "operations". However, the table is card that might be used for many years, not a one use thing. For accessing your bank data it uses a simple login/pin code (and not a long pin). Another important bank uses a login/pass to access, then a challenge-response method for operations, but instead of a long table of codes, it is just a an 8 char code of which they ask you, say, to type digits 5 and 7. Again, not a one use thing. I think they also use a verification code sent over SMS to your mobile phone, but I don't recall which one does. It may be a volunteer choice. A thing I have also noticed is that they ask you to enter pin codes not on the keyboard, but by clicking with the mouse on a keyboard on the screen. This might be to foul dongles inserted on the keyboard cable. Last time I noticed that the position of the virtual keys was random on one site. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

...

Assuming you are running a server serving encrypted data via openSSL:

meaning e.g. apache, openvpn, sshd, postfix (and exim et al), dovecot etc.

Not sshd from what I understand. And apache, only if you have https setup, right? I've forgotten where security certificates live with ssh. Public key on the server and private on my personal workstation, right? I have a email server running on one box. Can the vulnerability have been used to get the sshd private keys? I'm thinking the private ssh keys would have never been in the memory space of the email server, so they are safe? On the other hand, the pop/imap passwords could have been gotten and for users that have a re-used password they could have been used it to ssh straight into the box for any users not using a security certificate to authenticate. In that case all docs/data available to the user was potentially breached. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-04-11 16:41, Per Jessen wrote:

Wild guessing - if you have TSL enabled in your mail-server, I guess the vulnerability could have been used to extract data from it, but if your private key was never on that system ...

I know little of how the vulnerability works, but apparently they trick the machine (client? server? both?) to freely send a copy of 64 KB of RAM, which may contain anything. I don't clearly know if they can walk all memory, or just memory from the process that responds, or the memory assigned to the user of that process, or just one 64 KB block, where a particular buffer should have been assigned, but was not really assigned (ie, a non initialized pointer?). Or the block was assigned but not erased previous to been used. That RAM they get might contain data obtained from a different computer, so that the keys are on another computer, that's irrelevant. As long as the keys were retrieved and read on memory at some time, and they can read that memory block... And the vulnerability can be used even without accreditation for that server. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-04-11 21:42, Andrey Borzenkov wrote:

В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:

...

I know little of how the vulnerability works,

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Thanks. I love this paragraph: +++···················· Lessons What can we learn from this? I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++- My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us... I'm not a fan of C. But I have been paid to use it, so I used it.

It can read up to 64K starting from the memory location where incoming packet (which is being processed) is allocated. This is local memory belonging to process. There is no way to control *what* is read nor control memory location that is read; one can only make some guesses based on knowledge of a program being attacked and its allocation patterns. Good metaphor from another site: "but it's not [targeted attack]. It's more like panning for gold than robbing a bank.".

I see. So maybe they get nothing... Impossible for us to know what they got, I guess. So we have to assume the worst, to be safe... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Fri, Apr 11, 2014 at 5:23 PM, Cristian Rodríguez wrote:

El 11/04/14 17:30, Carlos E. R. escribió:

...

On 2014-04-11 21:42, Andrey Borzenkov wrote:

...

В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:

...

...

I know little of how the vulnerability works,

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Thanks.

I love this paragraph:

+++···················· Lessons

What can we learn from this?

I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before.

...

I'm not a fan of C. But I have been paid to use it, so I used it.

This suggestion frequently comes up.. particulary from people that suggest implementing this stuff in C++ .. what will happen if that were the case ? the library in question will be disfavoured or not considered for widespread use. Only projects with an existing C++ codebases such as KDE or libreoffice will take advantage of it.

I'd suggest that this would be the case only if badly done. If I were asked (and paid) to undertake such a task, one of the requirements I'd impose is that while the guts of the thing is implemented in C++, there'd be a suite of C functions that provide the interface for the DLL. While I have worked on projects that used libraries written in C in products mostly written in C++, it can be done the other way around; but it ain't easy. I know, and like, both C and C++, but I am not masochistic enough to undertake such a task if I didn't have to (or unless someone was willing to pay me enough over a few years to let me buy, and retire to, a mansion in Victoria BC ;-) And, it is harder than much more effective options that are available. On the other hand, I'd argue that there is nothing wrong with continuing on with the product being written in C. What I'd recommend, instead, is that, if the manpower can be found, beef up the unit and integration tests, and more aggressively perform security audits on the code. While I would not ask a junior programmer to do so, it is not especially hard for someone with more than a few years experience to write secure C code; as long as proper design documentation is maintained. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. wrote:

On 2014-04-11 21:42, Andrey Borzenkov wrote:

...

В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:

...

...

I know little of how the vulnerability works,

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Thanks.

I love this paragraph:

+++···················· Lessons

What can we learn from this?

I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++-

My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us...

I'm not a fan of C. But I have been paid to use it, so I used it.

Having seen, and used, a number of languages in the algol family (FORTRAN,Pascal, BASIC, C/C++/C#, Java, Perl, PHP, &c.), I became aware of the strengths and weaknesses of each early on. It seems to me to be silly to be afraid of any of the languages, but rather of the people who use and abuse them. There are incredibly powerful languages, like C++ and Perl, and then others that begin with the good languages, as it were, and dumb them down (Java, C#, PHP) so more junior and intermediate programmers can be more productive and less dangerous. But, in dumbing dow a language, things one can do in the more powerful languages that some deem too dangerous are simply prohibited (because a language feature it depends on is excluded). Look at what MS did with their 'Managed C++', and their suite of .NET libraries and languages. I have seen some old pros say that you have the dumbed down languages that limit what you can do, and basically protect you from yourself, and then languages like C++ that give you lots of power, along with the ability to shoot yourself in the foot, and then there is Perl, which gives you the power to blow your whole (expletive deleted) leg off. I suppose my favorite languages are C++ (for my number crunching) and perl (for my distributed, secure, programming). One can make business cases for all of the available languages in specific situations. It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on. In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime. His first two recommendations, generally, is the more useful. He also said we ought to: 1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing. As for his third recommendation, it can be argued that there are no truly safe languages that are useful (although, if someone were to pay me to do so, I might consider ADA, to see if it is both genuinely useful and as safe as I have heard it is), and that one must rely on the expertise of those using whatever language has been selected for the work. My final thought is that nothing is perfect, nor is it reasonable to expect perfection from beings as flawed as are human beings. All we can do is our best, and be diligent in acting appropriately when a flaw is detected. Cheers, Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 11, 2014 at 6:31 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-04-11 23:27, Ted Byers wrote:

...

On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. <> wrote:

...

...

It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on.

I agree.

...

In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime.

IMHO, C should be left to professionals and experienced programmers.

:-)

Yes, but there must be a way to develop the kids into seasoned old pros. ;-) Thus, I would teach the kids C and C++, but when it comes to developing production code, they do so only working closely with several intermediate programmers and very closely supervised by senior programmers. And, of course, nothing makes it into the code base without both unit tests and detailed code reviews. But the latter must be done with the intermediate and junior programmers, so that they can better learn what coding practices are risky, and, if needed, how the risks are to be mitigated. Personally, the educator in me, would accompany that exercise with contrived exercises that the junior programmers would have to work on with the intermediate programmers, so that they can see, in sample programs, why some practices are risky. That is, they would have to write several programs, one which includes the risky practice that was identified in the code they just had reviewed, and then write several programs to attack it, so they can see, experimentally, hands on, the nature of the vulnerability they almost created, how to exploit it, and how to write the code in the most secure manner possible. Alas, I doubt there are very many software houses that would support such continuing education of their software development staff. :-(

...

His first two recommendations, generally, is the more useful.

He also said we ought to:

1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages

One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing.

I agree, too.

It is good to learn that there is at least one person I agree with. ;-) Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 11, 2014 at 9:13 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-04-12 01:02, Ted Byers wrote:

...

On Fri, Apr 11, 2014 at 6:31 PM, Carlos E. R. <> wrote:

...

...

had reviewed, and then write several programs to attack it, so they can see, experimentally, hands on, the nature of the vulnerability they almost created, how to exploit it, and how to write the code in the most secure manner possible.

Alas, I doubt there are very many software houses that would support such continuing education of their software development staff. :-(

I would probably fail that testing myself. :-}

Ah, you misunderstand. This testing isn't so much an evaluation of what the kids know, but rather they'd be testing their own experimental programs, with a view to encouraging them to learn as much as possible about secure programming; as always working closely with intermediate and senior programmers. While early on, security wasn't an issue for the applications I developed, it has been a primary focus for quite a few years now, especially because of the sensitivity of the data and the distributed nature of the programs. At the transport layer, we relied on openssl, and mostly assumed it did what it was supposed to do, and we focussed our security related tasks to the application layer. It actually isn't so hard, especially with the ability to use perl's taint mode, and to use regular expressions to verify that the data is valid (of course, we do that validation both on the client and server, so typos are caught early and the experience is quite user friendly).

There was no multitasking when I trained, and it was never a consideration when I was paid for programing. I never had to care about intruders or any kind of attacks. Security, for me, was ensuring that motors would stop when requested, and such... Buffers having the correct size, properly initialized, inside bounds, etc, of course. Accidents, not hackers, were my consideration.

When I was working on applications that resided only on the usr's workstation, the same was much the same for me, though at that time, I primarily used C++.

So no, I probably could not code current day security stuff. :-}

But you could learn it quickly, as it is not all that hard, unless you're actually contributing source code to the openssl project. ;-) Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 2014-04-11 at 20:01 +0200, Carlos E. R. wrote:

On 2014-04-11 16:41, Per Jessen wrote:

...

Wild guessing - if you have TSL enabled in your mail-server, I guess the vulnerability could have been used to extract data from it, but if your private key was never on that system ...

I know little of how the vulnerability works, but apparently they trick the machine (client? server? both?) to freely send a copy of 64 KB of RAM, which may contain anything. I don't clearly know if they can walk all memory, or just memory from the process that responds, or the memory assigned to the user of that process, or just one 64 KB block, where a particular buffer should have been assigned, but was not really assigned (ie, a non initialized pointer?). Or the block was assigned but not erased previous to been used.

regarding TLS-secured daemons, it might be a big step get store all of those private keys into a HSM. All crypting/decrypting is done by the crypto-engine: off-line, so the private-key is never in the servers-mem -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" wrote:

...

Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch

It's not easy:

Try this: http://filippo.io/Heartbleed/ There is also a command-line version. -- Per Jessen, Zürich (16.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 11, 2014 8:25:31 AM EDT, Per Jessen wrote:

Greg Freemyer wrote:

...

On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" wrote:

...

Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch

It's not easy:

Try this: http://filippo.io/Heartbleed/

There is also a command-line version.

You answered a different question. E.g. You answered "how can I tell if I am currently vulnerable?" I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?" I tried to answer the second question. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 11, 2014 9:12:29 AM EDT, "Vojtěch Zeisek" wrote:

Dne Pá 11. dubna 2014 09:04:42, Greg Freemyer napsal(a):

...

On April 11, 2014 8:25:31 AM EDT, Per Jessen wrote:

...

Greg Freemyer wrote:

...

On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek"

wrote:

...

Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch

It's not easy: Try this: http://filippo.io/Heartbleed/

There is also a command-line version.

You answered a different question.

E.g.

You answered "how can I tell if I am currently vulnerable?"

I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?"

Yes, thank You. As I expected, there is no easy way how to find out if my server was attacked or not... I use denyhosts and fail2ban to block attackers randomly trying random combinations of username and password...

Since each bite at the able only got a small amount of random ram, that may have been the best secondary defense for this. To get around that a bad guy would have had to of used a botnet to hit you from 1000's of unique IPs. That is hard to coordinate, but certainly not impossible. Hopefully there weren't a huge number of botnets up and running the last couple of years attacking computers via this vulnerability. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek wrote:

Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.?

Between the announcement of the vulnerability and the roll-out of the patches, absolutely. Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out. To assume you weren't hit in the 2 or 3 days between the announcement of the problem and the roll-out of the patch is a leap of faith for sure. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/11/2014 06:52 AM, Greg Freemyer wrote:

...

Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.? Between the announcement of the vulnerability and the roll-out of the

On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek wrote: patches, absolutely.

Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out.

Did you find references for actual in-the-wild exploitation, Greg? I found some references to testing scenarios, but not actual data exfiltrations. This link from EFF thinks the only confirmed exploit kind of smells like an intelligence agency: https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-... http://tinyurl.com/lzez3sm Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/11/2014 7:15 PM, Greg Freemyer wrote:

On April 11, 2014 10:37:26 AM EDT, Lew Wolfgang wrote:

...

On 04/11/2014 06:52 AM, Greg Freemyer wrote:

...

...

Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.? Between the announcement of the vulnerability and the roll-out of the

On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek wrote: patches, absolutely.

Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out. Did you find references for actual in-the-wild exploitation, Greg? I found some references to testing scenarios, but not actual data exfiltrations.

This link from EFF thinks the only confirmed exploit kind of smells like an intelligence agency:

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-...

http://tinyurl.com/lzez3sm

Regards, Lew From: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-be...

"Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart."

So this was either cyber criminals or the NSA. I'll assume it was cyber criminals, but who knows.

Regardless, someone was scanning for the vulnerability 5 months ago. And this is not a complex vulnerability to leverage, once you find a vulnerable server, just keep sending authentication requests with invalid credentials. Using a spread out botnet defeats fail2ban style defenses.

My personal opinion is the world's governments should treat this as a global catastrophe and pay to have every credit card on the planet reissued at a minimum.

Greg

Your assertion that this is not a complex vulnerability to leverage may need some proof. People who have tried to leverage it have not been very successful. See http://blog.cloudflare.com/answering-the-critical-question-can-you-get-priva... You might get something, but deliberate attempts to do so are harder than you seem to think. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 12, 2014 1:00:37 AM EDT, John M Andersen wrote:

On 4/11/2014 7:15 PM, Greg Freemyer wrote:

...

...

Lew From: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-be...

"Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart."

So this was either cyber criminals or the NSA. I'll assume it was cyber criminals, but who knows.

Regardless, someone was scanning for the vulnerability 5 months ago. And this is not a complex vulnerability to leverage, once you find a vulnerable server, just keep sending authentication requests with invalid credentials. Using a spread out botnet defeats fail2ban style defenses.

My personal opinion is the world's governments should treat this as a global catastrophe and pay to have every credit card on the planet reissued at a minimum.

Greg

Your assertion that this is not a complex vulnerability to leverage may

need some proof. People who have tried to leverage it have not been very successful. See http://blog.cloudflare.com/answering-the-critical-question-can-you-get-priva...

You might get something, but deliberate attempts to do so are harder than you seem to think.

Did you see the note at the top of the article. They retract the whole thing because 2 independent testers got the ssl private key from their test site within 9 hours of the test starting. They now recommend everyone (on the planet?) revoke their private keys and get new ones re-issued. They say the heartbleed attack is like panning for gold. Most times you reach down a get some dirt, you get dirt, other times there is a nugget in there. In this case the logins/passwords/credit cards would be little bits of gold nugget, and a ssl private key would be decent size diamond. In the above test, one guy found the diamond (the ssl private key) after only 100,000 pans of dirt. The other took 2.5 million. With a 1,000 node botnet, that is only 2,500 pans of dirt each. For a cyber criminal, that is an almost trivial amount of work. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Apr 12, 2014 at 9:29 AM, jdd wrote:

Le 12/04/2014 14:24, Greg Freemyer a écrit :

...

For a cyber criminal, that is an almost trivial amount of work.

but on how many targets?

if somebody get my server's private key, he wont be rich...

jdd

If it's a self-generated key, you can re-create it in 10 or 15 minutes including doing the research of how to do it. If what you're protecting isn't worth a 15 minute investment, then I wouldn't bother with re-creating it. If it's one you paid for, then if it was worth buying, I assume it is worth revoking / re-issuing. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Apr 12, 2014 at 12:01 PM, jdd wrote:

Le 12/04/2014 17:52, Greg Freemyer a écrit :

...

If it's a self-generated key, you can re-create it in 10 or 15 minutes including doing the research of how to do it. If what you're protecting isn't worth a 15 minute investment, then I wouldn't bother with re-creating it.

yes, but I have to propagate it to the clients and verify it works,, that is reread the doc and understand it :-(

Am I missing something? Only SSL keys are in question to my understanding. SSL private keys are not propagated at all (unless you have a web farm / high availability cluster). SSL public keys are pushed by the protocol automatically. Nothing for you to do. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/12/2014 09:30 AM, jdd wrote:

Le 12/04/2014 18:20, Greg Freemyer a écrit :

...

SSL public keys are pushed by the protocol automatically. Nothing for you to do.

not for rsync backups

Doesn't rsync ride on the SSH protocol? SSH keys aren't affected by Heartbleed AFAIK. I guess you could use stunnel with rsync, but I think there might be other issues there. Regrds, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 12/04/2014 18:51, Lew Wolfgang a écrit :

Doesn't rsync ride on the SSH protocol?

yes SSH keys aren't

affected by Heartbleed AFAIK.

oh... it's ok then thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote:

On Sat, Apr 12, 2014 at 12:30 PM, jdd wrote:

...

Le 12/04/2014 18:20, Greg Freemyer a écrit :

...

SSL public keys are pushed by the protocol automatically. Nothing for you to do.

not for rsync backups

jdd

hmm...

I've only used rsync via ssh, so I have no insight as to how the openssl vulnerability impacts rsync.

I don't see any impact on rsync. With ssh, no impact, and rsyncd? does not use libssl. -- Per Jessen, Zürich (15.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org