Hyper-V ConceptsIt's time to get familiar with Hyper-V Virtualization, virtual servers, virtual switches, virtual CPUs, virtual deployment infrastructure (VDI) and more.
Have you ever tried to make a list of all the attack surfaces you need to secure on your networks and web farms? Try to do it and there will be one thing that will stand out; keeping websites and web applications secure. We have firewalls, IDS and IPS systems that inspect every packet that reaches our servers and are able to drop it should it be flagged as malicious, but what about web applications?
Web application security is different than network security. When configuring a firewall you control who accesses what, but when it comes to web application security you have to allow everybody in, including the bad guys and expect that everyone plays by the rules. Hence web applications should be secure; web application security should be given much more attention and considering the complexity of today’s web applications, it should be automated.
Let’s dig in deep in this subject and see why it needs to be automated.
Also known as Penetration Testing or “pen testing”, this is the process by which a security engineer or “pen tester” applies a series of injection or vulnerability tests against areas of a website that accept user input to find potential exploits and alert the website owner before they get taken advantage of and become massive headaches or even financial losses. Common places for this can include user data submission areas such as authentication forms, comments sections, user viewing configuration options (like layout selections), and anywhere else that accepts input from the user. This can also include the URL itself, which may have a Search Engine Optimization-friendly URI formatting system.
Most MVC frameworks or web application suites like WordPress offer this type of URI routing. (We differentiate a URL and URI. A URL is the entire address, including the http:// portion, the entire domain, and everything thereafter; whereas the URI is the portion starting usually after the domain (but sometimes including, for context), such as /user/view/123 or test.com/articles/123.)
For example, your framework may take a URI style as test.com/system/function/data1/data2/, where system is the controlling system you wish to invoke (such as an articles system), function is the action you wish to invoke (such as read or edit), and the rest are data values, typically in assumed positions (such as year/month/article-title).
Each of these individual values require a specific data type, such as a string, an integer, a certain regular expression match, or infinite other possibilities. If data types are not strictly enforced, or – sadly as often as this really does happen – user-submitted data is properly sanitized, then a hacker can potentially gain information to get further access, if not even force direct backdoor access via a SQL injection or a remote file inclusion. Such vulnerabilities are such a prevalent and consistent threat, that for example SQL Injection has made it to the OWASP Top 10 list for over 14 years.
Netsparker use open source web applications such as Twiki for a total different purpose than what they were intended for. They used them to test their own web application security scanners.
Netsparker need to ensure that their scanners are able to crawl and identify attack surfaces on all sort of web applications, and identify as much vulnerabilities as possible. Hence they frequently scan open source web applications. They use open source web applications as a test bed for their crawling and scanning engine.
Thanks to such exercise Netsparker are also helping developers ship more secure code, since they report their findings to the developers and sometimes also help them remediate the issue. When such web application vulnerabilities are identified Netsparker release an advisory and between 2011 and 2014 Netsparker published 87 advisories.
A few days ago Netsparker released some statistics about the 87 advisories they published so far. As a quick overview, from these statistics we can see that cross-site scripting is the most common vulnerability in the open source web applications that were scanned. Is it a coincidence? Not really.
The article also explains why most probably many web applications are vulnerable to this vulnerability, which made it to the OWASP Top 10 list ever since.
The conclusion we can draw up from such statistics is quite predictable, but at the same time shocking. There is still a very long way to go in web application security, i.e. web applications are still poorly coded, making them an easy target for malicious hacker attacks.
Click here to read more about the vulnerabilities discovered, methods used and shocking statistics about the security threats identified.
Long gone are the days where a simple port scan on a company’s webserver or website was considered enough to identify security issues and exploits that needed to be patched. With all the recent attacks on websites and webservers which caused millions of dollars in damage, we thought it would be a great idea to analyze the implications vulnerable webservers and websites have for companies, while providing useful information to help IT Departments, security engineers and application developers proactively avoid unwanted situations.
Unfortunately companies and webmasters turn their attention to their webservers and websites, after the damage is done, in which case the cost is always greater than any proactive measures that could have been taken to avoid the situation.
Without doubt, corporate websites and webservers are amongst the highest preference for hackers. Exploiting well-known vulnerabilities provides them with easy-access to databases that contain sensitive information such as usernames, passwords, email addresses, credit & debit card numbers, social security numbers and much more.
The sad part of this story is that in most cases, hackers made use of old exploits and vulnerabilities to scan their targets and eventually gain unauthorized access to their systems.
Most security experts agree that if companies proactively scanned and tested their systems using well-known web application security scanner tools e.g Netsparker, the security breach could have been easily avoided. The Online Trust Alliance (OTA) comes to also confirm this as they analyzed thousands of security breaches that occurred in the first half of 2014 and concluded that these could have been easily prevented. [Source: OTA Website]
When reading through recent security breaches, we can slowly begin to understand the implications and disastrous effects these had for companies and customers. Quite often, the figure of affected users who’s information was compromised, was in the millions. We should also keep in mind that in many cases, the true magnitude of any such security incident is very rarely made known to the public.
Below are a few of the biggest security data breaches which exposed an unbelievable amount of information to hackers:
Security researchers at qualys.com yesterday released information on a critical 15 year-old Linux security hole which affects millions of Linux systems dated back to the year 2000. The newly published security hole – code named ‘Ghost’ was revealed yesterday by Qualy’s security group on openwall.com. Readers interested can read through the summary and analysis here.
The security hole was found in the __nss_hostname_digits_dots() function of the GNU C Library (glibc).
The function is used on almost all networked Linux computers when the computer tries to access another networked computer either by using the /etc/hosts files or, more commonly, by resolving a domain name with Domain Name System (DNS)
As noted by the security team, the bug is reachable both locally and remotely via the gethostbyname*() functions, making it possible remotely exploit it by triggering a buffer overflow by using an invalid hostname argument to an application that performs DNS resolution.
The security hole exists in any Linux system that was built with glibc-2.2 which was released in November 10th, 2000. Qualy mentioned that the bug was patched on May 21st, 2013 in releases glibc-2.17 and glibc-2.18.
Linux systems that are considered vulnerable to the attack include RedHat Enterprise Linux 5, 6 and 7, CentOS 6 and 7, Ubuntu 12.04 and Debian 7 (Wheezy).
Debian has is already patching its core systems (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776391) while Ubuntu has already patched its 12.04 and 10.04 distributions (http://www.ubuntu.com/usn/usn-2485-1/). CentOS patches are also on their way.
Not many users are aware that Windows 7 provides more than one way to configure a workstation’s network adaptor IP address or force it to obtain an IP address from a DHCP server. While the most popular method is configuring the properties of your network adaptor via the Network and Sharing Center, the less popular and unknown way for most users is using the netsh Command Prompt. In this tutorial, we show you how to use the Command Prompt netsh command to quickly and easily configure your IP address or set it to DHCP. Competent users can also create simple batch files (.bat) for each network (e.g home, work etc) so they can execute them to quickly make the IP address, Gateway IP and DNS changes.
In order to successfully change the IP address via Command Prompt, Windows 7 requires the user to have administrative rights. This means even if you are not the administrator, you must know the administrative password, since you will be required to use the administrative command prompt.
To open the administrative command prompt in Windows 7, first click on the Start icon. In the search dialog box that appears, type cmd and right-click on the cmd search result displayed. On the menu that Windows brings up, click on the Run as administrator option as shown in the below screenshot:
Figure 1. Running CMD as Administrator
Depending on your User Account Control Settings (UAC), Windows may ask for confirmation. If this happens, simply click on Yes and Windows will present the CLI prompt running in elevated administrator privileged mode: