Android malware radically dominant

 

Image

A new report from Pulse Secure shows that 97% of mobile malware is targeted at the Android OS. Why does Android remain so dominant? What can you and your company do to reduce the risk of infection?

The report also shows that the overwhelming majority of Android malware is being developed and distributed by third party app stores in the Middle East and Asia. Another reason these findings skew so heavily towards Android could be how intensely regulated and locked down iOS is, which, beyond being jailbroken, is very difficult to install third party apps on. The colossal user base, open-source nature and ease with which almost anyone can install third-party apps and app stores could also contribute to the majority of malware being Android based. As Mark James, ESET IT security specialist, explains “the Android user has a much bigger opportunity to download aps from unknown or insecure markets it’s bound to have an impact on its security.”

How can you avoid mobile malware?

“If you’re sticking to the official app stores and limiting what you do and do not install then you will be fairly safe,” there are always risks involved and often minimising them as much as possible is the only way forward.

“Always download your apps from the official Google Play Store, if you have to download an APK from an external source make sure you do some research and ensure its safe.”

“Always where possible read the reviews for the app you’re downloading and check the permissions that the app requires; limiting what you download and what is installed on your phone will help to keep you and your device safe.”

It’s also worth mentioning that you have a look through the options once an app is installed: often location tracking and other features that gather your personal information can be disabled.

“Installing security software that can not only scan for malware but manage app permissions is a must, most of these will also provide anti-theft measures to track your device in case it’s lost or stolen.”

Last but certainly not least: BYOD policies should always limit what you install and where you install it from; this should be the basic requirement in protecting your work environment.”

ESET Regularly Releasing Updates to Products

[SCM]actwin,0,0,0,0;http:// ESET Shop - Google Chrome chrome 17.01.2013 , 14:57:35

At ESET, we adapt rapidly to the ever changing security environment, by regularly releasing updates to enhance our products and services. It is important that our users keep their security software up-to-date to ensure maximum protection.

We always take any reported issues seriously and our core technology team is continuously making improvements for our customers, delivering the updates automatically to make the security experience as smooth and safe as possible.

Recently Google’s Project Zero Team reported some vulnerabilities and fixes were implemented immediately. They have reported two vulnerabilities to us in the last 10 days. The first of them on June 19th, 2015, and the second on June 26th, 2015. In both cases, the issues were solved in less than 3 days, over a weekend. We made sure the fixes were available automatically to every customer, both businesses and home users, through the regular security updates of our products.

„Protecting customers is our top priority, therefore we continually update and improve our products, “said Juraj Malcho, Chief Research Officer at ESET. „We greatly value the commitment to responsible disclosure and collaborative nature of the IT security industry.“

ESET develops award-winning security software trusted by over 100 million users. Our industry leading security product portfolio is regularly recognized by a variety of independent testing organizations such as Virus Bulletin, AV-Comparatives, as well as IT media and customers.

More information about the ESET automatic product updates

ESET products are automatically updated several times a day to include the latest detection algorithms as well as scanning enhancements. If you want to make sure this is working correctly in your system, please check the following article in our Knowledge Base: http://kb.eset.com/esetkb/index?page=content&id=SOLN85

Both vulnerabilities have been fixed by ESET using this update system. The first one, with the update #11824, and the second with the update #11861.

Dino – the latest spying malware from an allegedly French espionage group analysed

In this blog we describe a sophisticated backdoor, called Dino by its creators. We believe this malicious software has been developed by the Animal Farm espionage group, who also created the infamous Casper, Bunny and Babar malware. Dino contains interesting technical features, and also a few hints that the developers are French speaking.

Animal Farm is the security industry’s name for a group of attackers first described by Canada’s Communications Security Establishment (CSE) in a set of slides leaked by Edward Snowden in March 2014. In those slides CSE assess with “moderate certainty” that this group is a French intelligence agency. Since then, several examples of malware created by Animal Farm have been found and publicly documented, in particular:

The connection between those pieces of malware and the group described in CSE slides has been convincingly established, for example by Paul Rascagnères (G Data).

In this blog post we add a new piece to the puzzle with Dino, another malicious program belonging to Animal Farm’s arsenal.

Introduction

The sample of Dino documented in this blog post was used in 2013 against targets in Iran. The original means of infection is unknown, though we believe Dino was installed by another program, as it contains an uninstallation command without the corresponding installation procedure. Given the set of commands it can receive, Dino’s main goal seems to be the exfiltration of files from its targets.

The binary’s original name, “Dino.exe”, has been left visible by its authors, as was the case with Casper. Dino – which could be referring to the pet character from The Flintstones cartoon show – was already mentioned in a recent Kaspersky blog as a “full-featured espionage platform,” but no technical analysis has been published yet.

Roughly, Dino can be described as an elaborate backdoor built in a modular fashion. Among its technical innovations, there is a custom file system to execute commands in a stealthy fashion, and a complex task-scheduling module working in a similar way to the “cron” Unix command. Interestingly, the binary contains a lot of verbose error messages, allowing us to see Dino’s developers’ choice of wording. Also, a few technical artefacts suggest that Dino was authored by native French speakers.

Dino Basics

Modules List

Dino has been developed in C++ and presents a well-defined modular architecture. The following array lists the modules contained in this Dino binary; the module names are those assigned by the developers.

Module Name Module Purpose
PSM Encrypted on-disk copy for Dino modules
CORE Configuration storage
CRONTAB Task scheduler
FMGR File upload and download manager
CMDEXEC Command execution manager
CMDEXECQ Storage queue for commands to execute
ENVVAR Storage for environment variables

Data Structure

Dino heavily relies on a custom data structure named “DataStore” by the Animal Farm developers. In particular, all Dino’s modules store their content inside this structure, making its understanding one of the keys to analyzing Dino.

A DataStore is a map from string keys to values of 8 possible types, such as integers or strings. The implementation of this data structure is based on a hash table. It means that to retrieve the value associated with a key, one has to calculate the hash of the key to locate a bucket from which the value can be retrieved.

Dino’s hash is a one-byte value calculated with a series of XOR operations on the key, and each bucket starts a linked list containing key/value pairs. The code responsible for retrieving the value associated with a key is shown in Figure 1.

1_DataStore_Searchforkey-1

Finally, DataStore objects can be serialized in a custom format, which begins with the magic word “DxSx”. This is used in particular by the PSM module to save the content of Dino modules in an encrypted file. More precisely, when a modification is made to a module’s content in memory, the PSM module saves it as a serialized DataStore. When Dino restarts, the module is deserialized from the file and loaded into memory. Funnily enough, the key serving to encrypt the file on disk is “PsmIsANiceM0du1eWith0SugarInside”.

Configuration

Dino’s configuration is initially stored in a serialized DataStore object contained in a zip archive at the end of the Dino binary. At runtime this object is deserialized and stored inside the CORE module. We can list the configuration’s content with Dino’s “conf –l CORE” command – described later – which displays on separate rows each key’s name, its associated value and the type of this value:

Started:5523F782 QWORD
InitialWaitDone:00000001 DWORD
InteractiveDelay:00000005 DWORD
MaxNothingSaidCount:00000078 DWORD
InstallDate: 5523F782 QWORD
fields:78537844…[REDACTED]…66B3900 BYTES
recID:11173-01-PRS WIDESTR
Version:1.2 WIDESTR
BD_Keys: 4D41474943424F58…[REDACTED]…9EB3506 BYTES
CC_Keys: 4D41474943424F58…[REDACTED]…0000000 BYTES
MaxDelay:00000E10 DWORD
ComServer0:hXXp://www.azhar.bf/…[REDACTED]…/postal.php STR
ComServer1:hXXp://www.rsvniima.org/…[REDACTED]…/din12/postal.php STR
ComServer2:hXXp://www.azhar.bf/…[REDACTED]…/postal.php STR
ComServer3:hXXp://www.rsvniima.org/…[REDACTED]…/din12/postal.php STR
ComServer4:hXXp://dneprorudnoe.info//…[REDACTED]…/postal.php STR
ComServer5:hXXp://dneprorudnoe.info//…[REDACTED]…/postal.php STR
ComServer6:hXXp://dneprorudnoe.info//…[REDACTED]…/postal.php STR
NextSendReceive:5CC33097FB72D001 BYTES
CC:000064F7-72E4-3F7D-C817-474D-A9BDBDF7 STR
DaysOfLife:00000000 DWORD
GUID:12FEB4A9EEDEE411B283000C29FD2872 BYTES
InitialDelay:00000000 DWORD
now:5523F78E QWORD
hash:A88E8181CA5CE35AE70C76145DFB820D BYTES
InitialCommands:78537844…[REDACTED]…000000 BYTES
xT0rvwz:DC188352A…[REDACTED]…00000 BYTES
tr4qa589:K/[RAFtIP?ciD?:D STR
jopcft4T:a.ini WIDESTR

While most of the keys have self-explanatory names, we would like to focus on the following keys:

  • “recID”: Animal Farms binaries contain an ID whose decimal value appears to identify the target, “11173-01-PRS” in this case. For example Casper used an “ID” value set to “13001”, whereas some Babar samples used “12075-01” and “11162-01”. We do not know the meaning of the “PRS” suffix added in the case of Dino.
  • “ComServer”: These keys contain the command and control (C&C) servers’ URLs. All the URLs were down when we started our analysis. Those C&Cs were compromised legitimate websites, which is standard operating procedure for Animal Farm.
  • “Version”: Dino’s code version; here set to “1.2”, which is confirmed by the “din12” folder used in one of the C&C URLs. For the record, a “d13” folder has been seen on another Animal Farm C&C (see “3.7 Calling home” of Marschalek’s Babar report), indicating that Dino version 1.3 has also likely been deployed at some point.
  • “BD_Keys” and “CC_Keys” contain cryptographic keys to encrypt the network communications with C&C servers. Their values start with the word “MAGICBOX”.
  • The three last keys are displayed with obfuscated names (“xT0rvwz”, “tr4qa589” and “jopcft4T”) and store parameters for the custom file system we will describe later.

Commands

The following Table lists the commands accepted by this Dino binary with the names chosen by the developers. Each of those commands can take one or more arguments.

Command Purpose
sysinfo Retrieve reconnaissance information from the machine
killBD Uninstall Dino using the custom file system (see ramFS description below for details)
! Execute Windows batch command passed as a parameter
cd Change the current work directory
pwd Retrieve the current work directory path
dir List files in a given directory with various additional information
set Set or remove environment variables stored in the ENVVAR module
conf Display or update module content
search Search for files whose names match given patterns. The files found are packed in an archive, which is then scheduled for upload to the C&C using the FMGR module.
archive Create an archive from given file paths
unarchive Unpack an archive to a given location
download Schedule a file transfer to the C&C using the FMGR module
cancel Remove the next file transfer scheduled in the FMGR module
cancelall Remove all scheduled file transfers in the FMGR module
cronadd Schedule a command to be executed at a certain time by the CRONTAB module (see CRONTAB description below for details)
cronlist List registered entries in the CRONTAB module
crondel Remove an entry in the CRONTAB module
wakeup Schedule a wake-up of the malware after a certain amount of time using the CRONTAB module
restart N/A: the command is actually not implemented
showip Display the public IP of the infected machine
cominfos Display information about the currently used C&C server
comallinfos Display information about all known C&C servers
wget Download a file from the currently used C&C server onto the machine
delayttk Delay the de-installation of the malware, if scheduled

One command of particular interest is “search”, which allows the operators to look for files very precisely. For example, it can provide all files with a “.doc” extension, the size of which is bigger than 10 kilobytes, and that were modified in the last 3 days. We believe this exfiltration of files to be Dino’s end goal.

At startup Dino executes successively the commands stored in the “InitialCommands” field in its configuration; in the sample we analyzed they are:

sysinfo
cominfos
!ipconfig /all
!ipconfig /displaydns
!tracert www.google.com

Those commands serve as a reconnaissance step for the operators. Their execution is managed by the CMDEXEC module, the commands being stored in a queue inside the CMDEXECQ module. The result is reported to the C&C server.

After having described Dino’s basics, we are now going to dig into two particularly interesting components; first, a custom file system used by the malware, and then the CRONTAB module in charge of task scheduling.

RamFS: A Temporary File System

Dino contains a custom file system named “ramFS” by its developers. It provides a complex data structure to store files in memory, each of them bearing a name corresponding to filenames used by usual file systems. RamFS also comes with a set of custom commands that can be stored in files and executed. It should be noticed that ramFS is also present in other Animal Farm binaries (see attribution paragraph below), but since we are unaware of previous analysis of ramFS, we are describing our findings here.

Architecture

RamFS content is initially stored encrypted in Dino’s configuration under the key “xT0rvwz”, whereas the corresponding RC4 key is stored under the key “tr4qa589”. Once the file system has been decrypted, it is stored in memory as a linked list of 512-byte memory chunks, each one of them being individually RC4-encrypted. When looking for a file in ramFS, each chunk is decrypted, processed and then re-encrypted. Hence there are very few noticeable traces of ramFS during its use.

Here are some high-level characteristics of this file system:

  • File names and file content are encoded in Unicode
  • File names length is limited to 260 characters
  • Once decrypted, file content is manipulated as chunks of 540 bytes
  • There is no metadata associated with the files

We could not find an existing file system matching the memory structures and the characteristics of ramFS, and therefore we believe this file system to be an original creation of the Animal Farm group.

Commands

Several commands can be executed in the context of ramFS, as listed in the following Table.

Command Meaning
CD Change the current work directory on the real file system
MD N/A: the command is actually not implemented
INSTALL Installation or de-installation of Dino, in Windows registry and/or as a service
EXTRACT Extracts a file stored in ramFS onto the machine
DELETE Deletes a file stored on the machine
EXEC Executes a file stored in ramFS
INJECT Injects a file stored in ramFS into a running process
SLEEP Sleeps for a given amount of time
KILL Terminates a running process
AUTODEL N/A: the command is actually not implemented

Usage of ramFS in Dino

In the case of Dino, ramFS serves as protected storage for one specific file containing the instructions to remove the malware from the machine. The developers named this file the “cleaner” and it is executed when Dino receives the command “killBD” (the “BD” acronym is the developers’ designation of the malware).

Figure 2 shows the code responsible for executing this cleaner file. First, it retrieves the name of the file from Dino’s configuration (“a.ini”), then it retrieves the key to decrypt ramFS, and it finally mounts the file system in memory in order to execute the cleaner file stored inside. The verbosity of the error messages makes it particularly easy to understand the purpose of the code.

2_cleaner_file

The cleaner file contains the string “INSTALL -A “wusvcd” -U” which, once executed, will uninstall the malware from the machine – “wusvcd” being the name used to register Dino on the machine.

Hence, ramFS serves as a protected container for files to be executed on the machine, offering a disposable execution environment to the operators and leaving very few traces on the system.

Tasks scheduling in a Unix fashion

The commands “cronadd”, “cronlist” and “crondel” serve respectively to add, list, and remove scheduled tasks registered in the CRONTAB module. Those tasks are Dino’s commands.

The syntax to define scheduled tasks is similar to the one used by the cron Unix command. In particular the time at which to run a command is given by a string following the format “minute hour day month year dayofweek”. Alternatively, this string can be replaced by “@boot” for a command to run at each startup – whereas some Unix cron implementations accept “@reboot”.

As an example, here is the output of the “cronlist” command after a “wakeup” command has been scheduled to run on 7th April 2015 at 15:44:

Screen Shot 2015-06-29 at 3.13.43 PM

As we can see, each entry is identified by an “Id”, an incrementing hexadecimal number starting at 0xC0. The purpose of the “Local” field remains unclear (the other possible value being “-l”). The “Count” parameter counts the number of times a command has been executed, “-1” indicating the command will be executed only once. Finally, the “Visibility” field defines whether the command execution will be reported to the C&C (the other possible value being “Silent”).

Attribution

Dino Belongs To The Farm

The amount of shared code between Dino and known Animal Farm malware leaves very little doubt that Dino belongs to Animal Farm’s arsenal. Among these shared features, we can cite the following:

  • At the very beginning of Dino execution, the current process name is checked against process names used by some sandboxes:

3_CheckSandbox

A very similar check (against “klavme”, “myapp”, “TESTAPP” and “afyjevmv.exe”) is present in Bunny samples, and in some first-stage implants deployed by Animal Farm.

  • To hide its calls to certain API functions, Dino employs a classic Animal Farm ploy: a hash is calculated from the function’s name and used to look for the address of the API function. The actual hashing algorithm used in Dino is the same that was used in Casper, namely a combination of rotate-left (ROL) of 7 bits and exclusive-or (XOR) operations.
  • The Dino’s custom file system – the so-called ramFS – is present in several droppers used by Animal Farm. In those binaries the file system serves to set the persistence of the payload. For example, here is the command executed by some NBOT droppers in the context of ramFS:

2

  • As a final indication that Dino belongs to Animal Farm menagerie, it is noticeable that the output of Dino’s sysinfo command looks like an updated version of the “beacon” from the SNOWBALL implant described in the leaked CSE slides – part of operation SNOWGLOBE, which led to the discovery of Babar:
Dino’s sysinfo example output
Login/Domain (owner): Administrator/JOHN (john)
Computer name: JOHN
Organization (country):  (United States)
RecId: 11173-01-PRS
MaxDelay: 3600
Version: 1.2
OS version (SP): 5.1 (Service Pack 3)
WOW64: No
Default browser: firefox.exe
IE version: Mozilla/4.0 (compatible; MSIE 7.0; Win32)
First launch: 04/01/2015 – 18:31:14
Time to kill: N/A
Last launch : 04/01/2015 – 19:21:44
Mode: N/A  |  Rights: Admin  |  UAC: No
ID: 4635BEF0-D89D-11E4-B283-000C-29FD2872
InstallAv: 0
Inj: Yes
SNOWBALL implant beacon

4_SNOWBALL_BEACON

All these indicators together make us very confident that Dino was developed by the Animal Farm group.

French speaking Developers

Dino adds at least two more indicators to those already documented suggesting that Animal Farm developers are French speaking:

  • Dino’s binary contains a resource whose language code value is 1036. The original purpose of this language code is to allow developers to provide resources (menus, icons, version information…) for different locations in the world in the corresponding language. Interestingly, when a developer does not manually specify the language code, the compiler sets it to the language of the developer’s machine. So, which language corresponds to the value 1036, or 0x40c in hexadecimal? French (France).

Of course a non-French speaking developer could have deliberately set this value to mislead attribution efforts. But in more recent Animal Farm binaries (for example Casper), this language code has been set to the classical English (USA) language code. Therefore, it seems that Animal Farm developers forgot to set this value in their first creations, realized their mistake at some point, and decided to set a standard value. Someone using the language code as a false flag would have likely kept the strategy going.

For the record, this Dino sample is not the only Animal Farm binary with 1036 as language code.

  • Dino’s binary is statically linked with the GnuMP library, which is used to manipulate big numbers in cryptography algorithms. The GnuMP code in Dino contains file paths coming from the developer’s machine:
..\..\src\arithmetique\mpn\mul.c
..\..\src\arithmetique\printf\doprnt.c
..\..\src\arithmetique\mpn\tdiv_qr.c
..\..\src\arithmetique\mpn\mul_fft.c
..\..\src\arithmetique\mpn\get_str.c

As the attentive reader has probably guessed, “arithmetique” is the French translation of “arithmetic”.

Conclusion

Dino’s binary shows an intense development effort, from custom data structures to a homemade file system. As with other Animal Farm binaries, it bears the mark of professional and experienced developers.

But Dino also shows a poor knowledge, or interest, from these developers in anti-analysis techniques – contrary to what was seen in Casper – as demonstrated, for example, by the verbosity of some Dino’s log messages:

3-2

All those messages provide substantial help in understanding Dino’s internal workings. One will also appreciate the numerous misspellings contained in the messages.

Regarding Dino’s victims, we know very little except that they were located in Iran in 2013. This is in accordance with the victimology described by Canada’s CSE in its presentation:

5_victimology

That leads us to the final point of this blog: several signs suggest that Dino’s creators are French speaking developers. These signs add to the pretty long list of indicators already supporting this hypothesis, in particular the ones mentioned by Canada’s CSE.

Indicators of Compromise

Indicator Value
Sample SHA1 BF551FBDCF5A982705C01094436883A6AD3B75BD
C&C URL hXXp://www.azhar.bf/modules/mod_search/found/cache/postal.php
C&C URL hXXp://www.rsvniima.org/templates/rsv/icons/din12/postal.php
C&C URL hXXp://dneprorudnoe.info/sxd/lang/i18n/charcodes/postal.php
Path C:\Program Files\Common Files\wusvcd\wusvcd.exe
Default storage file names C:\Program Files\Common Files\wusvcd\wusvcd00000000-0000-0000-0000-0000-00000000.{dax,dat,lck}
Downloaded file name extension .tmp_dwn
Registry key Software\Microsoft\Windows\Windows\CurrentVersion\Run\wusvcd

by Joan Calvet, ESET

UK Companies Commonly Held Hostage by Hackers

Ransom

ESET study reveals that 84 percent of companies would be crushed if infected by ransomware and 31 percent would have no choice but to pay the hackers.

Over a third of UK companies have either personally been held to ransom by hackers or know someone that has had their networks infected by ransomware, a new study from ESET has revealed.

The study, which was carried out at Infosecurity Europe in June 2015 and examined the attitudes 200 security professionals, also revealed that 84 percent of respondents believe that their company would be seriously damaged if it was ever infected by ransomware. However, 31 percent of respondents admitted that if they were infected by ransomware they would have no choice but to pay the fine because the alternative would mean losing all the data on their computer.

Ransomware is one of the most frightening types of malware due to its destructive power. The attack involves someone’s computer screen being replaced by a message that appears to be from the police, demanding money, or a message saying your files are lost unless you pay a ransom to unlock them. Over the last year cyber criminals have developed a number of new ransomware variants which have allowed hackers to encrypt their victims’ data, which has forced more people to pay the ransom.

IT security professionals still do not understand how to properly deal with ransomware. With all ransomware infections the biggest problem is the decision on how to deal with the attack. The options are limited to either paying the ransom, which is definitely not recommended, or restoring from backup, however depending on how often the files are backed up, this can mean losing a lot of data. Any company that pays the ransom is funding criminals and as long as hackers find ransomware to be profitable, the more effort they will put into building even more sophisticated variants, which will get harder and harder to remove.

by Mark James, ESET UK

Phone Scams: Increasing Numbers, Wider Scope

A few weeks ago my colleague Stephen Cobb (knowing my interest in research related to fraud and scams, including phone scams) drew my attention to a section in the *Consumer Sentinel Network Data Book for January-December 2014 that pointed to a rise in the percentage of fraud complaints about phone scam calls over the period 2012 to 2014. The data concerning ‘Fraud Complaints by Company’s Method of Contacting Consumers’ indicate that the percentage of phone scam complaints rose from 34% in 2012 to 54% in 2014, whereas the percentage of complaints about scam emails dropped from 37% in 2012 to 23% in 2014.

Interestingly, complaints about scams initiated via ‘Internet – Web Sites\Others’ rose from 12% to 15% in 2013 and dropped again to 11% in 2014. Maybe three years isn’t long enough to draw too many conclusions, and in any case the percentage of people who actually report the initial method of contact has dropped over the same period from 55% to 46%. However, one possibility is that the decline in email-related complaints represent at least two factors:

  • A continuing rise in awareness that email is an unsafe channel of communication with a high percentage of maliciously intended traffic.
  • A reflection of the gradual long-term shift from direct malicious content in email to content linked and redirected from a variety of sources (email and other messaging services, social media, DNS hijacking, legitimate but compromised sites, and so on).

The spike and subsequent drop in web-related fraud reports is harder to explain, so I won’t even try. :) But it does seem that phone fraud is getting more attention, and if the higher volume of reports really does reflect a rise in activity – and I have no reason to believe that it doesn’t – maybe that’s because it’s often harder to ascertain the legitimacy of a caller’s phone number (if available at all) than it is the legitimacy of an email. Admittedly, interpreting email headers isn’t always easy, but at least they’re there. Tracing the real source of a phone scam call is something most potential victims are not resourced for, however. And even tech support scams, part-based on trying to get remote access to the victims’ PC, don’t always offer easy attribution to the scammer’s point of origin.

Still, in view of these figures, it doesn’t come as a surprise that a report by Pindrop Security – *The State of Phone Fraud 2014-2015: a Global, Cross-Industry Threat – indicates that ‘more than 86.2 million calls per month in the US are phone scams’. The focus of the report is actually far wider than the direct attacks on individual consumers that the Consumer Sentinel Network data are drawn from, stating that ‘Across financial and retail institutions, 1 in every 2,200 calls is fraud, an increase of more than 30 percent since 2013’ and considering attacks on banks, brokerages, card issuers and retailers. In fact, there isn’t such a clear line between consumer attacks and attackers on these organizations, since stolen credit cards and credit card numbers are very common accessories to an attack on a provider. However – to take an example cited by Pindrop – chargeback fraud takes place when a scammer places an order with a stolen credit card. While the card owner should normally receive a refund from the card issuer if the loss of the card has been reported and the fraudulent charge disputed, the retailer or e-retailer may already have despatched goods for which it will receive no payment.

However, consumer scams are by no means ignored. Pindrop reckons that the top 25 consumer-oriented scams between them account for more than 36 million scams per month in the US, out of a total of 86.2 million. Frequent readers of this blog will probably not be surprised to hear that eight million of these calls are estimated to be tech support scams, while payday loans are close behind at nearly seven million. Among the other top-listed scams are IRS scams, auto insurance scams, home security system scams, and student loan scams. While IRS scam calls are well behind tech support scams at around a million a month, that figure does represent a significant increase in highly profitable scam calls over the last two years, including a particularly effective scam where the callers impersonate IRS agents over the phone and threaten arrest for tax evasion if payment isn’t made immediately.

Pindrop observes that ‘phone fraud rates are essentially the same in all major economically developed countries, especially the U.S. and U.K.’ I won’t try to summarize the whole paper, but it does make some interesting points about the impact of technology in terms of spoofing and VoIP, and the growing use of cell phones.

However, it’s worth noting that there isn’t necessarily an exact correlation between types of scam reported in the US and here in the UK. For instance, various types of UK-targeted Payment Protection Insurance (PPI) scam like these and these may share some characteristics with scams seen in the US, but don’t – as far as I know – have a precise equivalent. Similarly, some UK student loan scams may be significantly different to those commonly reported in the US. And though I still get the occasional tech support scam call here in the UK, the volume of such calls seems to have declined dramatically in recent years.

*Interesting though these reports are, there are some caveats to bear in mind as regards the accuracy of the data:

  • The Consumer Sentinel data are drawn directly from a database of complaints made to the FTC, various law enforcement agencies, other governmental and non-governmental departments, the Council of Better Business Bureaus (on behalf of all North American BBBs), and so on. As the Consumer Sentinel report states: ‘The 2014 Consumer Sentinel Network Data Book is based on unverified complaints reported by consumers. The data is not based on a consumer survey.’ This doesn’t make the report less interesting or useful, but it does mean that the information is reliant on the individual complainant’s good intentions and ability to interpret correctly what actually happened in the course of a telephone exchange and after. If the data were drawn from a survey the survey team would have attempted to select a range of respondents as representative as possible of the total population at risk and weight and verify the data accordingly. Hopefully.
  • The Pindrop data are collected by a proprietary ‘online complaint collection tool’ for the aggregation of data regarding ‘suspicious’ phone numbers as reported in ‘hundreds of complaint sites, online communities, and Web forums’. While there’s a great deal of interesting and useful information to be gathered this way, similar caveats apply as in the case of the Consumer Sentinel Network report. There is the additional complication that online forums are known to be vulnerable to infestation by groups paid to promote services and causes or to denigrate rivals. But that’s a topic I’ll probably return to in a separate article.

by David “Call me anytime” Harley
ESET Senior Research Fellow

Critical vulnerabilities in Windows and Adobe Reader exposed by hacker

A hacker has published an extensive list of Adobe Reader and Windows vulnerabilities based on his research into a relatively obscure area of font management.

Google Project Zero hacker Mateusz Jurczyk found a total of 15 vulnerabilities, any of which could trigger remote code execution or privilege escalation in Adobe Reader or the Windows kernel. However, the two worst (detailed as CVE-2015-3052 for 32-bit and CVE-2015-0093 for 64-bit) exist in the Adobe Type Manager Font Driver, which has existed in the Windows kernel since Windows NT 4.

He told IT blog the The Register that the most serious, an ‘entirely reliable’ BLEND instruction exploit relates to the handling of CharStrings that are responsible for drawing the shape of each glyph at a particular point size.

“The extremely powerful primitive provided by the vulnerability – together with the fact that it affected all supported versions of both Adobe Reader and Microsoft Windows thus making it possible to create an exploit chain leading to a full system compromise with just a single bug – makes it one of the most interesting security issues I have discovered so far,” Jurczyk said.

“The video demonstrates reliable exploitation of a vulnerability in the handling of the BLEND instruction in Type 1 fonts, used in two stages to first achieve arbitrary code execution in Adobe Reader 11.0.10, and further escape the sandbox and elevate privileges to System by attacking the Adobe Type Manager Font Driver in the Windows 8.1 Update 1 32-bit (or 64-bit) kernel”, he continued.

In a blog post the researcher also shared his presentation from the Recon security conference this month called ‘One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation.’

As welivesecurity.com recently reported, Google has extended the disclosure period for vulnerabilities uncovered in its Project Zero program by an additional two weeks, if a vendor is planning a patch in the two weeks following the deadline. The additional 14 day ‘grace period’ for vendors will “improve industry response times to security bugs, but will result in softer landings for bugs marginally over deadline”, according to Google.

by Karl Thomas, ESET

Polish airline LOT grounded by ‘first attack of its kind’

Hackers are being blamed for an attack which grounded 1,400 passengers set to fly on Polish airline LOT.

The passengers were waiting to fly from Warsaw’s Frederic Chopin Airport when the attack occurred at around 4:00 pm (1500 GMT). The airline’s ground operations system was knocked offline by the targeted attack, which led to the cancellation of 10 flights departing from Warsaw, and the delay of about a dozen more, according to Reuters.

“This is the first attack of its kind,” LOT spokesman Adrian Kubicki told TVN 24 television, according to Yahoo News.

The state-owned airline said in a statement on its website that the “IT attack” meant it was unable to create flight plans and flights were not able to depart from Warsaw. The affected systems were fixed within five hours,

A spokesman told Reuters that the attack could have wider consequences for the aviation industry: “We’re using state-of-the-art computer systems, so this could potentially be a threat to others in the industry,” Adrian Kubicki said.

Yahoo reports that in December last year the International Civil Aviation Organization said cybercrime was a serious threat to in-air safety, and pledged to set up a “security culture” to protect passengers against serious incidents.

As reported on WeliveSecurity recently, there are concerns that planes offering in-flight Wi-Fi are vulnerable to being hacked. A report published by the Government Accountability Office (GAO) suggested that the rise in modern technology on commercial flights could put passengers at risk, due to potential hack attacks via Wi-Fi and other internet-based services. The report did point out that a nightmare scenario would not be easily achieved, but said that firewalls protecting passengers are not sufficient.

by Karl Thomas, ESET

Follow

Get every new post delivered to your Inbox.

Join 101 other followers