Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/0227—Filtering policies
  • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
  • H04L63/1416—Event detection, e.g. attack signature detection
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
  • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
  • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/56—Provisioning of proxy services
  • H04L67/564—Enhancement of application control based on intercepted application data
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
  • H04L63/101—Access control lists [ACL]

Definitions

• the invention relates to systems and methods for blocking persistent malware. More particularly, the invention relates to systems and methods for detecting and blocking data packets sent to and from browser software applications and/or non-browser software applications operated on a computing device and infected with Trojans and/or other malware that attempts to communicate with one or more hacker's command and control centers.
• Persistent malware has been a longstanding problem for the cybersecurity industry. The industry's failure to find adequate solutions is highlighted by how popular this longstanding hacking method has become. A great need exists to finally be able to expose and block persistent malware. A further need exists to be able to detect and block Internet traffic to and from Trojans with which a computing device is infected while ensuring that the legitimate traffic to and from the infected apps is allowed.
• the invention relates to systems and methods for detecting and blocking data packets sent to and from browser software applications and/or non-browser software applications installed on a computing device and infected with Trojans and/or other malware that attempts to communicate with one or more hacker's command and control centers.
• the system is capable of allowing and blocking data packets sent to and from both browser software applications and non- browser software applications installed on a computing device.
• systems that allow and block traffic to and from only browser software applications or to and from only non-browser software applications may be used, although for providing the most effective computer security systems that perform both methods are used.
• the allowance and blocking of data packets to and from various sources may be performed automatically by the system or may be accomplished by action taken by a user of the computing device.
• the systems and methods described herein can use whitelisting based on the maker of a non-browser software application being a trusted source of data packets sent to the non-browser application or based on consensus by one or more consensus trusted computing devices that connections made by an URL open in a browser software application are correct and trusted.
• the system uses a local firewall of the computing device to block data packets to and from web addresses (i.e., domains, subdomains, path names, or URLs) that are not owned by the makers of the application, that are not trusted by the consensus trusted computing devices, or that are blocked by affirmative selection for blocking by a user of the computing device.
• the system can also include a health monitor engine to ensure that a kernel drive of the system is operational and not disabled by malware, which would prevent the system from detecting and blocking traffic between the browser and non-browser software applications installed on a computing device and a hacker's command and control center.
• a health monitor engine to ensure that a kernel drive of the system is operational and not disabled by malware, which would prevent the system from detecting and blocking traffic between the browser and non-browser software applications installed on a computing device and a hacker's command and control center.
• the invention features a system for detecting and blocking Trojan malware and other malware as follows:
• the system includes a computing device that is communicatively connected to a communications network, and a browser software application being operated on the computing device.
• the system also includes an open URL identification process to communicate an identity of a web address, wherein the web address is an open web address if it is open in the address bar of the browser software application.
• the system further includes an open connection tracking process that tracks at least one connection to a remote computing device made by the open web address.
• the open connection tracking process can report open connections as one or more of the following: domains, subdomains, path names, resource locations, URLs, IP addresses, and the like.
• the system also includes a firewall to intercept data packets sent to or from the browser software application. The firewall blocks data packets that are not being sent to or from the open web address or to or from the at least one connection of the open web address.
• the invention can feature the web address being a URL name, a path name of a URL, a domain name of a URL, or a subdomain of a URL.
• the identity can be an owner name, a URL name, a path name of a URL, a domain name of a URL, a subdomain of a URL, a derivative of one of the foregoing, or an alias representing one of the foregoing.
• the invention can feature the at least one connection, if any, made by the web address being a URL name, a path name of a URL, a resource named by a URL, a domain name of a URL, or a subdomain of a URL.
• the identity can be an owner name, a URL name, a path name of a URL, a resource named by a URL, a domain name of a URL, a subdomain of a URL, a derivative of one of the foregoing, or an alias representing one of the foregoing
• the invention can feature the connection tracking process verifying the authenticity of the at least one connection made by the open web address.
• the system further includes at least one trusted computing device to identify at least authentic one open connection of the open web address.
• the at least one trusted computing device reports an authenticity list that includes at least one connection of the web address that is authentic.
• the invention can feature a connection analysis engine to statistically analyze the connections reported by multiple computing devices that access the same open web address to verify that the at least one connection is a trusted connection that the connection analysis engine assigns a trusted status or is not a trusted connection that the connection analysis engine assigns a distrusted status.
• the invention can feature the connection analysis engine being operated on the computing device or on a different computing device that is communicatively connected to the computing device.
• the invention can feature the firewall being configured to intercept and automatically block data packets sent to or from the browser software application that are not being sent to or from the open web address or to or from the at least one connection of the open web address.
• the invention can feature a reputation engine to allow or block the open web address.
• the firewall blocks the open web address if the open web address does not meet a reputation threshold as determined by the reputation engine.
• the invention can feature a reputation engine to allow or block the at least one connection made by the open web address.
• the firewall blocks the at least one connection made by the open web address if the at least one connection made by the open web address does not meet a reputation threshold as determined by the reputation engine.
• the invention can feature a reputation engine to allow or block at least one other connection to the browser software application.
• the firewall blocks the at least one other connection if the at least one other connection does not meet a reputation threshold as determined by the reputation engine.
• the at least one other connection includes one or more connections that are not the open web address or the at least one connection to the open web address.
• the invention can feature a web address identity interface to display the identity of the open web address to a user, wherein the web address identity interface comprises at least one control element that permits the user to allow or block data packets sent to and from the open web address by selecting an allowed status or a blocked status for the open web address.
• the at least one connection, if any, of the open web address is also assigned the blocked status when the user operates the at least one control element of the web address identity interface to block the open web address.
• the firewall blocks data packets sent to and from the at least one connection, if any.
• the invention can feature the at least one connection of the open web address being allowed, and not blocked, when the open web address is blocked but a second open web address that is allowed shares the same at least one connection.
• the invention can feature a connection interface that displays the at least one connection of the open web address.
• the connection interface includes at least one control element that permits the user to allow or block the at least one connection.
• the firewall blocks data packets sent to and from the at least one connection if the blocked status is selected for the at least one connection.
• the connection interface can be the web address identity interface or a different interface, and the at least one control element of the connection interface can be the at least one control element of the web address identity interface or a different at least one control element.
• the invention can feature the interface displaying the identity of the web address of automatically blocked data packets.
• the blocked status of the web address of the automatically blocked data packets is overridable by at least one option selected from among the group of: (i) the user using the at least one control element of the interface to manually select the allowed status for the web address to override the blocked status of the web address; (ii) an override process overriding the blocked status of the web address by comparison to a whitelist that informs the override process that the data packets are not being sent to or from the open web address or its at least one connection; or (iii) a reputation engine overriding the blocked status of the web address when the data packets are not being sent to or from the open web address or its at least one connection when a reputation threshold is met or exceeded as determined by the reputation engine.
• the invention can feature the allowed open web address being a user-opened web address opened by the user.
• the system further includes an interface to display the identity of the user-opened web address to a user.
• the at least one connection includes at least one connection to a remote computing device made by the user-opened web address, if any.
• the interface does not display the at least one connection made by the user-opened web address but does allow data packets sent to or from that at least one connection.
• the interface displays and the firewall blocks data packets that are not sent to or received from the browser software application by the user-opened web address or its at least one connection.
• the invention can feature an override process to override the blocked status of the data packets that are not sent to or received from the browser software application by the user-opened web address or its at least one connection.
• the override process compares a web address or identity of the blocked data packets to a whitelist that informs the override process that the blocked status of the blocked data packets should be overridden.
• the override process displays the blocked data packets and changes their blocked status to allowed status if the web address or identity of the blocked data packets is located in the whitelist.
• the invention can feature a web traffic analysis system to determine the identity of the open web address, the identity of the at least one connection of the open web address, or the identity of both.
• the web traffic analysis system includes a browser plugin, a local man-in-the-middle http/https interception, a remote man-in-the-middle http/https interception, or a web proxy.
• the invention can feature an automated health monitor engine that periodically checks a status of a kernel driver of the system to ensure that the kernel driver is operational.
• the invention can feature the automated health monitor engine generating an alert if the kernel driver is disabled.
• the invention can feature an interface having a continuously changing visual display. A continuous change in appearance of the continuously changing visual display represents that the automated health monitor engine is checking the kernel driver. The continuously changing visual display ceases continuously changing in appearance if the automated health monitor engine is unable to perform the check of the status of the kernel driver.
• the invention also features a system for detecting and blocking Trojan malware and other malware as follows:
• the system includes a computing device that is communicatively connected to a communications network, and a browser software application being operated on the computing device.
• the system also includes a remote web proxy that replaces at least one connection made by an open web address, if any, with an alias based on a domain name of the web proxy or another domain name.
• the system further includes a firewall that blocks all data packets not sent to or received from the web proxy by the browser software application.
• the web address is an open web address if it is open in the web proxy.
• the invention can feature the web proxy reporting the open web address to the firewall.
• the invention can feature a firewall interface displaying the open web address.
• the invention can feature the firewall interface permitting a user to select an allowed status or a blocked status for the web address.
• the firewall communicates the web address to the web proxy when a blocked status is selected for the web address.
• the web proxy subsequently blocks data packets sent to or received from the web address and the web proxy blocks the connections made by the web address, if any.
• the invention can feature data packets not sent to or received from the web proxy by the browser software application are initially automatically blocked except data packets sent to or received from the browser software application by a web address or IP address that appears on a whitelist.
• the invention also features a system for detecting and blocking Trojan malware and other malware as follows:
• the system includes a computing device that is communicatively connected to a communications network, and at least one non- browser software application operated on the computing device.
• the system also includes a maker identification process to identify a maker of the at least one non- browser software application.
• the system further includes an identity verification process to determine an owner of at least one remote host address sending data packets to or receiving data packets from each at least one non-browser software application. The owner of each at least one remote host address as determined by the identity verification process and the maker of each at least one non-browser software application are compared to determine whether they are the same or different.
• the system also includes a firewall to block data packets sent to and from the at least one non-browser software application by each at least one remote host address when the owner of each at least one remote host address and the maker of each at least one non-browser software application are different.
• the invention can feature a mismatched application/remote host address communication pair being one at least one remote host address having an owner that is different from the maker of one at least one non-browser software application.
• the identification of a mismatched application/remote host address communication pair results in the firewall blocking data packets transmitted between the mismatched application/remote host address pair.
• the invention can feature a reputation engine that initially blocks data packets from the at least one remote host address when a reputation of the at least one remote host address is determined by the reputation engine to not meet or exceed a reputation threshold.
• the invention can feature the system having a first interface to display a name of each at least one non-browser software application, the maker of each at least one non-browser software application, each at least one remote host address with which each at least one non-browser application attempts to communicate, and the owner of each at least one remote host address.
• the system can also include a second interface that permits a user to selectively allow or block traffic sent to and received from each at least one non-browser software application by each at least one remote host address.
• the second interface can be the first interface or a different interface.
• the invention can feature each non-browser software application of the at least one non-browser software application that communicating with a remote host address of the at least one web address is an application/remote host address communication pair.
• the system includes a process to initially block all application/remote host address communication pairs.
• the system further includes a first interface to display a name of each non-browser software application, the maker of each non-browser software application, each web address with which each non-browser software application communicates, and the owner of each such web address.
• the system can also include a second interface that permits a user to selectively allow or block traffic sent to and received from each at least one non- browser software application by each at least one web address.
• the second interface is the first interface or a different interface.
• the invention can feature each non-browser software application of the at least one non-browser software application that communicating with a remote host address of the at least one remote host address is an application/remote host address communication pair.
• the system includes a process to initially block traffic between all application/remote host address communication pairs for a temporary period of time.
• the system further includes a first interface to display a name of each non-browser software application, the maker of each non- browser software application, each remote host address with which each non- browser software application communicates, and the owner of each such remote host address.
• the system further includes a second interface that permits a user to selectively quarantine one or more application/remote host address communication pairs of all of the application/remote host address communication pairs prior to expiration of the temporary period of time.
• the second interface can be the first interface or a different interface.
• the invention can feature legitimate DNS data packets and local packets and traffic to digital certificate authorities being automatically allowed.
• the invention also features a system for detecting and blocking Trojan malware and other malware as follows:
• the system includes a computing device that is communicatively connected to a communications network, and at least one non- browser software application operated on the computing device.
• the system also includes an identity verification process to determine an owner of at least one remote host address sending data packets to or receiving data packets from each at least one non-browser software application.
• the owner of each at least one remote host address as determined by the identity verification process and the maker of each at least one non-browser software application can be compared to determine whether they are the same or different.
• the system further includes an interface to communicate both an identity of the at least one non-browser software application and the owner of the at least one remote host address with which the at least one non-browser software application is communicating.
• the system further includes a firewall to block data packets transmitted between at least one application/destination pair, wherein the at least one application/destination pair includes one of the at least one non-browser applications communicating with one of the at least one remote host addresses that is the destination of the at least one application/destination pair.
• the invention can feature an interface to permit a user to selectively allow or block one or more of the at least one application/destination pairs.
• the invention can feature the firewall automatically blocking communication between each newly encountered application/destination pair of the at least one application/destination pair.
• the interface permits the user to toggle a current status of each at least one application/destination pair between an allowed status and a blocked status.
• the invention can feature the firewall automatically blocking communication between each newly encountered application/destination pair of the at least one application/destination pair unless the newly encountered application/destination pair, the destination, or both are whitelisted.
• the interface permits the user to toggle a current status of each at least one application/destination pair between an allowed status and a blocked status.
• the invention can feature the firewall automatically blocking communication between each newly encountered application/destination pair of the at least one application/destination pair unless a destination reputation of the destination meets or exceeds a destination reputation threshold.
• the system further includes a destination reputation engine to determine the destination reputation of the destination.
• the interface permits the user to toggle a current status of each at least one application/destination pair between an allowed status and a blocked status.
• Figure 1 is a flow chart showing a process of the system for processing data packets.
• Figure 2 is a flow chart showing one embodiment of a system for processing data packets sent and received by a browser app.
• Figure 3 is a flow chart showing one embodiment of a system for processing data packets sent and received by a non-browser app.
• Figure 4 is a flow chart showing another embodiment of a system for processing data packets data packets sent and received by a browser app.
• Figure 5 is a flow chart showing still another embodiment of a system for processing data packets data packets sent and received by a browser app.
• Figure 6 is a flow chart showing another embodiment of a system for processing data packets data packets sent and received by a non-browser app.
• Figure 7 is a flow chart showing still another embodiment of a system for processing data packets data packets sent and received by a non-browser app.
• Figure 8 is a graphic representation of the principles that allow the system to operate effectively.
• Figure 9 is a schematic diagram of one embodiment of the system.
• the invention provides a novel system and method that both exposes and blocks persistent malware - finally providing genuinely effective protection against this now most prevalent form of hacking.
• Trojans are but one example of persistent malware that communicates with a hacker's command and control center; other types of persistent malware exist as will be understood by one of skill in the field.
• the terms "computer” and "computing device” mean a computer, a tablet computer, a server, a mobile device (e.g., a cellular telephone, smartphone, etc.), a gaming device, a smart appliance, a smart television, a smart light bulb, a smart outlet adapter, a smart automobile, and any other device that includes a processor and is communicatively connected to a communications network.
• the term “smart” used with several items in the foregoing list means that such items are electronic devices that have a wireless connection to a communications network.
• the term “computing device” is used most frequently herein.
• the computing device also includes at least one browser software application, at least one non-browser software application, or both.
• Such software applications can be installed locally on the computing device or can be installed on a remote computing device but operated on the local computing device.
• web address means a URL name, a path name of a URL, a domain name of a URL, or a subdomain of a URL.
• identity and "name,” when used alone herein, mean an owner name, a URL name, a path name of a URL, a domain name of a URL, a subdomain of a URL, a derivative of one of the foregoing, or an alias representing one of the foregoing.
• the invention features a system for detecting and blocking Trojans and other persistent malware that connect to one or more hackers' command and control centers.
• the system includes a browser software application installed on a computing device that is communicatively connected to a communications network, a process to communicate an identity or identities of one or more web addresses open in the browser software application, a process that catalogues the connections made by open web addresses, a firewall that intercepts packets to or from a browser and blocks packets that do not belong to an open web address or to any of the connections made by an open web address.
• the system can feature automatically blocking a packet if it is to or from a browser yet does not belong to a subdomain of an open web address nor any of the connections made by an open web address.
• One or more trusted computing devices can record the correct connections made by web addresses so that the connections can be verified before being trusted.
• the system can include a process that uses a statistical analysis to deduce the correct connections made by web addresses so that the connections can be verified before being trusted.
• the system can also include an interface, which displays the names of open web addresses to the user in a manner that permits the user to allow or block the web address.
• names can be the owner of the domain, a domain name, subdomain name, and/or a derivative of these and/or an alias representing any of these.
• the interface can display the connections opened by web addresses.
• the interface can display the connections opened by web addresses in a manner that permits the user to allow or deny such connections.
• the user may elect to allow only data packets that belong to user-opened web addresses or connections made by user-opened web addresses that the user has not denied.
• the system can also include a reputation engine that can be used to initially allow or deny a web address (and its subsequent connections), such that web addresses that do not meet an established reputation threshold are initially blocked rather than initially allowed.
• the reputation engine can be used to initially allow or deny a web address (and its subsequent connections), such that domains and/or subdomains that do not meet an established reputation threshold are initially blocked rather than initially allowed.
• the aforementioned interface can display the names of automatically blocked packets.
• names can be a name of the owner of the domain, a domain name, subdomain name, and/or a derivative of these and/or an alias representing any of these.
• the interface can display the names of automatically blocked packets in a manner that permits the user to override the blocked name.
• names can be the owner of the domain, a domain name, subdomain name, and/or a derivative of these and/or an alias representing any of these.
• the system can feature a whitelist that can override the automatic blocking of browser-based packets that neither belong to an open web address nor to any of the connections made by open web addresses.
• the reputation engine of the system may also be capable of overriding the automatic blocking of browser-based packets that neither belong to an open web address nor to any of the connections made by open web addresses if the reputation meets or exceeds an established threshold.
• the system may display and allow the names of user-opened web addresses while not displaying, yet allowing, data packets belonging to connections made by user-opened web addresses.
• the system may display and block the names of packets that do not meet the prior two conditions.
• the system may display and allow the names of user- opened web addresses while not displaying, yet allowing, data packets belonging to connections made by user-opened web addresses.
• the names of web addresses sending and receiving data packets that do not meet the prior two conditions may be displayed and blocked unless such packets are whitelisted in which case they are displayed and allowed.
• the system can also feature an automated health monitor engine that periodically checks the status of the kernel driver to ensure that the kernel driver is operational.
• the automated health monitor engine can generate an alert if the kernel driver is disabled.
• the alert can be visual, audible, or both.
• the automated health monitor engine can include an interface with a constantly changing visual display representing the health monitor checking of the kernel driver such that the display will cease constantly changing if the user interface is prevented from performing the kernel driver health monitoring, thereby alerting the user that the system and computing device have potentially been hacked.
• the system can include a browser plugin, man-in-the-middle http/https interception (local and/or remote), and/or a web proxy for determining the identity of open web addresses and of connections made by open web addresses.
• the invention also features a system for detecting and blocking Trojans and other malware that communicate with one or more hackers' command and control centers.
• the system includes a browser software application installed on a computing device that is communicatively connected to a communications network and a remote web proxy, which replaces the connections made by web addresses with aliases based on the domain of the web proxy or some other agreed upon domain.
• the system also includes a local firewall that blocks all browser-based packets not destined to or received from the web proxy.
• the web proxy can report the open web address to the firewall, and a firewall interface can display the open web addresses.
• the firewall interface can permit the user to allow or deny the web addresses.
• the local firewall communicates denied web addresses to the web proxy, and the web proxy subsequently blocks the affected web addresses and their connections.
• the system may initially block data packets that are not destined to or received from the web proxy except whitelisted subdomains, domains, domain owners, and/or IP addresses (which are allowed).
• a web proxy could be used for browser traffic in which the web proxy communicates the web addresses of one or more open web addresses to the firewall of the system, and the web proxy could replace the connections made by the open web addresses with aliases such that the firewall could automatically block data packets if they do not belong to the subdomain and/or domain of any open web address.
• the invention also features a system for detecting and blocking Trojans and other malware that connect to one or more hackers' command and control centers, wherein the system includes a non-browser software application installed on a computing device that is communicatively connected to a communications network, a process that communicates the owner of the domains of the data packets sent to or from the non-browser app, a process to communicate the maker of the non-browser app, and a process that initially blocks packets when the identity of the maker of the app does not match the identity of the owner of the data packet's domain.
• This system can include a reputation engine in which packets are only initially blocked if the maker of the app does not match the owner of the domain, or if the reputation of the domain and/or the domain owner does not meet or exceed an established reputation threshold.
• This system can also feature an interface that displays the app names and/or the names of apps' makers, and the owner of the remote domains with which each app attempts to communicate.
• the system can also include an interface (which may the same interface as the previously described one or a different interface) that permits the user to selectively allow or deny traffic to and from each app on a per domain and/or per domain owner basis.
• the system can include a process that initially blocks all app/domain communication pairs, i.e., non-browser software applications and remote host addresses (also referred to herein as "destinations") that communicate or attempt to communicate with one another.
• An interface of the system can display the app names and/or the names of their makers, and the owner of the remote domains with which they attempt to communicate.
• the system may include a second interface that permits the user to selectively allow traffic to and from each app on a per domain and/or per domain owner basis, or these steps may be completed using the first interface.
• the system can further include a process that initially blocks all app/domain communication pairs for a temporary period of time and an interface that displays the app names and/or the names of their makers, and the owner of the remote domains with which they attempt to communicate.
• a process that initially blocks all app/domain communication pairs for a temporary period of time and an interface that displays the app names and/or the names of their makers, and the owner of the remote domains with which they attempt to communicate.
• first interface or a second interface may be provided by the system to permit the user to selectively quarantine the app/domain pairs before the time expires for the temporary period of time (in which case, the app/domain pair is allowed if not quarantined before the time expires).
• the system may automatically allow legitimate DNS packets, traffic to digital certificate authorities, and legitimate local packets.
• a user can control who can access the user's computing device when the user views the names of every party who wants to talk, in near real-time, each time the named entity wants to talk (i.e., communicate), whether that named entity is currently allowed or not.
• Entities can be any of the following (or derivatives or aliases of the following):
• Subdomains e.g., a.2mdn.net, b.2mdn.net, y.gstatic.com, and z.gstatic.com
• Domains also referred to herein as Domain Names (e.g., 2mdn.net, and gstatic.net)
• Entity Hierarchy IP Addresses ⁇ Subdomains ⁇ Domains ⁇ Registered Owners.
• Each level of the Entity Hierarchy moving from left to right encompasses more data packets.
• a single Registered Owner name can encompass hundreds of Domains, thousands of Subdomains, and even tens of thousands IP Addresses.
• some embodiments may choose to use Domain Names and/or Registered Owner names to reduce the amount of information a user will need to see in order to make an informed choice over who can access the computing device and who cannot.
• Non-browser traffic Two broad categories of PC internet traffic exists: browser data packets sent to or from a browser software application and non-browser data packets sent to or from non-browser software applications.
• non-browser traffic the user may find it useful to choose the app/destination pair. For example, a user may want to allow WinWord to talk to Registered Owner Microsoft Corp.; yet the same user might want to block WinWord from talking to Registered Owner Richard Smith.
• Allowing the user to allow or block an app/destination pair provides genuinely effective protection against the real-world problem of Trojans (also known as Trojan horse malware) injecting themselves into legitimate apps.
• Trojans also known as Trojan horse malware
• Richard Smith is the owner of xyz.org. If a Trojan injects itself into WinWord and tries to send sensitive data to trojan.xyz.org, one embodiment could show the user that WinWord wants to talk to Richard Smith. By keeping this connection blocked, yet allowing WinWord to talk to Microsoft Corp., the user's sensitive information remains protected while WinWord's legitimate activity remains intact.
• a highly effective method for protecting non-browser apps is to display the name of the app (or a derivative of the name or an alias representing the name) along with the destination name at the time the app wants to communicate with the non-browser app.
• the most secure method would be to initially block each new app/destination pair unless the pair was specifically whitelisted and/or the user chooses to unblock the communication between the pair.
• the app name would be to display the name of the maker of the app. For example, some embodiments might display that "Microsoft Corp.'s Winword" wants to talk to "Microsoft Corp.”
• Another highly secure method would be to temporarily block each newly encountered app/destination pair (unless the pair is whitelisted), and to display the requested connection to the user. If the user takes no action then the app/destination pair status automatically changes to allowed. However, if the user takes action then the status changes from "temporarily blocked” to "permanently blocked” (i.e., blocked until the user specifically decides to allow it and/or the app/destination pair is later added to a whitelist).
• a Trojan can literally send millions of bits of data in a single second. Therefore, the initial blocking of the Trojan is important so that not a single bit of data is compromised.
• some users may not want to have to manually allow every individual app/destination pair. By temporarily blocking all newly encountered app/destination pairs, both objectives can be satisfied for such users, and therefore, some embodiments may implement this particular method.
• traffic can be managed by the following Group Policy: if the user approves a URL (or the URL is whitelisted) then allow all connections made by that URL for as long as its webpage is active in the browser, without displaying such connections. For example, if cnn.com is an allowed URL then automatically allow the 56 sites to which it connects without displaying the 56 sites.
• Some embodiments of the system that can accomplish the above include (but are not limited to) a browser plugin that transmits each open URL and their connections to the security system, a local man-in-the-middle http/https interception can be used to retrieve this information, and/or a remote man-in-the-middle http/https proxy can be used to obtain open web addresses and their respective connections.
• a browser plugin can display the connections on the webpages themselves.
• the main security display of the system would solely show cnn.com while the plugin could show the 56 connections on the cnn.com browser webpage itself.
• Such embodiments could also give the user the ability to block any and/or all of the URL's connections.
• Some embodiments might allow the user to see the connections from a Menu choice in the main program and/or control the individual connections from a Menu choice in the browser plugin as well.
• the Group Policy can also be used for automation: Automatically allow open web addresses and their connections while automatically blocking everything else.
• cnn.com and its connections would automatically be allowed while Trojan.xyz.org would be automatically blocked (since it is neither an open URL subdomain nor the subdomain of any connection made by an open URL).
• the Group Policy easily exposes and blocks Trojans that attempt to make direct connections to their command and control center while masquerading as Firefox.
• an open loophole still remains: the Trojan can inject its command and control center destination into a webpage and thereby cause the connection to be allowed (at least temporarily).
• some embodiments can use Consensus-Based Whitelisting.
• the connections made by web addresses are recorded by one or more trusted machines (and/or a statistical deduction of the correct connections can be made from sampling a number of user machines for any given URL).
• the correct connections can be retrieved from the internet via an encrypted connection.
• These consensus-based connections are then used for the Group Policy (as opposed to inherently trusting the connections listed in the local webpage).
• Consensus-Based Whitelisting exposes and blocks Trojans that inject themselves into browsers, regardless of whether they try to make a direct connection or whether they insert their command and control destinations into the local webpages themselves.
• Consensus-Based Whitelisting is the use of a web proxy for the correct identification of connections made by web addresses. (See below for a description of one embodiment.)
• Consensus-Based Whitelisting can also be used for non-browser apps as an adjunct to Maker-Based Whitelisting.
• Consensus-Based Whitelisting can be used when an app has legitimate traffic that does not involve its maker.
• an app's traffic can be allowed if it passes either the Maker- Based Whitelisting rule or if one or more trusted machines (or a statistically significant number of other machines) record the same app communicating with the same destination (i.e., Consensus-Based Whitelisting).
• Some embodiments can use Consensus-Based Whitelisting to automate the discovery of an apps maker.
• Remote web proxies can also be used for managing open web addresses and their respective connections.
• a remote web proxy can report the domain and/or subdomain, and/or path, and/or URL name of each open URL to the firewall. For example, if the user enters "cnn.com” in the web proxy then it can report "cnn.com” as an open URL.
• the web proxy could also replace connections made by open web addresses with aliases based on the web proxy's domain or some other agreed upon domain.
• the web proxy domain is TerraProxy.com and cnn.com connects to "optimizely.com” and “instantads.com” then the web proxy could replace “optimizely.com” with “abc.TerraProxy.com” and the web proxy could replace “instantads.com” with “xyz.TerraProxy.com”.
• the firewall can initially block all web-based traffic that does not flow through the web proxy (e.g. TerraProxy.com). Moreover, the firewall can provide an interface for the user to see and block the list of open web addresses. The firewall reports the blocked web addresses to the web proxy, which in turn shuts down the web address and its respective connections. This will prevent Trojans from secretly using the web proxy for connectivity to a command and control center.
• Some embodiments could use a plugin for certain browsers and use the remote web based proxy for other browsers.
• the plugin could report open web addresses and manage the connections made by those web addresses for the given browser while the remote web proxy could be used to manage open web addresses and their respective connections for browsers that do not have such plugins available.
• the combination of Maker-Based Whitelisting and Consensus-Based Whitelisting (along with Group Policy) provides daunting protection for browser apps and non-browser apps alike. Therefore, a hacker could try to secretly disable the blocking/allowing security in an effort to covertly bypass it. An automated Health Monitor can protect against this remaining attack vector.
• GUI process can do one or more of the following:
• the GUI queries the driver every four seconds to get the information it needs to construct the display.
• this particular embodiment changes the color of a circle on the display (continually transitioning it from a grey color to a blue color and back again). If the driver should fail to respond to the query then the GUI changes the color of the circle to permanent red.
• a number of ways are available to implement such a health monitor. Provided that the health monitor is implemented such that the GUI continually changes the presentation of the health monitor based upon continued observation of driver state within the confines of a real-time traffic monitor integrated with a realtime traffic controller, such would be in the spirit and scope of this disclosure, as would altering the presentation of the health monitor based upon a change of driver status within the same confines.
• the system and method disclosed herein control the physical network interface card (NIC) in a computer 902.
• the firewall component (901) can be implemented as a kernel driver; and the interface to the display (904) can be a higher- level process or program communicating with the kernel driver.
• Figures 1-3 show one embodiment that can be a standalone Trojan trapping system and/or implemented as a subprocess, which exposes and blocks Trojans within a larger firewall system.
• This embodiment processes the NIC's raw data packets 100 by dividing Internet-based packets into two categories: browser packets 120 and non-browser packets 102.
• Figure 2 shows one example embodiment for processing browser packets.
• This embodiment first checks to see if the packet belongs to the subdomain of an open URL 201. Alternate embodiments might check to see of the packet belongs to the domain instead (e.g., alternate embodiments might approve cnn.com even if the URL itself is the subdomain sports.cnn.com).
• the packet is allowed 210. If the packet does not belong to the subdomain of an open URL 201 then the packet is checked to see if belongs to any of the connections made by an open URL 202.
• the packet If the packet does belong to a connection made by an open URL 202 then the packet is allowed 210. If the packet does not belong to a connection made by an open URL 202 then the packet is blocked 203.
• Figure 3 shows one example embodiment for processing internet-based packets to and from non-browser apps 300.
• the name of the maker of the app is obtained 301.
• Most software apps these days are digitally signed. Such digital signatures contain the name of the maker of the app. This is one way of obtaining the name of the maker of the app.
• the next step in this example embodiment is to obtain the name of the owner of the domain of the remote device to which the app is communicating 302.
• Various means of obtaining this information include standard Whois lookups and/or proprietary databases (such as those published by numerous third parties).
• the next step in this example embodiment is to determine whether the name of the app's maker matches the name of the domain owner 303. If the names do not match 303 then the packet is blocked 320; otherwise, the packet continues forward.
• Figures 4 and 5 show two additional example embodiments for how browser packets can be processed. There are numerous other possible alternative embodiments.
• Figure 4 is an example embodiment where the initial state is based upon the reputation of the web address. The user can then toggle the state thereafter.
• Figure 5 is an embodiment that does not use a reputation engine.
• browser packets 400 are processed by first translating the remote IP address into its subdomain and domain 401.
• an IP address might be translated into subdomain maps.google.com and domain google.com.
• Methods for mapping IP addresses into domains/subdomains have been disclosed in U.S. Patent No. 9,467,324.
• the system next checks to see if the subdomain matches an open URL 402, i.e., a web address that is open within the browser app.
• a browser plugin can be used to transmit open and closed web addresses.
• Web addresses can also be obtained from HTTP/HTTPS interception, and/or remote web proxies.
• the system checks the subdomain to see if it belongs to any of the connections made by an open URL 403, and if it does belong then it is allowed but not displayed 404.
• the connections made by an open web address can be determined by a browser plugin using standard Web Extensions API calls, or for greater security, the web address connections can be downloaded from a local LAN server or remote WAN server which retrieves the web address connections from one or more trusted machines that accessed the same web address and/or a statistical determination made from multiple user machines that accessed the same web address.
• Alternatively or adjunctively accessing web pages via a remote web proxy can allow correct web address connections to be obtained from and/or managed by the remote web proxy.
• the domain owner name is retrieved 420.
• the domain owner name can be obtained by a Whois lookup and/or from proprietary database lookups (such as in cases where anonymous domain privacy services are returned in the Whois lookup).
• the domain name and its respective owner are displayed 421.
• the packet is then checked to see if it is the first packet from the domain 422 (or alternatively from the subdomain). If it is the first packet received form the subdomain, then the subdomain' s reputation is checked 423 to determine whether to allow or block it 424. If this is not the first packet from the domain/subdomain, then the current state is retrieved 440 in order to determine whether to allow or block it 441.
• browser packets 500 are processed by first translating the remote IP address into its subdomain and domain 501. Then, the owner is retrieved 502. If the subdomain matches an open URL 503 then the owner and domain (and/or subdomain) are displayed and allowed 504.
• the system of this embodiment checks to see if the subdomain belongs to a connection made by an open URL 520.
• the same methods discussed above can be used to determine connections made by open web addresses. If the subdomain belongs to a connection made by an open URL 520 then it is allowed but not displayed 521; otherwise, the subdomain is blocked and displayed 540.
• Figures 4 and 5 both illustrate examples of embodiments of the system in which the connections made by open web addresses can be allowed yet not displayed in order for Trojans that hijack browsers to easily be exposed and blocked. Any Trojan hijacking a browser will be displayed in these embodiments. Meanwhile, the plethora of extraneous web address connections will not be displayed so that the Trojan's presence is readily seen by the user and blocked.
• Figures 6 and 7 illustrate additional example embodiments for processing non-browser data packets, i.e., data packets sent to and from a non-browser app. Numerous alternative embodiments are possible.
• the Figure 6 embodiment illustrates a manual implementation in which every new app/destination pair is initially blocked. The user can then manually toggle the status thereafter.
• the Figure 7 embodiment illustrates an automated implementation that uses a combination of Maker-Based Whitelisting and Consensus-Based Whitelisting to determine the initial state of each app/destination pair. The user can then toggle the status thereafter, if the user so chooses.
• the Figure 6 embodiment begins by first examining whether the packet is either a DNS packet or local packet 601. If it is either of these types of data packets, then the packet is allowed but not displayed 604. Alternatively, the DNS packets can be processed in accordance with the methods disclosed in U.S. Patent No. 9,467,324 for greater security.
• the packet is neither a DNS packet nor a local packet 601 then the name of the application with which it is communicating is retrieved 602. Modern operating systems provide Transport Layer API calls to obtain such information.
• the IP address of the remote machine is translated into a subdomain 603.
• the owner of the subdomain is retrieved 620. The app and its owner are then displayed 621.
• the initial status is set to blocked 623. If this is not the first packet from the app/destination pair 622 then the current state is retrieved 640 in case the user previously has manually allowed the pair. If the current state is not allowed 641 then the pair remains blocked 623. If the current state is allowed 641 then the pair remains allowed 642. Note that the manual toggling of states is described in U.S. Patent No. 9,467,324, which is incorporated herein in its entirety by this reference.
• the Figure 7 embodiment is the same as the Figure 6 embodiment until the App/Owner Name are displayed 721. Then, at this point, this embodiment uses Consensus-Based whitelisting to determine initial status.
• the Figure 7 embodiment checks to see if the maker of the app matches the domain owner 722. If it does then the packet is initially allowed 723. If the makers of the app does not match the domain owner 722 then a consensus list of app/destination pairs is retrieved from a local LAN server and/or a remote WAN server 740. If the destination is in the consensus list 741 then the pair is initially allowed 723; otherwise, the pair is initially blocked 742.
• Figure 8 illustrates an embodiment implementing the tri-level security of
• Figure 9 illustrates the system and method's control of the physical components of a computing device.
• the user keyboard, mouse, touchscreen, etc., 900 are used to toggle state changes (see U.S. Patent No. 9,467,324 for alternative embodiment implementations).
• the firewall itself 901 blocks/allows the data packets of the NIC 902 in accordance with the disclosure contained herein as well as the disclosure contained in U.S. Patent No. 9,467,324.
• the server 905 houses the connections made by various web addresses to be retrieved and used for Consensus- Based Whitelisting.
• the server can also house app/destination pairs for embodiments that use Consensus-Based Whitelisting for non-browser apps.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computing Systems (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Medical Informatics (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (4)

Publications (2)

Family

ID=67386081

Family Applications (1)

Country Status (2)

Family Cites Families (13)

• 2017
  • 2017-02-10 EP EP17753665.3A patent/EP3417396A4/de not_active Withdrawn
  • 2017-02-10 WO PCT/US2017/017293 patent/WO2017142799A2/en active Application Filing

Also Published As

Similar Documents

Legal Events