Nytro

[h=1]SA-CORE-2014-005 - Drupal core - SQL injection[/h] Posted by Drupal Security Team on October 15, 2014 at 4:02pm Advisory ID: DRUPAL-SA-CORE-2014-005 Project: Drupal core Version: 7.x Date: 2014-Oct-15 Security risk: 20/25 ( Highly Critical) AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:All Vulnerability: SQL Injection [h=2]Description[/h] Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks. A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks. This vulnerability can be exploited by anonymous users. [h=2]CVE identifier(s) issued[/h] CVE-2014-3704 [h=2]Versions affected[/h] Drupal core 7.x versions prior to 7.32. [h=2]Solution[/h] Install the latest version: If you use Drupal 7.x, upgrade to Drupal core 7.32. If you are unable to update to Drupal 7.32 you can apply this patch to Drupal's database.inc file to fix the vulnerability until such time as you are able to completely upgrade to Drupal 7.32. Also see the Drupal core project page. [h=2]Reported by[/h] Stefan Horst [h=2]Fixed by[/h] Stefan Horst Greg Knaddison of the Drupal Security Team Lee Rowlands of the Drupal Security Team David Rothstein of the Drupal Security Team Klaus Purer of the Drupal Security Team [h=2]Coordinated by[/h] The Drupal Security Team [h=2]Contact and More Information[/h] We've prepared a FAQ on this release. Read more at https://www.drupal.org/node/2357241. The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact. Sursa: https://www.drupal.org/SA-CORE-2014-005

Offtopic: zoso e prieten cu RST. Ceva de genul. Nu trebuie sa mentioneze sursa. Ontopic: Asa cum am mentionat, Arrow Electronics nu au niciolegatura cu site-ul respectiv si au spus ca departamentul "legal" va lua masuri, sunt curios daca iese urat pentru proprietar. Nu de alta, dar banii aia trebuie sa ajunga intr-un cont, nu?

[h=1]Apple si Facebook, primele companii care platesc pentru congelarea ovulelor angajatelor[/h] de A.C. HotNews.ro Miercuri, 15 octombrie 2014, 17:32 Magazin Femeile care lucreaza pentru Facebook si Apple primesc un beneficiu suplimentar, pe langa salariu: companiile platesc pentru congelarea ovulelor. Facebook a inceput sa ofere acest serviciu in Statele Unite de la inceputul anului, scrie BBC. Politica este conceputa pentru a atrage si a pastra talentele de varf ale sexului feminin, ajutandu-le pe acestea sa evite punctul in care trebuie sa aleaga intre maternitate si cariera. Apple va urma exemplul incepand cu ianuarie 2015. "Continuam sa ne extindem beneficiile pentru femei, cu o noua politica referitoare la concediul de maternitate, alaturi de crioconservare si stocarea ovulelor, ca parte a sprijinului nostru pentru tratatmentele de infertilitate", anunta Apple intr-un comunicat. Ambele companii ofera pana la 20.000 de dolari pentru angajatele din SUA pentru a finanta procedura de extragere si depozitare a ovulelor. "Vrem sa incurajam femeile de la Apple sa faca cel mai bun lucru al vietii lor pe masura ce au grija de cei dragi si isi cresc familiile", se mai arata in comunicatul Apple. Competitia pentru recrutarea de personal talentat din Silicon Valley este acerba si politica ar putea ajuta gigantii in domeniul tehnologiei sa atraga si sa pastreze cei mai buni candidati. In plus, in utlima perioada a existat o presiune tot mai mare asupra firmelor de a spori diversitatea in sectorul, care este dominat de barbati. Jennifer Tye, director de marketing la Glow, o companie de tehnologie care ofera servicii pentru controlul sanatatii reproductive a femeilor, saluta aceasta initiativa. "Congelarea ovulelor ofera mai mult control", a prezicat Tye. "Atunci cand am implinit 30 de ani, mi-am dat seama ca ceasul meu biologic ticaie, dar nu stiam care sunt optiunile. Acesti angajatori ar trebui sa fie apreciati", a adaugat Jennifer Tye. Cu toate acestea, criticii politicii au sugerat ca aceste companii ar trebui sa se concentreze pe oferirea unei mai mari flexibilitati in ceea ce priveste sprijinul pentru noii parinti. Sursa: Apple si Facebook, primele companii care platesc pentru congelarea ovulelor angajatelor - Magazin - HotNews.ro

Gmail’s SMTPUTF8 prone to homographic attacks (thanks, 4chan!) October 14, 2014 No comments Article I always loved working with Google. I have been participating in their program since 2012. Over the years, I addressed some nice vulnerabilities that got me a couple of hall of fame entries and of course some nice monetary awards. But this last time, I drew a blank. I spent some time researching Unicode last month. Browsing through a lot of interesting characters, two of them struck my eye: the soft hyphen and the zero with space. There characters are basically – nothing[1], except they are there. Doing a bit of research, I quickly found that these characters were used to “blank post” on the popular image board “4chan”. Interesting. Naturally, it is not allowed to submit “empty” comments to the board – but using this single character, it was possible to bypass this restriction. Well, such a post is technically not empty. It just seems like it is. I started wondering whether this could lead to some security implications in popular websites. Except for some low-priority design bugs I did not find anything. [1] The soft hyphen does have a functionality: it indicates where to break a word. Months passed by. I had forgotten about the special Unicode character and moved on, looking for new and unique bugs. Until I post on the Google Blog: Gmail would now support e-mail addresses with Unicode characters. The extraordinary characters from earlier popped up in my head and I had this crazy idea: inti@deceukelai.re vs in*ti@deceukelai.re Can you spot the difference? I can’t. But believe me – they are different. The 2nd one has a soft hyphen between “in” and “ti”. So technically, this gives us an e-mail that appears to be the same, but isn’t. So what’s the big deal? Monday morning at work. You receive the following mail from your colleague, who happens to be me. You recognize my e-mail address and send me the document. Or did you? You actually replied to in*ti@dece*ukelai.re instead of inti@deceukelai.re, without ever noticing you have been tricked in. Sounds like a problem to me. After reporting this bug, it got miraculously fixed, even though my initial test show that the vulnerability did exist. I noticed, however, that it was still possible to use a homograph attack mixing look-a-like characters of different character sets (e.g. latin and greek). Result: Even though these e-mail addresses may look the same, they are not: the first letter (blank one) of the e-mail address is a look-a-like character of some other script.So let’s say you send a mail to You think you are sending your message to me, but you are not, as the “e” of “de” is a letter from another alphabet. Say the server, in this case Gmail’s supports the creation of SMTPUTF8 e-mail addresses (they will, shortly), then this e-mail could be delivered to a different user without anyone even noticing. I reported this additional information to Google and they replied that they are working on it, but also that my report does not qualify for a reward. I am publishing this to show the dangers of the new RFC6530 e-mail standardization. While I do believe globalisation is a good thing, we should watch our steps toward it carefully. Nobody wants to get lost in translation. I was a bit “feeling unlucky” to see my work did not get rewarded. But that’s life, I guess. Luckily, I found some vulnerabilities at Facebook that did get a generous reward. I will do a write-up on those soon. Stay tuned! Sursa: Gmail’s SMTPUTF8 prone to homographic attacks (thanks, 4chan!) | Securinti

[h=2]October 14, 2014[/h] [h=3]Two more browser memory disclosure bugs (CVE-2014-1580 and #19611cz)[/h] To add several more trophies to afl's pile of image parsing memory disclosure vulnerabilities: MSFA 2014-78 (CVE-2014-1580) fixes another case of uninitialized memory disclosure in Firefox - this time, when rendering truncated GIF images on <canvas>. The bug was reported on September 5 and fixed today. For a convenient test case, check out this page. Rough timeline: September 5: Initial, admittedly brief notification to vendor, including a simple PoC. September 5: Michael Wu confirms the exposure and pinpoints the root cause. Discussion of fixes ensues. September 9: Initial patch created. September 12: Patch approved and landed. October 2: Patch verified by QA. October 13: Fixes ship with Firefox 33. [*] MSRC case #19611cz is a conceptually similar bug related to JPEG DHT parsing, seemingly leaking bits of stack information in Internet Explorer. This was reported to MSRC on July 2 and hasn't been fixed to date. Test case here. Rough timeline: July 2: Initial, admittedly brief notification to vendor, mentioning the disclosure of uninitialized memory and including a simple PoC. July 3: MSRC request to provide "steps and necessary files to reproduce". July 3: My response, pointing back to the original test case. July 3: MSRC response, stating that they are "unable to determine the nature of what I am reporting". July 3: My response, reiterating the suspected exposure in a more verbose way. July 4: MSRC response from an analyst, confirming that they could reproduce, but also wondering if "his webserver is not loading up a different jpeg just to troll us". July 4: My response stating that I'm not trolling MSRC. July 4: MSRC opens case #19611cz. July 29: MSRC response stating that they are "unable identify a way in which an attacker would be able to propagate the leaked stack data back to themselves". July 29: My response pointing the existence of the canvas.toDataURL() API in Internet Explorer, and providing a new PoC that demonstrates the ability to read back data. September 24: A notification from MSRC stating that the case has been transferred to a new case manager. October 7: My response noting that we've crossed the 90-day mark with no apparent progress made, and that I plan to disclose the bug within a week. October 9: Acknowledgment from MSRC. Well, that's it. Enjoy! Sursa: lcamtuf's blog: Two more browser memory disclosure bugs (CVE-2014-1580 and #19611cz)

XXE Attacks Introduction XXE (XML External Entity attack) is now increasingly being found and reported in major web applications such as Facebook, PayPal, etc. For instance, a quick look at the recent Bug Bounty vulnerabilities on these sites confirms this. Although XXE has been around for many years, it never really got as much attention as it deserved. Most XML parsers are vulnerable to it by default, which means it is the responsibility of a developer to make sure that the application is free from this vulnerability. In this article we will explore what XML external entities are and how they can be attacked. What are XML external entities? For someone who is not aware of XML, you can think of it as something that is used to describe data. Thus, two systems which are running on different technologies can communicate and exchange data with one another using XML. For example, below is a sample XML document which describes an employee. The ‘name’ ‘salary’ and ‘address’ are called XML elements. Now these XML documents can contain something called ‘entities’ defined using a system identifier and are present within a DOCTYPE header. These entities can access local or remote content. For example, below is a sample XML document that contains XML entities. In the above code, the external entity ‘entityex’ is declared with the value file:///etc/passwd. During XML parsing, this entity will be replaced with the respective value. The use of keyword ‘SYSTEM’ instructs the parser that the entity value should be read from the URI that follows. Thus, when the entity value is used many times, this would seem very helpful. What is an XXE attack? With XML entities, the ‘SYSTEM’ keyword causes an XML parser to read data from a URI and permits it to be substituted in the document. Thus, an attacker can send his own values through the entity and make the application display it. In simple words, an attacker forces the XML parser to access the resource specified by him which could be a file on the system or on any remote system. For example, the below code would fetch the folder/file present on that system and display it to the user. How to identify XXE vulnerabilities The straightforward answer to this question would be to identify those end points which accept XML as input. But sometimes you will encounter those cases where the end points that accept XML might not be so obvious (for example, those cases where the client uses only JSON to access the service). With these cases, a pen tester has to try out different things such as modifying the HTTP methods, Content-Type etc. to see how the application responds. If the application parses the content, then there is a scope for XXE. How to confirm For the purpose of demo, let us use the site http://testhtml5.vulnweb.com/ which is maintained by Acunetix. This is a test site that can be used to verify the capabilities of the Acunetix web scanner. Visit the site http://testhtml5.vulnweb.com/ and click on the ‘Forgot Password’ link present under ‘Login’. Observe that the application transmits data using XML as shown below. Request: Response: Looking at the above request and response we can understand that the application is processing XML, receiving certain input and displaying it back. In order to test whether the XML parser is parsing and executing the XML sent by us, I have sent the below request. Modified Request & Response: As seen in the above request, we have now introduced an entity within the request (myentity). The response clearly indicates that the XML parser has parsed whatever we have sent and accordingly echoed back the value. This confirms that this application is vulnerable to XXE attacks. How to exploit The following code samples can be used for exploitation of the XML external entity vulnerability. Insert Code 1 The above attack is known as ‘billion laughs’ attack and takes an exponential amount of space almost around 3 GB. Apart from these an attacker can also read sensitive data present on servers that the application can reach, look for open ports on backend systems by performing port scanning etc. Impact: The impact of exploiting this vulnerability can be very dangerous, as it allows an attacker to read sensitive files present on the server, perform denial of service attack on the server, etc. Remediation: The main problem as discussed above is that the XML parser parses the untrusted data sent by the user. However, it may not be easy or possible to validate only data present within the system identifier in the DTD. Most XML parsers are vulnerable to XML external entity attacks (XXE) by default. Therefore, the best solution would be to configure the XML processor to use a local static DTD and disallow any declared DTD included in the XML document. For example in Java (as shown in the below code), by setting the respective attributes to false, external entity attacks can be prevented. Thus external entities, parameter entities, and inline DTD are set to false to avoid XXE based attacks. Insert Code 2 By Rohit T|October 15th, 2014 Sursa: XXE Attacks - InfoSec Institute

POODLE attacks on SSLv3: https://www.imperialviolet.org/2014/10/14/poodle.html Some POODLE notes : Errata Security: Some POODLE notes

Attack of the week: POODLE Believe it or not, there's a new attack on SSL. Yes, I know you're thunderstruck. Let's get a few things out of the way quickly. First, this is not another Heartbleed. It's bad, but it's not going to destroy the Internet. Also, it applies only to SSLv3, which is (in theory) an obsolete protocol that we all should have ditched a long time ago. Unfortunately, we didn't. Anyway, enough with the good news. Let's get to the bad. The attack is called POODLE, and it was developed by Bodo Möller, Thai Duong and Krzysztof Kotowicz of Google. To paraphrase Bruce Schneier, attacks only get better -- they never get worse. The fact that this attack is called POODLE also tells us that attack names do get worse. But I digress. The rough summary of POODLE is this: it allows a clever attacker who can (a) control the Internet connection between your browser and the server, and ( run some code (e.g., script) in your browser to potentially decrypt authentication cookies for sites such as Google, Yahoo and your bank. This is obviously not a good thing, and unfortunately the attack is more practical than you might think. You should probably disable SSLv3 everywhere you can. Sadly, that's not so easy for the average end user. To explain the details, I'm going to use the usual 'fun' question and answer format I employ for attacks like these. What is SSL? SSL is probably the most important security protocol on the Internet. It's used to encrypt connections between two different endpoints, most commonly your web browser and a web server. We mostly refer to SSL by the dual moniker SSL/TLS, since the protocol suite known as Secure Sockets Layer was upgraded and renamed to Transport Layer Security back in 1999. This bug has nothing to do with TLS, however. It's purely a bug in the old pre-1999 SSL, and specifically version 3 -- something we should have ditched a long time ago. Unfortunately, for legacy reasons many browsers and servers still support SSLv3 in their configurations. It turns out that when you try to turn this option off, a good portion of the Internet stops working correctly, thanks to older browsers and crappy load balancers, etc. As a result, many modern browsers and servers continue to support SSLv3 as an option. The worst part of this is that in many cases an active attacker can actually trigger a fallback. That is, even if both the server and client support more modern protocols, as long as they're willing to support SSLv3, an active attacker can force them to use this old, terrible protocol. In many cases this fallback is transparent to the user. What's the matter with SSL v3? So many things it hurts to talk about. For our purposes we need focus on just one. This has to do with the structure of encryption padding used when encrypting with the CBC mode ciphersuites of SSLv3. SSL data is sent in 'record' structures, where each record is first authenticated using a MAC. It's subsequently enciphered using a block cipher (like 3DES or AES) in CBC mode. This MAC-then-encrypt design has been the cause of much heartache in the past. It's also responsible for the problems now. Here's the thing: CBC mode encryption requires that the input plaintext length be equal to a multiple of the cipher's block size (8 bytes in the case of 3DES, 16 bytes for AES). To make sure this is the case, SSL implementations add 'padding' to the plaintext before encrypting it. The padding can be up to one cipher block in length, is not covered by the MAC, and always ends with a single byte denoting the length of the padding that was added. In SSLv3, the contents of the rest of the padding is unspecified. This is the problem that will vex us here. How does the attack work? Let's imagine that I'm an active attacker who is able to obtain a CBC-encrypted record containing an interesting message like a cookie. I want to learn a single byte of this cookie -- and I'm willing to make the assumption that this byte happens to live at the end of a cipher block boundary. (Don't worry about how I know that the byte I want to learn is in this position. Just accept this as a given for now.) Imagine further that the final block of the record in question contains a full block of padding. If we're using AES as our cipher, this means that the last byte of the plaintext of the final block contains a '15' value, since there are 15 bytes of padding. The preceding 15 bytes of said block contain arbitrary values that the server will basically strip off and ignore upon decryption, since SSLv3 doesn't specify what they should contain. (NB: TLS does, which prevents this issue.) The attack works like this. Since I control the Internet connection, I can identify the enciphered block that I want to learn within an encrypted record. I can then substitute (i.e., move) this block in place of the final block that should contain only padding. When the server receives this new enciphered record, it will go ahead and attempt to decrypt the final block (which I'll call C_n) using the CBC decryption equation, which looks like this: Decrypted final block := Decipher(C_n) XOR C_{n-1} Note that C_{n-1} is the second-to-last block of the encrypted record. If the decrypted final block does not contain a '15' in the final position, the server will assume either that the block is bogus (too much padding) or that there's less padding in the message than we intended. In the former case it will simply barf. In the latter case it will assume that the meaningful message is longer than it actually is, which should trigger an error in decryption since MAC verification will fail. This should also terminate the SSL connection. Indeed, this is by far the most likely outcome of our experiment, since the deciphered last byte is essentially random -- thus failure will typically occur 255 out of every 256 times we try this experiment. In this case we have to renegotiate the handshake and try again. Every once in a while we'll get lucky. In 1/256 of the cases, the deciphered final block will contain a 15 byte at the final position, and the server will accept this as as a valid padding length. The preceding fifteen bytes have also probably been changed, but the server will then strip off and ignore those values -- since SSLv3 doesn't care about the contents of the padding. No other parts of the ciphertext have been altered, so decryption will work perfectly and the server should report no errors. This case is deeply meaningful to us. If this happens, we know that the decipherment of the final byte of C_n, XORed with the final byte of the preceding ciphertext block, is equal to '15'. From this knowledge we can easily determine the actual plaintext value of the original byte we wanted to learn. We can recover this valueby XORing it with the final byte of the preceding ciphertext block, then XOR that with the last byte of the ciphertext block that precedes the original block we targeted. Voila, in this case -- which occurs with probability 1/256 -- we've decrypted a single byte of the cookie. The important thing to know is that if at first we don't succeed, we can try, try again. That's because each time we fail, we can re-run the SSL handshake (which changes the encryption key) and try the attack again. As long as the cookie byte we're attacking stays in the same position, we can continue our attempts until we get lucky. The expected number of attempts needed for success is 256. We've got one byte, how do we get the rest? The ability to recover a single byte doesn't seem so useful, but in fact it's all we need to decipher the entire cookie -- if we're able to control the cookie's alignment and location within the enciphered record. In this case, we can simply move one byte after another into that critical final-byte-of-the-cipher-block location and run the attack described above. One way to do this is to trick the victim's browser into running some Javascript we control. This script will make SSL POST requests to a secure site like Google. Each time it does so, it will transmit a request path first, followed by an HTTP cookie and other headers, followed by a payload it controls. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Source: Möller et al.[/TD] [/TR] [/TABLE] Since the script controls the path and payload, by varying these values and knowing the size of the intermediate headers, the script can systematically align each specific byte of the cookie to any location it wants. It can also adjust the padding length to ensure that the final block of the record contains 16 bytes of padding. This means that our attack can now be used to decrypt an entire cookie, with an average of 256 requests per cookie byte. That's not bad at all. So should we move to West Virginia and stock up on canned goods? Maybe. But I'm not so sure. For a few answers on what to do next, see Adam Langley and Rob Graham's blog posts on this question. Note that this entire vulnerability stems from the fact that SSLv3 is older than Methuselah. In fact, there are voting-age children who are younger than SSLv3. And that's worrying. The obvious and correct solution to this problem is find and kill SSLv3 anywhere it lurks. In fact, this is something we should have done in the early 2000s, if not sooner. We can do it now, and this whole problem goes away. The problem with the obvious solution is that our aging Internet infrastructure is still loaded with crappy browsers and servers that can't function without SSLv3 support. Browser vendors don't want their customers to hit a blank wall anytime they access a server or load balancer that only supports SSLv3, so they enable fallback. Servers administrators don't want to lock out the critical IE6 market, so they also support SSLv3. And we all suffer. Hopefully this will be the straw that breaks the camel's back and gets us to abandon obsolete protocols like SSLv3. But nobody every went bankrupt betting on insecurity. It's possible that ten years from now we'll still be talking about ways to work around POODLE and its virulent flesh-eating offspring. All we can do is hope that reason will prevail. Posted by Matthew Green at 8:26 PM Sursa: A Few Thoughts on Cryptographic Engineering: Attack of the week: POODLE

Mda, am vrea noi Poate pe blackmarket-urile rusesti la ceva sute de mii de dolari.

Microsoft Patches 3 Zero-day Vulnerabilities actively being Exploited in the Wild Wednesday, October 15, 2014 Swati Khandelwal As part of monthly patch update, Microsoft released eight security bulletins on Tuesday that address dozens of vulnerabilities including a zero-day flaw reportedly being exploited by Russian hackers to target NATO computers and a pair of zero-day Windows vulnerabilities that attackers have been exploiting to penetrate major corporations' networks. Just a day before yesterday, our team reported you about a Zero-day vulnerability discovered by the cyber intelligence firm iSight Partners affecting all supported versions of Microsoft Windows and is being exploited in a five-year old cyber-espionage campaign against the Ukrainian government and U.S organisations. Researchers at FireEye found two zero-day flaws, used in separate, unrelated attacks involving exploitation of Windows kernel, just a day after iSight partners disclosed zero-day in Windows. The pair of zero-day vulnerabilities could allow an attacker to access a victim's entire system. According to the researchers at FireEye, the two of three so-called zero-day flaws are being actively exploited in the wild by hackers and are being used as "part of limited, targeted attacks against some major corporations." Microsoft updates for the month of October 2014 Patch Tuesday address several vulnerabilities in all currently supported versions of Windows, Internet Explorer, Office, Sharepoint Server and the .Net framework. Three of the bulletins are marked "critical" and rest are "important" in severity. Systems administrators are recommended to apply the patches immediately for the critical updates. The zero-day flaw (CVE-2014-4114) discovered by iSight partners in all supported versions of Microsoft Windows and Windows Server 2008 and 2012 that is being exploited in the "Sandworm" cyberattack, are patched as part of MS14-060. Microsoft rated Bulletin MS14-060 as important rather than critical because it requires a user to open a Microsoft Office file to initiate the remote code execution. "The vulnerability [exists in Windows OLE] could allow remote code execution if a user opens a Microsoft Office file that contains a specially crafted OLE object," Microsoft warned in its bulletin. "An attacker who successfully exploited this vulnerability could run arbitrary code in the context of the current user." (OLE is Microsoft technology for creating complex documents that contain a combination of text, sound, video and other elements.) However, the two zero-days discovered by FireEye are patched as part of MS14-058 and are marked critical. They are designated CVE-2014-4148 and CVE-2014-4113. "We have no evidence of these exploits being used by the same actors. Instead, we have only observed each exploit being used separately, in unrelated attacks," FireEye explained. CVE-2014-4148 exploits a vulnerability in TrueType Font (TTF) processing. TTF processing is performed in kernel mode as part of the GDI and has been the source of critical vulnerabilities in the past as well. The vulnerability affects Windows 8.1/Windows Server 2012 R2, Windows 8/Windows Server 2012, Windows 7/Windows Server 2008 R2 (Service Pack 0 and 1) and Windows XP Service Pack 3. It affects both 32-bit and 64-bit versions of the Operating System, but the attacks have only been observed against 32-bit systems. However, CVE-2014-4113 is a local Elevation of Privilege (EoP) vulnerability that affects all versions of Windows including Windows 7, Vista, XP, Windows 2000, Windows Server 2003/R2, Windows Server 2008/R2, Windows 8.x and Windows Server 2012/R2. Out of remaining bulletins, two are rated critical, both address remote code execution vulnerability in Internet Explorer and Microsoft .NET Framework respectively. Remaining bulletins are rated important in severity, include elevation of privilege bugs, Security Feature Bypass, and a remote code execution flaw. Sursa: Microsoft Patches 3 Zero-day Vulnerabilities actively being Exploited in the Wild Faceti update!

I-am contactat pe cei de la Arrow Electronics si: "this company is not affiliated with Arrow in any way and our legal team has taken steps to have our name removed from their website. thank you for alerting us of this issue."

Dorian Prodan - 15 oct 2014 2014 nu a fost un an prea grozav din punct de vedere al securit??ii, acesta fiind marcat de descoperirea unor bre?e majore de securitate precum Heartbleed sau Shellshock ?i compromiterea repetat? a datelor private ale utilizatorilor. Pe lista ve?tilor nepl?cute se mai adaug? o noutate, un grup de trei cercet?tori din cadrul Google anun?ând ieri descoperirea unei noi bre?e de securitate în cadrul protocolului de criptare SSLv3 care poate fi exploatat? pentru sustragerea datelor personale din toate browsere-le Web prezente pe pia??. Protocolul de criptare SSL nu este pentru prima oar? subiectul unor astfel de ?tiri, o parte din echipa de cercetare Google care a descoperit noua vulnerabilitate având meritul de a fi descoperit ?i alte dou? metode de exploatare a vulnerabilit??ilor din acela?i protocol în 2011 ?i 2012: BEAST ?i CRIME. Denumit? POODLE, adic? Padding Oracle On Downgraded Legacy Encryption, noua metod? de atac vizeaz? protocolul de criptare SSLv3 ?i permite organizarea unui atac de tip Man-in-the-middle prin care se pot sustrage datele utilizatorilor care sunt transferate securizat prin HTTPS. SSLv3 este, din punct de vedere tehnologic, o antichitate care a fost înlocuit? de mult? vreme de TLS (1.0, 1.1 sau 1.2). În mod normal, atunci când un serviciu Web ?i un browser negociaz? parametrii stabilirii unei conexiuni securizate HTTPS, acestea aleg cea mai puternic? criptare disponibil? pe care ambele o pot în?elege. În cele mai multe cazuri, este vorba de TLS, îns? unele browsere sau servicii Web vechi nu implementeaz? deloc acest protocol sau au o implementare defectuoas?, iar SSL este urm?toarea solu?ie aleas?. Pentru a p?stra aceast? compatibilitate, chiar ?i browser-ele moderne includ în continuare compatibilitatea cu vechiul protocol SSL, iar cercet?torii au exploatat tocmai prezen?a acesteia pentru a pune la punct atacul POODLE. Putând fi ini?iat, de pild?, pe un punct de acces wireless, atacul p?c?le?te într-o prim? faz? serviciul Web ?i-l face s? cread? c? protocolul de criptare TLS este indisponibil. Dup? ce protocolul SSLv3 este selectat ca solu?ie alternativ?, atacatorii încep s? modifice pachetele HTTPS ?i, prin încerc?ri repetate care au o rat? de succes de 1:256, ob?in bit cu bit întregul fi?ier cookie securizat al sesiunii. Odat? afla?i în posesia acestuia, atacatorii pot impersona utilizatorul legitim ?i ob?ine acces deplin la serviciul online ?i la datele utilizatorilor. Deoarece SSLv3 este implementat atât la nivelul clien?ilor cât ?i al serverelor, singura rezolvare este renun?area treptat? la suportul pentru acesta. CloudFlare a anun?at deja c? va elimina suportul SSLv3 de pe serverelor lor, iar Google ?i Mozilla au anun?at c?-l vor elimina din browser-ele lor în lunile urm?toare. Pân? atunci, utilizatorii pot dezactiva complet suportul din browser-ele Internet Explorer, Mozilla Firefox sau Google Chrome (instruc?iuni aici ?i aici). Aceast? eliminare a suportului SSLv3 va afecta utilizatorii browser-elelor vechi precum Internet Explorer 6, îns? CloudFlare afirm? c? traficul SSLv3 reprezint? doar 0,65 din cel global, deci impactul s-ar putea dovedi a fi mult mai mic decât am fi crezut la o prim? vedere. Sursa: POODLE: un protocol de criptare antic pune în pericol browser-ele moderne

[h=1]Black Hat USA 2014 - Windows: Windows Kernel Graphics Driver Attack Surface[/h]

[h=1]Black Hat USA 2014 - Windows: Abusing Microsoft Kerberos Sorry You Guys Don't Get It[/h]

[h=1]Black Hat USA 2014 - SCADA: Why Control System Cyber Security Sucks[/h]

[h=1]Black Hat USA 2014 - SCADA: Bringing Software Defined Radio to the Penetration Testing Community[/h]

[h=1]Black Hat USA 2014 - Reverse Engineering: SATCOM Terminals Hacking by Air, Sea, and Land[/h]

[h=1]Black Hat USA 2014 - Reverse Engineering: Reverse Engineering Flash Memory for Fun and Benefit[/h]

[h=1]Black Hat USA 2014 - Reverse Engineering: Capstone Next Generation Disassembly Framework[/h]

[h=1]Black Hat USA 2014 - Policy: Nobody is Listening to Your Phone Calls Really A Debate & Discussion[/h]

[h=1]Black Hat USA 2014 - Policy: Governments As Malware Authors The Next Generation[/h]

[h=1]Black Hat USA 2014 - Network: Multipath TCP Breaking Today's Networks with Tomorrow's Protocols[/h]

[h=1]Black Hat USA 2014 - Network: Internet Scanning Current State and Lessons Learned[/h]

[h=1]Black Hat USA 2014 - Network: 802.1x and Beyond![/h]

[h=1]Black Hat USA 2014 - Mobile: Unwrapping the Truth Analysis of Mobile Application Wrapping Solutions[/h]