Jump to content

Search the Community

Showing results for tags 'ssl'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 14 results

  1. Threats using SSL encryption are on the rise. An average of 60 percent of the transactions in the Zscaler cloud have been delivered over SSL/TLS. Researchers also found that the Zscaler cloud saw an average of 8.4 million SSL/TLS-based security blocks per day this year. “Hackers are increasingly using SSL to conceal device infections, shroud data exfiltration and hide botnet command and control communications. In fact, our study found that the amount of phishing attempts per day delivered over SSL/TLS has increased 400 percent from 2016,” said Deepen Desai, senior director, security research and operations. Malicious payload distributions ThreatLabZ researchers also identified new malicious payload distributions, based off unique payloads hitting the Zscaler Cloud Sandbox, leveraging SSL/TLS for command and control (C&C) activity. Banking Trojans comprised 60 percent of the payloads, including families like Dridex, Zbot, Vawtrak and Trickbot, while 25 percent were comprised of multiple ransomware families. Less popular payloads included Infostealer Trojan families and other miscellaneous families. Additional findings The amount of malicious content being delivered over SSL/TLS has more than doubled in the last six months. The Zscaler cloud blocked an average of 12,000 phishing attempts per day delivered over SSL/TLS—an increase of 400 percent from 2016. New, increasingly sophisticated malware strains use SSL to encrypt their C&C mechanisms. Zscaler saw an average of 300 hits per day for web exploits that included SSL as part of the infection chain. The most prevalent malware family leveraging SSL-based callbacks was Dridex/Emotet, which contributed 34 percent of the total unique, new payloads in 2017. New malicious payloads leveraging SSL/TLS for C&C activity: 60 percent were comprised of multiple Banking Trojan families (Zbot, Vawtrak, Trickbot, etc.) 25 percent were comprised of ransomware families 12 percent were comprised of Infostealer Trojan families (Fareit, Papras, etc.) 3 percent were from other miscellaneous families. Article source
  2. A majority of the top 1 million websites earn an “F” letter grade when it comes to adopting defensive security technology that protect visitors from XSS vulnerabilities, man-in-the-middle attacks, and cookie hijacking. The failing grades come from a comprehensive analysis published this week by the Mozilla Foundation using its Mozilla Observatory tool. According to a scan of Alexa ranked top 1 million websites, a paltry 0.013 percent of sites received an “A+” grade compared to 93.45 percent earning an “F”. The Observatory tool, launched last year, tests websites and grades their defensive posture based on 13 security-related features ranging from the use of encryption (HTTPS), exposure to XSS attacks based on the use of X-XSS-Protection (XXSSP) and use of Public Key Pinning which prevents a site’s use of fraudulent certificates. The silver-lining to the bad grades is that in the year since the Observatory tool began grading sites, security has improved. Compared to scans conducted between April 2016 and June 2017 the percentage of sites earning a “B” have jumped 142 percent and those earning a “C” have increased 90 percent. “It’s very hard if you’re just someone running a website to make it secure,” said April King, staff security engineer at Mozilla and developer of the Observatory tool. “There are so many different security standards. The documentation for those standards are scattered all over the place. There are not a lot of single resources that are telling you straight-up what you need to do.” King said she is encouraged at the pace of improvement when it comes to specific defensive tools. For example, the percentage of sites that support HTTPS has grown 36 percent in the past year. “The number might seem small, but it represents over 119,000 top websites,” she told Threatpost. Other security wins include a 125 percent increase in the number of sites that have adopted Content Security Policy (CSP), a browser feature that fends off Cross Site Scripting (XSS) and data injection attacks. Another win has been a 117 percent increase in adoption of Subresource Integrity (SRI), a verification feature that ensures when a browser fetches resources from third parties, such as a content delivery network, the content is not manipulated in transit. However, despite triple-digit growth in both CSP and SRI adoption, still less than one percent of sites still have adopted these security features. King concedes that achieving a secure website configuration, using all the available technologies developed in recent years by browser makers, is not easy. “I’m extremely optimistic. With tools that are free and easy to use, like Observatory, we can begin to see a common framework for building websites. This type of tool is pushing awareness back into the tool chain and making it very easy for people to implement,” King said. King likens Observatory to Qualys SSL Labs’ SSL Server Test, a free tool that analyses the configuration of SSL web servers. Observatory goes way beyond checking a website’s TLS implementation and checks for 13 different web security mechanisms. The scoring system is based on a 0 to 100 point scheme. Scores don’t just check for the presence of any given technology, but the correct implementation as well. Observatory is a tough grader, King said, because it’s designed to be a teaching tool to help administrators across the industry “become aware of the myriad technologies that standard bodies and browser companies have designed and implemented to improve the safety of the internet’s citizens.” “The fact that so many new sites have started using these technologies recently is a strong sign that we are beginning to succeed in that mission,” she said. Article source
  3. Despite 39 percent of businesses suffering an SSL-based attack in 2016, only 25 percent feel confident in their ability to deal with one according to a new study. The report from cyber security company Radware shows that cyber attacks are becoming the norm, with 98 percent of organizations experiencing some form of attack in 2016. SSL attacks though are of particular concern. SSL provided the backbone of eCommerce, though the Heartbleed attacks of three years ago have led many companies to switch to alternatives like TLS. For attackers though SSL offers a way to mask attack traffic and thwart malware detection in both network and application level threats. The use of SSL makes it harder to detect attacks as many existing solutions don't inspect SSL traffic because of the difficulty of decrypting it. Radware's data suggests SSL attacks have increased by 10 percent over the last year. The report's authors note, "SSL is both a blessing and a curse: blessing because it solves the privacy problem and secures the communication of sensitive information; curse because it creates new blind spots and vulnerabilities into an enterprise IT infrastructure." In order to protect themselves Radware say that organizations should aim to decrypt and re-encrypt SSL sessions to enable security inspection of both clear and encrypted traffic while maintaining privacy of content en-route. Any SSL inspection solution also needs to be able to selectively forward traffic to one or more security solutions. This needs careful implementation though as any solution must dynamically define filters that intercept and open traffic for inspection even if it flows through non-standard TCP ports (such as HTTPS port 443). To avoid turning the SSL traffic inspection solution into a target itself, it must not perform like a proxy or have its own IP address. Any solution must also be scalable to cope with varying levels of traffic, and ensure traffic is always forwarded to the fastest-responding available security servers. You can find out much more in the full report which is available from the Radware website. Source
  4. Kaspersky is moving to fix a bug that disabled certificate validation for 400 million users. Discovered by Google's dogged bug-sleuth Tavis Ormandy, the flaw stems from how the company's antivirus inspects encrypted traffic. Since it has to decrypt traffic before inspection, Kaspersky presents its certificates as a trusted authority. If a user opens Google in their browser, for example, the certificate will appear to come from Kaspersky Anti-Virus Personal Root. The problem Ormandy identified is that those internal certificates are laughably weak. "As new leaf certificates and keys are generated, they're inserted using the first 32 bits of MD5(serialNumber||issuer) as the key ... You don't have to be a cryptographer to understand a 32bit key is not enough to prevent brute-forcing a collision in seconds. In fact, producing a collision with any other certificate is trivial," he writes here. Ormandy's bug report gave, by way of demonstration, a collision between Hacker News and manchesterct.gov: "If you use Kaspersky Antivirus in Manchester, Connecticut and were wondering why Hacker News didn't work sometimes, it's because of a critical vulnerability that has effectively disabled SSL certificate validation for all 400 million Kaspersky users." Kaspersky fixed the issue on December 28. Source
  5. Chrome 55 (latest beta build available via Chrome Canary) is introducing the ability to specifically flag a HTTP website as non secure. HTTP Website in Chrome 55 This is a pretty big step change in making encryption much more important for every site owner. There has been talk that Chrome will also introduce a warning for sites containing password fields but no HTTPS. At this time there is no difference with the standard HTTP website “Not Secure” warning. HTTP Website in Chrome 55 with password field It looks as though Chrome are slowly encouraging owners to go HTTPS even if they don’t think it is needed. More prominence is also given to sites deploying correctly configured HTTPS certificates. HTTPS Website in Chrome 55 Finally EV Certificates continue to highlight the organisation details providing additional validation and trust. EV Certificate in Chrome 55 Article source
  6. I occasionally see people ask why we're calling it TLS 1.3 when so much has changed, and I used to simply think that it was too bikesheddy to bother changing at this point. However, now that we've redone negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the new (new codepoints needed for old ciphers) and the new are not backwards compatible with the old (they'll just be ignored). We actually risk misconfiguration in the future if the distinction isn't made clear. I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major version seems more appropriate. Note that contrary to what some people seem to think, version numbers are not completely without meaning. To someone who doesn't really know/care that much what TLS is, making sure to use the latest major version of a security protocol carries more weight than a minor version. It also makes it clear that there are new features here (e.g. 0-RTT). There's some de facto standardization in versioning which does carry some useful information. We're not just dealing with programmers here; this stuff needs to be clear for managers and non-professionals. If we want to get everyone upgraded eventually, messaging is important. Specific proposed changes: * Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2) * Keep the version ID as { 3, 4 } (already weird counting; changing risks more intolerance) * Rename the new cipher suites to have a "TLS2_" prefix to be less confusing for the registry & end configuration * Add a sentence noting the development history here, and that all documents that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2) This is a relatively simple set of changes to make that I think can be beneficial in the long run, and is essentially just editorial. Rebranding might not be something everyone really wants to bother with, but if we expect this to be in use for a decade or more (whether we like it or not), we should probably make sure to be as clear as possible at the start. Article source
  7. Monitoring SSL Traffic Now Everyone's Concern: A10 Networks As the uptake of SSL grows, Tim Blombery, systems engineer at A10 Networks, said threat actors are increasingly leveraging SSL-based encryption to hide malicious activity. As usage of Secure Sockets Layer (SSL) moves beyond the login page or banking website and out into the wider web, Tim Blombery, Systems Engineer at security firm A10 Networks, believes monitoring SSL traffic should now be a concern for almost every company. Blombery believes that encryption is necessary to protect online data in transit from being compromised, but noted threats are always evolving. With over half of the traffic on the internet now encrypted with SSL, he said bad actors are leveraging SSL-based encryption to hide malicious activity from existing security controls and technology. Consequently, Blombery said this means enterprises have lost the ability to look at the traffic that is traversing their network, opening themselves up to attack. "This is becoming an increasing vector for attacks and compromises of networks," he said. "I think SSL offers a very pertinent threat at the moment." Blombery said attacks often arrive via the likes of a Gmail account, which is encrypted to the desktop, with someone unwittingly opening a file containing a cryptolocker. "Off they go, they've compromised that particular system and potentially the entire network," he said. "Having SSL visibility is vital for Australian enterprises and I think they're just starting to get that idea." As it often takes a breach for someone to jump on board with a specific security solution, Blombery said more and more Australian businesses are starting to become aware of the need to monitor SSL traffic because they have either been affected or heard of someone who has been affected by this sort of attack. "There are serious breaches regularly, but everyone's breach is serious for them," he said. "Even the smallest of companies needs to be security conscious these days." The hardware for SSL inspection is a device sitting on the perimeter taking the SSL offload, the company said, which decrypts traffic and then passes it on to the firewall or IPS. "Once those devices do their job, they hand the traffic back to our device to re-encrpyt and send on to the destination -- that's traffic coming in or out," Blombery said. With mandatory breach reporting laws not yet in place in Australia, Blombery noted that even if there was an abundance of breaches due to SSL traffic not inspected, the public might not even know about it. "For the individuals affected, you certainly want to know if your account or any account is being breached -- you should be informed," he added. "A lot of people silly enough have the same password for everything or the same subset of passwords, so if a company you're working with has been breached and you don't have that visibility, then potentially all of your online identity can be compromised." A10 Networks recently completed its first acquisition, scooping up cloud application delivery firm Appcito. "It really expands us into not just the cloud but as a cloud native company as well," Blombery said. "Appcito brings load balancing as-a-service, in the cloud functionality that we'll be able to tie in with our own existing infrastructure based functionality, and allow for common policy to support the applications whether they're in the datacentre or in the public cloud somewhere." Blombery said Appcito is already embedded within A10 and are essentially the cloud decision of the organisation. Source
  8. SSL is a great way to encrypt and protect data transferred between servers or between browser and servers from any attempt to spy on the data on its way or as known as man in the middle attack, we will focus in this article on HTTPS protocol and the method to attack it and proper way to fight against this attacks. Is HTTPS that important ? first let’s declare the importance of using SSL with HTTP traffic. Imagine the next scenario. you are trying to login to your bank account with your laptop connected in your wifi and you know its secure its you and your little sister who connect in the same wifi, secure right? ? but your wifi uses weak password or vulnerable to exploits, so someone gain access to the same wifi and with a simple tool he can run a packet sniffer and catch all your and your sister’s traffic and look into your password and even change the data if he wants. Imaging the same scenario but your bank is using HTTPS, when you access the website you receive the website certificate signed and your browser validate the signature to make sure that certificate belongs to the website, then your browser encrypt all data then send the encrypted data to the server and do it vice versa, so if our attacker try to sniff the data all what he will get is the encrypted data, cool right ? Lets be honest no one is 100% secure and SSL had a tough couple of years from attacks like Heartblead, DROWN and POODLE , this attacks target the SSL it self , all what you have to do to mitigate this attacks is to be up to date always and apply vendors patches as it appears. But what about sniffing dangerous, does using HTTPS solve it? the answer is not completely, some researchers tried to sniff HTTPS packages by inventing tools like SSL sniff and SSL strip. SSL sniff :- SSL sniff is tool programmed by Moxie Marlinspike based on vulnerability he discovered, let us quickly describe it. When you request a website for example ( example.com ) as we said before you receive the example.com certificate the certificate must be issued by one of the valid vendors, so if follow certificate chain from the root certificate ( root certificate embedded in the browsers by default) to the leaf certificate ( example.com certificate) but what if leaf certificate tried to generate another certificate in the chain? lets say to website like paypal.com! the surprising thing that it worked and no one bothered himself by checking that leaf certificate generated another leaf certificate, but how attacker can use this? the website still be example.com not paypal.com, and that’s why he made SSL Sniff tool. by intercepting the traffic (man in the middle attack) you will intercept the request to paypal.com and with SSL Sniff, then you can generate the paypal.com certificate from the leaf certificate you have example.com and send it back to the browser instead of original paypal.com certificate, when the browser try to validate the certificate it will pass because the chain is correct, then any request between the browser and the server will be signed by the certificate you generate so you can decrypt the data as you want, and then re-transfer it by using the original paypal.com certificate, Boom. fortunately it had been fixed and now the leaf certificate cannot generate another certificate. SSL Strip:- Another tool by the same man Moxie Marlinspike. but in this time he came up with another trick using man in the middle, but what if he changed the request to http instead of HTTPS, and he will request the website on behalf of the user using HTTPS but between the attacker and the user its plain http, and the user will not be so suspicious to notice the difference in his browser. How to defend against this techniques ? Using HTTPS only will not solve it completely, even if you restricted the connection to HTTPS only in the server side, the attacker still can force user to use HTTP by using SSL strip and you will not notice the request still HTTPS in your end, and here HSTS header comes. HTTP Strict Transport Security (HSTS) is a web security policy mechanism it tells the browser that he must only connect to the website using secure HTTPS connection. just send header like this from your server. Strict-Transport-Security: max-age=31536000 The key is Strict-Transport-Security that tells the browser or any other agent to strict the transportation to ssl . the value is maximum age to use this header in seconds 31536000 equal to one non-leap year. Then the user agent will automatically change any url to HTTPS before it send it to the server allowing only secure connections. Bottom line , using HTTPS comes with responsibilities , you must be up to date , patch your system if any vulnerability comes up, renew your certificate on time and don’t forget to use Strict-Transport-Security Policy. Article source
  9. SSL malware samples, C&C servers, grow manifolds Malware statistics from January 2014 to December 2015 The overall numbers of malware families employing SSL to protect their C&C server communications has gone up dramatically, a Blue Coat report reveals. Researchers say that both the number of malware samples detected each month and the total number of active C&C servers are on the rise. For both categories, the security firm says it observed a huge spike in SSL deployment starting with the end of 2015. The company says it analyzed cyber-criminal activity from January 2014 up to December 2015 and has used data from the SSL Blacklist site which keep tracks of abused or bad SSL certificates, often deployed in criminal activities. The report analyzed detections and the infrastructure of common malware families known to implement SSL to protect themselves. Some of these malware variants included names such as Dridex, KINS, Shylock, URLzone, TeslaCrypt, CryptoLocker, TorrentLocker, CryptoWall, Upatre, Gootkit, Geodo, Tinba, Gozi, VMZeus, Redyms, Vawtrack, Qadars, Spambot, Emotee, and Retefe. Number of C&C servers using SSL grows 200 times Researchers discovered that during the two-year period they analyzed, malware samples, employing SSL or not, have both gone up. Malware samples deploying SSL have always been smaller in numbers when compared to the overall number, but something changed in October 2015, when the number of malware using SSL has increased manifolds. Blue Coat researchers saw SSL malware numbers going from 500 samples detected per month to 29,000 in the span of two months. The same thing happened with the number of C&C servers that used SSL-protected connections to talk to their bots, which jumped from around 1,000 servers in Q1 2015 to 200,000 in Q3 2015. Blue Coat included considered C&C server any website or IP that crooks used as coordination points, malware download sites, data exfiltration points, and other Web-based operations points. SSL malware recorded a big jump just before the holidays last year "Looking at the timeframe of the spike, it coincided with the onset of the holiday season. As such, the spike could have been attributed to the launch of one or more large-scale campaigns with infrastructures based on those malware families," Blue Coat researchers noted. Researchers also pointed out that the number of C&C servers grew well before the malware sample spike, something that is realistic since criminal gangs need to set up their C&C server infrastructure before initiating malware campaigns. "What’s more, the massive jump in C&C servers is likely attributed to the malware utilizing Domain Generating Algorithms (DGA) for short-living Domains to build out a C&C infrastructure," the Blue Coat team said, explaining the humongous jump in numbers regarding C&C server numbers. Article source
  10. New research suggests encrypted traffic is becoming the go-to method for threat actors to hide malicious code. The use of encrypted traffic to disguise malware attempting to infiltrate user devices and enterprise networks has "significantly" risen over the past year, researchers say. According to cybersecurity firm Blue Coat, there was a visible increase in the use of SSL/TLS encryption standards born out of privacy worries. However, while many individuals are now using these protocols whenever possible, it appears that threat actors are also harnessing SSL to disguise their activities. On Sunday, the team said in a press release that over 2015, analysis revealed a 58 times increase in SSL-cloaked traffic in command and control servers (C&C), which are used to relay commands remotely to malware which has infected computer systems. In addition, Blue Coat says there was a 200 times increase in C&C servers using SSL last year, indicating "that SSL/TLS will be increasingly used in the future to hide attacks." This spike in usage will likely cause concern for IT and security professionals. Encryption, in itself, is a beneficial way to protect user privacy and keep communication masked and kept away from spying eyes -- whether this is law enforcement, snooping governments or cyberattackers -- however, it can also be used by threat actors to increase the severity of their attacks. Michael Fey, president and COO of Blue Coat Systems commented: Last week, Blue Coat announced support for SCADA (Supervisory Control and Data Acquisition) environments and additional anomaly detection in the firm's range of security solutions. Article source
  11. StartSSL faces another issue that lets attackers obtains SSL certificates for domains they don't own StartEncrypt service logo Thijs Alkemade, a security researcher for Dutch security firm CompuTest, has discovered multiple design and implementation flaws in StartEncrypt, a tool created by Israeli company StartCom for issuing free SSL certificates. StartCom, the CA (Certificate Authority) behind the StartSSL service, launched the StartEncrypt project on June 4, inspired by the success of the Let's Encrypt project. Users who want to deploy free StartSSL certificates can take advantage of their StartEncrypt offering. They only need to download a Linux client they're supposed to upload to their servers. This client performs a domain validation process, informs the StartSSL service, which then issues and installs an "Extended Validation" SSL certificate for the domain it has found running on the server it has just checked. StartEncrypt contains design and implementation flaws According to CompuTest, this validation process is flawed, and through a few tricks, it allows server owners to receive SSL certificates issued for other domains, such as Facebook, Google, Dropbox, etc., which can be sold on the black market or used in man-in-the-middle attacks. The first issue Alkemade discovered in the StartEncrypt client was a design-related problem linked to the fact that users could manually configure the folder from where the client would download a signature from the server. An attacker would only have to point the tool to a folder on their server holding the signature of another domain. These domain signatures can be extracted from any sites that allow users to upload files: GitHub, Dropbox, etc.. StartEncrypt bug combined with OAuth 2.0 protocol condition The second issue is far more serious because it enabled an attacker to obtain SSL certificates for even more domains than the ones before. According to the researcher, one of the API verification calls contains a parameter dubbed "verifyRes," which takes a URL as input. This means the client was exposed to Open Redirect vulnerabilities. In other words, an attacker could forge this request and point the tool off-domain to a server not under their control. But this feature is not that easily exploitable. The domain URL to which the attacker needs to point the tool must (1) allow users to upload files and serve them back in raw format; or (2) to contain an Open Redirect issue of its own. While the first condition was quite rare, the second was not. All websites that support OAuth 2.0, a specification that powers social login features, must allow open redirects for the protocol to function properly. A crook leveraging this OAuth 2.0 condition and the StartEncrypt client could fool the StartSSL service into issuing a free SSL service in their name for any site that provides OAuth 2.0 support, such as Facebook, Twitter, Yahoo, Microsoft, and so on. Multiple other issues discovered as well Additionally, CompuTest also found that StartEncrypt doesn't check its own server's certificate for validity when connecting to the API, meaning crooks could receive verification requests and issue false SSL certificates for users trying to use StartEncrypt. The API also doesn't check the content type of the file it downloads for verification, so attackers can obtain certificates in the name of third-party websites where users can upload their avatars. At the same time, the certificate private key, which must be private, is stored with 0666 permissions in a public folder, so everyone could read it. Furthermore, just like Let's Encrypt, StartEncrypt is vulnerable to a Duplicate-Signature Key Selection attack. "In our opinion, StartCom made a mistake by publishing StartEncrypt the way it is," CompuTest's Christiaan Ottow explains. "Although they appreciated the issues for the impact they had and were swift in their response, it is apparent that too little attention was paid to security both in design (allowing the user to specify the path) and implementation (for instance in following redirects, static linking against a vulnerable library, and so on). Furthermore, they didn’t learn from the issues LetsEncrypt faced when in beta." StartCom has released a new version of the StartEncrypt Linux client, with the same version number CompuTest says they reported other issues to the service, which are still being corrected and will be fixed in future updates. Back in March, StartSSL faced a similar issue with its general service, which also allowed crooks to receive SSL certificates for domains they didn't own. Article source
  12. Banker Trojans have proven to be reliable and effective tools for attackers interested in quietly stealing large amounts of money from unwitting victims. Zeus, Carberp and many others have made piles of money for their creators and the attackers who use them, and researchers have been looking at a newer banker Trojan that has the ability to bypass SSL protection for banking sessions by redirecting traffic through the attackers’ own domains. The Trojan, which is being called either Dyre or Dyreza by researchers, uses a technique known as browser hooking to intercept traffic flowing between the victim’s machine and the target Web site. The malware arrives in users’ inboxes through spam messages, many of which will look like messages from a financial institution. The list of targeted banks includes Bank of America, Natwest, Citibank, RBS and Ulsterbank. Researchers say that much of the activity from the Trojan so far is in the U.K. When a victim opens the attached zip file in a spam message, the malware installs itself on the machine and then contacts a command-and-control server. Researchers at CSIS in Denmark located a couple of the C2 servers and discovered that one of them had an integrated money mule panel for several accounts in Latvia. The goal of the malware, of course, if to steal users’ credentials for online banking and other financial sites. Various banker Trojans go about this in different ways, and Dyreza’s creators decided to employ browser hooking to help defeat SSL. “The traffic, when you browse the Internet, is being controlled by the attackers. They use a MiTM (Man in The Middle) approach and thus are able to read anything, even SSL traffic in clear text. This way they will also try to circumvent 2FA,” an analysis by Peter Kruse at CSIS says. When users go to one of the targeted financial sites and attempt to log in, the data is intercepted by the malware and sent directly to the attackers. Victims would not have any visual cues that their data is being siphoned off or that the malware is redirecting their traffic to a domain controlled by the attackers and it’s no longer encrypted. “Here’s the kicker. All of this should be encrypted and never seen in the clear. By using a sleight of hand, the attackers make it appear that you’re still on the website and working as HTTPS. In reality your traffic is redirected to the attackers page,” anotheranalysis by Ronnie Tokazowski of PhishMe says. “To successfully redirect traffic in this manner, the attackers need to be able to see the traffic prior to encryption, and in the case of browsers, this is done with a technique called browser hooking. No DNS queries were performed for the c1sh Bank of America domain, suggesting the attackers simply appended this to the Host field in the network traffic.” The Dyreza malware has the ability to hook Google Chrome, Mozilla Firefox and Internet Explorer. Dyreza’s creators decided to employ browser hooking to help defeat SSL. Source
  13. The movement by technology companies to encrypt their respective corners of the Internet continues to gain steam as more and more are enabling SSL and other encryption technologies such as Perfect Forward Secrecy to ward off surveillance and enhance the privacy and security of user data. WordPress on Thursday became the latest to promise to encrypt its traffic by default. The popular blog and content management platform said it plans to have all wordpress.com subdomains served only over SSL by the end of 2014. “In the face of intrusive surveillance, we believe that everyone in the tech community needs to stand up and do what they can, starting with their own sites and platforms,” said Paul Sieminski, general counsel at Automattic, parent company to WordPress, Cloudup, Simplenote and other web-based development platforms. The announcement came on the anniversary of the first news reports describing the depths of NSA surveillance, also known as Reset the Netday, a coordinated movement urging websites to encrypt traffic using SSL, HSTS and PFS, applications to also deploy SSL and certificate pinning, and promoting privacy tools such as Tor for users interested in keep Web traffic private. Despite yesterday’s announcement, WordPress remains a laggard among its technology provider peers. According to the Electronic Frontier Foundation’s running tally on encryption, calledEncrypt the Web, WordPress does not support HTTPS Strict, also known as HSTS, nor does it support STARTTLS. The EFF was also unable to determine whether WordPress supports Perfect Forward Secrecy, or whether it encrypts data center links. Experts believe that web and application developers that Perfect Forward Secrecy and HSTS should be default encryption technologies in any new deployment. HSTS is a policy declaration that browsers, for example, may interact only over HTTPS connections; Perfect Forward Secrecy ensures that private session keys securing an encrypted connection are random and if one is compromised, it cannot be used to compromise other messages at a future time. “Intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised,” said Parker Higgins, an EFF activist, last November. Privacy and security advocates have long urged technology companies to encrypt traffic in order to secure communication and make government surveillance that much more difficult. The NSA’s efforts have long been facilitated by laggard technology companies who were lax in encrypting not only traffic streams, but also links between data centers which the NSA hacked in order to intercept email and other data on Yahoo and Google users. Both companies have since encrypted those links. “Just as troubling as the [snowden] revelations themselves is the fact that since last summer, little if anything has changed,” Automattic’s Sieminski said. “Despite a lot of rhetoric, our three branches of government in the United States have not made many concrete steps toward truly protecting citizens from unchecked government surveillance.” WordPress is not alone in failing to encrypt data center links; according to the EFF, other large providers such as Amazon, Apple, AT&T, Comcast, Foursquare, LinkedIn and Verizon do not. “If we’ve learned anything over the past year, it’s that encryption, when done correctly, works,” Sieminski said. “If we properly encrypt our sites and devices, we can make mass surveillance much more difficult.” Source
  14. Ponting

    SSL Eye v1.0

    SSL Eye is a unique tool that detects SSL man in the middle spying, by comparing SSL fingerprints of single or multiple sites across many remote nodes that are owned and managed by EEDS located in different countries such as Singapore, USA, and Netherlands, in order to compare the results with your own fingerprint that comes through your local ISP. Additionally the tool will tell you if the site is using Extended Validation (EV) certificates or perfect forward secrecy as the key exchange mechanism such as DHE_RSA or ECDHE_RSA which is used by google. We have also implemented global shortcut keys on the application so that you can copy a site from the browser address bar and call it for instant scan to check if you are a victim of Man in The Middle Attack (MITM). Where the attacker listens to your communication channel in a public key exchange re-sends the keys on your behalf, substituting his own fake keys for the requested one, so that the two original parties (you and your bank) will still appear to be communicating with each other. Features Retrieve fingerprint of any given ssl url from single or multiple sites across the EEDS nodes and compare them with yours.Check if the site is using Extended Validation (EV) certificates.Check if the site is implementing perfect forward secrecy on key exchange.Export results into HTML report.Sound alerts for invalid certificates.Scan with global keys from clipboard without user interaction.Homepage: https://www.digi77.com/ssl-eye-prism-protection/ Download Link: http://www.digi77.com/software/ssleye/update/SSLEye_Setup.exe
  • Create New...