security - Page 35

  • #heartbleed this is why this bug poses so many questions about the code of openssl

    The so-called "heartbleed" exploit is a buffer overrun. A read overrun, to be specific: the attacked system is induced into reading and sending back bytes from a buffer which is much shorter than the read length, thus reading whatever bytes reside in RAM past the buffer. Since the bytes are sent back to the peer, this gives a window to peek into the target system RAM.

    so just to make it sure that I wel understand

    it is a buffer overrun something that has been written about for ages and for which there are thousands of tools to detect them and to help to correct them

    and this kind of bug is in openssl for two years and nobody of opensll saw it ?

    makes you wonder if there are other things out there .......

  • #heartbleed find attacks against your infrastructure with SNORT

    For the technically adept, anyone (end user or site operator) running Snort or another IDS/IPS can look for indicators of realtime compromise in Snort rule form, as the attack can go both ways (your client can be attacked, too, if it's vulnerable). This doesn't tell you if someone else has attacked the website in the past, but it might tell you if someone's attacking you right now.


    • alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - SSLv3 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 00|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000000; rev:4;)

    • alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 01|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000001; rev:4;)

    • alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 02|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000002; rev:4;)

    • alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.2 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 03|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000003; rev:4;)

  • #heartbleed All these servers with these operating systems have to be upgraded NOW

    Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:


    • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
    • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
    • CentOS 6.5, OpenSSL 1.0.1e-15
    • Fedora 18, OpenSSL 1.0.1e-4
    • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
    • FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
    • NetBSD 5.0.2 (OpenSSL 1.0.1e)
    • OpenSUSE 12.2 (OpenSSL 1.0.1c)
  • best explanation yet of hearbleed

    What is leaked primary key material and how to recover?


    These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.


    What is leaked secondary key material and how to recover?


    These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.


    What is leaked protected content and how to recover?


    This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.


    What is leaked collateral and how to recover?


    Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

    joke OPENssl says all about its current state of security, OPEN :)

  • the biggest problem for heartbleed is under water (backoffice)

    you can use this service to test if your webservice is also vulnerable and if you have been hacked or penetrated in the last weeks, months or years it is possible that these webservices could have been compromised as well

    the problem that admins are talking about online is that you can't necessarily see in your logs if you have been compromised by this bug because it isn't logged

    so in fact you can't really known if you have been compromised unless you have been compromised....... for example by the NSA

    it is now becoming clear to an enormous list of webservices and webservices in the backoffice is vulnerable and now they have to find out if they have been compromised

    because it can be that the only goal of the attacker has been to intercept that data in that service without leaving many other traces or doing other stuff (the data in these protected services is quite interesting and important no?)

    ps we don't know the persons behind the checking service, so use at your own risk

    maybe you should ask yourself if openssl was the best solution, not if it was the cheapiest solution

  • heartbleed chaos extending : clients can also be vulnerable (older NGNIX)

    "As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open to exploitation. (Almost) everyone can connect to a public HTTP/SMTP/... server.


    This blog describes how the bug actually works (it mentions dtls_process_heartbeat(), but tls_process_heartbeat() is affected in the same way). This function is used both for clients and server applications, so indeed clients should be vulnerable too.


    According to RFC 6520, heartbeats should not be sent during handshakes. In practice, OpenSSL accepts heart beats right after the sending a ServerHello (this is what Jared Stafford's does). Upon further testing, I have discovered that servers can abuse clients by sending a Heartbeat right after sending the ServerHello too. It triggers the same bug.


    A proof of concept can be found in my repo at From its README:


    The following clients have been tested against 1.0.1f and leaked memory before the handshake:

    • MariaDB 5.5.36
    • wget 1.15 (leaks memory of earlier connections and own state)
    • curl 7.36.0
    • git 1.9.1 (tested clone / push, leaks not much)
    • nginx 1.4.7 (in proxy mode, leaks memory of previous requests)

  • test for heartbleed bug online for an IP range

    if you didn't upgrade or fix it than you will be found and your users and encrypted info can be attacked

    it is as easy to find you as to launch this tool, install metasploit with the new addin and get your data - especially your administrative accounts if you didn't use double authentification for that


  • freeware lastpass shows you which passwords to change because of heartbleed bug

    so it is not so that you can't do anything


  • all these sites were vulnerable to the heartbleed bug the 8th of april

    many are already completely or partly fixed

    the most interesting thing now is that we know they are using openssl so every new zero day - published or sold - can be tested immediately against all these services

  • heartbleed bug : five questions nobody is really posing

    First there was a really easy way not to be impacted by this bug. And it was not to use Openssl but to buy your certificate with a normal certificate firm (verisign, globalsisgn among others). THese certificates are not free but they are not that expensive either and those who have invested a very very small bit of their overall ITbuget in real professional certificates have not to worry now.

    The second question is how it is possible that this bug of which rumor says that exploits or the bugcode were already floating around for two years have only been fixed now after the analysis by a third party. It shows in fact that an Opensource model without a paid businessmodel behind to pay for the developers, the testing of the code and so on is not really a viable solution for really critical installations. In the freeware world it is called freemium. But you really need the permanent coders and testers to be sure that everything is always (re)checked and analyzed. THe community is an inspriration - even for commercial products - but it can't be a longterm strategy if there is no business model behind it.

    The third question is that there is another solution to all the problems with the passwords. In fact passwords are a vulnerability because not only are there millions of passwords leaked every month on the internet (and people re-use the same passwords all over again) they also need to be longer and longer (at least 12 characters) to withstand the bruteforce attacks by stronger hardware (graphical cards) and ever increasing libraries of effectivly used (leaked) passwords (which are always better than theoretical possiblities).

    There is double authentification. As used in the secure laptop of course.

    The fourth question is about the backoffice use of openssl. Openssl is maybe not used at the frontoffice but in backoffice operations in which institutions and firms exchange information between themselves or each other. This is not a problem if there is no problem in the backoffice, but what if you have been compromised the last 2 years and the intruders had access to the bugcode and could decode everything you did in the backoffice that you thought was encrypted and for this reason safe ? What if this is one of the reasons that the NSA was so sure it could decrypt VPN tunnels in internal networks when it had control over the router ? Just a question. Is it possible to replay the traffic - even if you didn't have the decode script than - and decrypt everything now if you have intercepted it at the time and kept a copy untill the encryption was broken ?

    Can you still have an absolute trust in backoffice operations using openssl if these services are used for data that need an absolute protection and certification ?

    THe fifth question is if services that are still vulnerable should be pushed of the internet or not or that there should be an automatic warning popping up in the browser not to insert any confidential information in that online services ? Just as we did when linux certificates were broken some time ago and we found out months later that there were still online services who weren't fixed yet. People should be warned if they are confronted with such services.

    You could otherwise even set up services with the old vulnerable openssl version and decrypt their passwords or other information afterwards. They will never think that it is possible because they have seen the ssl protection and have thought that it was safe.

    We are discovering services in Belgium that have updated the version but didn't re-issue the certificate and we have to state also that it is absolutely necessary that you also change the administrative passwords to the machines and the applications that were vulnerable.

    we still say that it is for the moment not very safe to go on tor or other services encrypted with openssl as it is for the moment not sure that everybody has done everything necessary in their sometimes very complex and big networks.

  • openssl bug : it is best to do also those two things if you could have been compromised

    You should in anyway change at least the administrative passwords to your server

    secondly you should re-issue the certificate as the certificate could have been copied and compromised

    the information about the website itself has been sent to the cert

    because it are not small services

    but you can check for yourself here

  • anti childpredatorapp for US police services gets tips from public about childpredators in hiding


     ICE’s Operation Predator App allows users to receive alerts about wanted predators, to share the information with friends via email and social media tools, and to provide information to HSI by calling or submitting an online tip. “Additionally,” ICE said, “the app allows users to view news about the arrest and prosecution of child predators and obtain information about ICE and its global partners in the fight against child exploitation.”



    ICE’s Operation Predator App was launched in September 2013 and has since been downloaded more than 89,000 times, ICE said. This year it was nominated as one of eight finalists for “Best App” in the PR News’ 2014 Social Media Icon Awards.



    The app is the first of its kind in US federal law enforcement.



    Currently, the app can be downloaded from Apple's App Store or iTunes. Users can look for expanded compatibility to other smartphones in the near future.



    HSI requests anyone with information about the fugitives profiled to contact the agency in one of two ways, which can be done through the app:


  • the undercoverage of the cyberinsurance of the energy sector

    Willis highlighted the industry's vulnerability to cyber threats in its annual review of the energy sector's insurance market, which called on insurers to find a way to provide cover.


    "A major energy catastrophe - on the same scale as ... Exxon Valdez or Deepwater Horizon - could be caused by a cyber attack, and, crucially, that cover for such a loss is generally not currently provided by the energy insurance market," the insurance broker said.


    Most insurance products currently available will cover minor things such as data losses or downtime caused by IT issues, but not major events like explosions at multiple facilities triggered remotely by hackers, Willis (WSH.N) said.

    Now there is another new thing that has been showed by Anonymous in the OpIsrael campaign : you can effectively disturb operations by ddossing internetfacing operations (in this case radars and airport operations) and with a DDOS going over the 200 GBPS with the new reflective methods there is not much that will stop them - except a big investment.

    hacking into infrastructure is not so easy although there has been some cases that were publicly known but it is not something to be done in one-two-three

  • go to to install those highly critical updates NOW

    MS14-017Vulnerabilities in Microsoft Word and Office Web Apps Could Allow Remote Code Execution (2949660)
    This security update resolves one publicly disclosed vulnerability and two privately reported vulnerabilities in Microsoft Office. The most severe of these vulnerabilities could allow remote code execution if a specially crafted file is opened or previewed in an affected version of Microsoft Office software. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.Critical   THESE ATTACKS ARE ALREADY ONGOING

    MS14-018 Cumulative Security Update for Internet Explorer (2950467)
    This security update resolves six privately reported vulnerabilities in Internet Explorer. These vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.Critical Expect attacks SOON

    MS14-019 Vulnerability in Windows File Handling Component Could Allow Remote Code Execution (2922229)
    This security update resolves a publicly disclosed vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if a user runs specially crafted .bat and .cmd files from a trusted or semi-trusted network location. An attacker would have no way to force users to visit the network location or run the specially crafted files. Instead, an attacker would have to convince users to take such action. For example, an attacker could trick users into clicking a link that takes them to the location of the attacker's specially crafted files and subsequently convince them to run them.Important

    MS14-020 Vulnerability in Microsoft Publisher Could Allow Remote Code Execution (2950145)
    This security update resolves a privately reported vulnerability in Microsoft Office. The vulnerability could allow remote code execution if a user opens a specially crafted file in an affected version of Microsoft Publisher. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.Important

  • opisrael by Anonymous disturbed air travel with some very targeted DDOS


    for the rest there is nothing breathtaking except defacements, some ddos and a few thousand passwords but nothing that is really impacting daily life or the security of the infrastructure

    this shows that with very targeted ddos you can start doing real harm because you can very easily by using reflective dns and ntp techniques that can amount up to 200GB and more attacks bring anything down

    so what about Zaventem, Antwerp Port and so on - have they ever thought about DDOS attacks against their infrastructure and the consequences if part of it wouldn't be available anymore

  • windows 2008 server gives Microsoft server share wings since november 2011

    we have always learned that Apache was the leader of the servers and that the internet was running on Apache but it now seems that more and more services are running windows front offices and that the future trend is with Microsoft and not with Apache which will have to reinvent itself

    the numbers in april 2012 were 59% for Apache and 15% for linux

    this is not the case for the millionth most active sites still running Apache and not for what it calls Active sites but clearly for what is internetconnected servers for whatever services Microsoft is growing and the question will be how much this growth can be translated to growth in the other domains



  • openssl bug has enormous impacts on TOR - wait for the upgrades if your life depends on TOR

    If your life depends on the leakage of information online than it is not a good time to be online at anytime and that may take a week or so before even the services promising you anonimity will be able to give you exactly that

    and even than we should need to check the relays we are using more profoundly because they could leak that information and if you never know for sure who is behind that relay you may never know who has your information afterwards

    enjoy holiday, life, familiy, books and films - offline if you really need total anonimity

    nobody will miss you that much that they can't wait that week


    Here are our first thoughts on what Tor components are affected:


    1. Clients: Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor.
    2. Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys.
    3. Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service, but an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.
    4. Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
    5. Tails is still tracking Debian oldstable, so it should not be affected by this bug.
    6. Orbot looks vulnerable; they have some new packages available for testing.
    7. The webservers in the rotation needed (and got) upgrades too. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.
  • the same code that tests your openssl servers is also now used to attack them

    you may consider any important server that still isn't fixed to be compromised soon

  • bitcoinworld in chaos as openssl issues hit at the core of the code behind it

    this is how to act nowadays

    "There are exactly two places in Bitcoin Core that may be affected by this issue.

    One is RPC SSL. If you're using this, turn it off. If you don't know what that is, you most likely aren't using it.

    The other is the payment protocol. Specifically, fetching payment requests. If you're using a vulnerable version, do not click any bitcoin: links and you will be protected. Note that this is only relevant for the GUI, and only for version 0.9.0.

    If you're using self-built executables, you're most likely using dynamically linked OpenSSL. Simply upgrade your OpenSSL package and you should be fine. If I'm not mistaken, the same applies if you're using the PPA. If you're using release binaries, a version 0.9.1 is being prepared that will use the fixed OpenSSL 1.0.1g.

    Note that if you're running the GUI (p.k.a. Bitcoin-Qt) you can check your OpenSSL version in the debug window's information tab. If you're on anything earlier than 1.0.1, for example 0.9.8, you're safe. If you're on 1.0.1g or later, you're safe. If you're on 1.0.1-1.0.1e, you may be vulnerable. However, that may not necessarily be the case -- for example, Debian has released an update for Wheezy, version 1.0.1e-2+deb7u5, which fixes the security bug without bumping the version number as reported by OpenSSL.

    • If you use the payment protocol, after clicking the bitcoin: link, you will see a green-coloured transaction with a name instead of a Bitcoin address. Any other bitcoin: link is not at risk.

    • If you ever opened one of these green-coloured links, or used RPC SSL, consider your wallet compromised. Create a completely new wallet and send all your bitcoins to it. It's probably not compromised, but do it just to be safe.

    • Another way to know if a bitcoin: link is safe: look at it. If it's just an address, amount, and/or memo, it's fine. If there's an "r" parameter with a link, that's potentially vulnerable.
  • stop testing your openssl servers online - the server is overloaded and the not-vulnerable results mistaken

    Load issues - fix in progress


    Load issues (probably) caused many connections to the tested servers to fail randomly and report a FALSE POSITIVE.

    Repeated tests will finally yield a red. The red result takes precedence over all the others and is certain. You are given a sample of live server memory as proof. I'm very sorry about this happening. I'm spinning up more machines for a quick fix, and then rewriting the test to give only positive green. Meanwhile you can use the command line tool that is completely unaffected.

    if you are the only one who thought about bringing it on the web as a webservice (where are the certs and other big providers anyway ?) and it is up for a lonely guy to keep this running (who will be paying ?)

    than shit happens