Il semble que les cookies ne soient pas activés dans votre navigateur. Veuillez activer les cookies pour garantir une expérience du site optimale.
Affichage des résultats 1 à 13 sur 13

Hybrid View

  1. #1
    Date d'inscription
    avril 2007
    Messages
    4 280

    Heartbleed Bug: OpenSSL Security Compromised

    Some of the MSM (main stream media) have not yet alerted people to the importance of an announcement by the OpenSSL project regarding a serious bug in their code (04/07/2014). The code affects 1,000,000+ servers (web, email, banking systems and others). There is a fix available but it will take a few days (at best) for companies to implement the fix and re-acquire new crypto keys and certificates.

    In the mean time, servers with this error have no real protection, all crypto keys, data on the server are open*.

    There are recommendations to verify with your providers, bank, and other web access providers as to the state of their patches. There are some systems that are NOT affected but only the providors can confirm that status.


    * That data leakage means that servers vulnerable to Heartbleed are less secure than they would be if they simply had no encryption at all. "This allows attackers to eavesdrop communications, steal data directly from the services and users, and to impersonate services and users," explained security group Codenomicon, which discovered the flaw.

    The OpenSSL project has created a webpage to inform everyone about the issues surrounding the Heartbleed bug.

    http://heartbleed.com/

    The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

    The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

    What leaks in practice?

    We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

    How to stop the leak?

    As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL [ht tps://www.openssl.org/news/secadv_20140407.txt ] has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.

    There is an extensive FAQ at the bottom of their statement indicating remedies, affected systems and remedial actions.
    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

  2. #2
    Date d'inscription
    juin 2011
    Messages
    1 837
    Use https://www.ssllabs.com/ssltest/ to check how vulnerable domains are.

    store.lotro.com gets an A- and is rated as not vulnerable to Heartbleed.
    105s: Aedfrith (HN), Aldnoth (CP), Brai (RK), Hrolfdan (MN), Aeldfryd (WD), Morriarty (CH), Aednoth (LM), Mishhar (BR), Hraldan (GR), Rummbold (BG). Tinies - Rumbelina (MN), Aenghus (CP)
    Rangers of Eriador (officer), ex-Snowbourn now Laurelin - A Noob for All Seasons

  3. #3
    Date d'inscription
    avril 2007
    Messages
    4 280
    Here are 2 sites that have compiled a list of MAJOR websites and their Heartbleed Status.

    Not every site is vulnerable and not every site uses the required vulnerable sections of the OpenSSL code.

    This is not a be-all/end-all set of lists and each person will need to determine for themselves all the sites they visit that MAY need to have password changes. There is a timing issue: do not change your password UNTIL the host site has completed their Heartbleed updates which include a software patch, re-encryption and a new SSL certificate (there are delays in the certificates). Changing a password before all of this may not protect your data/access/password.

    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

  4. #4
    Date d'inscription
    août 2008
    Localisation
    Vancouver, BC Canada
    Messages
    3 092
    Citation Envoyé par Aedfrith Voir le message
    Use https://www.ssllabs.com/ssltest/ to check how vulnerable domains are.

    store.lotro.com gets an A- and is rated as not vulnerable to Heartbleed.
    These types of sites are giving conflicting and misleading information, and are not a reliable source. The only authority on this issue that we should trust is Turbine, and they haven't made a statement yet.

  5. #5
    Date d'inscription
    avril 2007
    Messages
    4 280
    There is another aspect of the Heartbleed bug that is getting little or no attention and that is with embedded systems or firmware. Devices which uses microchips that have or rely on the vulnerable release of SSL will either take a very long time to fix or not be fixable at all.

    ex: Imagine a device like a cell phone that does an automated handshake with a server. Inside the cell phone are chips and software along with apps. In order to make the apps and phone run "fast" some aspects of the SSL handshake are moved into firmware where it will be fast and also less prone to hacking (along the normal lines).

    Now, consider this same chip requiring a firmware update. Because it's an embedded system it may be harder or take longer to patch. It can only be patched if the chip has a WriteMany ability. Some chips are WriteOnce and those are a one time burn. There are chips that have multiple write cycles but it's not so easy to just grab some section of a complicated software system and jam in new code.

    An other aspect that can impact the speed of resolution are complex systems that rely on multiple 3d party libraries or base code.

    ex: Imagine a large complex system that governs n,000 servers. These servers run multi-faceted software products, some home-grown by the owner-company and some of it purchased as 3d party add ons or code libraries or subsystems. (forums, email, data transfer upload, ftp, sales, inventory, purchasing, order processing, order fulfillment etc). There may even be operating system level add-ons that are involved.

    If any one of these products relies or implements some of the faulting code, then the owner-company has to wait for the 3d party to repair the 3d party code, test, and roll out the fix. There are some companies who are going to have to wait for base level fix from their 3d party provider.

    If there's one server in a sea of servers that remains vulnerable, the entire system is vulnerable. I hope those large players have a decent A&R system in place (Audit and Remediation).
    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

  6. #6
    Date d'inscription
    avril 2007
    Localisation
    Gallifrey. I need a Jelly Baby.
    Messages
    18 357
    Sabriel, I like your sig. I Googled it and read the entire thing.
    Life is not a journey to the grave with the intention of arriving safely in a well preserved body, but rather to skid in broadside, totally worn out & proclaiming "WOW, what a ride!"
    Continuing the never ending battle to keep Lobelia Sackville-Baggins in check

  7. #7
    Date d'inscription
    avril 2007
    Messages
    4 280
    Just when you thought it was safe to go back in the water.... Reverse Heartbleed affects clients not servers.

    The server version: Heartbleed, has been patched for the most part except those with embedded firmware or apps relying on the OS to fix it (ex: some android cell phones).

    Reverse Heartbleed, is the same vulnerability but it affects clients eg PCs.



    What kinds of clients are vulnerable?

    Anything that speaks TLS using OpenSSL is potentially vulnerable, but there are two main classes of client apps that are worth mentioning:

    1) Traditional clients are things like web browsers, apps that use HTTP APIs (everything from Dropbox to Microsoft Office), and of course many mobile apps on both iOS and Android. It might be easy to direct one of these clients to connect to a malicious server (as in the case of a web browser) or it might require a man-in-the-middle (MITM) attack to redirect a client to an evil endpoint.

    2) Open agents are clients that can be driven by an attacker but don't reside on an attacker's machine. If you can direct some remote application to fetch a URL on your behalf, then you could theoretically attack that application. The web is full of applications that accept URLs and do something with them; any of these have the potential to be vulnerable:


    •Social networks that do smart things with URLs; e.g. Facebook, which fetches any URL that you type in to a status update in order to generate a preview of that URL.

    •File sharing apps like image thumbnailers, image hosters, Gravatar, and anything else that can "upload" an image or other user-supplied data via a URL.

    •Web spiders like the Googlebot that can stumble on a URL and index it – they can be directed to a malicious server just by linking to it.

    •API consumers that allow integrations across websites. For example, Redbooth integrates with Dropbox to allow users to upload files to projects. If I can convince the Redbooth servers via MITM to send their Dropbox requests to my server, I can potentially exploit them.

    •Identity federation protocols, such as OpenID and WebFinger, allow low-trust users to direct high-trust servers to arbitrary URLs that the user can control. The StackOverflow login page prompts the user for a URL that can be used to log in with OpenID – therefore, the code that StackOverflow uses to fetch that URL must not be vulnerable.

    •Webhooks, which allow a user to register interest in a certain event happening and get a callback. I can tell Github that I'd like to be notified at a URL I control whenever someone pushes to a repository, and Github's agent will connect to that URL over TLS if specified.

    The surface of exposed clients is potentially very broad – any code in an application that makes outbound HTTP requests must be checked against reverse Heartbleed attacks.

    ....


    The important takeaway is that it's not enough to patch your perimeter hosts - you need to purge bad OpenSSL versions from your entire infrastructure. And you should keep a healthy distance between agent code that fetches user-provided URLs and sensitive parts of your systems.


    http://blog.meldium.com/home/2014/4/...rse-heartbleed
    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

 

 

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •  

La session de ce formulaire a expiré. Vous devez recharger la page.

Recharger