Patent Application
20160119376
The present invention relates to a system and a method for filtering electronic messages. It is known, in fact, that most cyber attacks to single users occur through messaging services such as electronic mail, instant messaging or the like.
Within the frame of electronic messaging services, a technique which is commonly used for swindling users is known as “phishing”. Phishing is a kind of cyber attack in which the user (victim) is invited to provide sensible data (e.g. bank account numbers, credit card numbers, confidential personal data, passwords, etc.), and then such data are collected by means of a server configured for deceiving the user, preferably through a graphic layout that is very similar or identical to that of a server on which the user usually carries out transactions requiring him/her to enter said sensible data.
More in detail, an ill-intentioned person (phisher) sends to the user, e.g. via electronic mail (email) and/or an instant messaging service, a message that simulates, in its graphic layout and/or formatting and/or contents, a message of an institution known to the addressee, e.g. a bank where the user has a bank account, a web service provider, an online auction site where the user has registered an account, or the like.
This message usually contains a warning about particular situations or problems requiring a quick response by the user, such as a large debit transaction on the user's bank account, the expiry of the account through which the user can make financial transactions, winning a large sum of money, or the like. Typically the message recommends to quickly find a solution to that situation or problem through one or more hyperlinks directing the user to one or more web pages residing on the server, which, being controlled by the ill-intentioned person, can fraudulently gather sensible data. In fact, these web pages are so constructed as to have the user believe that his/her data are being given to a trusted institution (e.g. a bank, a shipping company, or the like), while such data are, on the contrary, being collected for use by the ill-intentioned person.
Such sensible data are then used by the ill-intentioned person to commit criminal actions, e.g. transferring sums of money from the deceived user's bank account to another account, or selling the data to organizations that will use them for commercial purposes and/or for creating false identities useful for masking illicit activities.
Different approaches are currently available for facing the phishing problem. Many of these methods for filtering messages are based on the use of software programs on electronic computers, which implement techniques for recognizing and cataloguing the text of messages (e.g. through the use of suitably trained neural networks or the like). Unfortunately, these techniques always give a certain number of false positives/negatives, i.e. some “normal” (non-fraudulent) messages are catalogued as fraudulent messages, whereas a certain number of fraudulent messages are catalogued as non-fraudulent messages, thus not ensuring an adequate level of security for the user's sensible data.
In addition, fraudulent messages often contain images representing text that, since it cannot be immediately deciphered by a computer, requires an optical recognition process (OCR). The latter process increases the computer's computational load, thus reducing the number of messages that can be processed per time unit.
A further method for filtering messages is based on the use of a digital signature, which, although it ensures a high protection level, compels the sender to sign every message with his/her private key prior to sending it, thus increasing the number of steps that must be carried out by the user, who may not be able to obtain one or may not know about this possibility. Moreover, digital signatures are not always available, as is the case, for example, when sending an email message through a web browser, i.e. in the so-called webmail mode. This problem becomes even more apparent when strings of hyperlinks contained in the messages include specific parameters (e.g. the user's univocal identifier), in that each message will have different contents (and hence a different hash) from any other message being sent.
It should also be pointed out that most messages that are sent to the user, even from actual organizations warning about a particular situation (e.g. expiry of a password or the like) are usually transmitted in clear, so that this approach is hardly compatible with the current use of messaging services, particularly electronic mail, and with the applications that manage that aspect.
In addition, victims generally do not have the capability of accurately checking if an incoming message contains a digital signature; therefore, a message sent by an ill-intentioned person, even without a digital signature, might be considered to be authentic.
Anti-phishing prevention systems are known which deny access to hyperlinks contained in electronic messages based on whether the sender belongs or not to a certain sender category, e.g. senders reported as unwelcome and/or unreliable, or because, based on the analysis of the message content, the message is not considered to be safe when it comes from an unknown sender. These systems are not always effective, since sometimes said analysis provides wrong results. Moreover, they do not take into account the fact that some hyperlinks may be reliable if they are included in messages from a certain sender, but they may not if they are included in messages from another sender.
It is also possible that access to a trusted user's electronic mail or instant messaging account is gained by ill-intentioned people, who can then use it to send messages containing fraudulent hyperlinks. The known anti-phishing systems may not be able to intercept these counterfeit messages, since they come from senders considered to be reliable, while they are not.
In addition, ill-intentioned persons might send email messages from uncertified and publicly accessible servers, by perfectly simulating transmissions from known senders held as reliable by other email users. In this case as well, any dangerous links may not be blocked by the anti-phishing systems known in the art, so that the victim user may incur substantial risks for his/her property and privacy.
In U.S. patent application US 2008/104180 A1 to Christopher John GABE, it is described an anti-spam (not anti-phishing) system based only on the verification of the message sender's identifier. In order to do that, the identifier is sent to a server that verifies if said identifier is present in a database of identifiers, so as to estimate, through a suitable function, the probability that a message coming from a certain sender is undesired. This system, however, has the limitation that the estimate of the probability is carried out only on the basis of the message sender's identifier and not also on the basis of parts of the body of said message, thereby exposing the system to the risk of making mistakes especially in case where a trusted e-mail account is violated and used to send messages having fraudulent content.
The International patent application WO 03/044617 A2 to Reginald ADKINS describes an anti-spam system configured to operate in the following way: each time an email is received, it is checked whether the address of the sender of the received email belongs to the authorized address book (inclusive address book) or to the rejected address book (exclusive address book) or to the temporarily authorized address book (temporary address book); in the case where the address of the sender is not part of any of the categories, a truncated version of the message body is examined by means of the filters to search for contents such as offensive language, web links, contact information, e-mail attachments; after that the message is ranked on the basis of the search result. This approach has the limitation that the filters employed are of generic type, i.e. suitable for any type of message, by exposing the system to the risk of making classification errors.
In U.S. patent application U.S. 2006/200523 A1 to TOKUDA et al., it is described an anti-phishing system in which the message sender is validated on the basis of an anti-fraud policy which can verify if a certain e-mail message was actually sent by the sender specified in the header of the message. This anti-fraud policy is applied equally to all the messages, and to those considered authentic is added a header which attests the authenticity. In this way, it is possible to distinguish between authentic messages and fraudulent ones, similarly to that carried out by the two systems described in the cited documents. This system has the limitation that the messages are authenticated without examining the contents of the message body, but only using methods based on encrypted stamps (e.g. Truemark®) that make the use of this system unsuitable and burdensome from the computational point of view. In fact, for implementing this system, it is necessary to use cryptographic keys by creating considerable problems from the point of view of compatibility for the email clients that do not support these authentication systems.
Moreover, all the systems according to the above-described prior art perform a limited number of actions: once identified an unwanted message or a not authentic one, said systems classify said message as such, but do not block the user access to the body of said message and, therefore, also to potentially dangerous content.
The present invention aims at solving these and other problems by providing a method and a system for filtering electronic messages.
The basic idea of the present invention is to verify if at least a part of the body of the received message has characteristics, e.g. hyperlinks and/or special message formatting, which have been specified by the message sender.
This idea allows filtering messages in a quick and effective manner, considerably reducing the presence of false positives/negatives and avoiding the use of asymmetric cryptography. Furthermore, the message can be checked without opening any hyperlinks included therein.
Further advantageous features of the present invention will be set out in the appended claims.
These features as well as further advantages of the present invention will become more apparent from the following description of an embodiment thereof as shown in the annexed drawings, which are supplied by way of non-limiting example, wherein:
With reference to
In the scenario 0, the fraud begins with a message sending step P1, wherein a message 4 is sent to the addressee 1 from the hostile machine 2. This message 4 comprises a body which can contain one or more potentially dangerous content, and a header which includes identification information identifying the sender of that message 4.
An example of potentially dangerous content are at least one hyperlink or URL (Uniform Resource Locator), which allow the malicious person to start a data collection step P2, e.g. by opening a communication session with a web server residing in the hostile data collection server 3, which simulates the presence of an authentic Internet site known to the user.
Also with reference to
Of course, the present invention acts upon actual hyperlinks, not on apparent ones, which in counterfeit messages differ from the actual ones and simulate a reference to secure and authentic sites. For example, in a message formatted in the HTML (Hyper Text Markup Language) formatting language, the present invention will (also) examine the field “HREF” of the label “<A>”, containing the web address to which the user would be directed should he/she click on the malicious link.
During the data collection step P2, the victim user enters data (e.g. sensible data such as access credentials in the form of username and password, account number or the like) into the hostile data collection server 3, which will then store them locally and/or send them to the hostile machine 2 at the end of step P2. In this manner, the hostile machine 2 can take possession of the victim user's sensible data, thus allowing the ill-intentioned user with access to the hostile machine 2 to use said data for fraudulent purposes.
It will be apparent to those skilled in the art that the hostile machine 2 and the hostile data collection server 3 may be a single machine, without necessarily having to be two distinct machines. Moreover, the URL may, without distinction, direct to a page of a site, to a document, or to an electronic file of any kind (executable file, compressed file, image, video, etc.), or in general to any on-line reachable resource made available by the ill-intentioned person for fraudulent purposes.
Also with reference to
The content is typically a string of characters, but may also consist of images, sounds or the like, whereas the sender's address is a string of characters that univocally identifies a certain person who is sending the message. For electronic mail, the sender's address is formatted in accordance with the Internet RFC 5321, RFC 5322 and RFC 6531 standards, whereas for instant messaging applications, such as Skype, it is a simple string of characters. The sender's name is generally a name associated with the sender's address, and is composed of a string of characters (alphabetic letters, numbers, special characters like “@”, “_”, “-” etc.), which is usually chosen by the user on the basis of predefined rules set by third parties.
Once the content of at least one of the messages received by the user is accessible to the security module, said module is configured for executing the following steps:
The sensible parts of a generic email message may comprise hyperlinks included therein; however, as an alternative or in combination, they may also include message parts which cannot be directly seen by the user of the client machine 1, such as, for example, Internet addresses, invisible characters (e.g. character 255 of the ASCII code), formatting, or the like. In this manner, the invention not only allows to protect the user against computer attacks made by using the “phishing” technique, but also to verify if a received message is properly formatted, so as to advantageously further reduce the risk that a malicious user can make an attack by altering the content of a message.
One typical example of message alteration is called “email spoofing”, i.e. parts of the electronic mail message are altered in order to make the user believe that the message sender is a third party. By using the invention described herein, in addition to preventing the ill-intentioned user from entering hyperlinks directing to a hostile data collection server 3 under his control, it is also possible to verify that the message has certain characteristics (e.g. invisible characters in a given position), so as to advantageously reduce the probability that the ill-intentioned person will be able to carry out actions to the detriment of the user of the client machine 1.
The selection of at least one sensible part of the received message is preferably made by using a syntactic analysis algorithm (parser), which, by using the message, preferably the text thereof, as input, will output the sensible part(s) of the message.
As is known to those skilled in the art, this syntactic analysis algorithm is preferably built/generated by starting from a grammar that comprises a set of regular expressions and, if necessary, also a number of production rules.
The execution of step c. by the security module requires the use of the sender's address and/or name for retrieving and selecting validation information specified by the sender.
This validation information preferably comprises a list of strings identifying Internet domains that normally host contents to which reference is made, through hyperlinks, in the text of the messages received by the user of the client machine 1.
However, in combination with or as an alternative to the list of Internet domains, this validation information may also comprise other objects, e.g. images, sounds, formatting data, algorithms, grammars, or the like.
Once the validation information has been retrieved and selected, the sensible part(s) of the received message is(are) verified by using said validation information.
In the preferred embodiment, step c. consists of verifying if each one of the hyperlinks included in the message, preferably an email message, refers to a content which is present in at least one of the Internet domains included in a list of domains selected on the basis of the sender's address; the verification is successful if all hyperlinks meet such criterion, otherwise the verification is unsuccessful.
The result of the verification carried out at step c. is communicated to the user during step d., preferably by means of a visual and/or audible signal, e.g. by highlighting with a red icon those messages for which the verification has been unsuccessful, and with a green icon those messages for which the verification has been successful. If the verification is unsuccessful, then the hyperlinks will be preferably disabled without requiring the user's intervention, so that said user will not fall prey to the ill-intentioned person.
A man skilled in the art may have the security module communicate with the user of the client machine 1 differently than described above, without however departing from the teachings of the present invention.
In the preferred embodiment, the system for filtering electronic messages 5 comprises a verification server 6. This verification server 6 comprises means for storing data useful to ensure the proper operation of the system 5, i.e. to prevent the user of the client machine 1 from being exposed to the risk of fraud; such data residing in the verification server 6 preferably comprise also the validation information.
Furthermore, said verification server 6 can be contacted by the security module during the execution of the above-described step c. by means of a network connection (e.g. an Internet/Intranet connection or the like).
The latter searches a database DB for the list of allowable URLs (the so-called white list) for the sender identified in the communication received from the client (step 805). Then, at step 810, it is verified if there are any occurrences for the sender of the message 4; if there are, at step 820 the list of allowable Internet domains will be extracted from the database DB and communicated to the client; otherwise, the absence of any occurrences or an empty list will be communicated to the client. In a simplified embodiment of the invention, the server at this point ends all operations, which will then continue on the client side, where the client is at step 720, waiting for a reply.
At step 730, the communication received from the server is verified: if the list is empty, i.e. the DB contains no data relating to the sender of the message 4, at step 735 the user will be notified that the sender is unknown to the anti-phishing system, and the process will end. If the list is not empty, at step 740 it will be verified if the URLs contained in the message and previously stored satisfy the predefined security requirements. In general, it is required that the URLs belong to Internet domains or Internet addresses extracted from the database. In a more sophisticated embodiment of the invention, it may be required that, in order to be accepted, the URLs included in the message must also, in addition to belonging to domains specified in the DB for that sender (white list), utilize access protocols defined as admissible (e.g. one or more of the http, https, ftp, smtp, etc. protocols).
In another embodiment of the invention, the list received at step 720 may contain Internet domains associated with a sender that is only similar to the searched one, but not exactly equal. For example, the (fake) sender “Posta Italiana” may produce the same results as the (real and counterfeit) sender “Poste Italiane”.
At the verification check step 745, there are two possibilities: the security criteria established for URLs are complied with, and therefore the message will be considered to be reliable, or not.
If the message 4 is considered to be reliable, at step 750 the hyperlinks will be activated or left active, access to the message 4 and the contents thereof will be allowed, and the process will end.
If the content of the message 4 is not considered to be reliable, the invention can be implemented in two ways: the first option is exemplified in
In the event that the searched sender is not exactly equal, but only similar, to the sender found in the DB, a further warning will be sent to the user in order to indicate such difference and require the user to make further verifications. Afterwards, the procedure will end on the client side as well.
In this embodiment of the invention, the client cannot by any means influence the information present in the DB of the server. Its white lists are under exclusive control of the server and its administrator, who can decide about the record creation and update policies (additions, deletions and modifications).
In the second embodiment of the invention, shown in
In both cases, the result of the verification 830 will be communicated to the waiting client at step 765, who at this point will check if the suspicious URLs have all been considered to be reliable (step 770), after which the process will end. If so, the message will be considered to be trustworthy and the user will be allowed access to it (step 750). Otherwise, access to the suspicious hyperlinks or to the whole message will be denied, depending on the defined security policies (step 760), after which the process will end.
The embodiment of the invention that uses the client-server approach should not be considered in a limiting sense. It is just one way, not the only one, of implementing the invention. As an alternative, the functions performed by the client and by the server may be carried out by a single host process residing in the same machine; in such a case, for example, the blocks 805-820 of
In one embodiment of the invention, the client may reside in a user's client machine 1, and the server may reside in a verification server 6. The man skilled in the art will comprehend, however, that the client and the server must not necessarily reside in two different machines; they may be two processes executed on the same machine and exchanging data locally, e.g. through a TCP/IP Internet port. The man skilled in the art may therefore have the verification server 6 coincide with the user's client machine 1, without however departing from the teachings of the present invention.
The client machine is meant to be a data processing device equipped with a processor capable of processing digital data with the aid of a memory for storing such data, of receiving messages through a physical communication interface (e.g. an Ethernet network card, a Wi-Fi module belonging to the IEEE 802.11 standard family, etc.), as well as of accepting message access requests via input units (keyboard, touchscreen, mouse, etc.) and reproducing contents of hyperlinks contained in messages sent to a user via output units (e.g. screen, loudspeakers, etc.). In addition, the client machine contains software modules allowing the device to use the various units and allowing said modules to operate as described in the present invention. In general, it may therefore be, for example, a desktop or portable PC, a smartphone, a tablet or the like.
The server machine is meant to be a data processing device (computer) equipped with at least one processor capable of processing digital data with the aid of a memory for storing such data into a database, as well as of exchanging data with said client machine through any communication channel. The server machine may either coincide or not with the client machine, in that it comprises a subset of the components of the latter. In general, it should have adequate computation power and storage capacity to be able to carry out the tasks of the server process. The man skilled in the art can decide the best way of implementing the invention as a single host or as a client-server model with distinct machines or with unified machines, depending on the characteristics, in terms of computational power and storage capacity, of the devices to be protected, and also on the security management model (centralized or distributed) to be used.
The present invention may also be combined with other procedures for checking the reliability of message contents. For example, the entire check procedure according to the present invention may be bypassed for a certain category of messages which are considered to be safe, e.g. certified mail. In this case, upstream of the verification 705 of
Also with reference to
The database is preferably created by starting from a scheme 61 designed for application of the invention to a phishing prevention context; such scheme 61 comprises a relation which in turn comprises two attributes: ‘sender_name’ and ‘trusted_domain’. Both of these attributes have one-to-many cardinality, so that more than one ‘sender_name’ and more than one ‘trusted_domain’ can be associated with each sender.
Also with reference to
Furthermore, aiming at ensuring database integrity, in the ID column of the trusted_domains table there is a referential integrity constraint towards the ID column of the senders table.
The database thus created can be updated by an administrator or directly by senders wanting to benefit from the system 5 through the Internet or another means of communication.
For the purpose of satisfying at best the requirements of a specific application, the man skilled in the art may use a database of a different type and/or with a different scheme, compared with the one described above, without however departing from the teachings of the present invention.
More in general, when this server 6 is contacted by the security module for the execution of the above-described step c., the server 5 will carry out at least the following steps:
Step e. can preferably be carried out through the use of the HTTP protocol or another protocol well known to those skilled in the art, whereas step f. can be carried out, for example, by making the following SQL interrogation:
where the character ‘?’ identifies the sender's address and/or name received during step e. Additionally, step f. may include a broader search for the sender, e.g. aiming at finding those strings of characters that do not differ much from the sender being searched for, i.e. having at most a predefined number of different characters compared to a sender's name stored in said database (DB), so as to reduce the number of false negatives due to intentional or unintentional variations of the sender indicated in the received message. By way of example, let us consider the fake sender “Posta Italiana”, which may induce the user to think that it is the real sender called “Poste Italiane”. In this case, the search carried out by the server 6 may produce the same results as expected from the search for “Poste Italiane”. It is therefore conceivable that the list sent to the client at step 820 contains, in addition to the trusted domains, also the corresponding data of the selected sender that might be slightly different from the one initially searched for.
Also with reference to
It must be pointed out that the states S2 and S4 are comprised in the execution of step c. by the security module.
When a message 4 is received by the client machine 1, the system 5 enters the reading state S1, after which it will interrogate the appropriate database DB while entering the request state S2. If the interrogation produces no results (occurrences), then the system 5 will notify the user that the sender's address and/or name is not present in the database DB (step S3) and will end the process; otherwise, if there are some results, the system 5 will enter the result reading state S4 and will communicate the verification results to the user of the client machine 1 while entering the result notification state S5, after which its execution will end.
The verification results comprise, in addition to the sender's data (name and/or address) or to a sender's identifier known to the client terminal, the set of trusted Internet domains and/or URLs that the message received from the sender identified by said data may contain because they are considered to be safe. Optionally, for some or all domains or URLs belonging to a domain, admissible access protocols may also be specified: for example, for the URL “www.poste.it/bancoposta.login.asp”, it may be specified by whatever means that it can only be included in the message from that sender via the HTTPS protocol, so that the URL will have to begin with the string “https://”. Otherwise, the hyperlink will be considered to be dangerous, and hence it will be blocked.
In a first variant of the preferred embodiment of the system 5 just described, a security module (similar to the above-described one) sends the sensible parts of the received message to a verification server (similar to the verification server 6 just described) during the execution of step c. In this manner, the verification server comes to know not only the sender's address and/or name, but also the sensible parts, preferably hyperlinks, of the message received from that sender, so that it is advantageously able to understand if any fraudulent attacks (phishing) are being made against the user of the client machine 1 and the person or institution to which the sender's address corresponds. By concentrating this information within the verification server, it is advantageously possible to configure said server for warning the person or institution to which the sender's address corresponds and/or public security authorities, such as, for example, the national center against computer crime for the protection of critical infrastructures (CNAIPIC, Centro nazionale anticrimine informatico per la protezione delle infrastrutture critiche) or another relevant body, about the fact that at least one fraud attempt is being made.
The concentration of information of this kind advantageously ensures a higher level of supervision, in that a greater number of messages can be analyzed than just those received by a single user.
In a second variant, multiple databases and/or multiple verification servers 6 may be present, and the security module, while executing step c., may select the database to be interrogated on the basis of the information contained therein and/or by choosing the most updated one. This selection may preferably be made according to at least a part of the sender's address, e.g. the container thereof (“@yahoo.it”, “gmail.com”, etc.), or the like.
In a third variant, the validation information specified by the sender may include only a part of a hyperlink (e.g. a prefix such as “http://poste.it/user=”), since parameters are now commonly used. This advantageously prevents the sender (who wants to benefit from the system of the invention) from having to provide a long list of hyperlinks containing repeated elements.
In a fourth variant of the present invention, at step 720 images contained in the message as an embedded graphic file (as opposed to an URL directing to an image residing on a remote site) can be analyzed in order to extract identification information, i.e. digital signatures such as, for example, signatures, features or key points, to be sent to the server for analysis as a replacement for or in addition to the sender's address and/or name. The database DB may comprise, in addition to the ‘sender_name’ attribute, a further ‘key_points’ attribute comprising digital signatures such as features or key points of logos, trademarks and other known images of trusted domains. This attribute has one-to-many cardinality, so that more than one ‘sender_name’ and more than one ‘trusted_domain’ can be associated with each ‘key_points’ attribute. After having received the information from the client, the server will search its own database DB for the list of allowable URLs (the so-called white list) for the key_point identified in the communication received from the client. It will then be verified if there are any occurrences for the key points extracted from the message; if there are, the list of allowable Internet domains will be extracted from the database DB and communicated to the client, which will then block the URLs as described at step 760; otherwise, it will be communicated that no occurrences have been found.
As is known to the man skilled in the art, features or key points can be extracted by using image processing algorithms, while features or key points can be compared in the server by using known image recognition techniques. This further variant offers the advantage of finding messages that fraudulently contain images, logos and trademarks of trusted sites for the purpose of deceiving the potential victim.
In a further variant, the sender may also specify the period of validity of the validation information, thus advantageously increasing the degree of security of the system according to the invention.
In a further variant, the database DB may also comprise a list of domains and/or hyperlinks which are considered to be safe and reliable regardless of the sender, i.e. which are valid for all senders, for the purpose of saving memory. If a given message only contains contents which are included in this universal list, then its contents will be trusted regardless of the sender.
The invention may therefore be subject to many variations, without however departing from the novelty spirit of the inventive idea. It will be apparent to those skilled in the art that in the practical implementation of the invention the illustrated details may have different shapes or be replaced with other technically equivalent elements. It can therefore be easily understood that the present invention is not limited to the explanatory examples described herein, but may be subject to many modifications, improvements or replacements of equivalent parts and elements without departing from the basic inventive idea, as set out in the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| TO2013A000513 | Jun 2013 | IT | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2014/062286 | 6/17/2014 | WO | 00 |
