Microsoft security advisory (2718704):
http://bit.ly/McLPxg
Microsoft Security Research & Defense blog:
http://bit.ly/Lmomc6
Microsoft Security Response Center blog:
http://bit.ly/Ku7CGc
About Flame:
http://bit.ly/M9aF5c
Microsoft released on Sunday security advisory which revokes 3 digital certificates issued under the Microsoft Root Certificate Authority. In separate messages (Security Research & Defense and Security Response Center blogs), Microsoft stated that this update mitigates the threat of Flame malware. Flame is recently discovered highly sophisticated spyware which infected computers throughout Middle East and supposedly came from the same source as Stuxnet.
Microsoft security advisory (2718704): http://bit.ly/McLPxg Microsoft Security Research & Defense blog: http://bit.ly/Lmomc6 Microsoft Security Response Center blog: http://bit.ly/Ku7CGc About Flame: http://bit.ly/M9aF5c
0 Comments
According to the CloudFlare blog, the hacker was able to compromise the password recovery and two factor authentication systems and eventually gained access to one of CloudFlare customer's account: "Google reports that they discovered a "subtle flaw affecting not 2-step verification itself, but the account recovery flow for some accounts. We've now blocked that attack vector to prevent further abuse." Technical details about bypassing either Google password recovery or two factor authentication systems are unclear. CloudFlare blog: http://bit.ly/K7QTCg Google two factor authentication: http://bit.ly/KD1cmi Interesting article in SearchSecurity: "P2P encryption for mobile is not an technology endorsement, says PCI Council". So on the one hand, in their recent mobile payments guide for merchants, they present the P2PE as the only way to secure mobile payments. On the other hand, they say " We’re not endorsing specific technology here". I am not sure I understand the point they are trying to make.
Review of PCI mobile payments guidance for merchants: http://bit.ly/JCOB4q Article in SearchSecurity: http://bit.ly/KRCjnU Moxie Marlinspike and Trevor Perrin have submitted a proposal to the Internet Engineering Task Force (IETF). The draft document describes a new way of server certificate validation based on the trust accumulated and shared by multiple clients. The proposed TLS protocol extension is called Trust Assertions for Certificate Keys (TACK) and based on public key cryptography, however, it does not use the Public Key Infrastructure (certificates and certificate authorities). The text of the proposal: http://bit.ly/JieksQ The article in InfoSecurity magazine: http://bit.ly/L0jWtj It looks like OCSP Stapling currently is not the best alternative to classic CRL validation. First, because current implementation has serious limitation: only one certificate can be validated during the initial SSL/TLS handshaking session. However, as part of the server certificate checkup, the SSL client must validate the entire certificate chain -- until the root (self-signed) certificate -- which may contain more than one certificate. Second, it is not widely supported yet: not all the clients and server implementation are OCSP Stapling ready. For instance, it is still unclear whether Microsoft WCF hosting process (alternative to IIS) would support it - at least, it is not officially documented.
Original post 05/10/2012: Future of the SSL certificate revocation validationweb-services-with-ssl.html My article about using SSL in .NET Web Services application: http://www.gomzin.com/securing-net-web-services-with-ssl.html PCI Security Standards Council just released "customized fact sheet" - guidance for merchants on how to securely implement mobile payments. According to this document called "Accepting Mobile Payments with a Smartphone or Tablet" (but for some reason referenced in press-release as "At a Glance: Mobile Payment Acceptance Security"), Point-to-Point Encryption solution -- validated and certified by P2PE QSA using recently launched PCI P2PE assessment program, and listed on PCI SSC website -- "may help you in your responsibilities under PCI DSS" and "leverages a mobile device’s display and communication functions to secure mobile payments". The only diagram in this document, which illustrates the architecture of mobile payment solution, shows P2PE solution provider accepting and processing merchant's mobile payment transactions.
This is interesting and hot topic. Did you know that Google stopped the online validation of SSL server certificate revocations in Chrome browser? The situation with certificate revocation validation has been discussed by representatives of major browser software vendors during recent RSA conference. OCSP Stapling looks to me like most promising solution. Click to set custom HTML PCI SSC just released updated and finalized requirements for hardware/hardware Point-To-Point Encryption solutions. It is still unclear when software requirements will be available. The PCI P2PE validation program is supposed to be launched officially after the first P2PE QSA training on May 11-13. Click to set custom HTML BEAST stands for Browser Exploit Against SSL Tool.
This is variation of Man-in-the-middle attack invented by Juliano Rizzo and Thai Duong. Here is the results of my brief research on BEAST. Even though the detailed scenario of the attack apparently is not published by their authors, there is some information and area experts reviews available online so I could reconstruct the picture from several puzzles. The most important outcome – the attack is unable to compromise the custom client/server application communication as it is aimed against browser client/WEB server communication only. It is using WEB vulnerabilities and must inject malicious java script code into the client browser in order to initialize the attack. Therefore, it affects websites only and does not affect custom software using SSL. Workarounds/Mitigations that are known today: Using non block (stream) ciphers such as RC4 instead of standard default block ciphers such as AES. Disadvantages: o strongest ciphers (such as AES) mostly using blocks, and stream ciphers (such as RC4) may have their own weaknesses o streaming ciphers may not be supported by all browsers/servers Using TLS 1.X and higher (eliminating using SSL 3.0 and TLS 1.0 which are found vulnerable for the attack) Disadvantages: o TLS 1.X is not widely used and therefore not proven enough; o TLS 1.X is not supported by all browser versions therefore after server will be reconfigured some clients using old browser versions may be unable to access it. The two counter measures described above require WEB server reconfiguration that would possibly make some clients unable to access the websites. Before anything is done, it should be thoroughly researched and tested. Microsoft promised to release a Windows OS patch that blocks it (IE browser uses Windows SSL implementation). I would like to update you on most important topics that have been discussed during 2011 PCI SSC annual meeting in Scottsdale, Arizona.
P2PE The most (and almost the only) important topic was, as everyone expected, P2PE (Point To Point Encryption). Recently, just few days before the meeting, the Council released a big document which defines requirements for Hardware/Hardware P2PE. “Hardware/Hardware” means that both encryption and decryption are being performed by hardware modules approved by FIPS 140-2 Level 3, PCI HSM or PCI PTS certification programs (normally - pinpad device at the client point and HSM appliance at the switch end). The document and its outcomes have been widely discussed during the meeting, and here are several important points that I noticed: · Hardware P2PE, when implemented according to SSC requirements and properly certified, is supposed to significantly reduce the PCI DSS certification scope, meaning reducing the merchants PCI costs, particularly – may eliminate additional firewalls installations and quarterly penetration tests. Therefore, merchants are supposed to be financially stimulated to look for P2PE encryption solutions. Technical detail: This is applied mostly to Hardware encryption, also with pinpad content signed by the vendor in a way that it would be impossible to alternate it, which provides functionality of internal “firewall” isolating device middleware from the rest of merchant’s network. · Final release of the requirements and most important – test procedures – will be published in Q4, or by the end of 2011, which means that if you want to be the first in this race – the design and the code should be done by the end of this year. · There will be special certification program introduced for P2PE, auditors will have to be certified as “P2PE QSA” in order to be able to perform such assessments. The timeline for certification program finalization and QSA training – Q1 2012, but no one believes it is going to happen in Q1 and most probably it is going to be Q2 or even later. I talked to several QSAs and all of them have no clue about the program details, even not all of them intend to be trained for it in near future. If you want to be in first wave of certified P2PE solutions, most probably, you will have to stick with the “big” guys as they are the only ones who commit for everything from SSC as soon as it comes to live. · Even though major focus is being made on Hardware/Hardware P2PE as almost ultimate solution for the PCI compliance, software P2PE will still remain a valid option. There is a plan to release detailed requirements regarding SW P2PE as the next step (though no timelines were provided). This will include definition of HW P2PE with SW key management. PA-DSS There is interesting tool provided by PCI SSC that allows you to determine whether application is eligible for PA-DSS assessment. This is simple questionnaire which is available online. If one of the answers is YES, the application should not go through the PA-DSS validation. Please take a look – there are interesting questions. For example, according to question #8, if the product is DLL that requires third party hosting application, such software might not be validated through PA-DSS while any POS that uses it should be certified either through PA-DSS or PCI DSS process. Mobile Currently, according to the guidelines recently released by the PCI SSC, most mobile payment applications do not qualify to be PA-DSS compliant. There will be a draft guidance on PA-DSS for Mobile devices released in Q4 2011. ISA There is interesting program for companies that want to perform their own internal PCI DSS like assessments – it is called ISA (Internal Security Assessor). The company that wants to participate just needs to enroll to this program and send people for training. Links: https://www.pcisecuritystandards.org/documents/nb59Y8Qqv/P2PE_Hardware_Solution_%20Requirements_Initial_Release.pdf https://www.pcisecuritystandards.org/documents/Applications_Eligible_for_PA-DSS_Validation.pdf https://www.pcisecuritystandards.org/documents/statement_110624_pcissc.pdf https://www.pcisecuritystandards.org/training/isa_training.php |
Books
Recent Posts
Categories
All
Archives
March 2023
|