Threat Actors Continue to Target Websites

The European Central Bank (ECB) shut down one of its websites following the discovery that malicious actors accessed the site without authority and infected it with malicious software (malware). This incident shows that threat actors continue to target websites.

ECB, in a statement, said that unauthorized parties had breached the Bank’s Integrated Reporting Dictionary (BIRD) website, a site purposely built to provide the banking industry with details on how to produce statistical and supervisory reports. The Bank said that contact data, including email addresses, names and position titles of 481 subscribers to the BIRD newsletter may have been stolen by the attackers.

ECB, in a statement, said that the attack on BIRD website was discovered as a result of a “regular maintenance work”. An ECB spokesman told Reutersthat the earliest evidence found of the website attack dated back to December 2018, which means that the attack had gone unnoticed for months before being discovered during maintenance work.

This isn’t the first time that ECB reported an attack on its IT infrastructure. In 2014, ECBdisclosed that an unknown attacker or attackers had breached another of the Bank’s website used for registrations for events of the Bank such as conferences and visits.

The 2014 website attack, the Bank said, led to the theft of email addresses and other contact data left by individuals registering for events at the ECB. This 2014 attack in one of the Bank’s website was only known after an anonymous email was sent to the Bank asking for financial compensation in exchange for the data stolen.

Injection Attacks

In the latest attack on one of its websites, ECB said the attackers “succeeded in injecting malware onto the external server to aid phishing activities”. In the 2014 attack, ECB said the malicious actor or actors attacked a “database serving its public website”. Beyond those phrases, not much is known in the “injection” and “database” attacks.

The Open Web Application Security Project (OWASP)lists injection attacks as the number one threat to web security. Injection attacks refer to a broad attack paths that allow attackers to gain access to the database records of vulnerable websites. In certain cases, this type of attack allows attackers to gain administrative rights to a database.

One example of an injection attack is the SQL injection, also known as SQLI, attack. SQL, which stands for Structured Query Language, is a programming language understood by databases. By inserting malicious commands from this programming language into input fields on websites such as input forms, attackers can gain access to the database records of vulnerable websites, resulting in the unauthorized access of any data available in the database.

In late 2007 and early 2008, thousands of websites were defaced as a result of SQL injection attacks. According to researchers at Microsoft, These particular SQL injection attacks didn’t exploit vulnerabilities in Windows, IIS, SQL Server, or other infrastructure code; rather, it exploited vulnerabilities in custom web applications running on this infrastructure. Thousands of websites were affected due to 2 factors: first, there was an automated tool to launch this attack, and second, this SQL attack tool spread through the use of a botnet. 

SANSreported that thousands of websites were compromised in late 2007 and early 2008 as the attacker or attackers used an automated tool in search engines to find vulnerable web applications and exploiting them. “The exploit just consisted of an SQL statement that tried to inject a script tag into every HTML page on the web site,” SANS reported. SecureWorks, meanwhile, reported that the automated SQL attack tool, spread to thousands of websites as the attackers relied on a botnet – a group of computers or devices infected by the same malware and controlled by an attacker for malicious purposes such as in this case the spread of SQL attack tool.

Other than using SQL injection to attack indiscriminate websites using an automated tool and a botnet, SQL injection has also been used by attackers in targeted attacks. According to the U.S. Federal Bureau of Investigation (FBI), a malicious group obtained confidential information from Sony Pictures’ computer systems on May 27, 2011 to June 2, 2011 using an SQL injection attack against Sony Pictures’ website.

According to the UK's Information Commissioner's Office, SQL injection was also used in the TalkTalk cyber attack on the company’s website. As a result of the SQL injection attack on TalkTalk’s website, personal details of 156,959 customers, including their names, addresses, dates of birth, phone numbers and email addresses were stolen. The attacker also stole the bank account number and sort code of 15,656 TalkTalk’s customers.

Prevention

As shown in above-mentioned examples, injection attacks on websites are highly detrimental to the affected organizations. Loss of customer trust is one potential cost of an SQL injection attack should personally identifiable information such as full names, addresses and credit card details be stolen.

One of the cyber security measures, in order to prevent injection attacks such as SQL injection attacks, is through the use of a web application firewall (WAF). A WAF is often used to filter out injection attacks such as SQL injection attacks. In filtering out SQL injection attacks, a WAF uses a list that contains signatures to address specific attack vectors. This WAF is regularly updated to provide new filtering rules for newly discovered security vulnerabilities.

At The Driz Group, we specialize in protecting your websites and web applications with instant attack mitigation and a guaranteed DDoS protection. We support all deployment types including Cloud and on-premise. Setup take several minutes and there is nothing to buy, support, or maintain.

Connect with ustoday for a free consultation and protect your websites, web applications, online reputation and mission critical data.

3 Most Common Web Application Security Vulnerabilities

Almost all organizations today have an online presence, mostly in the form of an official website. While these websites open a window of opportunities for organizations, these same websites are at times a bane to organizations as these are becoming attractive targets for cyber attackers.

What Are Web Application Security Vulnerabilities?

One of the ways by which cyber attackers wreak havoc on corporate websites is by exploiting the security vulnerabilities in web applications.

Web applications, also known as web apps, refer to software programs that run in a web browser. A web application can be as simple as a contact form on a website or a content management system like WordPress. Web application security vulnerabilities, meanwhile, refers to system flaw or security weakness in a web application.

Web applications are gateways to a trove of data that cyber attackers find attractive and easy to steal. Every time website visitors sign up for an account, enter their credentials or make a purchase via an official corporate website, all this data, including personally identifiable information, is stored on a server that sits behind that web application. Exploiting a security vulnerability in a web application allows attackers to access the data stored on that server.

Imperva, in its “State of Web Application Vulnerabilities in 2018”, reported that the overall number of new web application vulnerabilities in 2018 increased by 23%, that is, 17,308 web application vulnerabilities, compared to 2017 with only 14,082 web application vulnerabilities.

Most Common Web Application Security Vulnerabilities

Here are the 3 most common security vulnerabilities affecting web applications:

1. Injections

Based on Imperva’s data, the number one web application vulnerability in 2018 was injection, representing 19% of the web application vulnerabilities last year. In an injection attack, an attacker inserts or injects code into the original code of a web application, which alters the course of execution of the web app.

According to Imperva, the preferred method of attackers last year to inject code into web applications was remote command execution (RCE) with 1,980 vulnerabilities.

Remote command execution allows an attacker to remotely take over the server that sits behind a web application by injecting an arbitrary malicious code on the web app. The Equifax data breach that exposed highly sensitive data of millions of U.S. customers, as well as thousands of U.K. and Canadian consumers, is an example of a cyberattack that used the injection method, in particular, remote command execution.

Attackers gained access to the data of millions of Equifax’ customers by exploiting the vulnerability designated as CVE-2017-5638in the web application used by the company. At the time of the attack, Equifax then used an outdated Apache Struts, a popular open source framework for creating enterprise-grade web applications.

Despite the advisory from the Apache Software Foundation, the organization that oversees leading open source projects, including Apache Struts, to update the software to the latest version, Equifax failed to do so, leading the attackers to breach the sensitive data of millions of the company’s customers.

On March 7, 2017, the Apache Software Foundation issued a patch or security update for CVE-2017-5638 vulnerability. On May 13, 2017, just a few days after the CVE-2017-5638 patch was released, attackers started their 76-day long cyberattack on Equifax, this according to the findings of the U.S. House Oversight Committee.

2. Cross-Site Scripting

The second most common web application vulnerability is cross-site scripting. According to Imperva, cross-site scripting ranked as the second most common vulnerability in 2018, representing 14% of the web application vulnerabilities last year. 

Cross-site scripting, also known as XSS, is a type of injection in which malicious code is inserted into a vulnerable web application. Unlike injection in general, cross-site scripting particularly targets web visitors.

In a cross-site scripting attack scenario, an attacker, for instance, embeds an HTML tag in an e-commerce website’s comments section, making the embedded tag a permanent fixture of a webpage, causing the browser to read the embedded tag together with the rest of the original code every time the page is opened, regardless of the fact that some site visitors don’t scroll down to the comments section.

The injected HTML tag in the comments section could activate a file, which is hosted on another site, allowing the attacker to steal visitors’ session cookies – information that web visitors have inputted into the site. With the stolen session cookies of site visitors, attackers could gain access to the visitors’ personal information and credit card data.

3. Vulnerabilities in Content Management Systems

Imperva’s State of Web Application Vulnerabilities in 2018 also showed attackers are focusing their attention to vulnerabilities in content management systems, in particular, WordPress.

Attackers are focusing their attention on WordPress as this content management system powers nearly one-third of the world’s website. Data from W3Techsshowed that as of late December, last year, WordPress usage account for 32.9% of the world’s websites, followed by Joomla and Drupal.

According to Imperva, the number of WordPress vulnerabilities increased in 2018 despite the slowed growth in new plugins. Imperva registered 542 WordPress vulnerabilities in 2018, the highest among the content management systems. The WordPressofficial website, meanwhile, reported that only 1,914 or 3% from the total 55,271 plugins were added in 2018.

Ninety-eight percent of WordPress vulnerabilities are related to plugins, Imperva reported. Plugins expand the features and functionalities of a website. WordPress plugins are, however, prone to vulnerabilities as with this content management system (being an open source software), anyone can create a plugin and publish it without security auditing to ensure that the plugins adhere to minimum security standards.

Web Application Attack Prevention

A web application firewall (WAF) is one of the best cybersecurity solutions that your organization can employ against web application vulnerabilities.

Trust the experienced team that protects hundreds of sites and applications. Protect your web application within 10-minutes and keep cybercriminals at bay. Get started today!

Search Engines Blacklist Fewer Sites, Study Shows

A study conducted by SiteLock showed that search engines are blacklisting fewer sites.

Blacklisting happens when a search engine removes a website from its results due to the presence of a malicious software (malware).

In the second quarter of 2018, SiteLockanalyzed over 6 million websites through the use of malware scanners. SiteLock’s analysis showed that search engines like Google and Bing only blacklisted 17.5% of infected websites with malware in the second quarter of 2018, a 6% decrease from the previous year.

Prevalence of Website Malware

Website visitors and website owners alike rely on search engine warnings. On the part of website visitors, they rely on search engines to flag malicious websites that may leave them unprotected as they surf the web.

According to SiteLock, when website owners rely mainly on search engine warnings and outwardly facing symptoms, they may be missing malware that’s attacking their website visitors.

Even as search engines are blacklisting fewer sites, malicious websites aren’t getting fewer. SiteLock’s study showed that 9% or as many as 1.7 million websites have a major security vulnerability that could allow attackers to embed malware on them. The 3 most common security vulnerabilities on websites identified by SiteLock are SQL injection (SQLi), cross-site scripting (XSS) and cross-site request forgery (CSRF).

SQLi security vulnerability allows attackers to inject malicious database code into website text fields or forms. In an SQL injection attack, an attacker can gain full access to the website’s MySQL database, administrative back end or the entire website. MySQL refers to an open source management system that makes it convenient to add, access and manage content in a website's database. 

XSS security vulnerability allows attackers to inject malicious code into a web form or web application. In a cross-site scripting attack, the web application is tricked into doing something that it isn’t supposed to do. CSRF, meanwhile, is often used with social engineering – tricking victims. In a cross-site request forgery attack, an attacker forces authenticated users to do unauthorized actions while logged into a vulnerable web application.

SiteLock’s sampled websites showed that 7.19% of sites have an SQLi vulnerability, 1.56% of sites have an XSS vulnerability and .19% of sites have a CSRF vulnerability.

Browser-Based Cryptojacking

SiteLock’s study also found that sampled websites experience an average of 58 attacks per day, with 1% of the sites infected with a malware. The study further found that website attacks are becoming increasingly sneaky and difficult to detect. An example of a symptomless attack on websites is the browser-based cryptojacking, which doubled (2%) in number compared to last year’s number (1%), according to SiteLock’s study. In browser-based cryptojacking, an attacker hijacks a browser to mine a cryptocurrency.

McAfee’s Blockchain Threat Reportshowed that nearly 30,000 websites host the Coinhive code for mining cryptocurrency with or without a user’s consent. This number, according to McAfee Labs, only accounts for non-obfuscated sites, which means that the actual number is likely much higher.

As it stands, Coinhive resides in a gray area of legitimacy. In an ideal world, both the website owner and website visitor must consent to Coinhive’s browser-based cryptocurrency mining. 

A website owner or, in the case of a cyberattack, an attacker may embed the Coinhive code into a website. When a user visits a website with an embedded Coinhive code, the cryptocurrency called “Monero” is then mined from the user's browser using the computing power or CPU of the website visitor. As of October 21, 2018, the price of one Monero coin is $103.

When the Coinhive code is embedded into the website by a website owner, the cryptomining income goes to the website owner. When the Coinhive code is embedded by a cyberattacker, the cryptomining income goes to the attacker.

Coinhive code made its way to YouTube. In January this year, Trend Microdiscovered that attackers abused Google's DoubleClick ad platform, enabling the attackers to display ads on YouTube that contain the Coinhive code. YouTube visitors in select countries, including Japan, France, Taiwan, Italy and Spain were affected, with 80% of the affected visitor's CPU resource was used to mine the cryptocurrency Monero.

"Mining cryptocurrency through ads is a relatively new form of abuse that violates our policies and one that we’ve been monitoring actively,” a Google representative said in a statement. “We enforce our policies through a multi-layered detection system across our platforms which we update as new threats emerge. In this case, the ads were blocked in less than two hours and the malicious actors were quickly removed from our platforms.”

Check Pointranked 3 browser-based cryptocurrency mining scripts Coinhive (ranked #1), Crypto-Loot (ranked #2) and JSEcoin (ranked #4) as “February 2018’s Top 10 ‘Most Wanted’ Malware”.

Prevention

Here are some of the security measures that need to be put in place in order to prevent attackers from installing malware into your website:

Use a Website Malware Scanner

A website malware scanner allows website owners to check their sites for web-based malware.

Keep All Website Applications Up-to-Date

Ensure that your web applications are up-to-date. Using outdated web applications with known security vulnerabilities can leave your website vulnerable to exploitation by cyberattackers.

Use Web Application Firewall (WAF) 

Filtering web traffic via WAF is one of the measures in protecting your website from a successful cyberattack. Your traditional perimeter firewalls don’t protect your website.

Contact ustoday if you need assistance in protecting your website against cyberattacks.

Why Your Organization Should Replace All TLS Certificates Issued by Symantec

October 2018 is a crucial month for anyone owning a website as two of the world’s biggest browsers, Chrome and Firefox, will “distrust” TLS certificates issued by Symantec.

What Is a TLS Certificate?

TLS stands for Transport Layer Security. This technology is meant to keep the internet connection secure by encrypting the information sent between the website and the browser, preventing cybercriminals from reading and modifying any information that’s being transferred.

The more popular TLS isn’t free. A website owner has to buy this technology – referred to as TLS certificate – from any of the companies trusted by browsers. Symantec was once a trusted issuer of TLS certificates by Google, the owner of Chrome, and Mozilla, the organization behind Firefox.

HTTPS, which stands for Hyper Text Transfer Protocol Secure, appears in the URL when a website uses a TLS certificate. Google has also been rewarding websites using TLS certificates with improved web rankings. As of July 2018, according to Mozilla, 3.5% of the top 1 million websites were still using Symantec TLS certificates.

When a visitor attempts to connect to a website, the browser used by the visitor requests the site to identify itself. The site then sends the browser a copy of its TLS certificate. The browser, in return, checks if this TLS certificate is a trusted one. If the browser finds that the TLS certificate can be trusted, the browser then sends back a digitally signed acknowledgment to start the TLS encrypted session.

Reasons Behind the Distrust of Symantec TLS Certificates

In March 2017, Ryan Sleevi, software engineer at Google Chrome, posted on an online forumGoogle’s findings, alleging that Symantec failed to properly validate TLS certificates. Sleevi said that Symantec mis-issued 30,000 TLS certificates over a period spanning several years.

“Symantec allowed at least four parties access to their infrastructure in a way to cause certificate issuance, did not sufficiently oversee these capabilities as required and expected, and when presented with evidence of these organizations’ failure to abide to the appropriate standard of care, failed to disclose such information in a timely manner or to identify the significance of the issues reported to them,” Sleevi said.

Symantec, for its part, said that Google’s allegations are “exaggerated and misleading”. “Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading,” Symantec said. “For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program.”

Mozilla, for its part, conducted its own investigation surrounding Symantec’s issuance of TLS certificates. Mozilla said it found a set of issueswith Symantec TLS certificates. A consensus proposalwas reached among multiple browser makers, including Google and Mozilla, for a gradual distrust of Symantec TLS certificates.

On October 31, 2017, DigiCert, Inc. acquired Symantec’s website security business, and on December 1, 2017 DigiCert took over the validation and replacement of all Symantec TLS certificates, including TLS certificates issued by Symantec’s subsidiaries: Thawte, GeoTrust and RapidSSL.

“DigiCert will replace all affected certificates at no cost,” DigiCertsaid in a statement. “Additionally, you don’t need to switch to a new account/platform. Continue to use your current Symantec account to replace and order your SSL/TLS certificates.” 

Implications of the Distrust of Symantec TLS Certificates

Mozillasets October 23, 2018 as the distrust date of all TLS certificates issued by Symantec. Googlesets October 16, 2018 as the distrust date for all TLS certificates issued by Symantec to non-enterprise users, while January 1, 2019 is the distrust date set by Google for all TLS certificates issued by Symantec to enterprise users. Apple, the owner of the Safari browser, sets “Fall 2018” as the date of complete distrust of Symantec TLS certificates.

In the case of Chrome, if website owners fail to replace their Symantec TLS certificates beyond the prescribed period by Google, the message below will be shown instead:

Image by Google

In the case of Firefox, the message below will be shown instead:

Image by Mozilla

As can be gleaned from the distrust notices by Google and Mozilla, failure to replace Symantec TLS certificates runs the risk of attackers trying to steal information from your organization’s website, including passwords, messages and credit card details.

According to Mozilla, whenever it connects to a website, it verifies that the TLS certificate presented by the website is valid and that the site’s encryption is strong enough to adequately protect the privacy of the visitor. If Firefox determines that the TLS certificate can’t be validated or if the encryption isn’t strong enough, the connection to the website will be stopped and instead, the message, “Your connection is not secure” will be shown, Mozilla said.

“When this error occurs, it indicates that the owners of the website need to work with their certificate authority to correct the policy problem,” Mozilla added. 

Contact us today if your organization needs assistance in replacing legacy Symantec TLS certificates.

Web Application Security Checklist for 2018

Chances are, your web app isn't as secure as it needs to be. That's why we're sharing this 2018 web application security checklist. Have you hit all the marks?

With a great sigh of relief, we welcome 2018. This new year brings us all new possibilities and opportunities. This is also a great time assess your business operations. From paperwork to threat assessments, now is your chance to start the year off right.

Unfortunately, it isn't just legitimate businesses that are hoping to have a great new year. The hackers of years past haven't gone anywhere. This year like any other, hackers will be looking to exploit your company's internet vulnerabilities. Let us help you prepare. 

Let us help you prepare. 

Make Sure Your User-Friendly Apps and Hacker Hostile

Web applications make is easy and efficient for clients, customers, contractors and employees to access your company's network.

But, these web apps can also open the door to unwanted visitors. Coding errors, weak passwords, and other mistakes can leave you vulnerable to attack.

But you aren't alone.

The Driz Group stands ready to help you defend your network against whatever this year brings.

Start 2017 with this Web Application Security Checklist 

To help you assess your web applications strengths and weaknesses, we've put together this web application security checklist. Use this list to ensure that your web apps are secure and ready for market. 

1. Assess and Review. This step involves a comprehensive review of the application. Test each step of the program for vulnerabilities. In fact, we will provide you with a complete vulnerability assessment checklist to make the assessment as simple and transparent as possible.

Ensure that users cannot bypass steps or gain access to unauthorized areas of the network through the app.

Can a user enter a new ID and receive a password without authorization? How many password attempts can be made before a lock-out? 

2. Plan and Challenge. Next, you'll want to conduct test attacks to assess your app's weaknesses.

From password challenges to brute force attacks, you'll want to determine what your app can withstand.

You'll also want to make sure sensitive information isn't revealed in cookies or other easily accessed code. 

3. Re-assess and Report. Once you have made your initial challenges, re-assess the app's areas of vulnerability. Conduct usability testing, perform functional testing and assess the error messages.

Did quick fixes solve the problem or is there more work to be done? In your report, you'll want to indicate which problems should be given highest priority for remediation.

Also, make note of any institutional errors that may threaten other web applications. 

4. Remediate and Test. In this step, you'll use the report prepared in step 3 to make changes to the app.

Remove security threats, repair coding errors and re-educate users to ensure your website's security.

Once you've implemented these steps, test the web application's security again. 

Need Assistance?

This four-step web application security checklist summarizes the path you'll need to take to ensure your web application doesn't leave you vulnerable.

But, as with all good things, the implementation isn't always easy. The Driz Group employs a team of experts dedicated to identifying and addressing your website's vulnerabilities. 

We can prepare a comprehensive web application security checklist designed specifically for your network and web applications. Just give us a call or send us an email to get started.

In the meantime, have a great and secure 2018!