HYPERTEXT PREPROCESSOR (PHP) VULNERABILITIES, RISKS AND COUNTERMEASURES

Transcription

1 HYPERTEXT PREPROCESSOR (PHP) VULNERABILITIES, RISKS AND COUNTERMEASURES Joseph D. Klos Florida State University Maxwell A. Galiana Florida State University Erich M. Marlowe Florida State University Roderick D. Givens Florida State University Abstract Since as early as 1990 PHP vulnerabilities have been an occurring problem on websites. PHP vulnerability, a security exploit in which attackers insert malicious code into web pages, has even affected the big companies such as Google, Yahoo and Facebook. By exploiting PHP vulnerabilities, a hacker can steal data, control a user s session, run malicious code, be apart of a phishing exam and more. PHP attacks are a serious concern regarding user security online and a skilled security developer must be able to handle all possible attacks. Introduction PHP vulnerabilities target scripts embedded in a page, which are then executed on the client-side. PHP vulnerabilities are a relevant security attack in today s world because most websites today are very interactive, accepting, processing, and returning data to users. With the demand of website interactivity, attacks also have the ability to interact directly with an application s processes. Sometimes attacks pass data designed to masquerade as legitimate application requests or through normal request channels (Cobb). According to a 2008 WhiteHat Security Statistics Report, 90 percent of all websites have at least one vulnerability (Cobb). Our group paper is designed to further introduce web server attacks, why they work, who are vulnerable, survey of an attack, and countermeasures to prevent such attacks. PHP VULNERABILITIES OVERVIEW & RISKS PHP is a very common attack on websites today because hackers are always looking to steal and/or alter information. PHP attacks can change appearance of webpages, send information to the attacker regarding the webpage, and download entire databases from the web server. PHP attacks are very common due to the amount of websites that do not have the proper coding or have left backdoors open in the coding. Additionally attacks are common on webpages and programs because PHP is such a popular coding language. As hackers have had more experience with the language and know much of it themselves, they have learned how to pack more sophisticated attacks into more simple scripts. SQL Injection An SQL Injection attack consists of the attacker inputting malicious coding into the website, then the malicious code usually stays dormant until a certain trigger or query is executed which can steal information. The attack method has been associated with high-class security attacks, many of which occur on retail websites with intent to steal user information (name, credit card, etc.). In 2011 Sony was attacked using SQL injection that allowed the attacking group to attain addresses, birth dates, and passwords of millions of users. The attack cost Sony an estimated $170 million. A SQL injection attack was allegedly the cause of leaked passwords from the LinkedIn database as well. In 2012, LinkedIn was hit with a class action lawsuit worth $5 million by users who claim that the company failed to use basic industry standard security practices. Having low password standards caused the LinkedIn database, and subsequently its users, to be at risk. Because the company stored user passwords in unsalted SHA-1 hashed format, they failed to provide adequate protection to their users. SHA-1 was initially published in 1995 by the National Security Agency. This was a significant problem due to the obvious fact that SHA-1 is severely outdated. By LinkedIn not salting their users passwords, they exposed large amounts of sensitive data in their database. The loss of data integrity became a major issue in this case, and many users were not pleased. Risks of this sort can be avoided by providing the proper encryption standards. Florida State University ischool 1

2 Cross-Site Scripting Cross Site Scripting (XSS) Cross Site Scripting is one of the other top PHP attacks being carried out today. A Cross Site Scripting attack can steal information from the user, take over their session, and perform unwanted actions on the user by means of a masquerade attack. Source Code Revelation This type of attack involves the hacker obtaining the coding of the webpage. This can allow them to alter the webpage and even download files that are embedded in the coding. PHP is a server side coding so you would not usually be able to see this coding by just doing a View Source action in your web browser. Attackers are able to see scripts they were not meant to and learn back end-coding aspects about the page that they were not meant to. Remote File Inclusion This attack is explained in its name, when you download an application and/or file another file is included that you may not know about. These unknown files usually contain malicious content and can stay on your machine undiscovered. Session Hijacking This type of attack occurs by the attacker stealing a user s session ID, which is used to gain access to the system. When a session is configured between a client and a web server, PHP coding will store the user s session ID in the cookie on the client s side. The attacker will input PHP coding that will send that information from the cookie to them as well as the system. SURVEY OF LAB 02 During our Lab 2 experiment we were using PHP coding to exploit server vulnerability. Initially we downloaded and unzipped our.php and.htm files from our 4774 directory. After we had downloaded the files we then transferred them into the proper /var/www directory In order to populate the webpage we needed to set the permissions for the.htm and.php files, to do this we used the command sudo chmod 705 R /var/www. After the permission had been set for each of the file types we used the apache2 start command to fully populate the page. Figure 1: Extreme Security Homepage 2 Florida State University ischool

3 Role-Based Access Control Team Turn Up After all the pages had been populated we used our Firefox remote session to type in our IP address, this took us to our populated webpage. The webpage was a mock page that had multiple pages for items such as products and information. The page had a search box, which functioned as a normal search box would. However the search box also functioned as a Linux shell command line. This allows the user to be able to browse the webpage s inner scanning and will take you to a webpage that would not be normally seen from browsing the site. The search box can be used to download information or even entire databases, depending on the search queries being entered into the box. Introduction of XSS Attacks Figure 2: Results of Lab 02 Cross-site scripting attacks an application s users, not the application or server. Since most websites have various injection points such as search fields or feedback forms, XSS attacks are easily carried out. One of the main goals of a XSS attack is to gather cookie data from websites (Cobb). Cookies can sometimes used incorrectly to accidentally store client information such as user ID, preferences, or login information. Client-side scripts cannot directly affect and alter server-side information, XSS attacks still compromise online security to alter form values or switch form action to post data to the attackers site. Cross-site scripting is a common web application vulnerability. With Cross-site scripting vulnerability, the attacker can hijack a logged in user s session. This means the hacker can change the user s log in password and overrule the user s session. For example, if a web application is vulnerable to cross-site scripting and the administrator s session is hijacked, the hacker will have full administration availability on that web application. Many web developers don t realize how big the impact of an exploited cross-site scripting vulnerability can be. Cross-site scripting vulnerability can expand in many ways, such as being used as a bug tracking system. Furthermore, web applications are becoming tricky and hard to manually identify and check every attack of a web application. Websites suffer from vulnerabilities that leave organizations helpless, and suffer from cross-site scripting attacks. Hackers are constantly experimenting on a wide range of hacking techniques to harm websites and web applications capturing important data including credit card numbers, and social security numbers. Cross-site scripting is an security exploit that if successful can steal data, take control of a user s session, run malicious code, or even be used as part of a phishing scam. Many times a XSS attack inserts malicious code into the Florida State University ischool 3

4 Cross-Site Scripting webpage without the users administrators ever noticing. It is often placed into the code as the HTML <script> tag, and hard to even see when that script is executed because the text inside a <script> tag is not generally displayed. This script could be run on something simple like viewing a page or one simple aspect of a page leaving the user completely unaware that what they just viewed caused a malicious script to be run. Scripts such as these can run request to view information about the user such as a member s cookie information and then pass that information on to the attacker. This technique is very hazardous to users if the script causes them to lose control of their session to the outside attacker. The attacker then can access important data, alter the site/program functions or aspects, and Figure more 4: setgetcookie.htm all using the user s role. Let s look to see how simple XSS attacks can be. We have members posting on Secuirty123 message forum, which allows the members to post general questions about security to enhance their knowledge on the subject. When one does post a message to the forum, that post is transferred to an online database and will be displayed for all other members to read without ever being validated or encoded. A malicious attacker can post a comment containing a script enclosed by the <script> tags without ever being validated. Members, not knowing that the script is present because it usually isn t viewed, don t even know they are being attacked. Once a member actually views the attackers comment, the script will legitimately requires the member s cookie information and pass it to the attacker. This is known as Persistent XSS as shown below (Glynn). Figure 3: Persistent XSS attack (Glynn) Survey of XSS PHP Vulnerability: Lab 03 When attackers succeed in exploiting XSS vulnerability, they have a vast array of options to hack. They can gain access to account credentials, spread webworms, view user s browser history or control the browser remotely. It is important that websites take necessary actions to validate user input and make sure pages are properly encoded. Web pages that are not properly encoded and are vulnerable to XSS are referred to as an XSS hole (Rouse). During Lab 03, our classmates retrieved files from the folder webhacking.zip and received two directories called XSS and script-attacks. In the XSS directory, the files setgetcookie.htm and malurl.htm were used to set up and steal the created cookie. The first step in Lab 03 was to create a cookie in setgetcookie.htm. Figure two shows what a participant would see 4 Florida State University ischool

5 once he or she opened up the setgetcookie.htm. Once that cookie was saved onto the system, the user would then be directed back to malurlhtm. Once he or she was in malurl.htm and clicks the second link, the coding redirects the user to redirectpage.htm also located in the XSS directory. Figure 3 shows the coding for malurl.htm. Once the user clicked a link, he or she was redirected to redirectpage.htm which has a script embedded in an html tag. The script inputs the documents cookie to stealcookie.php on the attacker s site and stealcookie.php logs the cookie on the attacker s site to log.txt. Hackers can easily gain this information from a user who doesn t understand coding in a webpage that well. The first link is a malicious link but can easily be discovered by hovering over the link. The Figure 5: malurl.htm Figure 7: stealcookie.php code Role-Based Access Control Team Turn Up second link is encoded so that the referral location isn t shown once you hover over the link. This is because the hacker s were able to hide the actual path of the clickable link. This is one countermeasure one person has to look into before navigating through a website. The actual path of the second link takes you directly to redirectpage.htm, which has the coding to start the process of stealing your cookie! Figure 6: redirectpage.htm code Figure 4 above shows the coding in redirectpage.htm. The coding inside redirectpage.htm shows that setgetcookie.htm is moved to the stealcookie.php script file. The stealcookie.php file then opens up log.txt and gets the name of the cookie and all the information stored in the cookie as shown to the right in figure 5. A hacker is easily able to retrieve a cookie from a user who is unknown to this type of vulnerability by using the HTTP parameter sent to stealcookie.htm using the GET method. Users who want to watch out for this XSS attack must know what they are getting themselves into within a web page. One known way to counter this act of hacking is to always hover over the link before clicking on it. Underneath the browser (depending on chosen browser) the path of the link will show up telling the user where he or she is going next. If something doesn t look how it is supposed to be or is completely different that the webpage you are currently on, do not click the link! It is a common occurrence for hackers to steal this information once you clicked on a malicious site! Florida State University ischool 5

6 Figure 10: Bank Statement Results Figure 9: roses.htm query result Cross-Site Scripting In the second part of Lab 03, we used a faulty webpage that uses php scripts to navigate through pages within the website. Once one opened up sample.htm, he or she can type roses.htm or lotus.htm to see more information about each individual webpage by using the test.php script. If a user types in roses.htm, he or she will be directed to the Figure 8: roses.htm sample.htm webpage code listed in the directory as shown in figure 6. Unfortunately, the coding in sample.htm allows the use of semi-colons (;) or pipelines ( ) to view the contents in the websites directory. With that being said, one could type in roses.htm; ls.. and the page will show all of the contents in the directory as shown to the right. When a hacker knows he or she is able to list the contents of a directory, they can then use this to find confidential information such as the bank account for a user. The hacker would type in roses.htm; ls confidential; cat bankinfo.htm and receive the bank statement in this directory. Hackers can use this information to find unsuspected information that should not be viewable. Countermeasures for this type of XSS attack are detailed later in our report. Twitter XSS Vulnerability Exploit On September 21 st, 2010 Twitter received complaints that were caused by cross-site scripting after a release of their new website to computer platforms. A user was able to find a security hole in their new updated site and took advantage of Twitter.com. First, the user created an account that exploited user accounts by switching tweets different colors and causing a pop-up box to appear with text when a user hovered over the actual Tweet. Users referred to this issue as onmouseover due to the fact that user only had to do is run his or her mouse over the Tweet (Lord). More users then took the security issue one-step further and then added more code to automatically 6 Florida State University ischool

7 Role-Based Access Control Team Turn Up have users retweet the original Tweet without their knowledge. A user searched for the keyword onmouseover and returned the results and within one minute the results had 33,053 more tweets since the user started the search! This example shows that anyone is susceptible from any XSS attack is countermeasures aren t applied to the system. Bob Lord, Twitters head security leader noted that the XSS issue was actually discovered a month before the incident and they patched it up. When they released their new version of Twitter, the patch was not included and users took it to their advantage (Westervelt). Since the patch was not included, users could submit JavaScript code as plaintext into a Tweet that could be executed on any browser of any user (Lord). Simple security mistakes such as this could have detrimental affects on the company and could lead to a decline in user activity due to trust issues with the website! PHP Detection Methods With the surge of PHP vulnerabilities in today s environment, numerous detection methods have been developed to counteract attackers attempting to uncover confidential information. PHP scanners have been created to review and uncover code vulnerabilities before a code is released and an attacker can exploit the broken code. Unfortunately, attackers evolve their skills and find new loopholes in code, so scanners cannot guarantee100% accuracy in finding all PHP vulnerabilities. It is recommended that a coding user must know his or her code extensively, know how to write secure software, and do diligent code reviews. Fortunately, PHP scanners are a must have for businesses and users looking to protect their web pages from exploitation by limiting the amount of security breaches found in their coding. With the surge of PHP exploitation, comes a multitude of PHP scanners for users to choose from. This section of our research report will contain an overview of three top PHP vulnerability detection scanners. RIPS Source Code Analyzer According to phpscanner.net, RIPS is a tool written to find PHP vulnerabilities using static code analysis. The RIPS security scanner detects a multitude of PHP vulnerabilities that include code execution, cross-site scripting, SQL injection, and many more. With the RIPS source code analyzer, a user may put their code into their scanner, choose the type of vulnerability to scan, and the RIPS scanner will detect any broken code one has inputted. Figure 11: RIPS results The results of the user code in the path of d:\cipher3\timeclock/work.php shows what vulnerabilities are present in the scan. The RIPS scan shows that the code has a total of three different PHP vulnerabilities inside the code. RIPS will break off the sections of the code and show the user exactly what is causing code vulnerability. After the scan is complete, RIPS will structure output of recommended code to implement to remove the found problems! Florida State University ischool 7

8 Cross-Site Scripting PHP Vulnerability Hunter The PHP Vulnerability Hunter program is an advanced whitebox PHP web application that will scan a vast range of vulnerabilities through static and dynamic analysis. The PHP Venerability Hunter is able to detect the following classes of vulnerabilities: Arbitrary command execution Arbitrary file read/write/change/rename/delete Local file inclusion Arbitrary PHP execution SQL injection User controlled function invocation Reflected cross-site scripting (XSS) Open redirect Full path disclosure The PHP Vulnerability Hunter scans through three phases: Initialization, Scan, and Uninitialization Phase. During the initialization phase, code is annotated and static analysis is performed on code to detect inputs. After code is annotated and static analysis is performed, the scanning starts to detect bugs inside the code. This is where dynamic analysis comes into play. Dynamic Analysis is performed to discover new inputs or bugs within the code. Once the scan is complete, all of the files are restored from backups made from initialization phase and results are posted. Acunetix Web Application Security Acunetix is a paid web server scanner that allows comprehensive scanning for SQL injection and Cross-Site Scripting Vulnerabilities. The product guarantees a fast detection method with the reduction of false positives with a precise pinpointing of where in the source code the vulnerability is located. On Acunetix.com, they state that some security scanners are not able to scan password-protected areas due to the complex scripting to test the actual page. With Acunetix, a user may record a login sequence, and replay the sequence during the scan process! Acunetix also lets a user scan multiple websites at one time. The figure below represents the process that Acunetix takes to scan a website, find a vulnerability, and send an notification of a full, comprehensive report of the vulnerability detected. 8 Florida State University ischool

9 Role-Based Access Control Team Turn Up Figure 12: Acenetix Scanner PHP Vulnerabilities Countermeasures The five most common PHP vulnerabilties include: Injection Vulnerabilities and Cross-Site Scripting Broken Authentication Session Management Insecure Direct Object References Security Misconfiguration In this section we will breakdown how to counteract these vulnerabilities to better serve customers and your business, webpage or database. Injection Vulnerabilities There are various forms of injection attacks, such as SQL, operating systems, and LDAP injection. Those attacks work by sending data to an application as part of a command. Carefully crafted data can trick an application into executing unintended commands or accessing unauthorized data. SQL injection happens when attackers take over sites that generate SQL queries using user-supplied data. This allows an attacker to submit malicious SQL queries and pass commands directly to a database. Broken Authentication and Session Management Web applications have to handle user authentication and establish sessions to keep track of each user's requests since HTTP does not provide this capability. All account management functions and transactions should require reauthentication to prepare itself in case an attacker discovers a session where the original user forget to log out. Something that also needs to be considered is the two-factor authentication for high-value transactions. Enterprises can perform test to discover the authentication and session management problems. Vulnerability scanners used by developers can access and take care of the security problems. Florida State University ischool 9

10 Cross-Site Scripting Insecure Direct Object References This is due to poor application design based on the false assumption that users will always follow the application rules. For instance, if a user's account name is shown in the URL page, a malicious user may be able to find another user's name and resubmit the request to access their data. Using random and unpredictable ID and file names is the best way to prevent this from happening. Some places were data can be incorrectly revealed are drop-down list boxes, JavaScript code, hidden form fields, URL, and links. Security Misconfiguration Some of the complex devices and software s like servers, firewalls, or databases support a Web application infrastructure. All these elements need to be properly maintained since many of these systems tend to fail at times. The reason why some of these Web application infrastructures are poorly maintained is because they sometimes don t undergo the necessary training. Conclusion After experimenting and researching with PHP vulnerabilities, we realized that it is important to know what exactly is going in your website. Hackers live to attack vulnerable servers for their advantage in retrieving confidential information. A security expert must be thoroughly involved in detecting, preventing, and recovering from all attacks before any hacker causes serious damage to a system or user! The results of our Lab 02 and Lab 03 shows a basic example of what a hacker can do to a system if you do not understand your source code inside and out. One little mistake is reviewing your code and a company s organization can lose credibility within all of their users if their data is stolen or shown to an unauthorized source! 10 Florida State University ischool

11 Role-Based Access Control Team Turn Up Works Cited Cobb, Michael. "Cross-site Scripting Explained: How to Prevent XSS Attacks."Computer Weekly. N.p., Nov Web. 28 Oct Cobb, Michael. "Five Common Web Application Vulnerabilities and How to Avoid Them." SearchSecurity RSS. Search Security, 07 July Web. 06 Dec Cornell, Dan. "Stamp out XSS Cross Scripting Vulnerabilities with Proactive Measures."Search Security. N.p., Nov Web. 28 Oct Dahse, Johannes. "RIPS." RIPS - Free PHP Security Scanner Using Static Code Analysis. RIPS, Web. 06 Dec Glynn, Fergal. "Cross-site Scripting." VeraCode. N.p., n.d. Web. 28 Oct "InfoSec Risks, Threats, Vulnerabilities & Countermeasures." CIPP Guide RSS. CIPP, 22 Nov Leitch, John. "PHP Vulnerability Hunter Overview." PHP Vulnerability Hunter Overview. AutoSec Tools, n.d. Web. 06 Dec Lord, Bob. "All about the "onmouseover" Incident Twitter Blogs." Twitter Blogs. N.p., 21 Sept Web. 28 Oct Rouse, Margaret. "Cross-site Scripting (XSS)." Search Security. N.p., Sept Web. 28 Oct Westervelt, Robert. "Cross-site Scripting Twitter Attack Causes Chaos." N.p., 21 Sept Web. 28 Oct "Worldwide Leader in Web Application Security." Acunetix. N.p., n.d. Web. 06 Dec < Florida State University ischool 11