On April 27, 2020, the Wordfence Threat Intelligence team discovered a Cross-Site Request Forgery(CSRF) vulnerability in Ninja Forms, a WordPress plugin with over 1 million installations. This vulnerability could allow an attacker to trick an administrator into importing a contact form containing malicious JavaScript and replace any existing contact form with the malicious version.
We reached out to Ninja Form’s security team according to their Responsible Disclosure Guidelines and they replied within a few hours. The plugin was patched less than 24 hours after our initial contact, on April 28, 2020.
All Wordfence users, including both Wordfence Premium and free Wordfence users, are protected from XSS attempts against this vulnerability by the Wordfence Firewall’s built-in XSS protection.
The Ninja Forms plugin features a “legacy” mode which allows users to revert its styling and features to those of the plugin’s final 2.9.x version. As part of this feature, it adds several AJAX functions which appear to be intended to import forms and fields between the “legacy” mode and the default mode. While all of these functions used capability checks, two of the functions failed to check nonces, which are used to verify that a request was intentionally sent by a legitimate user. One function in particular, ninja_forms_ajax_import_form, allowed importing forms containing custom HTML:
As such, if an attacker was able to trick an administrator into clicking a crafted link, they could spoof a request using that administrator’s session and import a form containing malicious JavaScript into the site. Worse yet, it was possible to replace any existing form on the site with one of these imported forms by setting the formID$_POST parameter to the ID of an existing form.
Depending on where the JavaScript was placed in the imported form, it could be executed in a victim’s browser whenever they visited a page containing the form, whenever an Administrator visited the plugin’s Import/Export page, or whenever an Administrator attempted to edit any of the form’s fields. As is typical with Cross-Site Scripting (XSS) attacks, a malicious script executed in an Administrator’s browser could be used to add new administrative accounts, leading to complete site takeover, while a malicious script executed in a visitor’s browser could be used to redirect that visitor to a malicious site.
Vulnerability Disclosure Policies are Important
One of the reasons this plugin was patched so quickly was because the plugin’s team maintains a Responsible Security Disclosure Policy, often referred to as a Vulnerability Disclosure Policy. This allowed us to contact them directly with our full disclosure rather than spending days trying to find or verify the appropriate contact channel. While we have occasionally seen plugins patched in less than 24 hours in the past, responses like this are exceptional and indicate a serious dedication to security.
If you are responsible for any kind of software product or service, having a Vulnerability Disclosure Policy (VDP) not only improves your chances of being alerted to serious security issues, but also allows you to set expectations for your response. Most importantly, it reduces the risk of vulnerabilities in your products being prematurely or irresponsibly disclosed and attacked by bad actors before you have a chance to fix them. For these reasons, we strongly recommend implementing a VDP to improve not only the efficiency of your response to specific flaws, but also the general security of your product.
Timeline
April 27, 2020 19:00 UTC – Our Threat Intelligence Team discovers and analyzes the vulnerability and verifies that our existing Firewall Rules provide sufficient protection against XSS. April 27, 2020 19:24 UTC – We provide full disclosure to the plugin’s developer as per their Responsible Security Disclosure Policy. April 27, 2020 20:27 UTC – We receive a response that a patch should be available the next day. April 28, 2020 19:00 UTC – Patched version of the plugin released.
Optimized partners can reach international customers faster with Railgun
Railgun ensures that the connection between your origin server and the Cloudflare network is as fast as possible.
Railgun compresses previously unreachable web objects by leveraging techniques similar to those used in the compression of high-quality video. This can result in additional performance increase.
Railgun accelerates the connection between each Cloudflare data center and an origin server so that requests that cannot be served from the Cloudflare cache are nevertheless served very fast.
Approximately 2/3 of requests to sites on Cloudflare are served directly from cache from the data center that is physically closest to the person surfing the web. Because Cloudflare has data centers around the world this means that whether you are in Bangalore, Brisbane, Birmingham or Boston web pages are delivered quickly even when the real, origin web server is thousands of miles away.
Cloudflare’s ability to make a web site appear to be hosted close to web surfers is key in accelerating web surfing. A web site might be hosted in the US, but accessed mainly by web surfers in the UK. With Cloudflare the site will be served from a UK data center eliminating the costly delay caused by the speed of light.
But the other 1/3 of requests made to Cloudflare have to be sent to the origin server for processing. This happens because many web pages are not cacheable. This can be because of a misconfiguration, or, more commonly, because the web page changes frequently or is personalized.
For example, it’s hard to cache the New York Times home page for any length of time because the news changes and being up to date is essential to their business. And for a personalized web site like Facebook each user sees a different page even though the URL may be the same for different users.
Railgun uses a collection of techniques to accelerate and cache these previously uncacheable web pages so that even when the origin server must be consulted web pages are delivered quickly. And that even works for rapidly changing pages like news sites, or for personalized content.
Cloudflare research showed that even though many sites cannot be cached they actually change very slowly. For example, the New York Times home page changes throughout the day as news stories are written, but the boilerplate HTML of the page mostly stays the same and many stories stay on the front page all day.
For personalized sites the boilerplate HTML is the same with only small pieces of content (such as a person’s Twitter timeline or Facebook news feed) changing. This means there’s a huge opportunity to compress web pages for transmission if the unchanging parts of a page can be detected and only the differences transmitted.
How It Works
When a request is made to a Cloudflare server for a web page that is not in cache Cloudflare makes an HTTP connection to the origin server to request the page. It’s that HTTP connection that Railgun accelerates and secures.
Railgun consists of two software components: the Listener and Sender. The Railgun Listener is installed at your web host on an origin server. It’s a small piece of software that runs on a standard server and services requests from Cloudflare using the encrypted, binary Railgun protocol.
The Railgun Sender is installed in all Cloudflare data centers around the world and maintains connections with Railgun Listeners.
When an HTTP request comes in that must be handled by an origin server, Cloudflare determines whether it is destined for a Railgun-enabled website. If not, standard HTTP is used, but if so the HTTP request is routed to the Railgun Sender for handling.
The Railgun Sender turns the request into a compressed, binary chunk that’s transmitted to the corresponding Railgun Listener. The Railgun Listener handles the request and performs an HTTP request to the origin server. From the origin server’s perspective it’s as if the HTTP connection came directly from Cloudflare, but because it comes from inside the hosting partner’s infrastructure the request suffers no latency related delay.
Railgun uses a new caching mechanism based on comparing page versions to determine what needs to be transmitted across the Internet to the Railgun Sender. Using this mechanism Cloudflare is able to achieve typical 99.6% compression (taking, for example, a 100k web page down to 400 bytes) and a speedup of over 700%. In fact, the compressed data is often so small that using the binary Railgun protocol the entire response fits inside a single TCP packet.
Railgun connections are secured by TLS so that requests sent across them cannot be eavesdropped upon. The connection is secured by certificates so that a man-in-the-middle attack is not possible. The TCP connection between Cloudflare and the origin server is kept alive so that it can be reused for subsequent requests eliminating the slow start up of a TCP connection.
Railgun requests are multiplexed onto the same connection and can be handled asynchronously. This means that Railgun is able to handle many, simultaneous requests without blocking and maximizing the use of the TCP connection.
QUIC.cloud is the first and only content delivery network with the ability to cache dynamic WordPress pages. Using QUIC as the transfer protocol, QUIC.cloud will make your website faster and more secure than the competition.
Litespeed’s QUIC.cloud is a new way to supercharge your website.
QUIC.cloud CDN, an intelligent cache CDN based on LiteSpeed Cache, is the only CDN service that can accurately cache dynamic pages (pages that can change frequently).
LSCache for WordPress knows when to automatically purge and sync data in QUIC.cloud CDN, giving it the upper-hand on all other CDN providers. Users can now provide anyone across the globe access to their sites in less than 100ms!
Also, new to QUIC.cloud is image optimization, critical CSS, and LQIP. With these new services readily available, QUIC.cloud is more customizable and efficient than ever before.
After reading through this guide, if there is something you do not understand, please let us know by sending an email to support[at]quic.cloud.
Requirements
Before you can utilize QUIC.cloud, you should refresh your LiteSpeed Cache for WordPress module to in any event v3.0.
Ths guide also assumes you already have a domain setup with WordPress. If you do not yet, please check out WordPress’ Domains guide.
Matching WordPress and QUIC.cloud
To begin, sign into your WordPress dashboard for the domain you’d like to use with QUIC.cloud.
QUIC.cloud
At that point explore to the menu bar on the left half of the site, and float over LiteSpeed Cache.
QUIC.cloud
Then, select General.
On that page there will be a box for a Domain key; click the link Apply Domain Key, on the right side of the box.
Pairing WordPress and QUIC.cloud
You will see a bar at the top saying you applied successfully and to wait for the result. Please refresh the page.
After refreshing, the box should be automatically filled with the key. Next click Save Changes in the right corner.
Once you save, click Link to QUIC.cloud.
Next you will be redirected to QUIC.cloud to sign up/login.
If you login, you will be redirected back to your WordPress dashboard.
If you sign up, you will be asked to fill in your desired password and to agree to the QUIC.cloud terms and conditions. Then click Register.
Check your emails for a message from QUIC.cloud and confirm your account.
Once you click the activation link, a new tab will open saying the activation was successful.
Click My Dashboard and you will be redirected back to the WordPress dashboard.
Back on the WordPress dashboard, there is a button that will direct you to your QUIC.cloud dashboard.
Once on the QUIC.cloud dashboard, you will see the new domain listed.
When you click into the domain, you should see a list including our CDN and the services offered.
If you’d like to use the CDN, please continue on to the next section of this document. If you are not interested in using the CDN, however, then you have successfully finished your setup. Congratulations and welcome to QUIC.cloud!
Setting up the CDN
Before a domain can use QUIC.cloud CDN, the DNS for that domain must be properly set up. Please follow the instructions below to set up your DNS.
DNS Setup
If you are not sure about how the DNS works, check out our DNS Primer. You will need to be logged into your WordPress admin and your DNS management page.
Note - The base domain, e.g. example.com is known as the Root or Apex Domain. All other usages of this domain such as sub.example.com or www.example.com are subdomains.
If you are adding the root domain to QUIC.cloud, refer to the following section. If you are adding a subdomain, refer to the subsequent section.
Adding the Root(Apex) Domain
QUIC.cloud requires that your DNS maps your domain to a domain provided during setup. This means that your DNS provider must support domain to domain mapping for the Root domain.
The following instructions have screenshots from the CloudFlare DNS manager.
Take a screenshot of your current configurations. Keep this as a reference in case things go wrong, so you have something to go back to.
Check what your TTL value is and adjust it to the smallest value possible (if not already). You will need to wait until the old DNS records expire before you can use QUIC.cloud. After the old value expires, every record should be using the new value. Example: previous value: 1 hour, new value: 2 minutes. If it is 3pm when you change the value to 2 minutes, you must wait until 4pm to be sure that all the records now use the 2 minute value.
(Optional) If you wish to use both the root domain and the www. subdomain: Create a CNAME record pointing www. to your Root domain:
If you have a www. record already, edit that to look like the above screenshot. The net result is that www.example.com will target the same server as example.com.
4. Create an A record for a random subdomain that points to your origin IP. For example, origin.example.com.
1.Convert your current record for @ to a CNAME record targeting the subdomain you created in step 4.
Deleting the root domain record:
Note – The below screenshots are for deleting an A record and adding a CNAME record. If your current record is a CNAME record or your DNS Manager allows changing record types, you can just edit the record.
Setting the CNAME record for the root domain:
Make sure that your site is still accessible as is. Here are some ways to test.
Note – If you are using CloudFlare DNS, ensure that the cloud is set to “Grey” (this means you are not actually using Cloudflare for anything other than the DNS).
After performing the above steps, the following should be true: * Your site is still accessible. Nothing should have changed. * If you performed step 3, your www. subdomain should also point to your current IP. Refer to how to check the DNS. * The random subdomain should also target the same IP.
If any of the above are not true, review your DNS configurations and run through the steps again. One possible reason that the above are not true is that the TTL for the old configuration has not expired yet. Make sure that the time has elapsed.
Adding the Subdomain
The following instructions have screenshots from the Digital Ocean DNS manager. The steps should be similar for your DNS provider.
Take a screenshot of your current configurations. Keep this as a reference in case things go wrong, so you have something to go back to.
Check what your TTL value is and adjust it to the smallest value possible (if not already). You will need to wait until the old DNS records expire before you can use QUIC.cloud. After the old value expires, every record should be using the new value. Example: previous value: 1 hour, new value: 2 minutes. If it is 3pm when you change the value to 2 minutes, you must wait until 4pm to be sure that all the records now use the 2 minute value.
If the subdomain points to the same origin server as the Root domain, this step is not required. Create an A record for a random subdomain that points to your origin IP. For example, origin.example.com.
Convert your current record for the subdomain to a CNAME record targeting the subdomain you created in step 3. If you are using the root domain as the base, target that instead.The below screenshots are for deleting an A record and adding a CNAME record. If your current record is a CNAME record or your DNS Manager allows changing record types, you can just edit the record.
Deleting the old record:
Make sure that your site is still accessible as is. Here are some ways to test. If you are using CloudFlare DNS, ensure that the cloud is set to “Grey” (this means you are not actually using Cloudflare for anything other than the DNS).
After performing the above steps, the following should be true: * Your site is still accessible. Nothing should have changed. * The random subdomain should also target the same IP.
If either of the above are not true, review your DNS configurations and run through the steps again. One possible reason that the above are not true is that the TTL for the old configuration has not expired yet. Make sure that the time has elapsed.
Enable CDN
When on your QUIC.cloud dashboard, click on the domain you’d like to enable the QUIC.cloud CDN service for.
Note – Domains can be listed in QUIC.cloud and use the QUIC.cloud services, without using the CDN.
Next, under the services list, click CDN.
Note - If the status of the CDN says ‘OK’, then your CDN is already enabled for that site and you do not need to continue with this guide.
On the following screen, click Enable CDN.
Next we will discuss the DNS records and verification.
Configure DNS Records and Verify
Update the DNS Manager
Note the CNAME record that we created for you, as below:
In your DNS Manager, change the CNAME you set up to point to this CNAME domain.
CloudFlare DNS Example:
At this point, nothing should have changed. Your site should still target your server. Here are some ways to test.
Configure Access for your site (Optional)
On the CDN page, under Setting -> Connection, there are three options that configure how the browser connects to QUIC.cloud and how QUIC.cloud connects to your origin server. Select the appropriate option.
Connection Type to Origin: This option specifies the connection type between QUIC.cloud and your origin server. The available options are: match the connection type from the browser to QUIC.cloud or use HTTP Only.
Frontend Force HTTPS: This option specifies the connection type between the browser and QUIC.cloud servers. If set to ON, HTTP requests to QUIC.cloud are redirected to HTTPS automatically. Otherwise, both request types are forwarded to your backend server (depending on how Connection Type to Origin is configured).
Enable QUIC Backend: If your site offers QUIC and/or HTTP/3, you can try this option. This will let QUIC.cloud servers attempt to connect to your origin server using QUIC and/or HTTP/3.
Configure your Firewall
When your site goes through QUIC.cloud servers, all the requests will appear via QUIC.cloud IPs. This will likely trigger some firewall rules. Make sure to whitelist QUIC.cloud IPs so that the requests do not trigger the firewall.
Verify Your Website is Using QUIC
You must have a valid SSL Certificate set up on QUIC.cloud to use QUIC.
If QUIC.cloud is working properly, your site should be using QUIC. You can use a browser extension to verify this, such as this for Google Chrome. It will show a Green lightning bolt indicator, if your website is using QUIC.
Alternatively, you could use HTTP/3 Check to test it out.
That’s it. QUIC.cloud CDN should now be set up. If you have any questions or issues, please contact us at support[at]quic.cloud.
An Entry Process is the number of PHP scripts you can run at a time. Our Shared Hosting and WordPress hosting plans have limitation of entry process at a time.
Number of visitors on website – An Entry Process should not be confused with the number of visitors you can have on your website as it takes just fractions of a second to complete.
For Eg. if we have restrict 25 entry processes that doesn’t mean that only 25 people can visit your website at a time. It’s because there is very rare possibility of 25 people browsing your website at the same fraction of a second.
When a visitor browses any web page of your website, the web server would start serving the request. While this request is being served, it will use one entry process.
Once this request has been served, the web server would no longer use an entry process and the entry process count would get decreased by 1.
Please note that cron jobs, shell scripts and other commands also use entry process for the duration of the time they are running.
Why such restrictions – Entry process limitations to ensure that no single user consumes all server resources and to prevent DDoS attacks against the web server.
Entry process will limit the number of concurrent connections to web server, thus preventing our server against malicious traffic.
When you use all allotted entry processes (25), new visitors would experience a 508 error.
Instructions in this article apply to Outlook 2019, 2016, 2013, 2010, 2007; and Outlook for Office 365.
If your business uses Microsoft Outlook on the collaborative communications server, Microsoft Exchange Server, you have some advantages over standard Outlook account users, such as the ability to search multiple mailboxes, increased security features and the ability to recall or even replace an email message. With the latter, you can “unsend” emails, which is ideal if you forget to include important information, discover an error in a message or realize you hit the dreaded “Reply All” button on a private email. In addition, you can replace the recalled message with a modified version.
Requirements to Recall
To recall Outlook email:
Both you and your recipient must have an Exchange server email account and use Outlook as the email client.
The recipient’s mailbox is open when you attempt to process a recall.
The original message is unread and is in the recipient’s Inbox.
The message was not touched by any process, such as a rule, spam filter, or add-in.
When you attempt to retract email, Outlook may notify the recipient of the recalled email.
How to Recall an Email in Outlook (and Replace It, if Desired)
1. To recall an email in Outlook:Open Outlook and go to the Sent Items folder.
2. Double-click the sent message you want to recall to open it in a separate window.
The options to recall a message are not available when the message is displayed in the Reading Pane.
3. Go to the Message tab, select the Actions dropdown arrow, and choose Recall This Message.
4. In the Recall This Message dialog box, select one of the following:
Delete Unread Copies of This Message to recall the message.
Delete Unread Copies and Replace With a New Message to replace the message with a new one.
5. If you want to receive notification of the results, select the Tell Me if Recall Succeeds or Fails for Each Recipient check box.
6. Select OK.
7. If you selected Delete Unread Copies and Replace with a New Message, modify the original message.
8. Select Send.
9. You’ll receive an Outlook notification message regarding the success or failure of your attempt to retract or replace the email.
How to ensure the recall is successful
Whether an already-sent e-mail can be replaced by a new message depends not only on the requirements listed above, but also on the recipient’s Outlook settings.
The following scenarios are possible according to Microsoft.
Scenario 1: The “Automatically process meeting requests and responses to meeting requests and polls” feature is enabled (as default).
If the recipient has the “Automatically process meeting requests and responses to meeting requests and polls” feature enabled, both the original message and the message to recall the e-mail will be stored in the recipient’s inbox. Whether the recall works or not depends on whether the mail has been read.
If the recipient has not yet read the original message, it will be replaced by the recall message. The recipient is then informed that you have recalled the original message.
If the message is marked as read when the recall message arrives, the recall attempt will fail and the message will remain in the recipient’s inbox. However, the recipient will be informed that you attempted to recall the message.
Scenario 2: The “Automatically process meeting requests and responses to meeting requests and polls” feature is disabled.
If the recipient has not enabled the “Automatically process meeting requests and responses to meeting requests and polls” feature, both the original message and the message about the recall will be stored in the recipient’s inbox. Whether the recall is successful or not depends on which e-mail is opened first:
If the recipient opens the message about the recall first, the original message will be deleted, meaning the recall was a success.
If the recipient opens the original e-mail first, the recall will be unsuccessful.
Scenario 3: An inbox rule moves the original e-mail to another folder.
If the recipient has defined a rule, which means that the original e-mail and the recall e-mail will be stored in different folders, the recall will fail.
Scenario 4: An inbox rule moves both the original e-mail and the recall e-mail to a different folder.
If the recipient has defined a rule stating that both e-mails should be stored in the same folder, then it depends which e-mail is opened first.
If the recipient opens the recall message first, the original message will be deleted. The recall was a success.
If the recipient opens the original e-mail first then the recall will fail.
Why recalling an email in Outlook doesn’t always work
Unfortunately, if the recipient opens the email you didn’t want them to see, you can’t recall it. They can still get the recall message and note that you wanted to delete the first email, but it will stay in their Outlook system anyway.
If your first message was sent to a folder other than the inbox then the recall won’t work. Neither will it work if it’s sent to a public folder or if you try to recall it from a mobile device. Once one person has seen it, it’s too late.
The recall feature is designed to work with Outlook. If you are sending from a Gmail account for example, you can’t expect it to work, you’ll need to read our guide on how to recall an email in Gmail for tips on how to achieve this.
Different Solution – Delay your emails.
This means you can delay the delivery of an email after you’ve sent it giving you that extra time to change your mind.
Delay the single message in Outlook.
1. Click Options in the Message editing window
2. Hit Delay Delivery.
3. Select the Do not deliver before check box.
4. Select the delivery date and time that you want from the two drop-down lists.
5. Then click on the Close button to save the changes
6. After you click Send, the message will stay in the Outbox folder until your scheduled delivery time.
This will only work to give you a bit more time to reconsider your message; it will not prevent you from accidentally sending the email to the wrong person. It is also only useful if you remember to check the message again before it leaves your Outbox.
Delay messages sending in group
1. Click on the File tab
2. Click Manage Rules & Alerts
3. Click New Rule under the Email Rules tab
4. In the Rules Wizard window under Step 1: Select a template box, and under Start from a Blank Rule, click Apply rule on messages I send, and then click Next to continue
5. In the Step 1: Select condition(s) list, select the boxes for any options that you want and then click Next
6. If you leave all the conditions unchecked when you click Next a confirmation dialogue box will appear. If you click Yes, the rule you are creating will then be applied to all messages you send
7. Now under Step 1: Select the action(s) list, check the box stating defer delivery by a number of minutes
8. In the Step 2: Edit the rule description (click an underlined value) box, click the underlined part of the phrase: defer delivery by a number of minutes
9. Enter the number of minutes you want to delay the messages for before it’s sent (Note: delivery can be delayed up to 120 minutes)
10. Click OK, and then when you’re done hit Next
11. Another list of checkboxes with exceptions that you want will then appear (Step 1: Select exception(s) if necessary)
12. If you want your rules to apply to all your emails click Next
13. Then under the Rules Wizard In the Step 1: Specify a name for this rule box enter a name for the rule you’ve created.
14. Check the Turn on this rule check box and then click Finish
15. It’s then a good idea to test your rule before relying on it when you come to sending something vital.
16. From now on, after you send each message it will stay in the Outbox folder for the time specified.
Again, this solution only works if you are carefully checking each of your emails for mistaken recipients or incorrect email attachments before it leaves your Outbox.
Error number: 4020Error message: 4020 : INVALID : Information received from an Invalid IP address.
Explanation: If your website is integrated with Sage Pay using either the Server or Direct method we must have a valid IP address from your platform or web hosting company in order to accept transactions.
The 4020 error message indicates that the transactional post that is coming from your site/hosting company is not being made using the valid IP addresses that you have entered into your Sage Pay account – via MySagePay.
All transactions that are posted from your website/server MUST be sent via one of the IP addresses that you have provided to Sage Pay. If your IP address is not entered within MySagePay, or is coming from a dynamic IP range then you will always encounter this error.
Solution: The 4020 error message is an easy fix, the first thing you will need to do to prevent this error is obtain the IP address that is being used to post the information through to Sage Pay.
You are able to locate the IP address that you are using by –
Process a transaction using the Sage Pay Simulator – you can then obtain the IP address that is being used for the transaction.
Contact your Server administrator – if your Server is being hosted internally – they will then be able to provide you with the IP directly.
Contact your Hosting Company – if your site is being externally hosted by a 3rd party – they will be able to provide you with the IP directly.
Perform a “Ping” test – open your start menu, type “CMD”, this will then load up the DOS screen where you can then type “PING” followed by the URL you are trying to reach – your own website – this will then provide you with the IP address of the site that is making the post to Sage Pay.
Once you have the IP address you will then be able to enter this into your MySagePay admin account, to do this see our Adding IP article here.
Very often during an attack there are a number of files of a certain type uploaded onto a victim’s system. These may be web shells (e.g. c99.php), backdoors, file uploaders, spam mailers, phishing pages, doorways (web pages that are created for the deliberate manipulation of search engine indexes), or defacement content (for example, the hacker’s logo, obscene messages, links, etc.). In some cases you can simply search the name of the suspicious file on the web to find out what it does—script kiddies usually do not bother modifying files much so it will probably turn up in search results.
2. Code Injection
Code injection: A popular method of malware deployment onto a target system is via injections: malicious code can be injected into the .htaccess file to create SEO and mobile redirections; PHP or Perl script injections can be used to create backdoors; malvertising scripts can be injected into static .js (JavaScript) and .html files; and, very often, it can be a combination of injection into an existing file together with the uploading of a command and control script. For example, malicious code can be injected into the exif-header of a .jpg file, and the code can be triggered and executed by some other benign-looking file uploaded in another part of the website.
3. SQL Injection
Database entries are a frequent target for hacker attacks. Static HTML content injections are possible using tags such as <script>, <iframe>, <embed>, or <object>. Such unauthorized code insertions can redirect visitors to related but unaffiliated sites, embed advertisements from which the site owner does not profit, embed mining trojans (e.g. CoinHive JavaScript miner), or spy on users and infect their computers using drive-by attacks. Besides this, many modern CMSs (e.g. IPB, vBulletin, modx and others) use template processors that allow the execution of PHP code, and the templates themselves are stored in the database. This gives attackers the opportunity to add backdoors and webshells to the website template directly in the database itself.
4. Cache Injections
Due to insecure settings of a caching server, for example, when using memcached, some injections can be done on cached data on the fly. In some cases, spam can be injected into website pages without actually hacking the core functionality of a website.
If hackers are able to get privileged (root) access to a server, they can replace some web server components or caching server components with infected versions. Such a web server can then be controlled via remote commands, and it can add dynamic redirects and malicious code to different website pages. As with cache injections, a webmaster is usually not able to spot the infection because all user files and databases appear unaffected. This is the most difficult case, and in some situations it is easier to rebuild the server and migrate user data rather than try to detect all the malware.
5. System components replacement
By now, I’ll assume that you’ve already checked the files and database dump with AV scanners and that they have not identified anything malicious. If the malicious redirect or script (embedded in the <script> tag) is still somewhere on the pages of your website, redirects will continue sending users to malicious websites.
Linux and some Unix-like systems, it is hard to find more useful commands for searching files than find and grep.
This command will look for all files that were modified in the past week.
find . -name '*.ph*' -mtime -7
Sometimes, attackers change file modification dates to avoid detection. In this case, you can use the following command to look for .php and .phtml files that have had their attributes changed.
find . -name '*.ph*' -ctime -7
If you need to look for file changes in a certain time frame, you can also use this find command.
And let’s not underestimate the grep command as well. This command can recursively search for certain patterns in the files, drilling down through all folders and files. Here is an example.
When your web server is compromised, it is good practice to check files with the guid/suid flag, just to be safe.
sudo find / -perm -4000 -o -perm -2000
Finally, you can use a command like this to identify what PHP scripts are currently running in the background and possibly impacting website performance.
Now that we know how to search for possibly malicious files, let’s dive a bit deeper and list what exactly we are looking for and where.
1. Check the upload, cache, tmp, backup, log, and images directories.
You need to check all directories that are used for file uploading. For example, with Joomla you should look for .php files in the ./images folder. There is a high chance that if you find something, it will be malicious. For WordPress it is worth checking the wp-content/uploads, backup and theme cache directories.
find ./images -name '*.ph*'
2. Looking for files with weird names
Here are examples of strange file names to look out for: php, fyi.php, n2fd2.php. You should also look for unusual patterns in file names. For example:
File names comprising an odd and unreadable mixture of letters, numbers and symbols, e.g. srrfwz.php, ath.php, kirill.php, b374k.php.php, tryag.php.
Because many users rename files by appending the digit ‘1’, look out for normal-looking file names that append numbers other than 1 to filename parts, e.g. index9.php, wp3-login.php.
3. Looking for files with unusual extensions.
Let’s suppose you have a website based on the WordPress CMS. Files with extensions such as .py, .rb, .pl, .cgi, .so, .c, .phtml, or .php3 would be unusual for such types of websites. If scripts or files with these extensions are found, most probably these are hacker tools. There is a chance of a false alarm, but it is low.
4. Looking for files with non-standard attributes or creation dates.
As mentioned above, files with modified attributes are suspicious. For example, if all the .php files that were uploaded to the server via FTP/SFTP have the owner file attribute set to ‘user’, and you also see a number of files having this attribute set to ‘www-data’, then it is worth checking the latter. Also, check if the script creation date is earlier than the website creation date. You can use the command templates from the cookbook section to bake up your own search queries, and speed up or optimize them.
5. Looking for doorways using a large number of .html or .php files.
If a directory contains a few thousand .php or .html files, there is a high chance that this is a doorway. You can use the following command to find the top 50 directories with the highest file counts (if you have many hosting accounts and files on the server, it is better to use this command in the specific folder/home directory you would like to check to save some execution time):
find ./ -xdev -type d -print0 | while IFS= read -d '' dir; do echo "$(find "$dir" -maxdepth 1 -print0 | grep -zc .) $dir"; done | sort -rn | head -50
(Check this thread to find more details on the commands for checking directory file counts.)
Server logs can help
Dependent relations between the date and time when an email was sent (using details in the mail log and email message header), and access_log entries, help to determine how mail spam was sent out, and find the mailer script on the server.
FTP xferlog analysis helps to identify which files were uploaded or changed during the attack and by whom.
If your mail server and PHP settings are correctly configured you can find the name of the sender PHP script and the full path to it in your mail log or in the full email message header. This helps to quickly find and eliminate the source of spammy deliveries.
Some modern CMSs and plugins have more advanced defense techniques to proactively detect cyber attacks. Their logs might show if there was any attack and whether the CMS or plugin was able to protect itself or not.
The access_log and error_log files also allow you to track a hacker’s actions, if you were able to identify the script names that were used, the IP address or the HTTP user agent (User-Agent). You can also check the POST request on the day the attack happened. Often, such checks allow you to find which malicious files were uploaded and which were already present before the attack.
Integrity checks
It is much easier to analyze attack vectors and look for malware scripts on websites if some security precautions were already made beforehand. Integrity checks help to identify the changes on the file system in a timely manner, and detect malicious activities quickly. The easiest and most effective way to perform such checks is by using version control systems such as git, SVN, or CVS. For example, with git, if you correctly configure the .gitignore file, the process of integrity checking comes down to executing two commands:
git status # check all changed files git diff # find malicious code
This guarantees that you have a backup copy of your files, and allows you to quickly restore the website to a previous state. Experienced server administrators can also use inotify, tripwire, auditd and similar tools to track file and folder access and changes.
Unfortunately, it is not always possible to configure the version control system or any site integrity check services on a server. In the case of shared hosting, it is not possible to use a version control system or system services. To overcome this problem you can use CMS extensions, in the form of a plugin or a stand-alone script, to track file changes. Some CMSs (e.g. Bitrix or DLE) already have built-in integrity checks.
If the website is using custom scripts or is built with static HTML files, you can use the following shell command to make a snapshot of currently stored files:
ls -lahR > original_file.txt
If any malware threats occur you can create another snapshot and then compare them using any comparison software you like, for example, WinDiff, AraxisMerge Tool, BeyondCompare, the diff command (on Linux) or even compare snapshots online.
This tutorial takes us to the basics of installing WordPress in a web host. There are literally 10+ methods by which you can install a deployable WordPress site. Factors such as your operating system, intended usage (local or live) and hosting environment lead to several ways of installing WordPress.
Softaculous is an application installer that automates setting up various management systems.
In this case, it will install WordPress and its database after just a few pieces of information from yourself.
It’s a quick and easy way to set up a website without having to learn a single line of code.
1. Login to cPanel.
2. From cPanel, scroll to the Softaculous Apps Installer and click WordPress.
Scroll to the Softaculous Apps Installer and click WordPress.
3. Install WordPress, from the Softaculous script window, click the Install Now button in the description. The Softaculous software will usually have the most recent version of WordPress available.
Softaculous script window, click the Install Now button in the description.
In the next screen, you will need to input all of your website’s settings. Let me break them down a bit for you:
Software Setup In this section, you’ll choose whether your site uses SSL protocols or not. This is done by selecting which “http:” version you want to use from the drop down options. You’ll also pick your domain. If you only have one domain name, it will be displayed automatically. Otherwise, you’ll have to select it from the list.
Site Settings This is the basic information of your website. You’ll put in your site’s name and a short description. This will be used by most themes as well as the WordPress system for identification purposes. It will also play a part in search engine optimization, so make sure the information is something you want seen in sites like Google.
Admin Account Input the admin username and password you want to use to log into WordPress. I suggest never using the name “admin” as the administrator username. It’s the first thing bots and hackers will try when attempting to access your website. Make it something completely unique to you.
Admin Email Address This address is only used by WordPress itself and is not available publicly. Plugins you install may also use this address to send you messages or updates. It can also be used for password recovery should you forget or lose your login credentials.
Choose Language This is set as English by default. However, you have the option of using many different language types for WordPress. Choose one that is ideal for you and your website.
Select Plugins Softaculous often comes with a couple of Plugins readily available should you choose. GreenGeeks displays “Loginizer” and “WPForms Lite.” These two plugins are very helpful for those who want to protect the login screen and create forms such as what you would use for contact information. Click the check boxes to activate or deactivate these optional plugins.
Advanced Options Advanced options are for those who have a firm grasp of databases, upgrades and backup control. You can customize these elements if you wish, but I would suggest new users to leave these settings.
Select Theme WordPress comes with a few themes readily available. These files dictate how your website appears. In Softaculous, you can choose from a wide variety of layouts. Simply click the one you want to install with WordPress and Softaculous will do the rest. Please note that you can change themes at any time and as often as you like.
Under the install button, you can enter your email address. You will get an email when the install is complete.
Softaculous will then analyze your information and settings while installing the WordPress.
Softaculous will then analyze your information and settings while installing the WordPress.
And a few seconds later – bam! You have a fully functional WordPress installation.
Bookmark this URL so you can find it easier at a later date.
AWstats is a popular server log analyzer included with cPanel. It can be used to generate a wide variety of traffic reports allowing you to understand who is visiting your website, when they are visiting and which pages they visit the most.
• Average monthly, daily and hourly visitor numbers • The links through which visitors access your website • HTTP codes • Visitor operating systems • Browser information • Visitor location
To access AWStats follow these instructions.
Login to cPanel.
Scroll down to the Metrics section and select the AWstats icon to proceed.
Click the view icon for the domain whose statistics you wish to see. The statistics will then be displayed.
The main AWstats interface will open at the Summary page, displaying the following details about your website’s visitors:
Unique visitors
Number of visits
Page impressions
Page impressions per visit
Hits
Bandwidth downloaded
You’ll see stats for both Viewed and Not viewed traffic. The latter includes traffic generated by robots, worms, or replies with special HTTP status codes.
Statistics are updated on a daily basis – you can see the date and time of the latest update at the top of the page. By default, you’ll be presented with a report for the current month. Use the dropdown menu at the top of the page to view the report for previous months.
Scroll down the summary page to see a wealth of information about your visitors. Summary traffic reports are aggregated by:
Month
Days of month
Days of week
Hours
Locales (Top 25)
Hosts (Top 25)
Authenticated users (Top 10)
Robots/Spiders visitors (Top 25)
Visit duration
File type
Downloads
Operating systems (Top 10)
Browsers
Search keywords and keyphrases
HTTP Status codes
Navigating AWstats
You can navigate through an extended range of reports using the left sidebar. Some of these links are shortcuts to the summary reports listed above. However, a number of links allow you to drill down into the logs, generating deeper insights into your traffic and visitors. They include:
Locales – a full list of visitor countries, ranked by page impressions, with hits and bandwidth metrics.
Hosts – a report showing full details of visitor IP addresses, with date stamps, page impressions, hits and bandwidth.
Authenticated users – users who have logged in to a password protected area of your site.
Robot/Spiders visitors – a list of web crawling robots that have visited the site, commonly used by Google, Yahoo, Bing and other service providers.
Downloads – a full list of files that have been downloaded on your site.
Viewed – a full list of URLs visited by website users. Metrics include page impressions (viewed), the average page size (in kilobytes or megabytes), and entry/exit statistics (useful for identifying your most common landing pages or exit URLs).
Operating Systems – detailed statistics on the operating systems being run by devices used to visit your website (handy for identifying mobile and desktop traffic).
Browsers – detailed statistics on the web browser applications used to visit your website
Referrers – search engines and websites that link to your content and send traffic to your website.
Search – a full list of search phrases and keywords used to identify and link to content on your website. This analysis is useful to understand what your users are seeking when visiting your website and can support a strong SEO (search engine optimization) strategy.
Errors – a list of pages that are currently generating errors when visited. Identifying and resolving these errors promotes a better user experience and will improve your standing with search engines.
Once you’ve mastered the basics of web traffic analysis with AWstats, you can progress to more comprehensive tools such as Google Analytics.
bbPress is forum software with a twist from the creators of WordPress. bbPress is plain and simple forum software, plain and simple.
It’s easy to use, easy to administrate, fast and clean. But don’t let its simplicity deceive you; underneath the gleam, it’s got some powerful features and is highly customizable
1. Log in to cPanel account.
2. In the SOFTACULOUS APPS INSTALLER section of the cPanel home screen, click any of the options under Categories. The Softaculous installer page appears.
3. In the Search text box, type bbpress and then press Enter.
4. Click Install. The installation page appears.
5. In the Choose Protocol list box, select the protocol.
If you have an SSL certificate installed on your site, select https:// or https://www. If you do not have an SSL certificate installed on your site, select http:// or http://www.
6. In the Choose Domain list box, select the domain for installation, or accept the default value.
7. In the In Directory text box, type the directory where you want to install the application, or accept the default value.
8. In the Board Name text box, type the name of the forum. By default, the board name appears in the title bar of users’ web browsers when they visit your site.
9. In the Site Description text box, type the site description.
10. In the First Forum Name text box, type the name of the first forum that you want to create.
11. In the Admin Username text box, type the administrator username.
12. In the Admin Password text box, type the administrator password.
Make sure that you choose a complex password! The Softaculous installer provides a ranking for your password’s strength, and turns green when the password is strong.
Alternatively, you can click the icon next to the Admin Password text box, and Softaculous generates a strong, random password for you.
13. In the Admin Email text box, type the site administrator e-mail address.
14. Click the icon to expand Advanced Options.
15. In the Database Name text box, type the name of the database to create for the application, or accept the default value.
16. In the Table Prefix text box, type the database table prefix, or accept the default value.
17. If you do not want to receive e-mail notifications when application updates are available, select the Disable Update Notifications check box.
18. In the Backup Location list box, you can select a location to store application backups.
19. In the Automated backups list box, you can select whether or not Softaculous makes periodic backups of your application.
20. In the Backup Rotation list box, you can select how often Softaculous overwrites the oldest backup file with a new backup file.
22. To receive site configuration information after the installation is complete, type an e-mail address in the Email installation details to text box.
23. Review the installation options and settings, and then click Install. When installation is complete, Softaculous provides information about the application’s configuration.
icon next to the Admin Password text box, and Softaculous generates a strong, random password for you.
icon to expand Advanced Options.