Google’s POODLE affects oodles

97% of SSL web servers are likely to be vulnerable to POODLE, a vulnerability that can be exploited in version 3 of the SSL protocol. POODLE, in common with BEAST, allows a man-in-the-middle attacker to extract secrets from SSL sessions by forcing the victim's browser into making many thousands of similar requests. As a result of the fallback behaviour in all major browsers, connections to web servers that support both SSL 3 and more modern versions of the protocol are also at risk.

The Secure Sockets Layer (SSL) protocol is used by millions of websites to protect confidential data in transit across the internet using strong cryptography. The protocol was designed by Netscape in the mid 1990s and was first released to the public as SSL 2 in February 1995. It was quickly replaced by SSL 3 in 1996 after serious security flaws were discovered. SSL 3 was replaced by the IETF-defined Transport Layer Security (TLS) version 1.0 in January 1999 with relatively few changes. Since TLS 1's release, TLS 1.1 and TLS 1.2 have succeeded it and should be used in its place wherever possible.

sslv3-vulnerable6

POODLE's bark may be worse than its bite

Unlike Heartbleed, POODLE can be used to attack client-server connections and is inherent to the protocol itself, rather than any one implementation such as OpenSSL or Microsoft's SChannel. In order to exploit it, an attacker must modify the victim's network traffic, know how the targeted secret information is structured (such as where a session cookie appears) and be able to force the victim into making a large number of requests.

Each SSL connection is split up into a number of chunks, known as SSL records. When using a block cipher, such as Triple DES in CBC mode, each block is mixed in with the next block and the record then padded to be a whole number of blocks long (8-bytes in the case of Triple DES). An attacker with network access can carefully manipulate the ordering of the cipher-blocks within a record to influence the decryption and exploit the padding oracle. If the attacker has been lucky (there's a 1 in 256 chance), she will have matched the correct value for the padding length in her manipulated record and correctly guessed the value of a single byte of the secret. This can be repeated to reveal the entire targeted secret.

SSL 3's padding is particularly easy to exploit as it relies on a single byte at the end of the padding, the padding length. Consequently an attacker must force the victim to make only 256×n requests for n bytes of secret to be revealed. TLS 1.0 changed this padding mechanism, requiring the padding bytes themselves to have a specific value making the attack far less likely to succeed.

The POODLE vulnerability makes session hijacking attacks against web applications reasonably feasible for a correctly-positioned attacker. For example, a typical 32-byte session cookie could be retrieved after eavesdropping just over 8,000 HTTPS requests using SSL 3. This could be achieved by tricking the victim into visiting a specially crafted web page which uses JavaScript to send the necessary requests.

Use of SSL v3

Within the top 1,000 SSL sites, SSL 3 remained very widely supported yesterday, with 97% of SSL sites accepting an SSL 3 handshake. CitiBank and Bank of America both support SSL 3 exclusively and presumably are vulnerable.

move-to-tls1

A number of SSL sites have already reacted to this vulnerability by disabling support for SSL 3, including CloudFlare and LinkedIn. On Tuesday 14th, the most common configuration within the top 1,000 SSL sites was to support SSL 3.0 all the way through to TLS 1.2, with almost two-thirds of popular sites taking this approach. One day later, this remains the most popular configuration; however, TLS 1.0 is now the minimum version for 11%.

Microsoft Internet Explorer 6 does not support TLS 1.0 or greater by default and may be the most notable victim of disabling SSL 3 internet-wide. Now 13 years old, IE6 was the default browser released with Windows Server 2003 and Windows XP in 2001 and will remain supported in Windows Server 2003 until July 2015. Despite its age and the end of Microsoft's support for Windows XP, IE6 remains popular, accounting for more 3.8% of web visits worldwide, and 12.5% in China. This vulnerability may ring the death knell for IE6 and Windows XP.

However, unless SSL 3 is completely disabled on the server side, a client supporting SSL 3 may still be vulnerable even if the server supports more recent versions of TLS. An attacker can take advantage of browser fallback behaviour to force otherwise secure connections to use SSL 3 in place of TLS version 1 or above.

SSL version negotiation

At the start of an SSL connection, servers and clients mutually agree upon a version of SSL/TLS to use for the remainder of the connection. The client's first message to the server includes its maximum supported version of the protocol, the server then compares the client's maximum version against its own maximum version to pick the highest mutually supported version.

While this mechanism protects against version downgrade attacks in theory, most browsers have an additional fallback mechanism that retries a connection attempt with successively lower version numbers until it succeeds in negotiating a connection or it reaches the lowest acceptable version. This additional fallback mechanism has proven necessary for practical interoperability with some TLS servers and corporate man-in-the-middle devices which, rather than gracefully downgrading when presented with a non-supported version of TLS, they instead terminate the connection prematurely.

An attacker with appropriate network access can exploit this behaviour to force a TLS connection to be downgraded by forging Handshake Alert messages. The browser will take the Handshake Alert message as a signal that the remote server (or some intermediate device) has version negotiation bugs and the browser will retry the connection with a lower maximum version in the initial Client Hello message.

handshake-alert

Operation of a forced downgrade to SSL 3 against a modern browser.

The fallback mechanism was previously not a security issue as it never results in the use of a protocol version that neither the client nor server will accept. However, those with clients that have not yet been updated to disable support for SSL 3 are relying on the server to have disabled SSL 3. What remains is a chicken and egg problem, where modern clients support SSL 3 in order to retain support for legacy servers, and modern servers retain support for SSL 3 for legacy clients.

There is, however, a proposed solution in the form of an indicator (an SCSV) in the fallback connection to inform compatible servers that this connection is a fallback and to reject the connection unless the fallback was expected. Google Chrome and Google's web sites already support this SCSV indicator.


Firefox 32

Chrome 40

IE 11

Opera 25

Safari 7.1
TLS 1.2 TLS 1.2 x 3 TLS 1.2 TLS 1.2 x 3 TLS 1.2
TLS 1.1 TLS 1.1 TLS 1.1
TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0 TLS 1.0
SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0 SSL 3.0

Comparison of browser fallback behaviour

We tested five major browsers with an attack based on the forged Handshake Alert method outlined above, and found that each browser has a variant of this fallback behaviour. Both Chrome and Opera try TLS 1.2 three times before trying to downgrade the maximum supported version, whereas the remainder immediately started downgrading. Curiously, Internet Explorer and Safari both skip TLS 1.1 and jump straight from TLS 1.2 to TLS 1.0.

Mitigation

Mitigation can take many forms: the fallback SCSV, disabling SSL 3 fallback, disabling SSL 3 in the client side, disabling SSL 3 in the server side, and disabling CBC cipher suites in SSL version 3. Each solution has its own problems, but the current trend is to disable SSL 3 entirely.

Disabling only the CBC cipher suites in SSL 3 leaves system administrators with a dilemma: RC4 is the only other practical choice and it has its fair share of problems making it an undesirable alternative. The SCSV requires support from both clients and servers, so may take some time before it is widely deployed enough to mitigate this vulnerability; it will also likely not be applied to legacy browsers such as IE 6.

Apache httpd can be configured to disable SSL 3 as follows:

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3
Microsoft IIS and nginx can also be configured to avoid negotiating SSL version 3.

Firefox can be configured to disable support for SSL 3 by altering security.tls.version.min from 0 (SSL 3) to 1 (TLS 1) in about:config.

firefox-disable

Internet Explorer can also be configured to disable support using the Advanced tab in the Internet Options dialogue (found in the Control Panel). In a similar way, IE 6 users can also enable support for TLS 1.0.

internet-options-disable

Chrome can be configured to not use SSL 3 using a command line flag, --ssl-version-min=tls1.

Site Report

You can check which SSL sites are still using SSL 3 using the Netcraft Site Report:

Netcraft site report
URL:

Phishing with data: URIs

A recent spate of phishing attacks has taken to using the data URI scheme for evil. Supported in most browsers, these special URIs allow the content of a phishing page to be contained entirely within the URI itself, effectively eliminating the need to host the page on a remote web server and adding an additional layer of indirection.

One of these attacks is demonstrated below, where a phishing campaign was used to herd victims to a compromised site in the US, which then redirected them to a Base64-encoded data URI. This particular example impersonates Google Docs in an attempt to steal email addresses and passwords from Yahoo, Gmail, Hotmail, and AOL customers.

Google Docs phishing site using data: URI

All of the attacks use Base64-encoded data URIs, rather than human-readable plain text, making it harder for people, simple firewalls and other content filters to detect the malicious content.

Most phishing sites are hosted on compromised websites, but can also be seen using purpose-bought domain names and bulletproof hosting packages that have been paid for fraudulently. However, fraudsters can take advantage of open redirect vulnerabilities to "host" these malicious data URIs without the need for conventional web hosting.

This situation is ideal for scenarios such as malware delivery and social engineering attacks where no subsequent client-server interaction is required, but phishing sites still need some way of transmitting their victim's credentials to the fraudster. Most phishing attacks that use data URIs resort to the traditional method of transmitting stolen credentials, i.e. POSTing them to a script on a remote web server. However, with no obvious phishing content being hosted on the remote web server, such scripts could be more difficult for third parties to take down; and as long as they remain functional, each one can continue to be used by any number of data URI attacks.

Another interesting example which impersonated an eBay login page is shown below. If a victim is unfortunate enough to fall for this particular phishing attack, his credentials will be transmitted to a PHP script hosted on a compromised web server in Germany.

eBay phishing site using a data: URI

This demonstrates an interesting deficiency in Google Chrome: If the data URI is longer than 100,000 characters, then none of the Base64-encoded data within the URI will be displayed in the address bar. Rather than truncating the URI, Chrome's address bar will only display the string "data:".

This behaviour could make it more difficult for wary victims to report such attacks. Although the victim is viewing an eBay phishing page, if he tries to copy the URI from the address bar in Chrome, the clipboard will still only contain the string "data:".

The Netcraft Extension provides protection against the redirects used in the phishing attacks above, and Netcraft's open redirect detection service can be used to identify website vulnerabilities which would allow fraudsters to easily redirect victims to similar phishing content.

Bitcoin phishers get desperate with search engine ads

More than a week after we reported deceptive search engine ads being used in Bitcoin wallet attacks, fraudsters are still using Bing ads to trick Blockchain users into visiting phishing sites — but this time, the ads are using some crude social engineering ploys.

Searching for "blockchain" on bing.com currently displays the following pair of phishing ads at the top of the search results:

"Other ads are all phishing site" – click this one!
(Page requested at 12:15 BST, 2nd July 2014)

The first ad begs the user to "click this one" and warns that all other ads are phishing sites, but clicking on the ad actually sends the victim to a Blockchain phishing site, where he is prompted to enter his identifier and password. This phishing site is hosted in a subdirectory on a compromised website, which belongs to a web development outsourcing company in India.

Similarly, the second phishing ad warns that the other one is a phishing site; however, the fraudster behind this ad has made a mistake. When a victim clicks on this ad, it will try to send him to blockchain.lnfo (.LNFO). This link won't work because the .lnfo top-level domain does not exist, and probably never will, because as the fraudster has so perfectly demonstrated, it could easily be confused with .info.

As we saw in previous attacks, the green display URLs shown in these ads are carefully chosen by the fraudster to look similar to the real Blockchain website, which uses the blockchain.info domain. Neither of the display URLs accurately reflect the actual location reached after clicking on the ads. Also, the blue link text on the second ad uses an i-acute character in place of the "i" in Blockchain, presumably to make it harder to detect misuse of the Blockchain brand.

The fact that these phishing ads are trying to discredit each other suggests that there are multiple Bitcoin fraudsters competing for click-through traffic on sites which display Bing ads. These phishing ads also appear on other search engines which use the Yahoo Bing ad network, such as Yahoo and DuckDuckGo.

A phishing ad displayed on the privacy-conscious DuckDuckGo search engine.

Steam phishing attacks exploiting look-alike domain names

An ongoing series of phishing attacks against the Steam gaming community is making effective use of look-alike domains to trick users into surrendering their usernames and passwords. The fraudsters behind these attacks then attempt to bypass Steam's two-factor authentication with a malicious executable that is deceptively named SteamGuard.exe.

One of the many look-alike domains involved in the attacks against steamcommunity.com

Victims are being targeted through Steam's own chat client, giving fraudsters the opportunity to spear phish accounts which are known to contain valuable tradable items. Since the inception of Steam Trading, it has become easier to monetize stolen accounts by selling the victim's virtual items to other Steam users.

Fraudsters are using Steam's own chat client to lure victims to phishing sites.
These sites use deceptive domain names, designed to look similar to the real steamcommunity.com.

If a targeted Steam user is persuaded to click on one of these links, he will be taken to a fake Steam profile. The following example shows another of these fake profiles on a similar look-alike domain. Profiles used in these attacks may appear to offer rare or unusual tradable items, and the high level and displayed XP score lends some degree of trustworthiness to potential trades.

The fake profile offers some attractive items up for trade.

To further entice the victim into trading with the fraudster, the fake profile also includes fabricated feedback which enhances the fraudster's reputation as a fast and reliable trader.

However, the fraudster is not intending to trade any items with his victim — he instead wants to gain access to the victim's account, and then steal the victim's own tradable items. When the victim clicks on the "Add Friend" button, he will be presented with a spoofed login form on the look-alike domain that requests his Steam username and password:

The stolen username and password will not be of much use to the fraudster if the victim has enabled Steam Guard. This two-factor authentication mechanism is enabled by default if the victim has a verified email address and has restarted Steam at least twice since verifying the address. If Steam Guard is enabled, the fraudster will be unable to access his victim's Steam account without entering an access code which is emailed only to the victim.

Bypassing Steam's two-factor authentication (Steam Guard)

Older Steam phishing sites simply asked the victim for their access code, but this approach is no longer suitable for trade fraudsters: there is now a time-delay before the trading feature can be used from a new device, which gives the victim an opportunity to recover his compromised account before any items can be traded by the fraudster.

Steam phishing sites consequently evolved to ask their victims to upload a special ssfn file. This file is located in the victim's Steam folder and acts as an authentication key, so that after providing a valid access code, the user does not have to keep on requesting and entering a new access code every time they launch Steam. If this file is copied to the fraudster's computer, he will be able to bypass the two-factor authentication mechanism and gain access to the victim's account.

The Steam phishing sites used in these latest attacks have evolved further still. Rather than tricking the victim into uploading the ssfn file, the phishing sites now display the following dialog box which prompts the victim to install a "special tool":

Unsurprisingly, this special tool is actually malware designed to find and upload the victim's ssfn file to the fraudster. The SteamGuard.exe file used in this particular attack is hosted on Google Drive, and submits the victim's ssfn file to a hard-coded URL on the phishing site it was originally downloaded from.

After the fraudster has been furnished with the victim's username, password and ssfn file, he will be able to login to the account and begin trading immediately.

Constant stream of look-alike domains

Since the start of May, more than a hundred look-alike domains have been registered specifically for the purpose of Steam phishing. More than a third of these phishing sites have been hosted in Russia, and many of the domains have also been registered to individuals with Russian addresses and email addresses at yandex.ru, a free webmail service.

Some of the 100+ look-alike domain names that have been registered for Steam phishing since May.

Most of the domains used in these attacks have been registered under the .com top-level domain. One notable counterexample is steamcommunity.cm, which uses the country code top-level domain for Cameroon. As well as being used in spear phishing attacks via Steam's chat client, it is likely that this particular phishing site could also have also received typo-traffic from Steam users.

More generally, the .cm ccTLD offers tremendous typosquatting opportunities against any corresponding .com domain. The domain's operators received criticism in the past when it wildcarded the entire .cm domain. It no longer does this, but there is evidently nothing stopping fraudsters from registering a .com domain's corresponding .cm domain anyway.

Using an "unusual hat" as a lure to visit the steamcommunity.cm phishing site.

Monetizing stolen Steam accounts

Albrecht Neumann, a mathematics student in Germany, is an active Steam trader who has reported some of these phishing attacks to Netcraft. He suspects the fraudsters are automatically searching trading portals for people who are offering to sell expensive items, and are then sending messages to those users via Steam: Each time he "bumps" a thread in which he is offering expensive items, he gets up to five new friend requests.

Neumann told Netcraft that keys and earbuds are a primary target for trade fraudsters, as these items serve as a relatively stable currency in the Steam economy, and are easy to turn into real money. Earbuds are cosmetic items which can be worn by a player's in-game character, and were given away to Mac OS X users who played Team Fortress 2 during a limited time period in 2010; but now they can only be obtained through trading. Some users stockpile these items in the hope that their value might increase and earn them a profit further down the line. Such items are valuable by virtue of their rarity, and can often be sold for $30-$40 each, making some accounts worth thousands.

All of the domain names used in these attacks were very similar to the real steamcommunity.com domain. Netcraft's Fraud Detection service helps brand owners pre-emptively identify these types of fraudulent domain registrations. Some of the domains were registered months before the attacks actually took place, which would have allowed plenty of time to get them shut down before they were misused. Domain registrars are in a position to nip this in the bud even earlier — they can use Netcraft's Domain Registration Risk service to prevent their customers from registering domain names which are deceptively similar to well known phishing targets.

Deceptive search engine ads used in Bitcoin wallet attacks

Fraudsters are exploiting loopholes in the presentation of ads by major search engines in order to lure victims to phishing sites. Searching for "blockchain", the name of a popular Bitcoin wallet provider, caused deceptive ads to be displayed at the top of search results pages from Google, Bing, Yahoo, and DuckDuckGo. In contrast to the traditional approach of sending emails indiscriminately, links to phishing sites in search engine ads may be much more convincing, especially when the domain they are impersonating is displayed as the destination.

With more than 1.7 million wallets, Blockchain.info is the most popular online Bitcoin wallet. Blockchain's My Wallet service allows users to send and receive payments in Bitcoins. When signing up, users are reminded that they must remember their passwords, as forgotten passwords cannot be recovered and will result in the loss of all Bitcoins stored in the wallet. These passwords are exactly what the fraudsters are after.

Phishing ads in Bing's search engine results. Screenshot taken on 19 June 2014 at 10:16 BST.

The above screenshot shows the results of searching for "blockchain" on Bing. The first link on the page is an ad, supposedly for the official Blockchain wallet service at Blockchain.info. However, clicking on this link actually takes victims to a phishing site under blockchaino.info (note the additional 'o' character).

Bing! There go your coins.

The phishing site at blockchaino.info immediately prompts a victim to enter his identifier and password, whereas the real Blockchain website only prompts for the user's identifier. Blockchain's security recommendations make it clear that the real Blockchain.info will never ask you for your password: "We NEVER need it and we NEVER want it". As soon as the fraudster has tricked the victim into giving up the required information, they "sweep the funds away".

This type of attack is likely to be extremely effective, as the ad displays the same domain name as the site it is targeting, and it is the first link to appear in the search engine results page. Some users may not realise that it is an ad, and instead believe that it is the top organic result. Showing the wrong display URL (green text) is forbidden by most ad networks' policies; however, the fraudsters have evidently managed to bypass these restrictions. Without strict enforcement, the ability to specify the displayed destination leaves such advertising open to fraud.

However, strict enforcement of destination URLs may alienate a search engine's customers — advertisers may use third-party services to manage their advertising and track clicks. These customers will rely on being able to display the final URL despite redirecting via a third-party service before reaching the target site. The use of redirects makes enforcement of any display policy difficult, as there is no guarantee that the target of the redirect will remain constant after the ad has been approved, or that the redirects presented to the search engine are the same as those presented to end users.

Another phishing site advertising at the top of Bing.

Other Bing ads directed victims to different Blockchain phishing sites, all of which used deceptive hostnames such as blockchain-info.itconflux.com, blockchain.info.pl and bllockchain.info.pl, but did not use the display domain of the site they were impersonating, blockchain.info.

It's not just Bing's search engine that has been affected by this phishing campaign. The search ads displayed at the top of Bing search results can appear anywhere on the Yahoo Bing Network. This means that the same fraudulent ads also appear when a victim searches for Blockchain on Yahoo.com. Similar phishing ads are also displayed on the DuckDuckGo search engine, which syndicates its sponsored links from the same network.

The same phishing ads appear on a Yahoo search for "blockchain".

And it is not just the Yahoo Bing ad network which is being exploited by phishers — search giant Google displayed the following phishing ad on its search results pages:

This Google phishing ad directed victims to blockchain-info.itconflux.com.

However, it's not necessarily game over if a victim's password has been stolen. If a Blockchain user has chosen to enable two-factor authentication via SMS, Yubikey or Google Authenticator, the fraudster will be unable to access the wallet at a later date unless he also has access to the victim's physical two factor authentication device (e.g. phone or Yubikey).

All of the sites involved in these attacks against Blockchain were blocked in Netcraft's phishing site feed, which allows third-party developers to integrate anti-phishing services into their products. Some of the domain names used in these attacks were very similar to the real blockchain.info domain. Netcraft's Fraud Detection service helps brand owners pre-emptively identify these types of fraudulent domain registrations, giving an opportunity to take action against the registrants, possibly before the attacks have even started.

Criminals launch mass phishing attacks against online dating sites

Criminals are running massive dedicated phishing campaigns against online dating sites, marking an interesting – but not unusual – shift in focus from the traditional phishing targets such as banks and other financial institutions. The most recent attack used a single compromised website to host hundreds of fraudulent PHP scripts, most of which were designed to steal usernames and passwords from users of the most popular dating sites.

The online dating sites targeted by the latest attack include match.com, Christian Mingle, POF (PlentyOfFish), eHarmony, Chemistry.com, SeniorPeopleMeet, Zoosk, Lavalife, amongst others. Only eight of the 862 fraudulent scripts on the server targeted banks.

It is likely that the criminals who steal accounts on these sites will go on to use them to commit online dating fraud — many dating sites only allow messages to be exchanged with other users after a subscription fee has been paid; by compromising existing paid accounts, the fraudsters can reduce their traceability by avoiding the need to make payments.

Part of one of the fraudulent scripts

Online dating fraud is often orchestrated by criminal gangs who use fake profiles to trick victims into developing long distance relationships. Once the fraudsters have gathered enough sympathy and trust from a victim, they will exploit this by claiming they need money to pay for travel costs, or to afford medical treatment for a family member. After the money has been stolen, the criminals will make up further reasons why they need more money. In some cases, the fraudsters blackmail their victim into sending money - if the victim has sent any explicit photos or videos to the criminals, they may threaten to send them to the victim's friends and family.

The amount of money involved in these scams can be considerable. In 2011, a woman in Britain was tricked into sending more than $59,000 to a pair of fraudsters who pretended to have inherited millions of dollars from a military friend in Nigeria. The fraudsters - who were actually a mother and daughter in America - managed to net more than a million dollars before being jailed in 2013.

While many online dating sites take measures to identify fake profiles, phishing for genuine established accounts gives fraudsters the edge. If a legitimate profile has been in active use for several months without cause for concern, then compromising this profile will allow the fraudster to benefit not just from the plausible appearance of the profile, but also take over several ongoing conversations. The real owner of the hijacked account will have already done the hard bit by establishing dialogues with other members on the site, possibly gaining enough trust to allow the fraudsters to strike immediately with success.

The latest attacks make use of a phishing kit which contains hundreds of PHP scripts, configured to send stolen credentials to more than 300 distinct email addresses. More than half of these addresses used the yahoo.com domain, while gmail.com was the next most common choice. Although most of the fraudster's scripts target online dating sites, some of them are also designed to steal credentials from users of these webmail platforms. Email accounts are often shut down after the provider notices they have been used for fraudulent purposes, so ensuring a fresh supply of compromised accounts gives fraudsters the opportunity to send even more phishing emails before the accounts get closed.

The phishing kit contains over 300 PHP scripts, most of which target online dating sites.

An attacker would typically deploy the phishing kit by uploading a zip file to a compromised web server and unzipping the tree of contents into a writable directory. Similar kits uploaded over the past few months have used various file names, such as moving.zip, send.zip, orokionline.zip, amioroki.zip and samoroki.zip. Each script within these kits is very similar in terms of functionality — they simply collate a set of POST parameters into the body of an email message, and then send it to two or more email addresses. The subject of the email is modified to describe what type of credentials are in the email (e.g. "MATCH ID & PASSWORD"), and after the emails have been sent, the victim is redirected to an appropriate URL on the target website, such as http://www.match.com/login/login.aspx?lid=2.

Each compromised server which hosts these scripts acts merely as a "dropsite" in the fraudsters' phishing campaigns. Rather than displaying any phishing content, the server simply accepts values that have been submitted from elsewhere, such as a form hosted on another website or within a phishing email. The victim is then immediately redirected to the legitimate website, most likely without realising that his credentials have just been transmitted to a different website.

Some of the scripts are also designed to steal credentials from Photobucket users, possibly so the fraudsters can host photos and other images to further their scams. It is not unusual for fraudsters to encourage their victims to migrate to instant messaging software or even text messages instead of continuing to chat on a dating site, which could be monitored to prevent such fraud.