Leaderboard

Tu crezi ca Elvetia e Teleorman =))) Acum doi ani au vrut sa faca transportul public gratuit si s-au opus cetatenii.

Autoritățile Elvețiene contestă pe oricine să-și spargă votul electoral. Un mod ciudat de a asigura securitatea sistemului lor. Și pentru a motiva hackerii, Elveția promite o recompensă de 150.000 de franci, sau 132.000 €, celor care vor ajunge acolo. Evenimentul va fi organizat în condițiile realității, între 25 februarie și 24 martie, cu un vot fals. Participanții trebuie să se înregistreze în prealabil pe acest site https://onlinevote-pit.ch/ . Cancelaria Federală afirmă în comunicatul său că hackerii vor " încerca să manipuleze voturile, să citească voturile exprimate, să încalce secretul votării și dezafectării sau să ocolească dispozitivele de securitate care protejează voturile. acele date inerente securității". Hackerii care intră în sistemul de vot vor împărți prada în funcție de nivelul lor de hacking. Oricine reușește să manipuleze voturile nedetectabil va câștiga jackpot-ul, și anume 50.000 de franci elvețieni. Cei care reușesc să încalce secretul votului vor câștiga 10.000 de franci pentru a împărți, în timp ce cei care distrug sistemul de vot electronic vor fi recompensați cu 5.000 de franci elvețieni. Din 2004, votul electronic a fost testat în Elveția și pare să atragă tot mai mulți alegători. Secțiile de votare tradiționale sunt din ce în ce mai puține, în avantajul e-mailurilor sau corespondenței, prin intermediul oficiului poștal. În 2018, guvernul a încheiat faza de testare și a inițiat un proces pentru ca votarea electronică să fie al treilea canal de votare. Acest lucru ar trebui să dureze doi ani. Rețineți că competiția este deschisă tuturor și va fi disponibilă în franceză, germană, italiană, romană, precum și documentație în limba engleză. Source : https://geeko.lesoir.be/

Super Mario Oddity A few days ago, I was investigating a sample piece of malware where our static analysis flagged a spreadsheet as containing a Trojan but the behavioural trace showed very little happening. This is quite common for various reasons, but one of the quirks of how we work at Bromium is that we care about getting malware to run and fully detonate within our secure containers. This enables our customers to understand the threats they are facing, and to take any other remedial action necessary without any risk to their endpoints or company assets. Running their malware actually makes our customers more secure. A quick look at the macros in this spreadsheet revealed that it was coded to exit Excel immediately if the machine was not based in Italy (country 39): We often see malware samples failing to run based on location, but usually they look for signs of being in Russia. This is widely believed to help groups based there avoid prosecution by local authorities, but of course leads to false-flag usage too. My interest was piqued, so I modified the document to remove this check so it would open and then I could see if we could get the malware to detonate. The usual social engineering prompt is displayed on opening: Roughly translated as ‘It’s not possible to view the preview online. To view the content, you need to click on “enable edit” and “enable content”’. After modifying the spreadsheet, the malware detonates inside one of our containers. We see the usual macro-based launch of cmd.exe and PowerShell with obfuscated arguments. This is very run-of-the-mill, but these arguments stood out as not being from one of the usual obfuscators we see, so I was determined to dig a bit deeper: (truncated very early) As a side note, malware authors actually spend quite a lot of effort on marketing, including often mentioning specific researchers by name within samples. This happens because of the nature of modern Platform Criminality – malware is licensed to affiliates for distribution, and in order to attract the most interest and best prices malware authors need to make a name for themselves. It’s not clear whether or not this sample was actually trying to encourage me to investigate or not, but sometimes huge clues like this are put into samples on purpose. The binary strings are just a list of encoded characters, so this was easily reconstructed to the following code, which looks like PowerShell: At this point, things seemed particularly interesting. My PowerShell skills are basic, but it looks like this sample is trying to download an image and extract some data from the pixel values. There was only one person to turn to – our PowerShell evangelist and polymath Tim Howes, who was also intrigued. Meanwhile, I pulled the images, with each looking roughly like this: (I’ve slightly resized and blurred). Steganographic techniques such as using the low-bits from pixel values are clearly not new, but it’s rare that we see this kind of thing in malspam; even at Bromium, where we normally see slightly more advanced malware that evaded the rest of the endpoint security stack. It’s also pretty hard to defend against this kind of traffic at the firewall. Now over to Tim to make sense of the PowerShell plumbing. A manual re-shuffle to de-obfuscate the code and you can see more clearly the bitwise operation on the blue and green pixels. Since only the lower 4 bits of blue and green have been used, this won’t make a big difference to the image when looked at by a human, but it is quite trivial to hide some code within. Recasting the above code to a different form makes slightly more sense of where in the image we’re extracting from: This equates to the area in blue at the top of the image here: The above code is finding the next level of code from the blue and green channel from pixels in a small region of the image. The lower bits of each pixel are used as adjustments to these and yield minimal differences to the perceived image. Running this presents yet more heavily obfuscated PowerShell: We can work through this by noticing that there is another large string (base64 encoded) sliced/diced into 40 parts. This can be reassembled: Looking at the above, we see they are using a .net decompressor; so employing our own local variables to step through each part yields: This gives a resultant stream of yet more PowerShell: We execute the “-split” operations on the large string and then convert to a string: We now see that $str is still more mildly obfuscated PowerShell: There’s another slice/dice to form “iex” (the alias for invoke-expression in PowerShell): ($env:comspec)[4,15,25] == 'iex'. The manually de-obfuscated PowerShell reveals the final level which is dropping and executing from a site, but only if the output of ‘get-culture’ on the machine matches “ita” (for example if the culture is Italian, which matches the earlier targeting attempts). Thanks Tim! We downloaded the samples from the above, including from an Italy-based VPN and were given various samples of Gandcrab ransomware. Gandcrab has seen phenomenal success last year, initially being distributed by exploit kits and becoming especially prevalent in the Far East. I am generally skeptical of malware attribution claims, and the implications of so much obfuscated code hidden within a picture of Mario and checking for an Italian victim are not obvious; for all we know the fictional Wario may be as likely to be responsible as any geopolitical actor. However, a future avenue for investigation here is to examine the encoded affiliate IDs, and compare against samples we have collected from other sources to see if there are patterns for whom this affiliate is targeting. Another key forensic advantage that we have at Bromium is that we partition our isolation at the granularity of a user task (in this instance, the opening of a piece of malspam from an email). This means we can associate each sample with lots of forensic metadata about the task the user was performing, simply because they are from the same container. Mining our set of Gandcrab samples to track the behaviour of their affiliates is definitely a task for another day. Whether or not they are based in a targeted country, our users can open malicious emails safely and transparently with Bromium as our hardware-enforced containers securely isolate the malware from the host system (our princess is in another castle). IOCs: Original Spreadsheet: 3849381059d9e8bbcc59c253d2cbe1c92f7e1f1992b752d396e349892f2bb0e7 Mario image: 2726cd6796774521d03a5f949e10707424800882955686c886d944d2b2a61e0 Other Mario image: 0c8c27f06a0acb976b8f12ff6749497d4ce1f7a98c2a161b0a9eb956e6955362 Ultimate EXEs: ec2a7e8da04bc4e60652d6f7cc2d41ec68ff900d39fc244cc3b5a29c42acb7a4 630b6f15c770716268c539c5558152168004657beee740e73ee9966d6de1753f February 8, 2019 • Category: Threats • By: Matthew Rowen Sursa: https://www.bromium.com/gandcrab-ransomware-code-hiding-in-image/

Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries On November 30, 2018. We disclosed CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869, and CVE-2018-16870. These were from vulnerabilities found back in August 2018 in several TLS libraries. Back on May 15, I approached Yuval Yarom with a few issues I had found in some TLS implementations. This led to a collaboration between Eyal Ronen, Robert Gillham, Daniel Genkin, Adi Shamir, Yuval Yarom and me. Spearheaded by Eyal, the research has now been published here. And as you can see, the inventor of RSA himself is now recommending you to deprecate RSA in TLS. We tested nine different TLS implementations against cache attacks and seven were found to be vulnerable: OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS. The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL. The attack leverages a side-channel leak via cache access timings of these implementations in order to break the RSA key exchanges of TLS implementations. The attack is interesting from multiple points of view (besides the fact that it affects many major TLS implementations): It affects all versions of TLS (including TLS 1.3) and QUIC. Where the latter version of TLS does not even offer an RSA key exchange! This prowess is achieved because of the only known downgrade attack on TLS 1.3. It uses state-of-the-art cache attack techniques. Flush+Reload? Prime+Probe? Branch-Predition? We have it. The attack is very efficient. We found ways to ACTIVELY target any browser, slow some of them down, or use the long tail distribution to repeatdly try to break a session. We even make use of lattices to speed up the problem. Manger and Ben-Or on RSA PKCS#1 v1.5. You heard of Bleichenbacher's million messages attack? Guess what, we found better. We use Manger's OAEP attack on RSA PKCS#1 v1.5 and even Ben-Or's algorithm which is more efficient than and was published BEFORE Bleichenbacher's work in 1998. I uploaded some of the code here. To learn more about the research, you should read the white paper. I will talk specifically about protocol-level exploitation in this blog post. Attacking RSA, The Origins Although the research of Ben-Or et al. was initially used to support the security proofs of RSA, it also outlined attacks on the protocol. Fifteen years later, in 1998, Daniel Bleichenbacher discovers a padding oracle and devises a unique and practical attack of his own on RSA. The consequences are severe. Most TLS implementations could be broken, and thus mitigations were designed to prevent Daniel's attack. Follows a long series of "re-discovery" in which the world realizes that it is not so easy to implement the advised mitigations: Bleichenbacher (CRYPTO 1998) also called the 1 million message attack, BB98, padding oracle attack on PKCS#1 v1.5, etc. Klima et al. (CHES 2003) Blei­chen­ba­cher’s At­tack Strikes Again: Brea­king PKCS#1 V1.5 In Xml En­cryp­ti­on (ESORICS 2012) Degabriele et al. (CT-RSA 2012) Bardou et al. (CRYPTO 2012) Cross-Tenant Side-Channel Attacks in PaaS Clouds (CCS 2014) Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks (USENIX 2014) On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption (CCS 2015) DROWN (USENIX 2016) Return Of Bleichenbacher's Oracle Threat (USENIX 2018) The Dangers of Key Reuse: Practical Attacks on IPsec IKE (USENIX 2018) Let's be realistic, the mitigations that developers had to implement were unrealistic. Furthermore, an implementation that would attempt to log such attacks would actually help the attacks. Isn't that funny? The research I'm talking about today can be seen as one more of these "re-discoveries." My previous boss' boss (Scott Stender) once told me: "You can either be the first paper on the subject, or the best written one, or the last one." We're definitely not the first one, I don't know if we write that well, but we sure are hoping to be the last one RSA in TLS? Briefly, SSL/TLS (except TLS 1.3) can use an RSA key exchange during a handshake to negotiate a shared secret. An RSA key exchange is pretty straight forward: The client encrypts a shared secret under the server's RSA public key, then the server receives it and decrypts it. If we can use our attack to decrypt this value, we can then passively decrypt the session (and obtain a cookie for example), or we can actively impersonate one of the peer. Attacking Browsers, In Practice. We employ the BEAST-attack model (in addition to being colocated with the victim server for the cache attack) which I have previously explained in a video here. Beast With this position, we then attempt to decrypt the session between a victim client (Bob) and bank.com: we can serve him with some javascript content that will continuously attempt new connections on bank.com. (If it doesn't attempt a new connection, we can force it by making the current one fail since we're in the middle.) Why several connections instead of just one? Because most browsers (except Firefox which we can fool) will time out after some time (usually 30s). If an RSA key exchange is negotiated between the two peers: it's great, we have all the time in the world to passively attack the protocol. If an RSA key exchange is NOT negotiated: we need to actively attack the session to either downgrade or fake the server's RSA signature (more on that later). This takes time, because the attack requires us to send thousands of messages to the server. It will likely fail. But if we can try again, many times? It will likely succeed after a few trials. And that is why we continuously send connection attempts to bank.com. Attacking TLS 1.3 Two ways exist to attack TLS 1.3. In each attack, the server needs to support an older version of the protocol as well. The first technique relies on the fact that the current server’s public key is an RSA public key, used to sign its ephemeral keys during the handshake, and that the older version of TLS that the server supports re-use the same keys. The second one relies on the fact that both peers support an older version of TLS with a cipher suite supporting an RSA key exchange. While TLS 1.3 does not use the RSA encryption algorithm for its key exchanges, it does use the signature algorithm of RSA for it; if the server’s certificate contains an RSA public key, it will be used to sign its ephemeral public keys during the handshake. A TLS 1.3 client can advertise which RSA signature algorithm it wants to support (if any) between RSA and RSA-PSS. As most TLS 1.2 servers already provide support for RSA , most will re-use their certificates instead of updating to the more recent RSA-PSS. RSA digital signatures specified per the standard are really close to the RSA encryption algorithm specified by the same document, so close that Bleichenbacher’s decryption attack on RSA encryption also works to forge RSA signatures. Intuitivelly, we have pmse and the decryption attack allows us to find (pmse)d = pms, for forging signatures we can pretend that the content to be signed tbs (see RFC 8446) is tbs = pmse and obtain tbsd via the attack, which is by definition the signature over the message tbs. However, this signature forgery requires an additional step (blinding) in the conventional Bleichenbacher attack. In practice this can lead to hundreds of thousands of additional messages. The TLS 1.3 signature forgery attack using a TLS 1.2 server as Bleichenbacher oracle. Key-Reuse has been shown in the past to allow for complex cross-protocol attacks on TLS. Indeed, we can successfully forge our own signature of the handshake transcript (contained in the CertificateVerify message) by negotiating a previous version of TLS with the same server. The attack can be carried if this new connection exposes a length or bleichenbacher oracle with a certificate using the same RSA key but for key exchanges. Downgrading to TLS 1.2 Every TLS connection starts with a negotiation of the TLS version and other connection attributes. As the new version of TLS (1.3) does not offer an RSA key exchange, the exploitation of our attack must first begin with a downgrade to an older version of TLS. TLS 1.3 being relatively recent (August 2018), most servers supporting it will also support older versions of TLS (which all provide support for RSA key exchanges). A server not supporting TLS 1.3 would thus respond with an older TLS version’s (TLS 1.2 in our example) serverHello message. To downgrade a client’s connection attempt, we can simply spoof this answer from the server. Besides protocol downgrades, other techniques exist to force browser clients to fallback onto older TLS versions: network glitches, a spoofed TCP RST packet, a lack of response, etc. (see POODLE) The TLS 1.3 attack downgrades the victim to an older version of TLS. Continuing with a spoofed TLS 1.2 handshake, we can simply present the server’s RSA certificate in a ServerCertificate message and then end the handshake with a ServerHelloDone message. At this point, if the server does not have a trusted certificate allowing for RSA key exchanges, or if the client refuse to support RSA key exchanges or older versions than TLS 1.2, the attack is stopped. Otherwise, the client uses the RSA public key contained in the certificate to encrypt the TLS premaster secret, sends it in a ClientKeyExchange message and ends its part of the handshake with a ChangeCipherSpec and a Finished messages. The Decryption Attack performs a new handshake with the server, using a modified encrypted premaster secret obtained from the victim’s ChangeCipherSpec message. At this point, we need to perform our attack in order to decrypt the RSA encrypted premaster secret. The last Finished message that we send must contains an authentication tag (with HMAC) of the whole transcript, in addition of being encrypted with the transport keys derived from the premaster secret. While some clients will have no handshake timeouts, most serious applications like browsers will give up on the connection attempt if our response takes too much time to arrive. While the attack only takes a few thousand messages, this might still be too much in practice. Fortunately, several techniques exist to slow down the handshake: we can send the ChangeCipherSpec message which might reset the client’s timer we can send TLS warning alerts to reset the handshake timer Once the decryption attack terminates, we can send the expected Finished message to the client and finalize the handshake. From there everything is possible, from passively relaying and observing messages to the impersonated server through to actively tampering requests made to it. This downgrade attack bypasses multiple downgrade mitigations: one server-side and two client-side. TLS 1.3 servers that negotiate older versions of TLS must advertise this information to their peers. This is done by setting a quarter of the bytes from the server_random field in the ServerHello message to a known value. TLS 1.3 clients that end up negotiating an older version of TLS must check for these values and abort the handshake if found. But as noted by the RFC, “It does not provide downgrade protection when static RSA is used.” – Since we alter this value to remove the warning bytes, the client has no opportunity to detect our attack. On the other hand, a TLS 1.3 client that ends up falling back to an older version of TLS must advertise this information in their subsequent client hellos, since we impersonate the server we can simply ignore this warning. Furthermore, a client also includes the version used by the client hello inside of the encrypted premaster secret. For the same reason as previously, this mitigation has no effect on our attack. As it stands, RSA is the only known downgrade attack on TLS 1.3, which we are the first to successfuly exploit in this research. Attacking TLS 1.2 As with the previous attack, both the client and the server targetted need to support RSA key exchanges. As this is a typical key exchange most known browsers and servers support them, although they will often prefer to negotiate a forward secret key exchange based on ephemeral versions of the Elliptic Curve or Finite Field Diffie-Hellman key exchanges. This is done as part of the cipher suite negotiation during the first two handshake messages. To avoid this outcome, the ClientHello message can be intercepted and modified to strip it out of any non-RSA key exchanges advertised. The server will then only choose from a set of RSA-key-exchange-based cipher suites which will allow us to perform the same attack as previously discussed. Our modification of the ClientHello message can only be detected with the Finished message authenticating the correct handshake transcript, but since we are in control of this message we can forge the expected tag. The attack on TLS 1.2 modifies the client’s first packet to force an RSA key exchange. On the other side, if both peers end up negotiating an RSA key exchange on their own, we can passively observe the connection and take our time to break the session. Take Aways For each vulnerability discovered, there are three pieces of articles you can read: the first paper, the best explanation on the subject, and finally the last paper. We're hoping to be the last paper. The last 20 years of attacks that have been re-discovering Bleichenbacher's seminal work in 1998 clearly show that it is close to impossible to correclty implement the RSA PKCS#1 v1.5 encryption scheme. While our paper recommends a series of mitigations, it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP and ECEIS for asymmetric encryption or Elliptic Curve Diffie-Hellman for key exchanges. Finally, we note that keyless implementations of TLS are attractive targets, but are most often closed source and thus were not analyzed in this work. Published date: 07 February 2019 Written by: David Wong Sursa: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in-major-tls-libraries/

Machine Learning for Everyone In simple words. With real-world examples. Yes, again 21 november 2018 :: 28834 views :: 8137 words This article in other languages: Russian (original) Special thanks for help: @wcarss, @sudodoki and my wife ❤️ Machine Learning is like sex in high school. Everyone is talking about it, a few know what to do, and only your teacher is doing it. If you ever tried to read articles about machine learning on the Internet, most likely you stumbled upon two types of them: thick academic trilogies filled with theorems (I couldn’t even get through half of one) or fishy fairytales about artificial intelligence, data-science magic, and jobs of the future. I decided to write a post I’ve been wishing existed for a long time. A simple introduction for those who always wanted to understand machine learning. Only real-world problems, practical solutions, simple language, and no high-level theorems. One and for everyone. Whether you are a programmer or a manager. Let's roll. Why do we want machines to learn? This is Billy. Billy wants to buy a car. He tries to calculate how much he needs to save monthly for that. He went over dozens of ads on the internet and learned that new cars are around $20,000, used year-old ones are $19,000, 2-year old are $18,000 and so on. Billy, our brilliant analytic, starts seeing a pattern: so, the car price depends on its age and drops $1,000 every year, but won't get lower than $10,000. In machine learning terms, Billy invented regression – he predicted a value (price) based on known historical data. People do it all the time, when trying to estimate a reasonable cost for a used iPhone on eBay or figure out how many ribs to buy for a BBQ party. 200 grams per person? 500? Yeah, it would be nice to have a simple formula for every problem in the world. Especially, for a BBQ party. Unfortunately, it's impossible. Let's get back to cars. The problem is, they have different manufacturing dates, dozens of options, technical condition, seasonal demand spikes, and god only knows how many more hidden factors. An average Billy can't keep all that data in his head while calculating the price. Me too. People are dumb and lazy – we need robots to do the maths for them. So, let's go the computational way here. Let's provide the machine some data and ask it to find all hidden patterns related to price. Aaaand it works. The most exciting thing is that the machine copes with this task much better than a real person does when carefully analyzing all the dependencies in their mind. That was the birth of machine learning. Articol complet: https://vas3k.com/blog/machine_learning/

eLearnSecurity PNDv1 (Practical Network Defense) https://mega.nz/#F!2qgSWChL!tSGdtQLlq60MCGqpCtt-aw