CASE STUDY PEOPLESHARZ.COM

CASE STUDY: PEOPLESHARZ.COM

Name

Institution

Course

Instructor

Date

Executive Summary

This report consists of two deliverables. First, it contains a work plan for incident response relating to the hacking of the PeopleSharz’s website in April 2013. Second, it contains proposed measures that PeopleSharz and the host of its website, HotHost1, should take to prevent the recurrence of a similar attack by web hackers. It is expected that the evaluation, as well as testing, of the various vulnerabilities that may have put the website at the risk of being hacked will reveal the specific reasons why the website was hacked. As well, it is expected that PeopleSharz and HotHost1 will actualize the proposed measures, including procuring and deploying the requisite software such as OSSEC or other file integrity monitoring or host-level intrusion detection utilities and Snort or other systems for detecting network intrusion and detecting data loss.

PeopleSharz should keep abreast with emerging website hacking threats. Together with HotHost1, PeopleSharz should bolster their network access controls. PeopleSharz should invest in the requisite software updates as they become available especially where they are meant to mitigate particular internet security vulnerabilities. It should bolster network security by working closely with its employees who access the website. It should install appropriate WAFs (Web Application Firewalls), which may be hardware-based or software-based. HotHost1 and PeopleSharz should deploy, or install, appropriate internet security applications. The admin pages of the PeopleSharz’s website should be hidden to ensure that search engines are incapable of indexing them. As well, PeopleSharz should facilitate the investigation, as well as testing, of the integrity of the PeopleSharz and HotHost1 servers especially with respect to their capability of monitoring incoming files’ integrity.

Background and Problem Analysis

PeopleSharz, an internet establishment, which was founded in 2011, suffered a security breach in April 2013. Its website was hacked. The hacker accessed its clients’ passwords and other details and drafted them on Pastebin. A number of events might have actualized the breach of the establishment’s website environment as well as the stealing of the clients’ details by the hacker (Ahmad & Russell 2002; Conway & Cordingley 2004). It is safe to assume that the hacker used either social engineering or a software exploit technique to hack the environment.

If the hacker engaged in social engineering to breach of the PeopleSharz’s website environment, as well as steal the clients’ details, it can be assumed that the environment is prone to attacks from even unsophisticated hackers. That is elementarily because social engineering is not as considerably technological as the other means used by hackers to access given website environments (Ahmad & Russell 2002; Conway & Cordingley 2004). If the hacker used social engineering with respect to the PeopleSharz’s website, he or she may have extracted credentials for accessing the website from unsuspecting users or user via phishing. The hacker may have sent phishing emails to internet users, inviting them to get into, or log on, websites that he or she controlled (McClure, Scambray & Kurtz 2009). If the users accepted the invitations and logged on the websites, the hacker would have captured their details such as their PeopleSharz passwords and drafted them as having been extracted from the PeopleSharz’s website environment.

The hacker may have extracted the credentials from HotHost1, which hosted the website. He or she may have extracted the credentials from disgruntled employees of PeopleSharz or HotHost1. If the website came under a social engineering attack, there is a high chance that PeopleSharz’s internal systems were then not as private as they should be ideally, making them easy to spoof (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). There is a high chance that the systems were accessible by the public, making them easy to replicate.

As noted earlier, a software exploit technique may have been employed to hack the PeopleSharz’s website environment. The use of the technique could have been successful owing to any erroneous assumptions may have been made by those who developed the website. That is because software-based attacks against websites most likely stem from website developers’ erroneous assumptions (Ahmad & Russell 2002). The assumptions may include thinking that given codes can filter away commands that are possibly malicious while the codes lack that capability.

Codes that are incapable of filtering out such commands from the external cause allow for code injection attacks against websites. The codes allow in commands that are malicious and embedded in incoming data. In most cases, hackers use the commands to access data held in the databases of targeted websites (Ahmad & Russell 2002). The hacker may have extracted the PeopleSharz clients’ details from either the PeopleSharz website or the HotHost1’s servers owing to the presence of codes that could not filter away commands that were possibly malicious. In numerous programs with network elements, such codes are probable entry points for website hackers.

Threat Analysis

With reference to the PeopleSharz website’s attack, there are varied things that should be investigated as well as tested. First, the integrity of the PeopleSharz and HotHost1 servers should be investigated, as well as tested, especially with respect to their capability of monitoring incoming files’ integrity. That will be achieved through the deployment of OSSEC or any other file integrity monitoring or host-level intrusion detection utilities on all the servers and running the utility. The utility would identify and use the attack’s signature, unanticipated file changes, and odd system behaviors to identify the nature of the security breach that PeopleSharz suffered (Ahmad & Russell 2002; Conway & Cordingley 2004). Especially, the expected deliverable should be a report identifying whether or not the hacker accessed the clients’ details since the website or the servers came under a successful code injection attack.

Second, the presence of odd network traffic in activities stemming from connections that are internet-bound and the internet should be investigated as well as tested. That can be achieved through the deployment of Snort or any other systems for detecting network intrusion and detecting data loss (Conway & Cordingley 2004). The systems will help in establishing whether sensitive client details will be attempting to exit the PeopleSharz and HotHost1 website environments. The systems will determine conclusively whether or not the PeopleSharz hacker actually got the client details that he or she drafted on Pastebin from the PeopleSharz website. As noted earlier, the hacker may have sent phishing emails to internet users, inviting them to get into, or log on, websites that he or she controlled. If the users accepted the invitations and logged on the websites, the hacker would have captured their details such as their PeopleSharz passwords and drafted them as having been extracted from the PeopleSharz’s website environment. The expected deliverable should be a report identifying whether or not the hacker accessed the clients’ details from the website (Ahmad & Russell 2002).

Third, the security logs from the PeopleSharz website and the HotHost1 servers and related systems, network applications, and network devices should be investigated as well as tested. That can be attained by centrally gathering, as well as examining, the security logs using specific log management tools. That will help in troubleshooting any extant operational problems. As well, that will help in making out any security related anomalies in the PeopleSharz website and the HotHost1 servers and related systems, network applications, and network devices (Ahmad & Russell 2002). The anomalies may include the presence of codes that are unable to filter away commands that are possibly malicious and the possible public nature of the PeopleSharz’s systems (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). If the systems were then not as private as they should be ideally they would be rather easy to spoof. The expected deliverable should be a report identifying whether or not there are specific security related anomalies in the PeopleSharz website and the HotHost1 servers and related systems, network applications, and network devices and their nature if present.

Fourth, the presence of risky contents on the PeopleSharz and HotHost1 servers should be investigated as well as tested. That will be done through the utilization of local tools capable of scanning the servers’ contents to make out any risky contents available. The risk content may be an indistinguishable a HTML tag with an iframe element (Merkow & Breithaupt 2000; Pauli 2013; Shema 2012). The risk content may be an indistinguishable a JavaScript command with an eval element. As well, the utilization of local tools capable of scanning the servers’ contents may make out any obfuscation present (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). Notably, in many cases, obfuscation points out possible server compromise. Server compromise indicators may exist in PHP files on the server side (Ahmad & Russell 2002). Such indicators include passthru commands and shell_exec commands. In addition to the use of the local tools, the presence of risky contents on the PeopleSharz and HotHost1 servers will be investigated, as well as tested, using tools that help in the creation of signatures along with running of scans aimed at flagging the contents (McClure, Shah & Shah 2003; Stuttard & Pinto 2013). Such tools include YARA and ClamAV. The expected deliverable should be a report identifying whether or not there are specific risky contents on the PeopleSharz and HotHost1 servers that may have led to the compromise of the clients’ data.

Fifth, the presence of directives that may have been received by those visiting the PeopleSharz to give out their personal details by way of phishing emails should be investigated as well as tested. As noted earlier, the hacker may have sent phishing emails to internet users, inviting them to get into, or log on, websites that he or she controlled. If the users accepted the invitations and logged on the websites, the hacker would have captured their details (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). Often, website hackers place or modify specific files on servers to direct internet users to open URLs hosting malicious exploit kits. The presence of the directives will be investigated, as well as tested, by requiring specific users of the PeopleSharz website to fill in questionnaires aimed at establishing whether they received such directions and their subsequent actions. The expected deliverable should be a report identifying whether or not the configuration of the PeopleSharz and HotHost1 servers allows for the streaming of such directives to users.

Sixth, the existence of codes that are malicious on the PeopleSharz website should be investigated as well as tested. That will be done using remote scanners capable of making out such codes’ presence. Such scanners include a QualysGuard and Sucuri Site Check. The tools will be deployed on the website and be allowed to crawl it detecting any present doubtful redirects (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). As well, the tools will be deployed on the website and be allowed to crawl it detecting any present embedded client-centered exploits. As noted earlier, the hacker may have extracted the PeopleSharz clients’ details from either the PeopleSharz website or the HotHost1’s servers owing to the presence of codes that could not filter away commands that were possibly malicious. In numerous programs with network elements, such codes are probable entry points for website hackers (Ahmad & Russell 2002). The expected deliverable should be a report identifying whether or not there are codes that are malicious on the PeopleSharz website.

Dependencies and Critical Success Factors

The success of the evaluation, as well as testing, of the possible PeopleSharz website environment’s vulnerabilities and their successful mitigation will be subject to various critical success factors and dependencies. The critical success factors and dependencies will include the tools, including software, required in the evaluation as well as testing. They software will include:

OSSEC or other file integrity monitoring or host-level intrusion detection utilities

Snort or other systems for detecting network intrusion and detecting data loss

Specific log management tools

Local tools capable of scanning the servers’ contents to make out any risky contents available

Questionnaires

Remote scanners capable of making out such codes’ presence

Various specialists will be required to ensure that the job is executed successfully. The specialists will include web and information security analysts, web developers along with computer network architects. The security analysts will be charged with analyzing, as well as investigating, possible problems with PeopleSharz’s software solutions reported by its clients (Ahmad & Russell 2002). The analysts will be documenting the outcomes of own investigations. They will be critical in the correction of any software defects that they will identify. They will be running units tests on the software, actualize test plans, and record test outcomes.

The security analysts will be charged with partnering with and leading web security development teams to realize compliance in cases where gaps will be identified. They will put in place the requisite metrics for communicating web security progress to the security development teams as well as senior management (Conway & Cordingley 2004; McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). In addition, they will afford PeopleSharz and HotHost1 engineering designs for additional software solutions for mitigating identified security vulnerabilities and consult with the teams regarding secure coding practices.

The architects will be critical in the designing, as well as development, of PeopleSharz’s data communication networks and web security systems in line with its business goals and plan. The architects will work closely with the start-up’s CTO (Chief Technology Officer) in deciding on its website environment’s future (Ahmad & Russell 2002). The architects will research on new web security technologies and determine the ones that will work best for the start-up, especially in the light of the start-up’s information security needs and goals.

Web developers will be critical to the success of the evaluation, as well as testing, of the possible PeopleSharz website environment’s vulnerabilities and their successful mitigation. As noted earlier, a software exploit technique may have been employed to hack the PeopleSharz’s website environment. The use of the technique could have been successful owing to any erroneous assumptions may have been made by those who developed the website. That is because software-based attacks against websites most likely stem from website developers’ erroneous assumptions. Web developers will be useful in identifying the erroneous assumptions that the original developers of the PeopleSharz’s website may have had (Ahmad & Russell 2002; Conway & Cordingley 2004). The web developers may help in developing new codes to substitute the possibly malicious ones that may have given rise to the attack.

Recommendations

Regarding the extant attack, PeopleSharz should facilitate the investigation, as well as testing, of:

the integrity of the PeopleSharz and HotHost1 servers especially with respect to their capability of monitoring incoming files’ integrity

the presence of odd network traffic in activities stemming from connections that are internet-bound and the internet

the security logs from the PeopleSharz website and the HotHost1 servers and related systems, network applications, and network devices

the presence of risky contents on the PeopleSharz and HotHost1 servers

the presence of directives that may have been received by those visiting the PeopleSharz to give out their personal details by way of phishing emails

the existence of codes that are malicious on the PeopleSharz website (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012)

PeopleSharz should keep abreast with emerging website hacking threats (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). The management of the start-up should earn at least an elementary knowhow of the threats and put in place means of countering them if they occur (Ahmad & Russell 2002). The management can get the knowhow by following the relevant updates bulkposted on tech websites. Such websites include The Hacker News, which offers readers insights that are useful in putting up new precautions where they are required (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012).

PeopleSharz and HotHost1 should bolster their network access controls. Especially, the PeopleSharz website’s administrator level should be configured to ensure that hackers cannot get access to critical data or information. The administrators of the website should enforce passwords, as well as usernames, that are challenging to guess. They should rewrite the prefix of the default database to a combination of symbols, letters, and numerals that are challenging to guess and random (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). Each user of the website should only be allowed a few login attempts within a given period, possibly with email password resets since hackers can compromise the users’ email accounts too. The users should be advised to desist from sending their login details via emails as emails can fall into website hackers’ hands.

PeopleSharz should invest in the requisite software updates as they become available especially where they are meant to mitigate particular internet security vulnerabilities (Ahmad & Russell 2002). If PeopleSharz delays such updates, it will expose its website environment to possible attacks by hackers before putting the updates in place.

PeopleSharz should bolster network security by working closely with its employees who access the website (McClure, Shah & Shah 2003; Stuttard & Pinto 2013). That can be done by requiring the employees to change own passwords frequently and requiring the employees to ensure that they have strong passwords and desist from writing the passwords down (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012). As well, that can be done by requiring the employees to scan every device that they plug it into the start-up’s network.

PeopleSharz should install appropriate WAFs (Web Application Firewalls), which may be hardware-based or software-based. The WAFs may be cloud-based. Essentially, PeopleSharz should deploy the WAFs in front of own servers to filter the incoming traffic, identifying and stopping malicious traffic. WAFs, if used appropriately, block web hacking attempts by filtering away malicious traffic, including malicious bots along with spammers (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012).

PeopleSharz and HotHost1 should deploy, or install, appropriate internet security applications. The applications, such as Acunetix WP Security plugins, ensure that hackers do not access specific internet resources easily (Ahmad & Russell 2002). If deployed, the Acunetix WP Security plugins will help hide the CMS of the PeopleSharz’s website. That will increase the website’s resilience regarding hacking tools that scout websites automatically when deployed in search of sites with particular version, builds, and identified vulnerabilities (McClure, Scambray & Kurtz 2009; McClure, Mcclure, Scambray & Kurtz 2012).

The admin pages of the PeopleSharz’s website should be hidden to ensure that search engines are incapable of indexing them. They can be hidden using robots_txt files, which ensure that search engines do not list them (Ahmad & Russell 2002). Notably, hackers can access indexed web pages easily and intrude them.

References list

Ahmad, DRM & Russell, R 2002, Hack proofing your network, Syngress, Rockland.

Conway, R & Cordingley, J 2004, Code hacking: A developer’s guide to network security, Charles River Media, Hingham.

McClure, S, Mcclure, S, Scambray, J & Kurtz, G 2012, Hacking exposed 7: Network security secrets & solutions, McGraw-Hill, New York.

McClure, S, Scambray, J & Kurtz, G 2009, Hacking exposed 6: Network security secrets & solutions, McGraw-Hill, New York.

McClure, S, Shah, S, & Shah, S 2003, Web hacking: Attacks and defense, Addison-Wesley, Boston.

Merkow, MS & Breithaupt, J 2000, The complete guide to Internet security, AMACOM, New York.

Pauli, J 2013, Basics of Web Hacking: Tools and Techniques to Attack the Web, Elsevier Science & Technology.

Shema, M 2012, Hacking web apps: Detecting and preventing web application security problems, Syngress, Amsterdam.

Stuttard, D & Pinto, M 2013, The web application hacker’s handbook: Discovering and exploiting security flaws, Wiley, Hoboken.