Software developers are faced with growing security concerns when it comes to the source codes powering their applications for users around the globe.
It has become SOP for organizations to conduct penetration testing and vulnerability scans on a regular basis. Such practice is even endorsed by most IT specialists since an attack could lead to disastrous outcomes. Penetration testing assesses an IT infrastructure’s security by safely exploiting vulnerabilities. These vulnerabilities may exist in incorrect configurations, hazardous end-user behavior, operating systems and application flaws.
If you are a security professional, you are most definitely familiar with what vulnerability assessment and penetration testing are. These two are types of vulnerability testing in order to complete a vulnerability analysis. Both are valuable tools for information security and are integral components of the process of managing threat and vulnerability of network systems.
The success of an enterprise wide vulnerability assessment program depends on many factors such as planning, budgeting, resources, technical solution and others, but the most important is the ability to analyse vulnerability scanning reports. Properly identified and categorised vulnerabilities will help organisations to get the most benefit from the program and achieve more Return on Investment. This article will cover some of the points to consider when analysing network and web application reports.
Amazon’s AWS (Amazon Web Services) is a popular cloud computing application which is used by people worldwide. It can help business owners reduce their IT costs. You no longer have to purchase expensive machinery and hire extra IT staff. You can use this cloud application to pay as you go to cut monthly costs for IT services.
Like every other popular service or software on the internet, WordPress is prone to hacker attacks. There are some vulnerabilities in WordPress itself. Other security risks are created because of user neglect and carelessness. Users create websites and blog pages using WordPress and all their information is at risk when proper care is not taken to keep the pages secure.
Following are some common security risks that users face when using WordPress, by avoiding these you can keep your websites safe:
Secure Sockets Layer or SSL pertains to the standard security technology utilized mainly for establishing an encrypted link between a browser and a server. This link makes sure that all essential data are transferred between browsers and web servers in an integral and private manner. SSL is a widely known digital networking protocol managing client authentication, server authentication and the encrypted communication between clients and servers.
The Transport Layer Security or TLS, on the other hand, pertains to the protocol that completely ensures privacy between exclusive communication applications and their respective users online. When a client and a server interact or communicate, this technology makes sure that there is no third-party tampering or eavesdropping with the messages. The Transport Layer Security is said to be the successor of Secure Sockets Layer of SSL.
Freak-Analyzed and Defined
Freak attacks take advantage of RSA Export major clippers that are designed to be weaker on purpose so that they will fit in the borders of US Encryption controls of export of previous years. The deconstruction of attack is composed of three steps which are outlined below:
This is as simple as going to a public Wi-Fi area and setting up the proxy. Modify the traffic of clients to request the main Export RSA key.
There are reliable services specifically for this pursuit. One of these is using the online services of Amazon which only takes about 7 to 12 hours for one hundred dollars. Modify or monitor the traffic that is going between the unconfirmed server and vulnerable client in plain text.
You might have caught caution in the third step which is unconfirmed server and vulnerable client. The server must be willing to negotiate the weaker export key or must host the susceptible third-party software like the Facebook JavaScript SDK, sites that include Facebook’s login button and like button or Apache’s Open SSL and mod_SSL versions. Some susceptible devices and clients can include the Safari on any Apple device.
What You Need to Do to Ensure Ultimate Personal Protection
Freak attacks are getting widespread more than you previously thought. Browsers using OpenSSL are susceptible and this includes Android browsers and perhaps Samsung-derived browsers called “Internet.” Similarly, Apple’s exclusive implementation of TLS, known as Secure Transport, puts OS X and also Safari at risk.
The best thing that needs to be done now is to ensure your protection against this vulnerability. However, you need to make sure that you have clear ideas on how to configure this for your usual privacy. If you truly want to protect yourself, this can be done in simple steps.
If you are running a web server, you need to disable support for all the export suites, but you also need to check and ensure that you are not utilizing any known unsecure ciphers. Enabling support also needs to be done to forward exclusivity or secrecy.
Magento platform is a popular eCommerce framework used by the organisation all over the world to create the Online shops.
The researchers from Check Point discovered the critical security issues, which could potently allow the remote compromise of a Magento based web site and gaining unauthorized access to the customer and credit card information. See the full post here: http://blog.checkpoint.com/2015/04/20/analyzing-magento-vulnerability/ . The vulnerability is currently affecting thousands of online stores.
Technical Details
Three vulnerabilities were discovered by the Check Point team:
CVE-2015-1398 - An authentication bypass vulnerability was reported in Magento component. The vulnerability is due to a user controlled parameter affecting the login mechanism. A remote attacker can exploit this issue by sending a specially crafted HTTP request to a vulnerable system. Successful exploitation may allow the attacker to gain access to a target system.
CVE-2015-1397 - An SQL injection vulnerability has been reported in Magento component. Successful exploitation of this vulnerability would allow a remote attacker to execute arbitrary SQL commands on the affected system.
CVE-2015-1399 - A remote file inclusion vulnerability has been reported in Magento component. The vulnerability is due to lack of sanitization for user-supplied data. Successful exploitation of this vulnerability could allow a remote attacker to execute arbitrary code on the affected system.
What should you do
Check your Magento implementation using our Trial Web Site Assessment Service and see if you are vulnerable. If yes, apply the designated patch SUPEE-5344 released by Magento as soon as possible.
The POODLE Attack (CVE-2014-3566)
Update (8 Dec 2014): Some TLS implementations are also vulnerable to the POODLE attack. More information in thisfollow-up blog post.
After more than a week of persistent rumours, yesterday (Oct 14) we finally learned about the new SSL 3 vulnerability everyone was afraid of. The so-called POODLE attack is a problem in the CBC encryption scheme as implemented in the SSL 3 protocol. (Other protocols are not vulnerable because this area had been strengthened in TLS 1.0.) Conceptually, the vulnerability is very similar to the 2011 BEAST exploit. In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim's browser and also be able to observe and manipulate encrypted network traffic on the wire. As far as MITM attacks go, this one is complicated, but easier to execute than BEAST because it doesn't require any special browser plugins. If you care to learn the details, you can find them in the short paper or in Adam Langley's blog post.
POODLE is a protocol-level vulnerability that can't be easily fixed. Although it might be possible to attempt a BEAST-style mitigation, it seems that browser vendors are not interested in that approach. Adam said Chrome won't pursue that direction. Firefox said they would disable SSL 3 in Firefox 34. And that's great news. Traditionally we struggle with letting go of old protocols. Because SSL 3 is not very widely used and POODLE is serious enough, it seems that we'll be able to retire this old protocol version soon. In fact, some CDNs have already disabled it.
You can look at this problem from two perspectives. As a user, you want to protect yourself from attacks, and the best way to do that is to disable SSL 3 in your browser. (Instructions are easy to find online.) The updated SSL Labs Client Test will tell you if your change was successful.
As a web site operator, you should disable SSL 3 on your servers as soon as possible. You need to do this even if you support the most recent TLS version because an active MITM attacker can force browsers to downgrade their connections all the way down to SSL 3, which can then be exploited. In normal operation, SSL 3 shouldn't needed by the vast majority of sites. Although it's likely that there's a long tail of clients that don't support anything better, Internet Explorer 6 on Windows XP is potentially the biggest user segment that still relies on SSL 3. Options are to guide users to manually enable TLS 1.0 (IE6 supports it, but not by default) or upgrade to other browsers. In the short term, it's possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream cipher whose name no one wants to mention. I don't recommend this approach.
POODLE wouldn't be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There's a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective. Google implemented this feature in February (in Chrome and in their web sites) and has been successfully using since. Mozilla said Firefox will support the indicator in early 2015. A new version of OpenSSL has just been released, which includes support for the SCSV. The support might be backported to various Linux distributions. For best results, support also needs to be added to other major browsers. Once that happens, the POODLE attack surface will be much smaller; it will affect only the users with older browsers.
For detailed guidance on how to disable SSL 3 in various servers and browsers, head to Scott Helme's blog post. Qualys customers should go here to learn how to configure reports to find systems that use SSL 3.
