Articles 2017 November - English Press English Articles Page 1 2 3 4 5 6 2020 2019 2018 2017 2016 2015 2014 2013 2012
H Analysis Android Apple APT Attack BigBrothers BotNet Congress Crime Crypto Cryptocurrency Cyber CyberCrime CyberSpy CyberWar Exploit Forensics Hacking ICS Incindent iOS IT IoT Mobil OS Phishing Privacy Ransomware Safety Security Social Spam Virus Vulnerebility
Jednotlivé články jsou rozděleny podle měsíců a zde je najdete./The articles are broken down by month and can be found here.
2017 - January February March April May June July August September October November December
Crypto-Miner Botnet Spreads over SSH
4.1.2018 securityweek BotNet
A recently discovered Linux crypto-miner botnet spreading over the SSH protocol is based on the Python scripting language, which makes it difficult to detect, F5 Networks has discovered.
Dubbed PyCryptoMiner, the botnet is using Pastebin to receive new command and control server (C&C) assignments when the original C&C isn’t available. Under active development, the botnet recently added scanner functionality hunting for vulnerable JBoss servers (exploiting CVE-2017-12149), F5 says.
Designed to mine for Monero, a highly anonymous crypto-currency, the botnet is estimated to have generated the equivalent of approximately $46,000 as of late December.
PyCryptoMiner isn’t the only botnet targeting online Linux systems, but because of its scripting language-based nature, the malware is more evasive and be easily obfuscated. Furthermore, it is executed by a legitimate binary, F5's researchers discovered.
The botnet spreads by attempting to guess the SSH login credentials of target Linux machines. If the credentials are successfully discovered, the attacking bot deploys a simple base64-encoded spearhead Python script designed to connect to the C&C server to download and execute additional Python code.
The second-stage code is the main bot controller, which registers a cron job on the infected machine to create persistency.
The original spearhead bash script also collects information on the infected device, including Host/DNS name, OS name and architecture, number of CPUs, and CPU usage. It also checks whether the machine has been already infected and whether the bot is used for crypto-mining or scanning.
The bot then sends a report with the collected information to the C&C, which responds with task details. Tasks include arbitrary commands to be executed, update, identifier so the C&C can synchronize botnet results, and time interval to poll the C&C. The bot sends an output of the executed task to the C&C.
In mid-December, the botnet was updated with code to scan for vulnerable JBoss servers, in an attempt to exploit CVE-2017-12149, a vulnerability disclosed several months ago.
“The list of the targets to scan is controlled by the C&C server, while the bot has a separate thread that polls the C&C server for new targets. The server responds with a Class C IP range to scan but could also provide a single IP address,” the researchers reveal.
The botnet uses two pool addresses that show approximately 94 and 64 Monero, with a value of around $60,000. However, the researchers are uncertain how much profit the threat actor behind the malware has made overall.
Unlike other malware that has the C&C server address hardcoded, which causes bots to become unreachable when the server is taken down, the botnet uses Pastebin to publish an alternate C&C server address if the original one is unreachable.
According to F5, with all C&C servers of the botnet inaccessible at this moment, all newly infected bots are idle, polling for the attacker’s Pastebin.com page, which could be updated at any time.
The page allowed researchers to determine that the botnet might have been active since August 2017, and that the resource had been viewed 177,987 times at the time of the investigation. However, the researchers couldn’t determine the exact size of the botnet, as a single bot could periodically ask the resource if the C&C server is down.
Looking at other resources created by the same actor, who uses the moniker “WHATHAPPEN”, the researchers discovered 235 email addresses and more than 36,000 domains associated with them. The registrant has been involved in scams, gambling, and adult services since 2012.
“Our research is still ongoing while we hunt for more missing pieces of this puzzle, such as the “scanner node” component and additional C&C servers, if there are any. We are also waiting to see whether the current C&C server will come back to life,” F5 notes.
Andromeda Botnet to Die Slow, Painful Death After Takedown
4.1.2018 securityweek BotNet
Following a takedown operation in early December 2017, the Andromeda botnet is expected to slowly disappear from the threat landscape, ESET says.
Also known as Wauchos or Gamarue, the botnet has been around since at least September 2011 and lived through five major versions over the years. The Andromeda malware was detected or blocked on an average of around 1.1 million machines every month over the six months leading to the takedown.
The botnet was mainly used for stealing credentials and to download and install additional malware onto compromised systems. Thus, systems infected with Andromeda would likely have other threats installed on them as well, ESET says.
Some of the threats usually distributed via Andromeda included Kasidet, also known as Neutrino bot, which can launch distributed denial-of-service (DDoS) attacks, and Kelihos and Lethic, which are notorious spambots known for their involvement in massive junk mail campaigns. It was also used for the distribution of the Dridex banking Trojan and point-of-sale (PoS) malware GamaPoS.
Andromeda was distributed through various methods, including social media, instant messaging, removable media, spam, drive-by downloads, and exploit kits. Because it didn’t conduct targeted attacks, the malware could infect any computer if the user clicked on malicious links.
Since there were no obvious signs to alert the user on the infection, the botnet managed to remain hidden and compromise a large number of systems. Featuring a modular design, the botnet could get additional capabilities through plugins such as a keylogger, a form grabber, and a rootkit.
ESET Senior Malware Researcher Jean-Ian Boutin, who was involved in the takedown operation, explains that the botnet’s numerous features and continuous development made it appealing to cybercriminals interested in using it. Thus, Andromeda was able to survive for a long period of time and to also become a prevalent threat.
At the time of Andromeda’s takedown, security researchers identified 464 distinct botnets, 80 associated malware families, and 1,214 domains and IP addresses of the botnet’s command and control (C&C) servers.
The takedown operation, a joint effort from the FBI, the Luneburg Central Criminal Investigation Inspectorate in Germany, Europol’s European Cybercrime Centre (EC3), the Joint Cybercrime Action Task Force (J-CAT), Eurojust, and private-sector partners, built on information gathered during the shutdown of a large criminal network known as Avalanche.
According to Boutin, investigators started gathering information and evidence in 2015 and needed a lot of time to get everything ready for a law enforcement operation. Following the takedown, authorities seized control of Andromeda’s C&C servers and the botnet is expected to slowly disappear.
“It will probably slowly disappear as remediation is under way. For this type of long-lived botnet, it is very hard to clean all the systems that have been compromised by Wauchos, but as long as the good guys are in control of the C&C servers, at least no new harm can be done to those compromised PCs,” Boutin says.
Reading privileged memory with a side-channel
4.1.2017 Google Projet Zero Vulnerebility blog
We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts.
Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1].
So far, there are three known variants of the issue:
Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)
Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:
Spectre (variants 1 and 2)
Meltdown (variant 3)
During the course of our research, we developed the following proofs of concept (PoCs):
A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
For interesting resources around this topic, look down into the "Literature" section.
A warning regarding explanations about processor internals in this blogpost: This blogpost contains a lot of speculation about hardware internals based on observed behavior, which might not necessarily correspond to what processors are actually doing.
We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance.
The PoC code and the writeups that we sent to the CPU vendors will be made available at a later date.
Tested Processors
Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)
Glossary
retire: An instruction retires when its results, e.g. register writes and memory writes, are committed and made visible to the rest of the system. Instructions can be executed out of order, but must always retire in order.
logical processor core: A logical processor core is what the operating system sees as a processor core. With hyperthreading enabled, the number of logical cores is a multiple of the number of physical cores.
cached/uncached data: In this blogpost, "uncached" data is data that is only present in main memory, not in any of the cache levels of the CPU. Loading uncached data will typically take over 100 cycles of CPU time.
speculative execution: A processor can execute past a branch without knowing whether it will be taken or where its target is, therefore executing instructions before it is known whether they should be executed. If this speculation turns out to have been incorrect, the CPU can discard the resulting state without architectural effects and continue execution on the correct execution path. Instructions do not retire before it is known that they are on the correct execution path.
mis-speculation window: The time window during which the CPU speculatively executes the wrong code and has not yet detected that mis-speculation has occurred.
Variant 1: Bounds check bypass
This section explains the common theory behind all three variants and the theory behind our PoC for variant 1 that, when running in userspace under a Debian distro kernel, can perform arbitrary reads in a 4GiB region of kernel memory in at least the following configurations:
Intel Haswell Xeon CPU, eBPF JIT is off (default state)
Intel Haswell Xeon CPU, eBPF JIT is on (non-default state)
AMD PRO CPU, eBPF JIT is on (non-default state)
The state of the eBPF JIT can be toggled using the net.core.bpf_jit_enable sysctl.
Theoretical explanation
The Intel Optimization Reference Manual says the following regarding Sandy Bridge (and later microarchitectural revisions) in section 2.3.2.3 ("Branch Prediction"):
Branch prediction predicts the branch target and enables the
processor to begin executing instructions long before the branch
true execution path is known.
In section 2.3.5.2 ("L1 DCache"):
Loads can:
[...]
Be carried out speculatively, before preceding branches are resolved.
Take cache misses out of order and in an overlapped manner.
Intel's Software Developer's Manual [7] states in Volume 3A, section 11.7 ("Implicit Caching (Pentium 4, Intel Xeon, and P6 family processors"):
Implicit caching occurs when a memory element is made potentially cacheable, although the element may never have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent processor families due to aggressive prefetching, branch prediction, and TLB miss handling. Implicit caching is an extension of the behavior of existing Intel386, Intel486, and Pentium processor systems, since software running on these processor families also has not been able to deterministically predict the behavior of instruction prefetch.
Consider the code sample below. If arr1->length is uncached, the processor can speculatively load data from arr1->data[untrusted_offset_from_caller]. This is an out-of-bounds read. That should not matter because the processor will effectively roll back the execution state when the branch has executed; none of the speculatively executed instructions will retire (e.g. cause registers etc. to be affected).
struct array {
unsigned long length;
unsigned char data[];
};
struct array *arr1 = ...;
unsigned long untrusted_offset_from_caller = ...;
if (untrusted_offset_from_caller < arr1->length) {
unsigned char value = arr1->data[untrusted_offset_from_caller];
...
}
However, in the following code sample, there's an issue. If arr1->length, arr2->data[0x200] and arr2->data[0x300] are not cached, but all other accessed data is, and the branch conditions are predicted as true, the processor can do the following speculatively before arr1->length has been loaded and the execution is re-steered:
load value = arr1->data[untrusted_offset_from_caller]
start a load from a data-dependent offset in arr2->data, loading the corresponding cache line into the L1 cache
struct array {
unsigned long length;
unsigned char data[];
};
struct array *arr1 = ...; /* small array */
struct array *arr2 = ...; /* array of size 0x400 */
/* >0x400 (OUT OF BOUNDS!) */
unsigned long untrusted_offset_from_caller = ...;
if (untrusted_offset_from_caller < arr1->length) {
unsigned char value = arr1->data[untrusted_offset_from_caller];
unsigned long index2 = ((value&1)*0x100)+0x200;
if (index2 < arr2->length) {
unsigned char value2 = arr2->data[index2];
}
}
After the execution has been returned to the non-speculative path because the processor has noticed that untrusted_offset_from_caller is bigger than arr1->length, the cache line containing arr2->data[index2] stays in the L1 cache. By measuring the time required to load arr2->data[0x200] and arr2->data[0x300], an attacker can then determine whether the value of index2 during speculative execution was 0x200 or 0x300 - which discloses whether arr1->data[untrusted_offset_from_caller]&1 is 0 or 1.
To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.
A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further.
Attacking the kernel
This section describes in more detail how variant 1 can be used to leak Linux kernel memory using the eBPF bytecode interpreter and JIT engine. While there are many interesting potential targets for variant 1 attacks, we chose to attack the Linux in-kernel eBPF JIT/interpreter because it provides more control to the attacker than most other JITs.
The Linux kernel supports eBPF since version 3.18. Unprivileged userspace code can supply bytecode to the kernel that is verified by the kernel and then:
either interpreted by an in-kernel bytecode interpreter
or translated to native machine code that also runs in kernel context using a JIT engine (which translates individual bytecode instructions without performing any further optimizations)
Execution of the bytecode can be triggered by attaching the eBPF bytecode to a socket as a filter and then sending data through the other end of the socket.
Whether the JIT engine is enabled depends on a run-time configuration setting - but at least on the tested Intel processor, the attack works independent of that setting.
Unlike classic BPF, eBPF has data types like data arrays and function pointer arrays into which eBPF bytecode can index. Therefore, it is possible to create the code pattern described above in the kernel using eBPF bytecode.
eBPF's data arrays are less efficient than its function pointer arrays, so the attack will use the latter where possible.
Both machines on which this was tested have no SMAP, and the PoC relies on that (but it shouldn't be a precondition in principle).
Additionally, at least on the Intel machine on which this was tested, bouncing modified cache lines between cores is slow, apparently because the MESI protocol is used for cache coherence [8]. Changing the reference counter of an eBPF array on one physical CPU core causes the cache line containing the reference counter to be bounced over to that CPU core, making reads of the reference counter on all other CPU cores slow until the changed reference counter has been written back to memory. Because the length and the reference counter of an eBPF array are stored in the same cache line, this also means that changing the reference counter on one physical CPU core causes reads of the eBPF array's length to be slow on other physical CPU cores (intentional false sharing).
The attack uses two eBPF programs. The first one tail-calls through a page-aligned eBPF function pointer array prog_map at a configurable index. In simplified terms, this program is used to determine the address of prog_map by guessing the offset from prog_map to a userspace address and tail-calling through prog_map at the guessed offsets. To cause the branch prediction to predict that the offset is below the length of prog_map, tail calls to an in-bounds index are performed in between. To increase the mis-speculation window, the cache line containing the length of prog_map is bounced to another core. To test whether an offset guess was successful, it can be tested whether the userspace address has been loaded into the cache.
Because such straightforward brute-force guessing of the address would be slow, the following optimization is used: 215 adjacent userspace memory mappings [9], each consisting of 24 pages, are created at the userspace address user_mapping_area, covering a total area of 231 bytes. Each mapping maps the same physical pages, and all mappings are present in the pagetables.
This permits the attack to be carried out in steps of 231 bytes. For each step, after causing an out-of-bounds access through prog_map, only one cache line each from the first 24 pages of user_mapping_area have to be tested for cached memory. Because the L3 cache is physically indexed, any access to a virtual address mapping a physical page will cause all other virtual addresses mapping the same physical page to become cached as well.
When this attack finds a hit—a cached memory location—the upper 33 bits of the kernel address are known (because they can be derived from the address guess at which the hit occurred), and the low 16 bits of the address are also known (from the offset inside user_mapping_area at which the hit was found). The remaining part of the address of user_mapping_area is the middle.
The remaining bits in the middle can be determined by bisecting the remaining address space: Map two physical pages to adjacent ranges of virtual addresses, each virtual address range the size of half of the remaining search space, then determine the remaining address bit-wise.
At this point, a second eBPF program can be used to actually leak data. In pseudocode, this program looks as follows:
uint64_t bitmask = <runtime-configurable>;
uint64_t bitshift_selector = <runtime-configurable>;
uint64_t prog_array_base_offset = <runtime-configurable>;
uint64_t secret_data_offset = <runtime-configurable>;
// index will be bounds-checked by the runtime,
// but the bounds check will be bypassed speculatively
uint64_t secret_data = bpf_map_read(array=victim_array, index=secret_data_offset);
// select a single bit, move it to a specific position, and add the base offset
uint64_t progmap_index = (((secret_data & bitmask) >> bitshift_selector) << 7) + prog_array_base_offset;
bpf_tail_call(prog_map, progmap_index);
This program reads 8-byte-aligned 64-bit values from an eBPF data array "victim_map" at a runtime-configurable offset and bitmasks and bit-shifts the value so that one bit is mapped to one of two values that are 27 bytes apart (sufficient to not land in the same or adjacent cache lines when used as an array index). Finally it adds a 64-bit offset, then uses the resulting value as an offset into prog_map for a tail call.
This program can then be used to leak memory by repeatedly calling the eBPF program with an out-of-bounds offset into victim_map that specifies the data to leak and an out-of-bounds offset into prog_map that causes prog_map + offset to point to a userspace memory area. Misleading the branch prediction and bouncing the cache lines works the same way as for the first eBPF program, except that now, the cache line holding the length of victim_map must also be bounced to another core.
Variant 2: Branch target injection
This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second.
Basics
Prior research (see the Literature section at the end) has shown that it is possible for code in separate security contexts to influence each other's branch prediction. So far, this has only been used to infer information about where code is located (in other words, to create interference from the victim to the attacker); however, the basic hypothesis of this attack variant is that it can also be used to redirect execution of code in the victim context (in other words, to create interference from the attacker to the victim; the other way around).
The basic idea for the attack is to target victim code that contains an indirect branch whose target address is loaded from memory and flush the cache line containing the target address out to main memory. Then, when the CPU reaches the indirect branch, it won't know the true destination of the jump, and it won't be able to calculate the true destination until it has finished loading the cache line back into the CPU, which takes a few hundred cycles. Therefore, there is a time window of typically over 100 cycles in which the CPU will speculatively execute instructions based on branch prediction.
Haswell branch prediction internals
Some of the internals of the branch prediction implemented by Intel's processors have already been published; however, getting this attack to work properly required significant further experimentation to determine additional details.
This section focuses on the branch prediction internals that were experimentally derived from the Intel Haswell Xeon CPU.
Haswell seems to have multiple branch prediction mechanisms that work very differently:
A generic branch predictor that can only store one target per source address; used for all kinds of jumps, like absolute jumps, relative jumps and so on.
A specialized indirect call predictor that can store multiple targets per source address; used for indirect calls.
(There is also a specialized return predictor, according to Intel's optimization manual, but we haven't analyzed that in detail yet. If this predictor could be used to reliably dump out some of the call stack through which a VM was entered, that would be very interesting.)
Generic predictor
The generic branch predictor, as documented in prior research, only uses the lower 31 bits of the address of the last byte of the source instruction for its prediction. If, for example, a branch target buffer (BTB) entry exists for a jump from 0x4141.0004.1000 to 0x4141.0004.5123, the generic predictor will also use it to predict a jump from 0x4242.0004.1000. When the higher bits of the source address differ like this, the higher bits of the predicted destination change together with it—in this case, the predicted destination address will be 0x4242.0004.5123—so apparently this predictor doesn't store the full, absolute destination address.
Before the lower 31 bits of the source address are used to look up a BTB entry, they are folded together using XOR. Specifically, the following bits are folded together:
bit A
bit B
0x40.0000
0x2000
0x80.0000
0x4000
0x100.0000
0x8000
0x200.0000
0x1.0000
0x400.0000
0x2.0000
0x800.0000
0x4.0000
0x2000.0000
0x10.0000
0x4000.0000
0x20.0000
In other words, if a source address is XORed with both numbers in a row of this table, the branch predictor will not be able to distinguish the resulting address from the original source address when performing a lookup. For example, the branch predictor is able to distinguish source addresses 0x100.0000 and 0x180.0000, and it can also distinguish source addresses 0x100.0000 and 0x180.8000, but it can't distinguish source addresses 0x100.0000 and 0x140.2000 or source addresses 0x100.0000 and 0x180.4000. In the following, this will be referred to as aliased source addresses.
When an aliased source address is used, the branch predictor will still predict the same target as for the unaliased source address. This indicates that the branch predictor stores a truncated absolute destination address, but that hasn't been verified.
Based on observed maximum forward and backward jump distances for different source addresses, the low 32-bit half of the target address could be stored as an absolute 32-bit value with an additional bit that specifies whether the jump from source to target crosses a 232 boundary; if the jump crosses such a boundary, bit 31 of the source address determines whether the high half of the instruction pointer should increment or decrement.
Indirect call predictor
The inputs of the BTB lookup for this mechanism seem to be:
The low 12 bits of the address of the source instruction (we are not sure whether it's the address of the first or the last byte) or a subset of them.
The branch history buffer state.
If the indirect call predictor can't resolve a branch, it is resolved by the generic predictor instead. Intel's optimization manual hints at this behavior: "Indirect Calls and Jumps. These may either be predicted as having a monotonic target or as having targets that vary in accordance with recent program behavior."
The branch history buffer (BHB) stores information about the last 29 taken branches - basically a fingerprint of recent control flow - and is used to allow better prediction of indirect calls that can have multiple targets.
The update function of the BHB works as follows (in pseudocode; src is the address of the last byte of the source instruction, dst is the destination address):
void bhb_update(uint58_t *bhb_state, unsigned long src, unsigned long dst) {
*bhb_state <<= 2;
*bhb_state ^= (dst & 0x3f);
*bhb_state ^= (src & 0xc0) >> 6;
*bhb_state ^= (src & 0xc00) >> (10 - 2);
*bhb_state ^= (src & 0xc000) >> (14 - 4);
*bhb_state ^= (src & 0x30) << (6 - 4);
*bhb_state ^= (src & 0x300) << (8 - 8);
*bhb_state ^= (src & 0x3000) >> (12 - 10);
*bhb_state ^= (src & 0x30000) >> (16 - 12);
*bhb_state ^= (src & 0xc0000) >> (18 - 14);
}
Some of the bits of the BHB state seem to be folded together further using XOR when used for a BTB access, but the precise folding function hasn't been understood yet.
The BHB is interesting for two reasons. First, knowledge about its approximate behavior is required in order to be able to accurately cause collisions in the indirect call predictor. But it also permits dumping out the BHB state at any repeatable program state at which the attacker can execute code - for example, when attacking a hypervisor, directly after a hypercall. The dumped BHB state can then be used to fingerprint the hypervisor or, if the attacker has access to the hypervisor binary, to determine the low 20 bits of the hypervisor load address (in the case of KVM: the low 20 bits of the load address of kvm-intel.ko).
Reverse-Engineering Branch Predictor Internals
This subsection describes how we reverse-engineered the internals of the Haswell branch predictor. Some of this is written down from memory, since we didn't keep a detailed record of what we were doing.
We initially attempted to perform BTB injections into the kernel using the generic predictor, using the knowledge from prior research that the generic predictor only looks at the lower half of the source address and that only a partial target address is stored. This kind of worked - however, the injection success rate was very low, below 1%. (This is the method we used in our preliminary PoCs for method 2 against modified hypervisors running on Haswell.)
We decided to write a userspace test case to be able to more easily test branch predictor behavior in different situations.
Based on the assumption that branch predictor state is shared between hyperthreads [10], we wrote a program of which two instances are each pinned to one of the two logical processors running on a specific physical core, where one instance attempts to perform branch injections while the other measures how often branch injections are successful. Both instances were executed with ASLR disabled and had the same code at the same addresses. The injecting process performed indirect calls to a function that accesses a (per-process) test variable; the measuring process performed indirect calls to a function that tests, based on timing, whether the per-process test variable is cached, and then evicts it using CLFLUSH. Both indirect calls were performed through the same callsite. Before each indirect call, the function pointer stored in memory was flushed out to main memory using CLFLUSH to widen the speculation time window. Additionally, because of the reference to "recent program behavior" in Intel's optimization manual, a bunch of conditional branches that are always taken were inserted in front of the indirect call.
In this test, the injection success rate was above 99%, giving us a base setup for future experiments.
We then tried to figure out the details of the prediction scheme. We assumed that the prediction scheme uses a global branch history buffer of some kind.
To determine the duration for which branch information stays in the history buffer, a conditional branch that is only taken in one of the two program instances was inserted in front of the series of always-taken conditional jumps, then the number of always-taken conditional jumps (N) was varied. The result was that for N=25, the processor was able to distinguish the branches (misprediction rate under 1%), but for N=26, it failed to do so (misprediction rate over 99%).
Therefore, the branch history buffer had to be able to store information about at least the last 26 branches.
The code in one of the two program instances was then moved around in memory. This revealed that only the lower 20 bits of the source and target addresses have an influence on the branch history buffer.
Testing with different types of branches in the two program instances revealed that static jumps, taken conditional jumps, calls and returns influence the branch history buffer the same way; non-taken conditional jumps don't influence it; the address of the last byte of the source instruction is the one that counts; IRETQ doesn't influence the history buffer state (which is useful for testing because it permits creating program flow that is invisible to the history buffer).
Moving the last conditional branch before the indirect call around in memory multiple times revealed that the branch history buffer contents can be used to distinguish many different locations of that last conditional branch instruction. This suggests that the history buffer doesn't store a list of small history values; instead, it seems to be a larger buffer in which history data is mixed together.
However, a history buffer needs to "forget" about past branches after a certain number of new branches have been taken in order to be useful for branch prediction. Therefore, when new data is mixed into the history buffer, this can not cause information in bits that are already present in the history buffer to propagate downwards - and given that, upwards combination of information probably wouldn't be very useful either. Given that branch prediction also must be very fast, we concluded that it is likely that the update function of the history buffer left-shifts the old history buffer, then XORs in the new state (see diagram).
If this assumption is correct, then the history buffer contains a lot of information about the most recent branches, but only contains as many bits of information as are shifted per history buffer update about the last branch about which it contains any data. Therefore, we tested whether flipping different bits in the source and target addresses of a jump followed by 32 always-taken jumps with static source and target allows the branch prediction to disambiguate an indirect call. [11]
With 32 static jumps in between, no bit flips seemed to have an influence, so we decreased the number of static jumps until a difference was observable. The result with 28 always-taken jumps in between was that bits 0x1 and 0x2 of the target and bits 0x40 and 0x80 of the source had such an influence; but flipping both 0x1 in the target and 0x40 in the source or 0x2 in the target and 0x80 in the source did not permit disambiguation. This shows that the per-insertion shift of the history buffer is 2 bits and shows which data is stored in the least significant bits of the history buffer. We then repeated this with decreased amounts of fixed jumps after the bit-flipped jump to determine which information is stored in the remaining bits.
Reading host memory from a KVM guest
Locating the host kernel
Our PoC locates the host kernel in several steps. The information that is determined and necessary for the next steps of the attack consists of:
lower 20 bits of the address of kvm-intel.ko
full address of kvm.ko
full address of vmlinux
Looking back, this is unnecessarily complicated, but it nicely demonstrates the various techniques an attacker can use. A simpler way would be to first determine the address of vmlinux, then bisect the addresses of kvm.ko and kvm-intel.ko.
In the first step, the address of kvm-intel.ko is leaked. For this purpose, the branch history buffer state after guest entry is dumped out. Then, for every possible value of bits 12..19 of the load address of kvm-intel.ko, the expected lowest 16 bits of the history buffer are computed based on the load address guess and the known offsets of the last 8 branches before guest entry, and the results are compared against the lowest 16 bits of the leaked history buffer state.
The branch history buffer state is leaked in steps of 2 bits by measuring misprediction rates of an indirect call with two targets. One way the indirect call is reached is from a vmcall instruction followed by a series of N branches whose relevant source and target address bits are all zeroes. The second way the indirect call is reached is from a series of controlled branches in userspace that can be used to write arbitrary values into the branch history buffer.
Misprediction rates are measured as in the section "Reverse-Engineering Branch Predictor Internals", using one call target that loads a cache line and another one that checks whether the same cache line has been loaded.
With N=29, mispredictions will occur at a high rate if the controlled branch history buffer value is zero because all history buffer state from the hypercall has been erased. With N=28, mispredictions will occur if the controlled branch history buffer value is one of 0<<(28*2), 1<<(28*2), 2<<(28*2), 3<<(28*2) - by testing all four possibilities, it can be detected which one is right. Then, for decreasing values of N, the four possibilities are {0|1|2|3}<<(28*2) | (history_buffer_for(N+1) >> 2). By repeating this for decreasing values for N, the branch history buffer value for N=0 can be determined.
At this point, the low 20 bits of kvm-intel.ko are known; the next step is to roughly locate kvm.ko.
For this, the generic branch predictor is used, using data inserted into the BTB by an indirect call from kvm.ko to kvm-intel.ko that happens on every hypercall; this means that the source address of the indirect call has to be leaked out of the BTB.
kvm.ko will probably be located somewhere in the range from 0xffffffffc0000000 to 0xffffffffc4000000, with page alignment (0x1000). This means that the first four entries in the table in the section "Generic Predictor" apply; there will be 24-1=15 aliasing addresses for the correct one. But that is also an advantage: It cuts down the search space from 0x4000 to 0x4000/24=1024.
To find the right address for the source or one of its aliasing addresses, code that loads data through a specific register is placed at all possible call targets (the leaked low 20 bits of kvm-intel.ko plus the in-module offset of the call target plus a multiple of 220) and indirect calls are placed at all possible call sources. Then, alternatingly, hypercalls are performed and indirect calls are performed through the different possible non-aliasing call sources, with randomized history buffer state that prevents the specialized prediction from working. After this step, there are 216 remaining possibilities for the load address of kvm.ko.
Next, the load address of vmlinux can be determined in a similar way, using an indirect call from vmlinux to kvm.ko. Luckily, none of the bits which are randomized in the load address of vmlinux are folded together, so unlike when locating kvm.ko, the result will directly be unique. vmlinux has an alignment of 2MiB and a randomization range of 1GiB, so there are still only 512 possible addresses.
Because (as far as we know) a simple hypercall won't actually cause indirect calls from vmlinux to kvm.ko, we instead use port I/O from the status register of an emulated serial port, which is present in the default configuration of a virtual machine created with virt-manager.
The only remaining piece of information is which one of the 16 aliasing load addresses of kvm.ko is actually correct. Because the source address of an indirect call to kvm.ko is known, this can be solved using bisection: Place code at the various possible targets that, depending on which instance of the code is speculatively executed, loads one of two cache lines, and measure which one of the cache lines gets loaded.
Identifying cache sets
The PoC assumes that the VM does not have access to hugepages.To discover eviction sets for all L3 cache sets with a specific alignment relative to a 4KiB page boundary, the PoC first allocates 25600 pages of memory. Then, in a loop, it selects random subsets of all remaining unsorted pages such that the expected number of sets for which an eviction set is contained in the subset is 1, reduces each subset down to an eviction set by repeatedly accessing its cache lines and testing whether the cache lines are always cached (in which case they're probably not part of an eviction set) and attempts to use the new eviction set to evict all remaining unsorted cache lines to determine whether they are in the same cache set [12].
Locating the host-virtual address of a guest page
Because this attack uses a FLUSH+RELOAD approach for leaking data, it needs to know the host-kernel-virtual address of one guest page. Alternative approaches such as PRIME+PROBE should work without that requirement.
The basic idea for this step of the attack is to use a branch target injection attack against the hypervisor to load an attacker-controlled address and test whether that caused the guest-owned page to be loaded. For this, a gadget that simply loads from the memory location specified by R8 can be used - R8-R11 still contain guest-controlled values when the first indirect call after a guest exit is reached on this kernel build.
We expected that an attacker would need to either know which eviction set has to be used at this point or brute-force it simultaneously; however, experimentally, using random eviction sets works, too. Our theory is that the observed behavior is actually the result of L1D and L2 evictions, which might be sufficient to permit a few instructions worth of speculative execution.
The host kernel maps (nearly?) all physical memory in the physmap area, including memory assigned to KVM guests. However, the location of the physmap is randomized (with a 1GiB alignment), in an area of size 128PiB. Therefore, directly bruteforcing the host-virtual address of a guest page would take a long time. It is not necessarily impossible; as a ballpark estimate, it should be possible within a day or so, maybe less, assuming 12000 successful injections per second and 30 guest pages that are tested in parallel; but not as impressive as doing it in a few minutes.
To optimize this, the problem can be split up: First, brute-force the physical address using a gadget that can load from physical addresses, then brute-force the base address of the physmap region. Because the physical address can usually be assumed to be far below 128PiB, it can be brute-forced more efficiently, and brute-forcing the base address of the physmap region afterwards is also easier because then address guesses with 1GiB alignment can be used.
To brute-force the physical address, the following gadget can be used:
ffffffff810a9def: 4c 89 c0 mov rax,r8
ffffffff810a9df2: 4d 63 f9 movsxd r15,r9d
ffffffff810a9df5: 4e 8b 04 fd c0 b3 a6 mov r8,QWORD PTR [r15*8-0x7e594c40]
ffffffff810a9dfc: 81
ffffffff810a9dfd: 4a 8d 3c 00 lea rdi,[rax+r8*1]
ffffffff810a9e01: 4d 8b a4 00 f8 00 00 mov r12,QWORD PTR [r8+rax*1+0xf8]
ffffffff810a9e08: 00
This gadget permits loading an 8-byte-aligned value from the area around the kernel text section by setting R9 appropriately, which in particular permits loading page_offset_base, the start address of the physmap. Then, the value that was originally in R8 - the physical address guess minus 0xf8 - is added to the result of the previous load, 0xfa is added to it, and the result is dereferenced.
Cache set selection
To select the correct L3 eviction set, the attack from the following section is essentially executed with different eviction sets until it works.
Leaking data
At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
The eBPF interpreter entry point has the following function signature:
static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
The second parameter is a pointer to an array of statically pre-verified eBPF instructions to be executed - which means that __bpf_prog_run() will not perform any type checks or bounds checks. The first parameter is simply stored as part of the initial emulated register state, so its value doesn't matter.
The eBPF interpreter provides, among other things:
multiple emulated 64-bit registers
64-bit immediate writes to emulated registers
memory reads from addresses stored in emulated registers
bitwise operations (including bit shifts) and arithmetic operations
To call the interpreter entry point, a gadget that gives RSI and RIP control given R8-R11 control and controlled data at a known memory location is necessary. The following gadget provides this functionality:
ffffffff81514edd: 4c 89 ce mov rsi,r9
ffffffff81514ee0: 41 ff 90 b0 00 00 00 call QWORD PTR [r8+0xb0]
Now, by pointing R8 and R9 at the mapping of a guest-owned page in the physmap, it is possible to speculatively execute arbitrary unvalidated eBPF bytecode in the host kernel. Then, relatively straightforward bytecode can be used to leak data into the cache.
Variant 3: Rogue data cache load
Basically, read Anders Fogh's blogpost: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
In summary, an attack using this variant of the issue attempts to read kernel memory from userspace without misdirecting the control flow of kernel code. This works by using the code pattern that was used for the previous variants, but in userspace. The underlying idea is that the permission check for accessing an address might not be on the critical path for reading data from memory to a register, where the permission check could have significant performance impact. Instead, the memory read could make the result of the read available to following instructions immediately and only perform the permission check asynchronously, setting a flag in the reorder buffer that causes an exception to be raised if the permission check fails.
We do have a few additions to make to Anders Fogh's blogpost:
"Imagine the following instruction executed in usermode
mov rax,[somekernelmodeaddress]
It will cause an interrupt when retired, [...]"
It is also possible to already execute that instruction behind a high-latency mispredicted branch to avoid taking a page fault. This might also widen the speculation window by increasing the delay between the read from a kernel address and delivery of the associated exception.
"First, I call a syscall that touches this memory. Second, I use the prefetcht0 instruction to improve my odds of having the address loaded in L1."
When we used prefetch instructions after doing a syscall, the attack stopped working for us, and we have no clue why. Perhaps the CPU somehow stores whether access was denied on the last access and prevents the attack from working if that is the case?
"Fortunately I did not get a slow read suggesting that Intel null’s the result when the access is not allowed."
That (read from kernel address returns all-zeroes) seems to happen for memory that is not sufficiently cached but for which pagetable entries are present, at least after repeated read attempts. For unmapped memory, the kernel address read does not return a result at all.
Ideas for further research
We believe that our research provides many remaining research topics that we have not yet investigated, and we encourage other public researchers to look into these.
This section contains an even higher amount of speculation than the rest of this blogpost - it contains untested ideas that might well be useless.
Leaking without data cache timing
It would be interesting to explore whether there are microarchitectural attacks other than measuring data cache timing that can be used for exfiltrating data out of speculative execution.
Other microarchitectures
Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked.
Other JIT engines
We developed a successful variant 1 attack against the JIT engine built into the Linux kernel. It would be interesting to see whether attacks against more advanced JIT engines with less control over the system are also practical - in particular, JavaScript engines.
More efficient scanning for host-virtual addresses and cache sets
In variant 2, while scanning for the host-virtual address of a guest-owned page, it might make sense to attempt to determine its L3 cache set first. This could be done by performing L3 evictions using an eviction pattern through the physmap, then testing whether the eviction affected the guest-owned page.
The same might work for cache sets - use an L1D+L2 eviction set to evict the function pointer in the host kernel context, use a gadget in the kernel to evict an L3 set using physical addresses, then use that to identify which cache sets guest lines belong to until a guest-owned eviction set has been constructed.
Dumping the complete BTB state
Given that the generic BTB seems to only be able to distinguish 231-8 or fewer source addresses, it seems feasible to dump out the complete BTB state generated by e.g. a hypercall in a timeframe around the order of a few hours. (Scan for jump sources, then for every discovered jump source, bisect the jump target.) This could potentially be used to identify the locations of functions in the host kernel even if the host kernel is custom-built.
The source address aliasing would reduce the usefulness somewhat, but because target addresses don't suffer from that, it might be possible to correlate (source,target) pairs from machines with different KASLR offsets and reduce the number of candidate addresses based on KASLR being additive while aliasing is bitwise.
This could then potentially allow an attacker to make guesses about the host kernel version or the compiler used to build it based on jump offsets or distances between functions.
Variant 2: Leaking with more efficient gadgets
If sufficiently efficient gadgets are used for variant 2, it might not be necessary to evict host kernel function pointers from the L3 cache at all; it might be sufficient to only evict them from L1D and L2.
Various speedups
In particular the variant 2 PoC is still a bit slow. This is probably partly because:
It only leaks one bit at a time; leaking more bits at a time should be doable.
It heavily uses IRETQ for hiding control flow from the processor.
It would be interesting to see what data leak rate can be achieved using variant 2.
Leaking or injection through the return predictor
If the return predictor also doesn't lose its state on a privilege level change, it might be useful for either locating the host kernel from inside a VM (in which case bisection could be used to very quickly discover the full address of the host kernel) or injecting return targets (in particular if the return address is stored in a cache line that can be flushed out by the attacker and isn't reloaded before the return instruction).
However, we have not performed any experiments with the return predictor that yielded conclusive results so far.
Leaking data out of the indirect call predictor
We have attempted to leak target information out of the indirect call predictor, but haven't been able to make it work.
Vendor statements
The following statement were provided to us regarding this issue from the vendors to whom Project Zero disclosed this vulnerability:
Intel
No current statement provided at this time.
AMD
AMD provided the following link: http://www.amd.com/en/corporate/speculative-execution
ARM
Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog. Correspondingly, Arm has developed software mitigations that we recommend be deployed.
Specific details regarding the affected processors and mitigations can be found at this website: https://developer.arm.com/support/security-update
Arm has included a detailed technical whitepaper as well as links to information from some of Arm’s architecture partners regarding their specific implementations and mitigations.
Literature
Note that some of these documents - in particular Intel's documentation - change over time, so quotes from and references to it may not reflect the latest version of Intel's documentation.
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf: Intel's optimization manual has many interesting pieces of optimization advice that hint at relevant microarchitectural behavior; for example:
"Placing data immediately following an indirect branch can cause a performance problem. If the data consists of all zeros, it looks like a long stream of ADDs to memory destinations and this can cause resource conflicts and slow down branch recovery. Also, data immediately following indirect branches may appear as branches to the branch predication [sic] hardware, which can branch off to execute other data pages. This can lead to subsequent self-modifying code problems."
"Loads can:[...]Be carried out speculatively, before preceding branches are resolved."
"Software should avoid writing to a code page in the same 1-KByte subpage that is being executed or fetching code in the same 2-KByte subpage of that is being written. In addition, sharing a page containing directly or speculatively executed code with another processor as a data page can trigger an SMC condition that causes the entire pipeline of the machine and the trace cache to be cleared. This is due to the self-modifying code condition."
"if mapped as WB or WT, there is a potential for speculative processor reads to bring the data into the caches"
"Failure to map the region as WC may allow the line to be speculatively read into the processor caches (via the wrong path of a mispredicted branch)."
https://software.intel.com/en-us/articles/intel-sdm: Intel's Software Developer Manuals
http://www.agner.org/optimize/microarchitecture.pdf: Agner Fog's documentation of reverse-engineered processor behavior and relevant theory was very helpful for this research.
http://www.cs.binghamton.edu/~dima/micro16.pdf and https://github.com/felixwilhelm/mario_baslr: Prior research by Dmitry Evtyushkin, Dmitry Ponomarev and Nael Abu-Ghazaleh on abusing branch target buffer behavior to leak addresses that we used as a starting point for analyzing the branch prediction of Haswell processors. Felix Wilhelm's research based on this provided the basic idea behind variant 2.
https://arxiv.org/pdf/1507.06955.pdf: The rowhammer.js research by Daniel Gruss, Clémentine Maurice and Stefan Mangard contains information about L3 cache eviction patterns that we reused in the KVM PoC to evict a function pointer.
https://xania.org/201602/bpu-part-one: Matt Godbolt blogged about reverse-engineering the structure of the branch predictor on Intel processors.
https://www.sophia.re/thesis.pdf: Sophia D'Antoine wrote a thesis that shows that opcode scheduling can theoretically be used to transmit data between hyperthreads.
https://gruss.cc/files/kaiser.pdf: Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard Fellner, Clémentine Maurice, and Stefan Mangard wrote a paper on mitigating microarchitectural issues caused by pagetable sharing between userspace and the kernel.
https://www.jilp.org/: This journal contains many articles on branch prediction.
http://blog.stuffedcow.net/2013/01/ivb-cache-replacement/: This blogpost by Henry Wong investigates the L3 cache replacement policy used by Intel's Ivy Bridge architecture.
Necurs botnet involved in massive ransomware campaigns at the end of 2017
3.1.2017 securityaffairs Ransomware
The Necurs botnet made the headlines at year-end sending out tens of millions of spam emails daily as part of massive ransomware campaigns.
Necurs was not active for a long period at the beginning of 2017 and resumed it activity in April.
The Necurs botnet was used in the past months to push many other malware, including Locky, Jaff, GlobeImposter, Dridex , Scarab and the Trickbot.
According to data collected by the experts at AppRiver, between December 19 and December 29, 2017, the Necurs botnet was involved in the distribution of ransomware. Crooks use typical holiday-themed scam emails to distribute both Locky and GlobeImposter, malicious messages used .vbs (Visual Basic Script) or .js (JavaScript) files inside a .7z archive.
Starting on Dec. 19, the Necurs botnet was observed sending tens of millions of spam emails daily to distribute ransomware, the peak was reached on December 20th with over 47 million email (peaking at 5.7 million per hour).
“On Dec. 19, AppRiver’s filters stopped 45,976,814 malicious emails sent by the Necurs botnet. Maximum traffic for it was a just more than 4.6 million emails per hour. These were all .7z that contained malicious .vbs files leading to an infection.” reads the analysis published by AppRiver.
Experts noticed that during the first day operators only used vbs files inside the .7z archive, while the second day they started using also .js files.
“On Dec. 21 and 22, the traffic switched back over to the .js files and began to taper off. We saw 36,290,981 and 29,602,971 messages blocked respectively, for those two days, before the botnet went quiet from Dec. 23-25. Today (Dec. 26), Necurs re-awoke from its slumber for a couple hours then went quiet again.” continues the analysis.
“Hard to say why, however, I would hypothesize the operators may have been testing or monitoring the rate of infections and realized many workers are on vacation. As of the time this blog was authored we’ve captured the below statistics for today”
The activity of the botnet increased again on Dec. 28-29, on the first day it peaked 6.5 million messages early morning, on the next day, the Necurs botnet sent out nearly 59 million ransomware messages.
Critical Flaw Reported In phpMyAdmin Lets Attackers Damage Databases
3.1.2017 thehackernews Vulnerebility
A critical security vulnerability has been reported in phpMyAdmin—one of the most popular applications for managing the MySQL database—which could allow remote attackers to perform dangerous database operations just by tricking administrators into clicking a link.
Discovered by an Indian security researcher, Ashutosh Barot, the vulnerability is a cross-site request forgery (CSRF) attack and affects phpMyAdmin versions 4.7.x (prior to 4.7.7).
Cross-site request forgery vulnerability, also known as XSRF, is an attack wherein an attacker tricks an authenticated user into executing an unwanted action.
According to an advisory released by phpMyAdmin, "by deceiving a user to click on a crafted URL, it is possible to perform harmful database operations such as deleting records, dropping/truncating tables, etc."
phpMyAdmin is a free and open source administration tool for MySQL and MariaDB and is widely used to manage the database for websites created with WordPress, Joomla, and many other content management platforms.
Moreover, a lot of hosting providers use phpMyAdmin to offer their customers a convenient way to organize their databases.
Barot has also released a video, as shown above, demonstrating how a remote attacker can make database admins unknowingly delete (DROP) an entire table from the database just by tricking them into clicking a specially crafted link.
"A feature of phpMyAdmin was using a GET request and after that POST request for Database operations such as DROP TABLE table_name; GET requests must be protected against CSRF attacks. In this case, POST requests were used which were sent through URL (for bookmarking purpose may be); it was possible for an attacker to trick a database admin into clicking a button and perform a drop table database query of the attacker’s choice." Barot explains in a blog post.
However, performing this attack is not simple as it may sound. To prepare a CSRF attack URL, the attacker should be aware of the name of targeted database and table.
"If a user executes a query on the database by clicking insert, DROP, etc. buttons, the URL will contain database name and table name," Barot says. "This vulnerability can result in the disclosure of sensitive information as the URL is stored at various places such as browser history, SIEM logs, Firewall Logs, ISP Logs, etc."
Barot reported the vulnerability to phpMyAdmin developers, who confirmed his finding and released phpMyAdmin 4.7.7 to address this issue. So administrators are highly recommended to update their installations as soon as possible.
15-Year-Old Apple macOS 0-Day Kernel Flaw Disclosed, Allows Root Access
3.1.2017 thehackernews Apple
A security researcher on New Year's eve made public the details of an unpatched security vulnerability in Apple's macOS operating system that can be exploited to take complete control of a system.
On the first day of 2018, a researcher using the online moniker Siguza released the details of the unpatched zero-day macOS vulnerability, which he suggests is at least 15 years old, and proof-of-concept (PoC) exploit code on GitHub.
The bug is a serious local privilege escalation (LPE) vulnerability that could enable an unprivileged user (attacker) to gain root access on the targeted system and execute malicious code. Malware designed to exploit this flaw could fully install itself deep within the system.
From looking at the source, Siguza believes this vulnerability has been around since at least 2002, but some clues suggest the flaw could actually be ten years older than that. "One tiny, ugly bug. Fifteen years. Full system compromise," he wrote.
This local privilege escalation flaw resides in IOHIDFamily, an extension of the macOS kernel which has been designed for human interface devices (HID), like a touchscreen or buttons, allowing an attacker to install a root shell or execute arbitrary code on the system.
"IOHIDFamily has been notorious in the past for the many race conditions it contained, which ultimately lead to large parts of it being rewritten to make use of command gates, as well as large parts being locked down by means of entitlements," the researcher explains.
"I was originally looking through its source in the hope of finding a low-hanging fruit that would let me compromise an iOS kernel, but what I didn’t know it then is that some parts of IOHIDFamily exist only on macOS - specifically IOHIDSystem, which contains the vulnerability."
The exploit created by Siguza, which he dubbed IOHIDeous, affects all versions of macOS and enables arbitrary read/write bug in the kernel.
Besides this, IOHIDeous also disables the System Integrity Protection (SIP) and Apple Mobile File Integrity (AMFI) security features that offer protection against malware.
The PoC code made available by Siguza has for some reason stopped working on macOS High Sierra 10.13.2 and works on macOS High Sierra 10.13.1 and earlier, but he believes the exploit code can be tweaked to work on the latest version as well.
However, the researcher pointed out that for his exploit to work, it needs to force a log out of the logged-in user, but this can be done by making the exploit work when the targeted machine is manually shut down or rebooted.
Since the vulnerability only affects macOS and is not remotely exploitable, the researcher decided to dumped his findings online instead of reporting it to Apple. For those unaware, Apple's bug bounty program does not cover macOS bugs.
For in-depth technical details about the vulnerability, you can head on to researcher's write-up on GitHub.
Flaw In Major Browsers Allows 3rd-Party Scripts to Steal Your Saved Passwords
3.1.2017 thehackernews Vulnerebility
Security researchers have uncovered how marketing companies have started exploiting an 11-year-old bug in browsers' built-in password managers, which allow them to secretly steal your email address for targeted advertising across different browsers and devices.
The major concern is that the same loophole could allow malicious actors to steal your saved usernames and passwords from browsers without requiring your interaction.
Every modern browser—Google Chrome, Mozilla Firefox, Opera or Microsoft Edge—today comes with a built-in easy-to-use password manager tool that allows you to save your login information for automatic form-filling.
These browser-based password managers are designed for convenience, as they automatically detect login form on a webpage and fill-in the saved credentials accordingly.
However, a team of researchers from Princeton's Center for Information Technology Policy has discovered that at least two marketing companies, AdThink and OnAudience, are actively exploiting such built-in password managers to track visitors of around 1,110 of the Alexa top 1 million sites across the Internet.
Third-party tracking scripts found by researchers on these websites inject invisible login forms in the background of the webpage, tricking browser-based password managers into auto-filling the form using the saved user's information.
"Login form auto filling in general doesn't require user interaction; all of the major browsers will autofill the username (often an email address) immediately, regardless of the visibility of the form," the researchers say.
"Chrome doesn't autofill the password field until the user clicks or touches anywhere on the page. Other browsers we tested don't require user interaction to autofill password fields."
Since these scripts are primarily designed for user-tracking, they detect the username and send it to third-party servers after hashing with MD5, SHA1 and SHA256 algorithms, which could then be used as a persistent ID for a specific user to track him/her from page to page.
"Email addresses are unique and persistent, and thus the hash of an email address is an excellent tracking identifier," the researchers said. "A user's email address will almost never change—clearing cookies, using private browsing mode, or switching devices won't prevent tracking."
Although the researchers have spotted marketing firms scooping up your usernames using such tracking scripts, there is no technical measure to prevent these scripts from collecting your passwords the same way.
However, most third-party password managers, like LastPass and 1Password, are not prone to this attack, since they avoid auto-filling invisible forms and require user interaction as well.
Researchers have also created a demo page, where you can test if your browser's password manager also leaks your username and password to invisible forms.
The simplest way to prevent such attacks is to disable the autofill function on your browser.
Many GPS Tracking Services Expose User Location, Other Data
3.1.2017 securityweek Privacy
Researchers discovered that many online services designed for managing location tracking devices are affected by vulnerabilities that expose potentially sensitive information.
Fitness, child, pet and vehicle trackers, and other devices that include GPS and GSM tracking capabilities are typically managed via specialized online services.
Security experts Vangelis Stykas and Michael Gruhn found that over 100 such services have flaws that can be exploited by malicious actors to gain access to device and personal data. The security holes, dubbed Trackmageddon, can expose information such as current location, location history, device model and type, serial number, and phone number.
Some services used by devices that have photo and audio recording capabilities also expose images and audio files. In some cases, it’s also possible to send commands to devices in order to activate or deactivate certain features, such as geofence alerts.
Attackers can gain access to information by exploiting default credentials (e.g. 123456), and insecure direct object reference (IDOR) flaws, which allow an authenticated user to access other users’ accounts simply by changing the value of a parameter in the URL. The services also expose information through directory listings, log files, source code, WSDL files, and publicly exposed API endpoints that allow unauthenticated access.
Stykas and Gruhn have notified a vast majority of the affected vendors in November and December. Nine services have confirmed patching the flaws or promised to implement fixes soon, and over a dozen websites appear to have addressed the vulnerabilities without informing the researchers. However, the rest of the tracking services remain vulnerable.
There are roughly 100 impacted domains, but some of them appear to be operated by the same company. Researchers have identified 36 unique IPs hosting these domains and 41 databases that they share. They estimate that these services expose data associated with over 6.3 million devices and more than 360 device models.
The vulnerable software appears to come from China-based ThinkRace, but in many cases the company does not have control over the servers hosting the tracking services.
Gruhn and Stykas pointed out that vulnerabilities in ThinkRace products – possibly including some of the issues disclosed now – were first discovered in 2015 by a New Zealand-based expert while analyzing car tracking and immobilisation devices that relied on ThinkRace software.
Users of the online tracking services that remain vulnerable have been advised to change their password and remove any potentially sensitive information stored in their account. However, these are only partial solutions to the problem and researchers have advised people to simply stop using affected devices until patches are rolled out.
Critical Vulnerability Patched in phpMyAdmin
3.1.2017 securityweek Vulnerebility
An update released just before the holidays by the developers of phpMyAdmin patches a serious vulnerability that can be exploited to perform harmful database operations by getting targeted administrators to click on specially crafted links.
phpMyAdmin is a free and open source tool designed for managing MySQL databases over the Internet. With more than 200,000 downloads every month, phpMyAdmin is one of the top MySQL database administration tools.
India-based researcher Ashutosh Barot discovered that phpMyAdmin is affected by a cross-site request forgery (CSRF) flaw that can be exploited by an attacker to drop tables, delete records, and perform other database operations.
For the attack to work, an authenticated admin needs to click on a specially crafted URL. However, Barot noted that the attack works as long as the user is logged in to the cPanel web hosting administration interface, even if phpMyAdmin has been closed after use.
These types of attacks are possible due to the fact that vulnerable versions of phpMyAdmin use GET requests for database operations, but fail to provide CSRF protection.
The researcher also discovered that the URLs associated with database operations performed via phpMyAdmin are stored in the web browser history, which can pose security risks.
“The URL will contain database name and table name as a GET request was used to perform DB operations,” Barot said in a blog post published on Friday. “URLs are stored at various places such as browser history, SIEM logs, firewall logs, ISP logs, etc. This URL is always visible at client side, it can be a serious issue if you are not using SSL (some information about your previous queries were stored in someone’s logs!). Wherever the URL is being saved, an adversary can gain some information about your database.”
phpMyAdmin developers fixed the CSRF vulnerability found by Barot with the release of version 4.7.7. All prior 4.7.x versions are impacted by the security hole, which phpMyAdmin has classified as “critical.” Users have been advised to update their installations or apply the available patch.
Necurs Botnet Fuels Massive Year-End Ransomware Attacks
3.1.2017 securityweek Ransomware
The Necurs botnet started 2017 with a four-month vacation, but ended the year sending tens of millions of spam emails daily as part of massive ransomware distribution campaigns.
Considered the largest spam botnet at the moment, Necurs was the main driver behind the ascension of the Locky ransomware (which in turn is associated with the Dridex banking Trojan) in 2016. As Necurs took a long vacation in the beginning of 2017, Locky was silent as well, but both resumed activity in April.
Over the course of 2017, however, the botnet was involved in the distribution of the Jaff, GlobeImposter, and Scarab ransomware families, as well as in 'pump-and-dump' schemes.
Over a 10-day period between December 19 and December 29, 2017, Necurs was once again involved in the distribution of ransomware, in addition to sending typical holiday-themed scam emails, data collected by AppRiver reveals.
The messages, AppRiver says, were distributing the Locky and GlobeImposter ransomware families and revealed the attackers’ preference to use malicious .vbs (Visual Basic Script) or .js (JavaScript) files located inside a .7z archive.
Consisting of between 5 and 6 million infected hosts and keeping around 1 or 2 million of them active at any given time, Necurs provides operators with remote access to the infected machines and can be used for various malicious activities, including malware downloads.
Starting on Dec. 19, the botnet was observed sending tens of millions of spam emails daily to distribute ransomware. It started at nearly 46 million emails on the first day (peaking at over 4.6 million messages per hour) and continued with over 47 million messages on Dec. 20 (peaking at 5.7 million per hour).
While the initial spam featured mainly .vbs files inside the .7z archive, .js files started appearing as well on the second day, and the traffic switched to .js files on Dec. 21-22, when it also started to taper off, at 36 million and 29 million messages per day, respectively. The botnet remained quiet from Dec. 23-25 and recommenced activity for only a couple of hours on Dec. 26.
“Hard to say why, however, I would hypothesize the operators may have been testing or monitoring the rate of infections and realized many workers are on vacation,” AppRiver’s David Pickett notes.
On Dec. 28-29, however, the botnet was highly active. It peaked at 6.5 million messages early morning on Dec. 28, but wasn’t active for long. On the next day, Necurs was observed sending nearly 59 million ransomware messages.
The malicious emails, the security researchers reveal, were masquerading as purchase orders and voicemails, but also claimed to contain images of interest to the intended victims.
Internet-connected Sonos Speakers Leak User Information
3.1.2017 securityweek Vulnerebility
A vulnerability found in Internet-connected Sonos Play:1 speakers can be abused to access information on users, Trend Micro has discovered.
By exploiting the issue, an attacker could learn a user’s musical preferences, get hold of their email address, and could even learn where the user lives and whether they are at home. Additionally, an attacker could play a recorded message on the device and trick the target into downloading malware.
While analyzing the device, Trend Micro’s researchers discovered the device had only three ports open and that Sonos applications on it were pointed to a specific website, while most of the communications were performed over port TCP/1400.
Looking at the specific URI path of /status on the device, the researchers also noticed that many of its subpages were shown via a simple website. Thus, no authentication was required to access information about the tracks being played or the music libraries the device knows about.
Furthermore, the website revealed personal information such as emails associated with audio streaming services and exposed various debug functions, including “the ability to traceroute, ping, and even make an mDNS announcement via a simple website,” the researchers say. The status page can reveal other information as well.
“Let’s say an attacker knows the target uses a Sonos device. The attacker can then take the information collected here to tailor better attacks against the target. This could include mobile devices, printers, and even types of computers on the networks,” Trend Micro notes in a technical analysis (PDF).
The security researchers also discovered a series of plausible attack scenarios that could be used not only against home users, but also to target enterprise networks.
By learning the user’s musical preferences, an attacker could craft phishing emails and deliver them to the target. In a workplace environment, such an attack could be used to discover other IoT devices connected to the same network and find vulnerabilities on them to further compromise the network.
Using a website that compounds multiple sources of Wi-Fi geolocation an attacker could also find where the user lives (the researchers determined the device location by looking at the wireless access points (WAPs) the device tried to access during installation) and whether they are at home by monitoring when the speaker is activated and deactivated.
“This hybrid attack involving cyber and physical elements presents new dangers that home and enterprise users should be aware of. Devices leaking presence data not only make users easier to predict — they can also put the user at physical risk,” the researchers say.
Leveraging information discovered on the aforementioned status page, including model numbers and serial numbers, an attacker could disrupt the device and even play a crafted status message containing misleading information.
The attacker could also send tailored emails to the user (to the addresses tied to accounts on music streaming applications) and trick them into downloading malware masquerading as a software update. Using other discoverable information on the target, the attacker could add personalized information to the message to make it even more convincing.
With the help of search service Shodan, the security researchers were able to find roughly 5,000 Sonos devices exposed to the Internet. The manufacturer was informed on the findings and has already released and updated to address the discovered bugs, but some of the issues continue to impact users, Trend Micro says.
“The problem of unsecured internet-connected devices is not limited to home users but also extends to workplace environments when seemingly safe IoT devices are introduced into the company network, as was shown in the attack scenarios. Whether these devices are installed to improve productivity or are simply brought to work by employees, the risk of having an exposed and unsecured device should not be taken lightly,” Trend Micro concludes.
Former NSA hacker reversed Kaspersky Lab antivirus to compose signatures capable of detecting classified documents
2.1.2017 securityaffairs BigBrothers
Former NSA hacker, demonstrated how to subvert the Kaspersky Lab antivirus and turn it into a powerful search tool for classified documents.
The Kaspersky case demonstrated that security software can be exploited by intelligence agencies as a powerful spy tool.
Patrick Wardle, chief research officer at Digita Security and former NSA hacker, demonstrated it by subverting the Kaspersky Lab antivirus and turning it into a powerful search tool for classified documents.
“In the battle against malicious code, antivirus products are a staple,” Patrick Wardle told the New York Times. “Ironically, though, these products share many characteristics with the advanced cyberespionage collection implants they seek to detect.”
“I wanted to know if this was a feasible attack mechanism,” Mr. Wardle added. “I didn’t want to get into the complex accusations. But from a technical point of view, if an antivirus maker wanted to, was coerced to, or was hacked or somehow subverted, could it create a signature to flag classified documents?”
In December, US President Donald Trump signed a bill that bans the use of Kaspersky Lab products and services in federal agencies.
According to a draft of a top-secret report leaked by Edward J. Snowden, the NSA at least since 2008 was targeting antivirus software (i.e. Checkpoint and Avast) to collect sensitive information stored in the target machines.
Mr. Wardle conducted a reverse-engineering of Kaspersky Lab antivirus software to explore the possibility to abuse it for intelligence purposes. The expert’s goal was to compose a signature that is able to detect classified documents.
Mr. Wardle discovered that the code incredibly complex, unlike traditional antivirus software, Kaspersky’s malware signatures are easily updated. This feature can be tweaked to automatically scan the victim’s machine and steal classified documents.
“Modern anti-virus products are incredibly complex pieces of software and Kaspersky is likely one of the most complex. Thus, merely gaining a reasonable understanding of its signatures and scanning logic is a challenging task.” wrote Wardle.
“Though the installer ships with built-in signatures, as is the case with any anti-virus program, Kaspersky’s anti-virus engine regularly checks for, and automatically installs any new signatures” “When new signatures are available, they are downloaded by the kav daemon from Kaspersky’s update servers”
Wardle found antivirus scanning could be the used for cyberespionage activities.
The expert pointed out that officials routinely classify top secret documents with the marking “TS/SCI,” (“Top Secret/Sensitive Compartmented Information),” then he added a rule to Kaspersky’s antivirus program to flag any documents that contained the “TS/SCI” marker.
To test the new rule, the researcher edited a document on his computer containing text from the Winnie the Pooh children’s book series and added “TS/SC” marker.
As soon as the Winnie the Pooh document was saved to his machine, the Kaspersky’s antivirus software flagged and quarantined the document.
The successive phase of Wardle’s test was on discovering how flagged documents are managed, but it normal that an antivirus software send data back to the company for further analysis.
Kaspersky Lab explained that Wardle’s research is not corrected because the company is not able to deliver a specific signature or update to only one user in a stealthy way.
“It is impossible for Kaspersky Lab to deliver a specific signature or update to only one user in a secret, targeted way because all signatures are always openly available to all our users; and updates are digitally signed, further making it impossible to fake an update,” Kaspersky said in a statement.
Anyway, Wardle’s research demonstrated that hacking vendor’s platforms it is possible to use the antivirus as a search tool.
“However, a malicious or willing insider within any anti-virus company, who could tactically deployed such a signature, would likely remain undetected. And of course, in a hypothetical scenario; any anti-virus company that is coerced to, or is willing to work with a larger entity (such as a governemnt) would equally be able to stealthily leverage their product to detect and exfilitrate any files of interest.” concluded the expert.
“Sometimes the line between what is good and evil, comes down to a signal signature… “
Iran ‘s Government is reportedly blocking the Internet to calm down protests
2.1.2017 securityaffairs BigBrothers
The Iran Government is also trying to isolate the protests by blocking internet on mobile networks, authorities are blocking Instagram and messaging services like Telegram.
At least 12 people dead in the biggest challenge to the Government of the Tehran regime since mass demonstrations in 2009. The Iranian President Hassan Rouhani tried to downplay the dangerous situation, while violent protests mount across the country.
The Government is also trying to isolate the protests by blocking internet on mobile networks, multiple reports confirm the authorities are blocking social media services like Instagram and messaging services like Telegram since December 30.
“It’s a busy weekend for oppressive governments trying to suppress digital communication. Iran has blocked mobile access to at least Telegram and Instagram as it tries to thwart protests that started over economic concerns (particularly inflation), but have extended into broader resistance to the government and clerical rule.” reported the website engadget.com.
“Officials claim the censorship is meant to “maintain peace,” but the argument doesn’t hold water. Telegram founder Pavel Durov noted that his company refused to shut down “peacefully protesting channels,” and Instagram is primarily being used to document protests — Iran clearly doesn’t want to reveal the extent of the demonstrations.”
Pavel Durov
✔
@durov
Iranian authorities are blocking access to Telegram for the majority of Iranians after our public refusal to shut down https://t.me/sedaiemardom and other peacefully protesting channels.
1:17 PM - Dec 31, 2017 · Dubai, United Arab Emirates
1,058 1,058 Replies 2,944 2,944 Retweets 5,358 5,358 likes
Twitter Ads info and privacy
The Government fears that technology could amplify the protests like happened during the Arab Spring.
“The authorities appeared to respond by cutting internet access to mobile phones, with the main networks interrupted at least in Tehran shortly before midnight” AFP reporters said.
“Several Iranian news agencies warned Telegram, the most popular social media service in the country, might soon be shut down after communications minister Mohammad-Javad Azari Jahromi accused one popular channel, Amadnews, of encouraging an “armed uprising”.”
1 Jan
Kavé Salamatian
@kavesalamatian
@bgpmon @InternetIntel Changes in Iran BGP connectivity happening right now. Seems that the full internet is getting disconnected
@InternetIntel
Large routing outage in Iran about 2hrs ago. pic.twitter.com/382BYEIscF
4:35 PM - Jan 1, 2018
View image on Twitter
5 5 Replies 75 75 Retweets 51 51 likes
Twitter Ads info and privacy
Iran Freedom
@4FreedominIran
#Sanandaj, January 1 - Large crowd took to streets confronting oppressive security forces. Some were arrested. (via #MEK activists in #Iran) #FreeIran #Iranprotests #IranProtests #Iran #RegimeChange
4:55 PM - Jan 1, 2018
1 1 Reply 111 111 Retweets 82 82 likes
Twitter Ads info and privacy
“How nervous the government is about losing control over the population is proportional to various control tactics they implement over the Internet,” Mahsa Alimardani, who researches internet freedoms in Iran for Article 19, told Motherboard. “In the past few hours there are also some reports of home connections (up until today mostly left undisturbed) also facing some blocks to accessing foreign web content.”
At the time I’m writing it is not clear the real effect on the Internet access by the population, in the following graph it is visible the increase in the number of directly connecting users to the Tor network.
During Iran’s elections earlier this year, Rouhani promised to cut down on censorship, but evidently, it was only political propaganda.
Force 47 – The Vietnamese brigade tasked with fighting “wrongful views” spreading online
2.1.2017 securityaffairs APT
Force 47 is a brigade composed of 10,000 cyber warriors to fight online dissent in Vietnam, a new threat to freedom of speech in the country.
Like many other Governments, also Vietnam is deploying a cyber army of 10000 cyber experts to fight online dissent in the country.
The news was revealed by a top Vietnamese general last week, the official that the brigade dubbed ‘Force 47’ has been tasked with fighting “wrongful views” spreading online.
More than half of the population (around 93 million people) has access to the Internet.
According to web watchdog Freedom House, the Internet in Vietnam is “not free”, the organization ranked it second only to China in Asia.
Human Rights Watch deputy Asia director Phil Robertson believes that the brigade Force 47 is a “shocking new dimension to Vietnam’s crackdown on dissent”.
“This is just the latest plank in a campaign to curb internet freedoms at all costs,” Shawn Crispin, Committee to Protect Journalists’ Southeast Asia representative, told AFP Friday.
“While they can’t unplug Facebook, Instagram and the likes outright, they can apply more and more pressure on those platforms and it looks like these cyber troops are their latest attempt to do that.”
The activist Nguyen Chi Tuyen (aka Anh Chi) said the new brigade is an important step in ahead of online repression.
“The main purpose for Force 47 is to try and control news and public opinion on the internet… they want to protect the party, not protect the country,” explained Tuyen.
The Vietnamese Government is applying a strict online monitoring, it continues to ask tech giants like Facebook and YouTube to remove any “toxic content” from their platforms.
The Vietnamese Government believes that hostile groups and foreign governments could use social media and the Internet to destabilize the country and threaten the “prestige of the party’s leaders and the state”.
According to Amnesty International, many dissidents have already been identified and arrested in the country, at least 15 people this year.
Madeline Earp, a senior research analyst with Freedom House, explained that the unit Force 47 is likely to include commentators tasked of spreading online pro-government content and counter critics.
“Vietnam very much follows China’s example when suppressing internet freedom, particularly when it comes to blocking websites and arresting dissidents,” she told AFP.
Vietnam had built up considerable cyber capabilities in across the years, according to the incident response firm Volexity, Vietnamese APT32 group is today one of the most advanced APTs in the threat landscape.
Expert publicly disclosed a macOS zero-day that allows local privilege escalation
2.1.2017 securityaffairs Apple
A security researcher has publicly disclosed the details of macOS zero-day flaw that can be exploited to take complete control of a system.
A security researcher that goes online with the Twitter account Siguza (@s1guza) has publicly disclosed the details of macOS zero-day vulnerability that can be exploited to take complete control of a system. The expert speculates the flaw has been around since at least 2002
Siguza
@s1guza
Fuck it, dropping a macOS 0day. Happy New Year, everyone. https://siguza.github.io/IOHIDeous/
11:59 PM - Dec 31, 2017
119 119 Replies 2,634 2,634 Retweets 4,407 4,407 likes
Twitter Ads info and privacy
The flaw is a local privilege escalation (LPE) vulnerability that affects IOHIDFamily, a kernel extension designed for human interface devices (HID) (e.g. the touchscreen, buttons, accelerometer, etc.).
The flaws discovered by the expert affect all versions of macOS and they can lead to an arbitrary read/write vulnerability in the kernel.
An attacker who has access to a system can trigger the zero-day flaw to execute arbitrary code and gain root permissions.
The expert was analyzing the iOS code searching for vulnerabilities in the iOS kernel when he discovered that the component IOHIDSystem exists only on macOS.
“I was originally looking through its source in the hope of finding a low-hanging fruit that would let me compromise an iOS kernel, but what I didn’t know it then is that some parts of IOHIDFamily exist only on macOS – specifically IOHIDSystem, which contains the vulnerability discussed herein.” Siguza wrote in the technical analysis published on gitHub.
The expert published a PoC code, dubbed IOHIDeous, that works for Sierra and High Sierra (up to 10.13.1, see README) and is able to disable both the System Integrity Protection (SIP) and Apple Mobile File Integrity (AMFI).
“Targets Sierra and High Sierra (up to 10.13.1, see README), achieves full kernel r/w and disables SIP to prove that the vulnerability can be exploited by any unprivileged user on all recent versions of macOS.” continues the expert.
The exploit code developed by the expert runs as fast as possible to avoid user interaction, for example on a shutdown “we’d be able to slip in between the user getting logged out and the kernel killing us.”
The PoC code published by Siguza seems not work on macOS High Sierra 10.13.2 released on December 6, but the expert believes that this version is still vulnerable.
“The prefetch timing attack I’m using for hid for some reason doesn’t work on High Sierra 10.13.2 anymore, and I don’t feel like investigating that.” said Siguza.
“Maybe patched, maybe just the consequence of a random change, I neither know nor care. The vuln is still there and my code does both info leak and kernel r/w, just not in the same binary – reason is explained in the write-up. If you want that feature, consider it an exercise for the reader.”
Siguza publicly disclosed this macOS zero-day because it is exploitable only by a local attacker and because Apple bug bounty doesn’t cover it.
1 Jan
Security Around The World
@security_china
Replying to @s1guza
Can I ask, why not sell it? I'm sure some government or blackhat would have paid a lot for it? Or are you just the type of person who can't be reasoned with, who doesn't care for money and just want to watch the world burn?
Siguza
@s1guza
My primary goal was to get the write-up out for people to read. I wouldn't sell to blackhats because I don't wanna help their cause. I would've submitted to Apple if their bug bounty included macOS, or if the vuln was remotely exploitable.
3:43 PM - Jan 1, 2018
4 4 Replies 11 11 Retweets 150 150 likes
CSRF Vulnerability in phpMyAdmin allows attackers to perform DROP TABLE with a single click!
2.1.2017 securityaffairs Vulnerebility
The development team of phpMyAdmin has fixed a CSRF vulnerability in phpMyAdmin that could be exploited by attackers for removing items from shopping cart.
Researcher Ashutosh Barot has discovered a critical CSRF vulnerability in phpMyAdmin that could be exploited by attackers to perform malicious operations like drop tables and delete records.
phpMyAdmin developers released the version 4.7.7 that addresses the CSRF vulnerability found by Barot.
“By deceiving a user to click on a crafted URL, it is possible to perform harmful database operations such as deleting records, dropping/truncating tables etc.” reads the security advisory published by phpMyAdmin developers.
An attacker could trick a database admin into performing database operations like DROP TABLE using CSRF with devastating consequences.
“In this case, a CSRF vulnerability allows an attacker to send a crafted URL to the victim and if she (authenticated user) clicks it, the victim may perform a DROP TABLE query on her database. phpMyAdmin team considers this issue as critical vulnerability.” reads the analysis published by Ashutosh Barot.
This means that an attacker can create a crafted URL and trick the victims having an active session into performing dangerous operations without their knowledge.
The expert discovered a feature in phpMyAdmin that uses GET requests for Database operations such as DROP TABLE table_name, this means that it is possible for an attacker to trick a database admin into clicking a button and perform a database query of the attacker’s choice.
Ashutosh Barot also discovered that the URL for performing database operations was being saved in the browser history, an attacker can access them to gain some information about the database.
“Any query you execute by clicking insert, DROP, etc., button as shown in above image . The URL will contain database name and table name as GET request was used to perform DB Operations. URLs are stored at various places such as browser history, SIEM logs, Firewall Logs, ISP Logs, etc. this URL is always visible at client side, it can be a serious issue if you are not using SSL (some information about your previous queries were stored in someone’s logs!)” continues the analysis. 
The expert pointed out that the CSRF attack worked even when the user was authenticated in cPanel and phpMyAdmin was closed after use.
The vulnerability is ranked as Medium severity because its exploitation needs the user interaction.
Below a video PoC published by Barot:
All versions prior 4.7.7 are affected by the vulnerability, users must update their installations or apply the following patches:
The following commits have been made on the 4.7 branch to fix this issue:
edd929216ade9f7c150a262ba3db44db0fed0e1b
The following commits have been made on the 4.8 branch to fix this issue:
72f109a99c82b14c07dcb19946ba9b76efc32a1b
Necurs Botnet Fuels Massive Year-End Ransomware Attacks
2.1.2017 securityweek Ransomware
The Necurs botnet started 2017 with a four-month vacation, but ended the year sending tens of millions of spam emails daily as part of massive ransomware distribution campaigns.
Considered the largest spam botnet at the moment, Necurs was the main driver behind the ascension of the Locky ransomware (which in turn is associated with the Dridex banking Trojan) in 2016. As Necurs took a long vacation in the beginning of 2017, Locky was silent as well, but both resumed activity in April.
Over the course of 2017, however, the botnet was involved in the distribution of the Jaff, GlobeImposter, and Scarab ransomware families, as well as in 'pump-and-dump' schemes.
Over a 10-day period between December 19 and December 29, 2017, Necurs was once again involved in the distribution of ransomware, in addition to sending typical holiday-themed scam emails, data collected by AppRiver reveals.
The messages, AppRiver says, were distributing the Locky and GlobeImposter ransomware families and revealed the attackers’ preference to use malicious .vbs (Visual Basic Script) or .js (JavaScript) files located inside a .7z archive.
Consisting of between 5 and 6 million infected hosts and keeping around 1 or 2 million of them active at any given time, Necurs provides operators with remote access to the infected machines and can be used for various malicious activities, including malware downloads.
Starting on Dec. 19, the botnet was observed sending tens of millions of spam emails daily to distribute ransomware. It started at nearly 46 million emails on the first day (peaking at over 4.6 million messages per hour) and continued with over 47 million messages on Dec. 20 (peaking at 5.7 million per hour).
While the initial spam featured mainly .vbs files inside the .7z archive, .js files started appearing as well on the second day, and the traffic switched to .js files on Dec. 21-22, when it also started to taper off, at 36 million and 29 million messages per day, respectively. The botnet remained quiet from Dec. 23-25 and recommenced activity for only a couple of hours on Dec. 26.
“Hard to say why, however, I would hypothesize the operators may have been testing or monitoring the rate of infections and realized many workers are on vacation,” AppRiver’s David Pickett notes.
On Dec. 28-29, however, the botnet was highly active. It peaked at 6.5 million messages early morning on Dec. 28, but wasn’t active for long. On the next day, Necurs was observed sending nearly 59 million ransomware messages.
The malicious emails, the security researchers reveal, were masquerading as purchase orders and voicemails, but also claimed to contain images of interest to the intended victims.
Unpatched macOS Flaw Allows Code Execution, Root Access
2.1.2017 securityweek Apple
A researcher who specializes in hacking Apple’s iOS operating system has made public the details of an unpatched vulnerability in macOS that can be exploited to take complete control of a system.
The details of the exploit and proof-of-concept (PoC) code were made public on the first day of 2018 – or the last day of 2017, depending on where you are located in the world – by a researcher who uses the online moniker Siguza (s1guza). An attacker who has access to a system can leverage the vulnerability, which the expert has described as a “zero day,” to execute arbitrary code and obtain root permissions.
This local privilege escalation (LPE) vulnerability affects IOHIDFamily, a kernel extension designed for human interface devices (HID), such as a touchscreen or buttons. While trying to discover flaws that would let him hack the iOS kernel, Siguza noticed that some components of this extension, specifically IOHIDSystem, exist only on macOS, which led him to identify a potentially serious security hole.
The bugs he discovered affect all versions of macOS and they can lead to an arbitrary read/write vulnerability in the kernel. The exploit created by the hacker also disables the System Integrity Protection (SIP) and Apple Mobile File Integrity (AMFI) security features.
However, the expert pointed out that his exploit, dubbed IOHIDeous, is not stealthy as it needs to force a logout of the logged-in user. On the other hand, an attacker could design an exploit that is triggered when the targeted device is manually shut down or rebooted.
Some of the PoC code made available by Siguza only works on macOS High Sierra 10.13.1 and earlier, but the researcher believes the exploit can be tweaked to work on the latest version as well, namely 10.13.2, which Apple released on December 6.
The expert believes the vulnerability has been around since at least 2002, but some clues suggest it could actually be a decade older than that. “One tiny, ugly bug. Fifteen years. Full system compromise,” Siguza said.
The researcher said he would have reported his findings to Apple instead of disclosing them to the public if the flaw had been remotely exploitable or if the tech giant’s bug bounty program covered macOS.
SecurityWeek has reached out to Apple for comment and will update this article if the company responds.
Some may argue that making the exploit public puts macOS users at risk of attacks, but Siguza believes that is not the case.
Critical Vulnerability Patched in phpMyAdmin
2.1.2017 securityweek Vulnerebility
An update released just before the holidays by the developers of phpMyAdmin patches a serious vulnerability that can be exploited to perform harmful database operations by getting targeted administrators to click on specially crafted links.
phpMyAdmin is a free and open source tool designed for managing MySQL databases over the Internet. With more than 200,000 downloads every month, phpMyAdmin is one of the top MySQL database administration tools.
India-based researcher Ashutosh Barot discovered that phpMyAdmin is affected by a cross-site request forgery (CSRF) flaw that can be exploited by an attacker to drop tables, delete records, and perform other database operations.
For the attack to work, an authenticated admin needs to click on a specially crafted URL. However, Barot noted that the attack works as long as the user is logged in to the cPanel web hosting administration interface, even if phpMyAdmin has been closed after use.
These types of attacks are possible due to the fact that vulnerable versions of phpMyAdmin use GET requests for database operations, but fail to provide CSRF protection.
The researcher also discovered that the URLs associated with database operations performed via phpMyAdmin are stored in the web browser history, which can pose security risks.
“The URL will contain database name and table name as a GET request was used to perform DB operations,” Barot said in a blog post published on Friday. “URLs are stored at various places such as browser history, SIEM logs, firewall logs, ISP logs, etc. This URL is always visible at client side, it can be a serious issue if you are not using SSL (some information about your previous queries were stored in someone’s logs!). Wherever the URL is being saved, an adversary can gain some information about your database.”
phpMyAdmin developers fixed the CSRF vulnerability found by Barot with the release of version 4.7.7. All prior 4.7.x versions are impacted by the security hole, which phpMyAdmin has classified as “critical.” Users have been advised to update their installations or apply the available patch.
Botnet's Huawei Router Exploit Code Now Public
2.1.2017 securityweek Exploit
Exploit code used by the Satori botnet to compromise Huawei routers via a zero-day vulnerability became public last week, researchers have discovered.
The exploit has been used in attacks involving the Mirai variant Satori to target Huawei vulnerability CVE-2017–17215, which was unpatched at the time the first assaults started. The vulnerability was found in Huawei HG532 devices in November. Shortly after, Huawei published an advisory on how users can circumvent or prevent the exploit.
Discovered on Pastebin this Christmas, the code could fuel a spike in attempts to exploit the vulnerability. In fact, it has been already used by the destructive BrickerBot malware to target Internet of Things (IoT) devices, NewSky Security says.
In early December, the actor behind BrickerBot dumped some of the code online and announced plans to retire his project. The released code included some of the malware’s attack modules, including one that targeted said Huawei flaw, researchers have discovered.
“While analyzing this code, we also uncovered the usage of CVE-2017–17215, implying that this code has been in blackhats’ hands for a while,” NewSky reveals.
While analyzing the Satori and BrickerBot code, the security researchers noticed that the same attack vector (code injection) is present in both, which led to the conclusion that both malware developers “had copied the exploit source code from the same source.”
The security researchers also point out that the SOAP protocol (Simple Object Access Protocol) has been abused before in attacks involving IoT devices. Several Mirai variants observed last year were using two other SOAP bugs (CVE-2014–8361 and TR-64). One iteration was using them together, to increase the chances of a successful attack.
“IoT attacks are becoming modular day by day. When an IoT exploit becomes freely available, it hardly takes much time for threat actors to up their arsenal and implement the exploit as one of the attack vectors in their botnet code,” NewSky concludes.
Jak reagovat na incidenty ve věku cloudů?
2.1.2017 SecurityWorld Incidenty
Platforma pro reakce na incidenty může pomoci interním i externím týmům spolupracovat, sledovat procesy reakcí na incidenty a automatizovat důležité úlohy zabezpečení.
Většina ředitelů zabezpečení informací zažívá drsné probuzení, když se setkají se svým prvním významným bezpečnostním problémem v cloudu. Pokud zjistí kritickou zranitelnost, která vyžaduje opravu, může jim chybět povolení ke změnám v prostředí připraveném od poskytovatele cloudu. Pokud zákazník síť nevlastní, nemusí existovat způsob, jak získat podrobnosti zásadní pro vyšetření incidentu.
Aby se v cloudu zabránilo významným bezpečnostním problémům, musí mít ředitel zabezpečení informací plán reakcí na incidenty. Zde je návod, jak ho vytvořit:
1. Stanovte společný plán reakce s poskytovatelem cloudu. Pokud jste ještě do cloudu nepřešli, je nejpraktičtějším prvním krokem stanovení společného procesu reakcí. Je potřebné jasně definovat odpovědnosti a role a vzájemně si vyměnit kontaktní informace pro primární a sekundární kontakty. Získejte podrobné vysvětlení toho, co u poskytovatele vyvolává reakci na incidenty a jak bude poskytovatel řešit různé problémy.
2. Vyhodnoťte způsob monitoringu a bezpečnostní opatření používané v daném cloudu. Pro zajištění efektivní reakce na bezpečnostní problémy související s cloudovou infrastrukturou je důležité pochopit, jaký druh monitorovacích a bezpečnostních opatření používá poskytovatel cloudu a jakým způsobem jsou pro vás tyto nástroje dostupné. Pokud zjistíte, že jsou nedostatečné, hledejte způsoby, jak lze nasadit doplňující řešení, které to napraví.
3. Vytvořte plán obnovy. Rozhodněte, zda bude v případě výpadku u poskytovatele nutná obnova. Vytvořte plán obnovy, který určí, jestli se má použít alternativní poskytovatel nebo interní vybavení, a stanoví také postup pro získání a přesun dat.
4. Vyhodnoťte forenzní nástroje pro cloudovou infrastrukturu. Zjistěte, jaké nástroje jsou k dispozici od poskytovatele cloudu a z dalších zdrojů pro forenzní šetření v případě incidentu. Pokud incident zahrnuje citlivé osobní údaje, mohl by přerůst v právní problém, takže je dostupnost vhodných nástrojů pro forenzní práci a sledování důkazů zásadní.
Zvládnutí incidentu v cloudu
Při reakci na incident je mnoho kroků stejných nehledě na to, zda k němu došlo v cloudu či v interní infrastruktuře. V případě cloudového incidentu však existují některé další kroky, které je potřebné udělat:
Ihned kontaktujte tým reakce na incidenty daného poskytovatele a při komunikaci buďte důrazní. Pokud je tým poskytovatele nedostupný, udělejte v souvislosti s incidentem vše, co je ve vašich možnostech pro jeho zastavení – například kontroly připojení ke cloudové službě a v případě pochyb také zrušení uživatelského přístupu ke cloudové službě.
Pokud nelze incident kontrolovat, ani zastavit, připravte si přesun na alternativní službu nebo si nakonfigurujte svůj interní server.
Cloud vám umožní odložit identifikaci a odstranění na dobu po skončení krize. Ve většině případů můžete okamžitě zahájit obnovení produkčních služeb vytvořením nové instance.
Nejlepší postupy pro reakce na incidenty v cloudu
Jedním z kritických problémů, kterým mnoho podniků čelí, je nedostatek talentovaných pracovních sil s potřebnými schopnostmi pro správu zabezpečení. Je těžké najít vhodné kandidáty, a pokud je najdete, můžete čekat, že jim budete muset nabídnout vysoké platy. Statistický úřad ministerstva práce USA očekává, že do roku 2024 vzroste počet pracovních míst v oblasti analýz bezpečnostních informací o 18 % a průměrné platy v dolarech jsou šesticiferné již nyní.
Existují však některé kroky, které můžete udělat, abyste rychle zaškolili nové zaměstnance a zlepšili schopnosti zaměstnanců současných:
Podporujte spolupráci, která pomůže mladším analytikům učit se ze zkušeností vedoucích analytiků. Jako bonus může kooperace odhalit duplicitní činnosti, které lze odstranit.
Vytvářejte příručky, které popíšou standardní postupy pro reakce na incidenty. Samozřejmě nelze vytvořit návod pro každou možnou situaci, ale příručky mohou být cennými průvodci a vynikajícími školicími materiály. Jen nezapomínejte příručky aktualizovat, což je úloha, kterou lze často zautomatizovat.
Když už mluvíme o automatizaci, mnoho úloh je možné automatizovat, zejména pokud se opakují a jsou rutinní. Běžné úlohy zabírají nepřijatelné množství času. Automatizace může uvolnit váš personál pro důležitější úkoly.
Podporujte vznik situační všímavosti z perspektivy historické i z perspektivy reálného času. Efektivní analýza minulých incidentů vám pomůže k lepšímu rozhodování o incidentech současných.
Analyzujte incidenty a vytvořte si databázi, která pomůže určit druhy problémů, potřebné schopnosti k jejich vyřešení, frekvenci různých typů incidentů a další skutečnosti. Analýza vám může pomoci identifikovat zranitelnosti a zjistit, kde lze zabezpečení zlepšit.
Jako většina nejlepších bezpečnostních postupů pro cloudové aplikace je také reakce na incidenty společnou odpovědností. Při plánování reakcí na budoucí incidenty je zásadní zajistit dostupnost správných kontaktů, nástrojů a procesů.
Mít platformu pro reakce na incidenty, která umožňuje spolupráci interních a externích týmů, sleduje procesy reakce na incidenty a automatizuje klíčové bezpečnostní úlohy, je v čase krize nezbytné, aby bylo možné rychle problémy zastavit a efektivně na ně reagovat.
Jak (ne)bezpečná je virtualizace?
2.1.2017 SecurityWorld Zabezpečení
Firmy intenzivně využívají virtualizaci navzdory obavám z narušení bezpečnosti. Je to dobře?
Společnosti jsou s cloudem, virtualizací, a dokonce se softwarově definovanými datovými centry spokojenější, než tomu bylo v minulosti, a to navzdory obavám z narušení bezpečnosti, uvádí studie dvou technologických firem – HyTrust a Intel.
I když si nikdo nemyslí, že bezpečnostní problémy někdy zmizí, jsou firmy ochotné tolerovat rizika ve jménu agility, flexibility a nižších nákladů.
Přibližně 62 procent dotázaných manažerů, správců sítí a inženýrů očekává v letošním roce větší přijetí SDDC, což může měřitelně zvýšit virtualizaci a optimalizaci serverů, a dvě třetiny respondentů předpovídají, že se tyto implementace dokonce ještě dále zrychlí.
O bezpečnosti však nemají žádné iluze. Čtvrtina dotázaných uvedla, že zabezpečení bude i nadále překážkou, a více než polovina předpovídá pro letošní rok větší počet narušení. Ve skutečnosti jsou obavy ze zabezpečení primárním důvodem, proč zhruba polovina respondentů vůbec nevolí virtualizaci, uvádí zpráva.
Mají k obavám dobrý důvod. Jediný bod selhání ve virtualizované platformě, jako je například proniknutí do softwaru hypervizoru, který je bezprostředně nad hardwarem a funguje jako sdílené jádro pro všechno nad ním, má potenciál ke zneužití celé sítě – a nejen jednoho systému, jak tomu bývá obvykle.
„Je zde silný zájem, zejména mezi nejvyšším vedením společností, pokročit s těmito projekty, protože nabízejí jasné výhody,“ popisuje Eric Chiu, prezident a spoluzakladatel společnosti HyTrust. Příležitost ke zvýšení agility, výnosů a zisku přebíjí potřebu zvýšit bezpečnost virtuálního prostředí, dodává.
Personál oddělení IT se soustředí spíše na to, co umí ochránit, a ne nutně na to, co je potřeba chránit, uvádí zpráva společnosti Kaspersky Labs. Jen třetina z dotazovaných organizací má rozsáhlé znalosti virtualizovaných řešení, která používají, a přibližně jedna čtvrtina má tyto znalosti buď slabé, nebo dokonce vůbec žádné.
Dave Shackleford to ví až příliš dobře. Je lektorem týdenního kurzu zabezpečení virtualizace a cloudu pro institut SANS. Na konci prvního dne obvykle zjistí, že 90 procent studentů, mezi které patří mnoho správců systémů, virtualizace i cloudu, síťových inženýrů i architektů, má jen velmi malou představu o tom, co je nutné zajistit při zabezpečení virtuální infrastruktury.
„Máme zde organizace, které jsou z 90 procent virtualizované, což znamená, že celé datové centrum funguje někde mimo jejich úložné prostředí. Nikdo o tom tímto způsobem ale nepřemýšlí,“ uvádí Shackleford, který je zároveň výkonným ředitelem společnosti Voodoo Security.
„Není neobvyklé, když i u skutečně velkých a vyzrálých podniků zjistíte, že netuší o velkém množství potřebných bezpečnostních opatření pro virtuální prostředí nebo je nějakým způsobem přehlížejí,“ dodává Shackleford.
Zmatek se zvyšuje tím, že virtualizace způsobila posun v odpovědnostech IT v mnoha organizacích, podotýká Greg Young, viceprezident výzkumu v Gartneru. Datové centrum obvykle zahrnuje týmy vyškolené pro provoz sítí a serverů, ale virtualizační projekty jsou často vedené týmy specializovanými pro servery.
„Problémy se zabezpečením sítě jsou záležitosti, kterými se dříve ve skutečnosti nemuseli zabývat,“ vysvětluje Young.
Průměrné náklady na nápravu úniku dat ve virtualizovaném prostředí přesahují 800 tisíc dolarů, uvádí Kapersky Labs. Náklady na nápravu průměrně směřující k milionu dolarů jsou téměř dvojnásobkem nákladů ve srovnání s útokem na fyzické infrastruktury.
Společnosti zatím nepovažují technologii za jedinou odpověď na tyto bezpečnostní problémy, uvádí se ve výsledcích průzkumu společnosti HyTrust. Přibližně 44 procent účastníků průzkumu kritizuje nedostatek řešení od současných dodavatelů, nevyzrálost samotných výrobců i nových nabídek nebo problémy s interoperabilitou nezávislou na platformě.
Přestože dodavatelé jako třeba Illumio, Catbird, CloudPassage nebo Bracket Computing přinášejí řešení některých bezpečnostních problémů, firmy si nemohou dovolit čekat na další řešení zabezpečení.
„Máte-li nyní virtualizovaných 50 procent, dostanete se za dva roky na podíl 70 až 90 procent virtualizace a přidávání zabezpečení nebude nijak snadnější,“ vysvětluje Shackleford.
„Když začnete přesouvat provoz do cloudu – na Amazon nebo Azure nebo k libovolnému jinému velkému poskytovateli cloudu – chcete mít své zabezpečení alespoň promyšlené nebo v ideálním případě už zavedené, abyste se nedostali do situace, kdy byste měli menší kontrolu, než máte dnes.“
Bezpečnější prostředí
Výše zmínění bezpečnostní profesionálové souhlasí, že firmy skutečně mohou mít k dispozici zabezpečené virtuální prostředí už dnes, pokud si dokážou vytvořit jasnou představu své virtuální infrastruktury, používat některé technologie a nástroje zabezpečení, které už mají, a lépe harmonizovat technologii a zabezpečení ve firmě. Tady jsou jejich rady, jak to udělat:
1. Získejte kontrolu nad svou virtuální infrastrukturou
„Velmi dobré zabezpečení můžete získat pomocí plánování – vykonávání kroků zároveň s ověřováním nasazení bezpečnostních opatření,“ prohlašuje Young. Začíná to správou inventáře.
„Tým zabezpečení potřebuje získat popis infrastruktury s ohledem na virtualizaci,“ připomíná Shackleford.
Podle něj musíte zjistit, kde jsou hypervizory, kde konzole pro správu, co je v interní infrastruktuře, kde to je a jaké jsou provozní procesy pro údržbu toho všeho. Dále je potřeba definovat standardy pro jejich uzamčení. „Když už nic jiného, je nutné uzamknout alespoň hypervizory,“ dodává Shackleford.
Významní dodavatelé, jako jsou VMware a Microsoft, mají návody, které vám pomohou, stejně jako například organizace Centrum pro zabezpečení internetu (CIS, Center for Internet Security).
2. Přehodnoťte způsob, jakým se díváte na data a úložiště.
Lidé vážně potřebují přemýšlet o svém prostředí jako o sadě souborů, tvrdí Shackleford. „Je to velmi velká změna pro bezpečnostní profesionály, když si mají uvědomit, že se celé datové centrum spouští z vaší sítě SAN. Musejí se tedy alespoň seznámit s druhy používaných kontrol.“
Dodavatelé také přehodnocují své přístupy k zabezpečení a vítají třetí strany, které umějí poskytnout opravy zabezpečení.
„Dříve problém spočíval v tom, že jsme se ptali, zda lze použít detailně nastavené zabezpečení sítě ve virtualizovaném prostředí, a dostávali jsme od provozního personálu odpověď typu ‚absolutně ne, nedokážeme to podporovat‘, uvádí Chris King, viceprezident pro sítě a zabezpečení ve VMwaru.
„Nyní jsou k dispozici technologie, které jim umožní přehodnotit reakci na tento požadavek. Jakmile se útočník dostane dovnitř, zůstává uvězněn v daném místě a musí při útoku prorazit další zeď.“
3. Šifrování dat
To je v současné době nejdůležitější, ale stále mnoho firem šifrování nepoužívá, uvádí Chiu. „Přetrvává zde zastaralá myšlenka, že ‚pokud se něco nachází mezi našimi čtyřmi stěnami, nemusíme se o to obávat‘, ale to rozhodně neplatí. Je nutné šifrovat minimálně všechna data zákazníků a veškeré duševní vlastnictví, ať už se nachází ve vašem prostředí kdekoli,“ prohlašuje Chiu.
„Samozřejmě že cloud situaci ztěžuje, protože nevíte jistě, kde data jsou, ale šifrování veškerých těchto dat by mělo být základním principem.“
4. Koordinujte co nejdříve týmy zabezpečení a infrastruktury.
Je potřeba zajistit spojenectví a koordinaci mezi týmem zabezpečení a týmem infrastruktury již od počátku virtualizačních projektů, prohlašuje Chiu. „Je mnohem jednodušší integrovat bezpečnostní opatření a požadavky od počátku, než něco přidávat dodatečně.“
Zabezpečení také musí plánovat požadavky organizace na několik příštích let. „Plánuje společnost virtualizovat data související s platbami a zdravotními záznamy? Plánuje přechod na sdílené prostředí, kde dojde ke sloučení obchodních a aplikačních vrstev? Na tom všem záleží, protože v závislosti na tom budou vaše požadavky jiné,“ dodává Chiu.
Forever 21 confirms Payment Card Breach and provides further info on the incident
1.1.2018 securityaffairs Incindent
FOREVER 21 confirmed the presence of a malware at some point of sale (POS) systems in stores across the US.
On November 2017, the US clothes retailer FOREVER 21 announced it has suffered a security breach, the company now confirmed that hackers stole payment card data from its locations throughout the country for several months during 2017.
Even if the investigation is still ongoing, FOREVER 21 confirmed the presence of a malware at some point of sale (POS) systems in stores across the US, the malicious code was used at least between April 3, 2017, and November 18, 2017.
The payment made on the company website, forever21.com, were not affected by the incident.
The company explained that it has been using encryption technology since 2015 to protect its payment processes, but the investigation revealed that the encryption was switched off for some POS terminals at certain stores, a circumstance that allowed crooks to install the malware.
“The investigation determined that the encryption technology on some point-of-sale (POS) devices at some stores was not always on. The investigation also found signs of unauthorized network access and installation of malware on some POS devices designed to search for payment card data. The malware searched only for track data read from a payment card as it was being routed through the POS device. In most instances, the malware only found track data that did not have cardholder name – only card number, expiration date, and internal verification code – but occasionally the cardholder name was found.” reads the advisory published by the company.
“The investigation found that encryption was off and malware was installed on some devices in some U.S. stores at varying times during the period from April 3, 2017 to November 18, 2017. In some stores, this scenario occurred for only a few days or several weeks, and in some stores this scenario occurred for most or all of the timeframe.”
FOREVER 21
The company pointed out that not every POS terminal in affected stores was infected with the malware
“Each Forever 21 store has multiple POS devices, and in most instances, only one or a few of the POS devices were involved. Additionally, Forever 21 stores have a device that keeps a log of completed payment card transaction authorizations,” the company said while explaining the incident.
“When encryption was off, payment card data was being stored in this log. In a group of stores that were involved in this incident, malware was installed on the log devices that was capable of finding payment card data from the logs, so if encryption was off on a POS device prior to April 3, 2017, and that data was still present in the log file at one of these stores, the malware could have found that data.”
The company advised customers who shopped at its locations to monitor their credit transactions for any suspicious activity.
Hackers can remotely control thousands of Sonos and Bose speakers
1.1.2018 securityaffairs Hacking
Security experts at Trend Micro have demonstrated that certain models of Sonos and Bose speakers are affected by vulnerabilities that could allow attackers to hijack them.
Hackers can trigger the flaws to access the speakers and use them to play spooky sounds or to issue Alexa commands.
Only specific models of the two companies are actually affected by the issues, including the Sonos One and the Bose SoundTouch.
Attackers scan the Internet for vulnerable devices, once discovered flawed speakers they can use the API to instruct them into playing any audio file hosted at a specific URL.
“The impacted models allow any device on the same network to access the APIs they use to interface with apps like Spotify or Pandora without any sort of authentication.” reads the post published by Wired. “Tapping into that API, the researchers could simply ask the speakers to play an audio file hosted at any URL they chose, and the speakers would obey.”
The experts at Trend Micro have found between 2,500 to 5,000 Sonos devices and 400 to 500 Bose devices open to audio hacking.
The attacks are more scaring in scenarios in which those voice assistant devices control smart home features from door locks, conditioners, and lighting.
“Whereas previous studies focused on seizing control of speakers like the Amazon Echo and Google Home, the results of our case study led to unique findings. These include security gaps that resulted from a simple open port that gave anyone on the internet access to the device and user information.” reads the post published by Trend Micro. “The first glaring finding was access to email addresses that are linked to music streaming services synced with the device. Another was access to a list of devices as well as shared folders that were on the same network as the test device. “
In testing devices running an older version of Sonos software, the researchers demonstrated that they leak detailed information, like the IP addresses and device IDs of gadgets that had connected to the speakers.
The attack that was theorized by Trend Micro were already reported in the wild, one Sonos customer earlier this year reported that her speaker started playing strange sounds.
Trend Micro shared its findings with Sonos, which quickly fixed the issues, including a denial-of-service (DoS) bug, while Bose still hasnìt replied.
The full report including the attack scenarios is available at the following link:
The Sound of a Targeted Attack.
Happy IR in the New Year!
1.1.2018 Kaspersky APT
At the end of last year Mr. Jake Williams from aka @MalwareJake asked a very important question about Lack of visibility during detecting APT intrusions in twitter. Results show us that endpoint analysis is the most important part of any research connected with APTs. Also, for sure endpoint forensics is critical during any Incident Response (IR) because in many cases the initial intrusion happened too far away in time so there are no relevant logs and no backups to identify the first victim and the way how attackers were moving from one computer to another. At least once a year we have such issues during IR activities with our customers. In these cases we use a very simple script that is uploaded to every Windows computer in the corporate network to collect logs, NTFS data, entries from the Windows registry and strings from the binary files to find out how exactly the attackers were moving through the network. It’s holiday season and it is our pleasure to share this script with you. We hope it will help to save a lot of time during IR and any malware/APT investigations providing the so much needed visibility into potentially infected endpoint PCs.
Let’s start with collecting the collect file system information from the computer using the wonderful forensics tool FLS (administrative privileges required) from the open source package Sleuthkit. The only thing that the official Windows build lacks is Windows XP/2003 support. If you are planning to run the tool on Windows XP/2003 machines then you may need to recompile FLS from sources using MinGW or download our our pre-compiled version (see the end of this blog post). We also do not want to write the results to the computers’ hard drive to avoid wiping its unallocated space. So the tool is going to utilize a big (approx. 300 MB free space for one corporate computer ) share folder that should be prepared in advance and should be accessible from all computer in the network that will execute the script:
set data_share=”\\corp_share\data_share”
net use y: %data_share%
mkdir y:\%COMPUTERNAME%_report
set dp=y:\%COMPUTERNAME%_report
echo %date% %time% %COMPUTERNAME% > %dp%\report.log
fls.exe -lpr \\.\c: >> %dp%\fls.log
It will take several (dozens of) minutes to create the full list of filesystem entries for the computer’s system drive. After that we are ready to extract the inode numbers of Windows registry files that are interesting to us. We will use the ICAT tool from the same Sleuthkit package and the RegLookup utility to grab modification timestamps of every windows registry key. At the end we want to collect all the strings (using the tools either by Mr. Mark Russinovich or from http://pubs.opengroup.org/onlinepubs/9699919799/utilities/strings.html tool (our choice)) from the registry files to search for any data from the unallocated space and deleted keys:
::Get Windows reg files
findstr /i “windows\/system32\/config\/system ” %dp%\fls.log | findstr /vi “profile” | findstr /vi log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\system.reg.inode
for /f “tokens=1” %%a in (%dp%\system.reg.inode) do icat \\.\c: %%a > %dp%\system.reg
findstr /i “windows\/system32\/config\/software ” %dp%\fls.log | findstr /vi “profile” | findstr /vi log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\software.reg.inode
for /f “tokens=1” %%a in (%dp%\software.reg.inode) do icat \\.\c: %%a > %dp%\software.reg
::Convert reg files
reglookup.exe %dp%\system.reg > %dp%\system.reg.log
reglookup.exe %dp%\software.reg > %dp%\\software.reg.log
::Get strings from reg files
strings -afel %dp%\system.reg > %dp%\system.str.log
strings -afeb %dp%\system.reg >> %dp%\system.str.log
strings -afel %dp%\software.reg > %dp%\software.str.log
strings -afeb %dp%\software.reg >> %dp%\software.str.log
Once finished, we are ready to do the same with the Windows system and security eventlog files. To parse log the files will we use the open source tools evtxexport and evtexport by Mr. Joachim Metz
::Get Logs
findstr -i “windows\/system32\/winevt/logs/system.evtx” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\system.evtx.inode
for /f “tokens=1” %%a in (%dp%\system.evtx.inode) do icat \\.\c: %%a > %dp%\system.evtx
findstr /i “windows\/system32\/winevt/logs/security.evtx” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\security.evtx.inode
for /f “tokens=1” %%a in (%dp%\security.evtx.inode) do icat \\.\c: %%a > %dp%\security.evtx
strings -afeb %dp%\system.evtx > %dp%\system.evtx.str.log
strings -afel %dp%\system.evtx >> %dp%\system.evtx.str.log
strings -afeb %dp%\security.evtx > %dp%\security.evtx.str.log
strings -afel %dp%\security.evtx >> %dp%\security.evtx.str.log
::Conv evtx
evtxexport.exe %dp%\system.evtx > %dp%\system.evtx.res.log
::get evt logs
findstr /i “windows\/system32\/config/SysEvent.Evt” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\SysEvent.Evt.inode
for /f “tokens=1” %%a in (%dp%\SysEvent.Evt.inode) do icat \\.\c: %%a > %dp%\SysEvent.Evt
findstr /i “windows\/system32\/config/SecEvent.Evt” %dp%\fls.log | cut -f2 -d” ” | cut -f1 -d”:” > %dp%\SecEvent.Evt.inode
for /f “tokens=1” %%a in (%dp%\SecEvent.Evt.inode) do icat \\.\c: %%a > %dp%\SecEvent.Evt
::get strings from evt
strings -afeb %dp%\SysEvent.Evt > %dp%\SysEvent.Evt.str.log
strings -afel %dp%\SysEvent.Evt >> %dp%\SysEvent.Evt.str.log
strings -afeb %dp%\SecEvent.Evt > %dp%\SecEvent.Evt.str.log
strings -afel %dp%\SecEvent.Evt >> %dp%\SecEvent.Evt.str.log
::Conv evt
evtexport.exe %dp%\SysEvent.Evt > %dp%\SysEvent.Evt.res.log
Actually this is it. All logs will be collected in our share’s folder so we may search for something interesting. In the latest cases with Carbanak we were looking for mentions of the malicious Powershell scripts so let’s add the following string in our version of this script:
findstr /i “powershell” %dp%\*.log >> %dp%\report.log
This will provide us with a complete picture of how the attackers were moving from one computer to another with exact timestamps and artifacts on NTFS, registry and logs that is critical for fast and effective IR with no lack of endpoint visibility. GLHF and HAPPY IR in NEW YEAR!
PS. LINK 2 FILE
SHA256 (HappyNewYear.zip) = c166d1e150db24ea27014e1d4a9eeb79f9e317ded9918a623fee8e66a010f9fa
Nový virus dokáže obelstít antiviry, varovali bezpečnostní experti
1.1.2018 Novinky/Bezpečnost Viry
Národní bezpečnostní tým CSIRT.CZ varoval před zákeřným malwarem Loki, který se v posledních týdnech šíří internetem bez nadsázky jako lavina. Tento počítačový virus zneužívá populární kancelářský balík Office od společnosti Microsoft, aby se vyhnul odhalení.
„Malware Loki se šíří pomocí produktů Microsoft Office, a to z důvodů, aby se vyhnul detekci antivirových programů. Ukrývá se v tabulkách Microsoft Excel a dalších aplikacích Office,“ uvedl Pavel Bašta, bezpečnostní analytik CSIRT.CZ, který je provozován sdružením CZ.NIC.
Ten zároveň zdůraznil, že nezvaný návštěvník se snaží od uživatele vylákat přístupové údaje k různým účtům. S jejich pomocí pak mohou počítačoví piráti získat přístup k citlivým údajům uživatelů, případně jejich on-line účty zneužít i bez přímého přístupu k počítači.
Trhlina již byla opravena
„Útok využívá zranitelnost CVE-2017-0199 Microsoft Office/WordPad RCE, která byla opravena v dubnu a updatovaná v září,“ prohlásil bezpečnostní expert.
Kybernetičtí nájezdníci tedy zneužívají toho, že uživatelé instalaci aktualizací velmi často podceňují. Najde se tedy poměrně početná skupina uživatelů, kteří jsou stále v ohrožení, protože aktualizaci pro kancelářský balík Office nestáhli.
„Chyba existuje ve způsobu, jakým Office a WordPad analyzuje speciálně vytvořené soubory. Útok vyžaduje, aby oběť otevřela nebo zobrazila soubor, ve kterém je ukrytý malware,“ uzavřel Bašta.
S ohledem na možná bezpečnostní rizika by uživatelé s instalací aktualizací – aktuálně v případě kancelářského balíku Office – neměli otálet.
Pomáháte pirátům vydělat? Kyberměny se těží na miliardě počítačů bez vědomí uživatelů
1.1.2018 Novinky/Bezpečnost Kriminalita
Počítačové viry bylo ještě před pár lety možné odhalit zpravidla na první pohled. V počítači totiž dělaly tak velkou neplechu, že si jich uživatel všiml hned. Proti tomu moderní škodlivé kódy se snaží zůstat co nejdéle v anonymitě a vydělávají kyberzločincům velké peníze. Podle aktuálně zveřejněné analýzy AdGuard těží viry potají kybernetické mince na více než miliardě počítačů.
Virtuálních měn existuje mnoho. Jednou z nejstarších a aktuálně nejpopulárnějších jsou tzv. bitcoiny. Ty vznikly už v roce 2009, větší popularitě se ale těší v posledních letech. Tato měna byla vytvořena tak, aby se nedala ovlivňovat žádnou vládou ani centrální bankou.
Kybernetické mince „razí“ síť počítačů se specializovaným softwarem naprogramovaným tak, aby uvolňoval nové mince stabilním, ale stále klesajícím tempem. Počet mincí v oběhu má dosáhnout nakonec 21 miliónů, což má být kolem roku 2140.
Bitcoiny a další kryptoměny se těší velké popularitě především coby prostředek pro investici. Kurzy však často kolísají. Evropský bankovní úřad kvůli tomu dokonce varoval spotřebitele, že neregulované virtuální měny představují velké riziko. Jejich vklady totiž nejsou nijak chráněny.
pátek 29. prosince 2017, 10:50
To je dramatický nárůst, ještě podle říjnové statistiky totiž bylo podobnými škodlivými kódy napadeno pouze půl miliardy strojů.
Za pouhé dva měsíce se tak počítačovým pirátům podařilo infikovat další stovky miliónů počítačů. Kyberzločinci využívají toho, že za těžbu virtuálních měn – například velmi populárních bitcoinů – nemusí uživatelé zaplatit teoreticky ani korunu.
Pokud mají dostatečně výkonný počítač, mohou si nainstalovat speciální software a jeho pomocí kryptoměny doslova těžit. Tento program totiž používá předem nastavené výpočty, jejichž výsledkem je zisk virtuálních mincí. Za ty je pak možné klidně nakupovat prakticky cokoliv.
Vydělávají milióny
Jenže právě toho jsou si vědomi také počítačoví piráti. Ti stále častěji instalují podobný software do cizích počítačů místo klasických virů. Podobně zotročené stroje pak kyberzločincům vydělávají peníze, aniž by o tom majitelé počítačů měli ponětí.
I když přesné odhady nejsou k dispozici, počítačoví podvodníci si touto cestou pravděpodobně vydělají několik miliónů korun každý den podle nejstřízlivějších odhadů - soudě podle aktuální hodnoty bitcoinů.
Ta se nyní pohybuje okolo 14 600 dolarů, tedy v přepočtu bezmála 315 000 korun. Na začátku letošního roku přitom jeden bitcoin stál méně než 1000 dolarů.
Antiviry nemusí pomoci
Uživatelé si mohou sami všimnout, že je podobný software na jejich počítači nainstalován podle toho, že je daný stroj nebývale vytížený, tedy reaguje pomaleji, než je běžné. V takovém případě se vyplatí prohledat nainstalované aplikace a doplňky v internetových prohlížečích a ty podezřelé odinstalovat.
Antiviry totiž u podobných programů a doplňků nemusí rozpoznat, že jsou nainstalované bez vědomí uživatele.
Bitcoiny a další kryptoměny se uchovávají ve speciálních virtuálních peněženkách. Více se o této problematice dozvíte v našem dřívějším článku.
Bezpečnost citlivých informací zasílaných elektronicky se posílí
1.1.2018 Novinky/Bezpečnost Zabezpečení
Posílit bezpečnost citlivých informací posílaných elektronicky má za cíl novela zákona o utajovaných informacích, která bude účinná od začátku příštího roku. Změny mají zohlednit elektronizaci státní správy a posílit ochranu utajovaných informací.
Důvodem změn je to, že platný zákon umožňuje použít pasáže o administrativní bezpečnosti u utajovaných informací v papírové podobě. Nová úprava postupy ochrany informací promítá také pro zpracování a přenos utajovaných informací v elektronických spisech nebo v certifikovaném informačním systému.
„Prostřednictvím uvedené změny dojde k dokumentaci celého životního cyklu utajované informace v elektronické podobě při dodržování podmínek administrativní bezpečnosti, jako je tomu v případě utajovaných informací v listinné nebo nelistinné podobě," píše se v důvodové zprávě novely.
Na utajované informace v elektronické podobě se budou až na výjimky používat ustanovení, která obsahují požadavky na vyznačování údajů a evidenci utajované informace. Například se neuplatní ustanovení upravující podmínky přepravy a přenášení utajované informace.
Bojíte se, že někdo zveřejní vaše nahé fotky? Pošlete nám je a my je zablokujeme, vyzývá Facebook
1.1.2018 Novinky/Bezpečnost Sociální sítě
Populární sociální síť zkouší bojovat proti aktům zveřejněným z pomsty. Bezpečnostní experti varují, že její řešení nemusí být bezpečné.
Pilotní projekt boje proti fotografiím obnažených uživatelů zveřejněným z pomsty spustila v Austrálii sociální síť Facebook. Společnost ve spolupráci s tamní vládou připravila systém, který je založen na „hashování“ nahrávaných snímků.
Potenciální oběť musí Facebooku poskytnout snímky, o kterých se domnívá, že se je někdo pokusí zveřejnit na Facebooku, a sociální síť poté při nahrávání veškerých fotek porovnává nahrávané snímky s poskytnutými akty. Pokud najde shodu, nahrání a zveřejnění snímku zablokuje.
Ohrožení uživatelé mají Facebooku zasílat choulostivé snímky prostřednictvím služby Messenger. Podle australské komisařky pro internetovou bezpečnost Julie Inman Grant se lidé nemusí obávat, že jejich akty poskytnuté sociální síti budou uloženy na serverech Facebooku.
„Neukládají se tam snímky, ale digitální stopa a poté se používá umělá inteligence a jiné technologie pro porovnávání fotografií,“ zdůraznila. Podle zpravodajského serveru ABC však není jasné, zda hashování je dostatečně dobrou technologií na to, aby se vypořádalo s pokusy obcházení filtrů založených na umělé inteligenci, jako je pozměnění původního snímku.
Není to bezpečné, varují experti
Existují také vážné obavy z toho, jak Facebook naloží s tak citlivými snímky, které mu poskytnou sami uživatelé, když firma v minulosti čelila obavám ohledně zabezpečení a ochrany osobních dat.
„Z koncepčního hlediska jde o záslužnou myšlenku, ale fungovalo by to lépe, kdyby uživatel dostal možnost využít samoobslužný nástroj pro načtení souborů na Facebook,“ uvedl pro server Infosecurity-magazine.com Andrew Clarke ze společnosti Identity EMEA. Podle bezpečnostního experta společnosti ESET Marka Jamese existují vážné obavy, že by tato služba mohla být zneužita podvodníky.
„Pravděpodobnost, že se Facebook sám stane terčem útoku, je sice malá, ale pokud by se tak stalo a uživatelé by byli podvedeni a poslali takto citlivé snímky třetí osobě, mohli by se vystavit dalšímu riziku vydírání,“ varoval James. „ESET neustále zdůrazňuje, aby lidé pečlivě zvažovali, kam si ukládají intimní fotografie, a aby je pokud možno neměli uloženy on-line v jakékoli podobě,“ dodal.
Pilotní projekt Facebooku probíhá kromě Austrálie ve třech dalších zemích. Má jít jen o jednu ze součástí řady opatření, která tato sociální síť zavádí v souvislosti s bojem proti rostoucímu trendu zveřejňování intimních snímků uživatelů bez jejich souhlasu.
Pozor na soubory v Messengeru, mohou ukrývat malware pro těžbu kryptoměn
1.1.2018 Živě.cz Viry
Odborníci z Trend Micro informovali o novém malwaru, který se šíří prostřednictvím komunikátoru Messenger. V případě, že vám v jeho desktopové verzi, ať už v rámci Facebooku nebo webu Messenger.com, přijde odkaz na video, zpozorněte.
Dorazí-li vám podobná zpráva na Messenger, na soubor či odkaz v žádném případě neklikejte
Za odkazem se totiž nemusí ukrývat pouze vtipný klip s koťátky, ale i doplněk do prohlížeče Chrome se skrytou instalací. Ten pojmenovali v Trend Micro jako Digmine a z názvu se dá vytušit jeho primární účel. Na pozadí totiž umožňuje těžbu kryptoměny Monero. Využívá k tomu open-source nástroj XMRig.
V případě, že oběť využívá Facebook v Chromu, kde se neodhlásí, umí si Digmine spustit na pozadí instanci Chromu a nastartovat jeho těžební komponentu. Zároveň obsahuje i propagační část, která začne odesílat stejné škodlivé zprávy všem kontaktům v Messengeru.
Ruští hackeři útočí na poštovní účty novinářů
1.1.2018 Novinky/Bezpečnost BigBrother
Ruští hackeři od roku 2014 napadli účty elektronické pošty zhruba 200 novinářů, jejichž kritika na adresu Moskvy dráždí Kreml. Napsala to agentura AP s odvoláním na analýzu bezpečnostní internetové firmy Secureworks. Cílem hackerů je prý získat citlivou poštu, kterou by proti žurnalistům mohli v budoucnu použít.
úterý 26. prosince 2017, 12:31 - Washington/Moskva
V seznamu napadených je padesátka zpravodajů zahraničních médií působících v Moskvě, ale i málo známí blogeři z ruských provincií nebo bývalých sovětských republik. Postižená byla i řada prominentních opozičních novinářů, například televizní moderátorka Xenia Sobčaková, která kandiduje v prezidentských volbách.
Na seznamu je také britský novinář Eliot Higgins, zakladatel investigativní skupiny Bellingcat, která mimo jiné vyšetřuje pád malajsijského letadla nad Donbasem v roce 2014. Terčem hackerů byla i Ellen Barryová, bývalá moskevská zpravodajka listu The New York Times.
Za útoky podle společnosti Secureworks stojí hackerská skupina Fancy Bear, kterou podle amerických tajných služeb řídí ruská vláda. Členové Fancy Bear měli podle tvrzení expertů loni zaútočit na server americké Demokratické strany s cílem kompromitovat prezidentskou kandidátku Hillary Clintonovou.
Těžba kryptoměn už potají zneužívá miliardu uživatelů. Patříte mezi ně?
1.1.2017 cdr.cz Bezpečnost
Pomáháte někomu vydělávat pomocí svého počítače bez vašeho vědomí? Pravděpodobně ano. Přehrávání videí se stalo novým terčem na poli vytěžování kryptoměn z neinformovaných návštěvníků. Zneužitých je již okolo jedné miliardy za měsíc.
Celkem alarmující množství videostreamů provozuje tajně na pozadí těžbu kryptoměn s využitím výkonu počítačů jejich návštěvníků.
V nedávné době výzkumníci ze společnosti AdGuard uveřejnili informaci, že některé stránky se snaží využít toho, že jsou vysoce frekventované právě těžbou kryptoměny. Počet zneužitých nic netušících návštěvníků je již kolem jedné miliardy. Skript je přitom umísťován tam, kde uživatelé stráví velké množství času, tedy ideální situace v kombinaci s delšími videi (např. nelegálními streamy filmú).
Bylo dokonce zjištěno, že tři ze čtyřech stránek mají kód vložený na identickém místě. Stále je největším trnem v oku situace, že nikdo neoznámí uživatelům nic o těžbě či využití výkonu jejich zařízení.
Nejznámnější ochranou jsou tzv. Ad-blokátory. Ty částečně dokáží zabránit těžbě kryptoměny, nejsou však neprůstřelné. Mnozí uživatelé dále zůstávají v ohrožení, a to díky oblíbenéCoinHive metodě. Jsou i takové názory, že se dá CoinHive využít jako jakási alternativa k reklamám. Pravdou však zůstává, že bez souhlasu majitele by neměla být využívána.
Ale jak výzkumníci AdGuard sami konstatovali: „Pochybujeme, že všichni majitelé těchto stránek jsou si vědomi, že do těchto přehrávačů je zabudována i skrytá těžba kryptoměny.“
Obliba v této činnosti, kryptojackingu, narůstá s alarmující rychlostí. Podle AdGuard se jedná o epidemii. Od doby, kdy se tento problém poprvé objevil, uplynulo pár měsíců a nyní se již jedná o miliardy poškozených měsíčně. Není však zcela jasné, jak se s tímto problémem vypořádat.
SimilarWeb statistics odhaduje, že tyto stránky navštíví každý měsíc zhruba 992 milionů návštěvníků. Díky těmto něvštěvníkům je vytěžena kryptoměna v celkové hodnotě zhruba 320 000 dolarů měsíčně.
Nedávno jsme informovali o tom, že pirátská zátoka, The Pirate Bay, je podezřelá z těžby kryptoměny. Posléze se tak potvrdilo a zástupce The Pirate Bay přiznal, že se jednalo jen o pokus, zda je tento web schopný na své náklady vydělat skrze těžbu kryptoměn. Touto těžbou si zhruba vydělají přes 12 000 dolarů měsíčně.
Vietnam's 10,000-strong 'Cyber Army' Slammed by Rights Groups
1.1.2018 securityweek BigBrothers
The deployment of 10,000 cyber warriors to fight online dissent in Vietnam adds a grim "new dimension" to controls on free speech in the Communist country, a rights group has said.
Vietnam routinely jails its critics and closely monitors activists on social media, which is not banned unlike in neighbouring China.
A top Vietnamese general this week said a 10,000-strong brigade dubbed "Force 47" has been tasked with fighting "wrongful views" spreading on the internet, according to state media reports.
It was not immediately clear what Force 47 is responsible for, but observers anticipate the cyber soldiers will escalate smear campaigns against activists online.
Rights groups rounded on the move.
Human Rights Watch deputy Asia director Phil Robertson said the cyber scouts announcement was a "shocking new dimension to Vietnam's crackdown on dissent".
Others said the tactic is designed to squeeze online critics.
"This is just the latest plank in a campaign to curb internet freedoms at all costs," Shawn Crispin, Committee to Protect Journalists' Southeast Asia representative, told AFP Friday.
"While they can't unplug Facebook, Instagram and the likes outright, they can apply more and more pressure on those platforms and it looks like these cyber troops are their latest attempt to do that."
Vietnam's internet is classified as "not free", according to web watchdog Freedom House, which ranks it second only to China in Asia.
Around half of the country's 93 million people have access to the internet, and the country also ranks among Facebook's top 10 users by numbers.
Vietnamese officials did not respond to a request for comment from AFP.
Earlier this year the government asked Facebook and YouTube to remove "toxic content" from its sites.
In August, the president called for tougher internet controls, saying that groups have used the web to launch campaigns against the government that threaten the "prestige of the party's leaders and the state".
A conservative leadership in power since last year has waged a crackdown on dissidents, with at least 15 arrested this year, according to Amnesty International.
Several other have been handed heavy jail terms, joining scores of activists already behind bars.
Force 47 is likely to include commentators hired to publish pro-government material and counter critics, said Madeline Earp, senior research analyst with Freedom House.
"Vietnam very much follows China's example when suppressing internet freedom, particularly when it comes to blocking websites and arresting dissidents," she told AFP.
For some activists, the cyber troop announcement is no surprise. But activist Nguyen Chi Tuyen said the new force marked an escalation in state tactics of repression.
"The main purpose for Force 47 is to try and control news and public opinion on the internet... they want to protect the party, not protect the country," said Tuyen, more commonly known by his online handle Anh Chi.
WeChat is set to become China’s official electronic ID system
1.1.2018 securityaffairs Mobil
China’s largest social media network, WeChat, is set to become an official electronic ID system in the country, an ID pilot program was launched in Guangzhou’s Nansha District.
WeChat (‘Weixin’ in China) is China’s largest social media network, according to Tencent Holdings, the platform had 980 million monthly active users as of late September.
A project launched by the government of Beijing could use WeChat as the official electronic personal identification system.
A WeChat ID pilot program was launched in Guangzhou’s Nansha District, citizens in the area will soon be able to identify themselves through the social network. According to Xinhua, over 30,000 people have applied for ID cards in the 24 hours following the launch of the project.
The WeChat ID could be used to authenticate citizens to online and offline government services, it will also give them access to many other online services such as hotel registration and ticketing.
The Anonymity on WeChat is not possible, China has phased in a real-name registration requirement for mobile phone numbers since 2013, and every account is associated with a mobile phone number.
The ID programme was developed by the research institute of the Ministry of Public Security in collaboration with the Tencent’s WeChat team. Several banks in the country and many government departments have provided their support to the project.
The project aims to deter online identity theft, the system relies upon a facial recognition technology to verify applicants before their virtual ID cards get authorized.
The ID cards are available in “lightweight” format to provide a simple proof of identity while accessing services, and the “upgraded” format where more information is requested, for example, while requiring business registration.
Privacy advocates have raised concerns about the program because this public-private partnership could allow the Government to intensify it extensive surveillance and censorship activities.
A new Facebook security feature reveals fraudulent Facebook-like mails
1.1.2018 securityaffairs Social
A new Facebook security feature protects users from identity theft, the tech giant is taking note of every email it has “recently” sent to its users.
Facebook has rolled out a new security feature to protect users from identity theft, the tech giant is taking note of every email it has “recently” sent to its users.
The full list of email sent by Facebook is available under the Settings menu on the social network platform.
Facebook users that will receive a message allegedly sent by the social network giant can check its authenticity by viewing the new “See recent emails from Facebook” section at the bottom of the Security and Login page.
If the message is not included in the list it is fraudulent and must be discarded.
“Facebookmail.com is a common domain that Facebook uses to send notifications when we detect an attempt to log in to your account or change a password. If you’re unsure if an email you received was from Facebook, you can check its legitimacy by visiting facebook.com/settings to view a list of security-related emails that have been recently sent.” states the announcement published by Facebook.
Even if threat actors are able to disguise emails, to make them look like official messages sent by Facebook, the new Facebook security feature will help users to identify phishing attacks.
Crooks use phishing attacks to obtain victim’s credentials, access their profile, and perform a wide range of fraudulent activities.
Compromised accounts could be used to send out phishing messages or to spread malware.
Users that will discover email scam pretending to be sent from the Facebook platform can report it to phish@facebook.com.
If your account has been compromised due to a phishing attempt, visit facebook.com/hacked.
“If you’ve checked this tool and determined that an email you received is fake, we encourage you to report it to phish@facebook.com, and if you believe your account has been compromised due to a phishing attempt, you may attempt to regain access to your account at: facebook.com/hacked. ” concludes Facebook.