je internetový portál zaměřený na počítačovou bezpečnost, hacking, anonymitu, počítačové sítě, programování, šifrování, exploity, Linux a BSD systémy. Provozuje spoustu zajímavých služeb a podporuje příznivce v zajímavých projektech.


5G security and privacy for smart cities

Kaspersky Securelist - 37 min 40 sek zpět

The 5G telecommunications revolution is imminent. It is the next generation of cellular network, making use of the existing 4G LTE in addition to opening up the millimeter wave band. 5G will be able to welcome more network-connected devices and increase speeds considerably for users. It will serve as the foundation for advanced services, including:

  • 8k streaming, real-time mobile gaming into augmented/virtual reality experiences;
  • Complex remote operations such as remote unmanned vehicles, delivery and surveillance drones, surgical robots;
  • Critical infrastructure operations: enhanced management and monitoring systems for traffic, energy and water facilities;
  • Emergency and healthcare interventions: services for saving lives greatly benefit from 5G installations; drones can quickly reach and live broadcast an incident location, could be used for delivering first aid and equipment or even to transport a victim to the closest medical center.
5G risks and challenges

Managing security is a continuous and dynamic process. With the dramatic increase in the number of connected devices comes a natural expansion of the attack surface and threat intensity. As 5G technologies become widely deployed, the weaknesses and inherent security flaws of 5G will be identified and hopefully quickly patched.

The key anticipated risks can be described as follows:

  • Protocol weaknesses and large-scale vulnerability exploitation
  • Severe DDoS attacks
  • BYOD threats
  • Data security and privacy
  • State-funded terrorism, anti-fossil fuel activism, espionage or corporate sabotage
  • Critical infrastructure/public safety
Public privacy, safety and critical infrastructure

Connected services and infrastructure is a double-edged sword that helps provide better visibility, efficiency and performance, but is making non-critical infrastructure critical and therefore exposing more of the population to unaffordable risks. The general public is being ‘lulled’ into welcoming the convenience and continuous visibility provided by 5G, though in the event of a disruption, public order could be at stake.

The conventional boundaries of critical infrastructure such as water supply, energy grid, and military facilities, and financial institutions will expand much further to other unprecedented areas in a 5G-connected world. All these will require new standards of safety.

On the privacy side, matters become more complex. The advent of 5G with its short range will definitely mean more cell communication towers and building antennas being deployed in dense urban centers. With the right toolset, someone could collect and track the precise location of users. Another issue is that 5G service providers will have extensive access to large amounts of data being sent by user devices that could show exactly what is happening inside a user’s home and at the very least describe via metadata their living environment, in-house sensors and parameters.

Taking into account all of the above, it is our view that government and industry leaders need to combine their efforts to promote secure and safe 5G technology projects to enhance the services and quality of life for citizens of smart cities.

To learn more about 5G technologies, risks, challenges and security solutions, please read the full report.

Black Friday Alert 2019: Net Shopping Bag of Threats

Kaspersky Securelist - 1 hodina 34 min zpět

Every year, Kaspersky releases an annual Black Friday alert to highlight how fraudsters may capitalize on increased levels of online shopping at this time of year when many brands are offering their customers appealing discounts. In the rush to get a big discount or, even more panic-inducing, a limited time offer, many shoppers lose all sense of vigilance. Caution goes out the window and consumers start tapping on links and email vouchers without their usual care and attention.

Spam and Phishing

Unfortunately, online shopping at this time of year needs more security-awareness, not less. It is the peak season for phishers and spammers. Along with many genuine offers, there also lurk phishing scams ready to reel in an unwitting bargain hunter’s bank details. By clicking on a too-good-to-be-true discount link online without checking it’s genuine, you could find yourself at a fake marketplace, that may look indistinguishable from the real website. On these sites, entering your bank details could result in money leaving your account, but no package arriving at your door.

Since Kaspersky has been analyzing financial phishing activity, which began in 2013, there has been a steady rise in threats – peaking at 54% in 2017. However, last year this trend did slow down and decrease. The figure dropped to 44.70%. Financial phishing attacks are still expected to be a big risk around the upcoming Black Friday event, and there will be close analysis to see if the figure rises once more.

Share of financial phishing attacks from all phishing decreased for the first time in four years in 2018

Social Engineering in the Retail Sector How do phishing scams work?

In order to make these scams a success, fraudsters need to lure their potential victims to fake webpages and obtain their bank details. To do this, attackers register website domains, often containing the magic phrase ‘Black Friday’ and keep their registration data hidden.

Their sites are usually well designed and appear to be genuine and of a high quality. Unlike many old typo-filled spam emails, phishing web pages are relatively easy to make look authentic – scammers can simply copy the source code from the real store’s website and make theirs appear to be a near perfect match.

Domain addresses are usually hidden until the event itself, so they are not blocked in advance by antivirus software vendors. The scam website is then activated immediately before the phishing mail goes out, just as shown in these screenshots.

Occasionally, these attacks appear to be sent by large banks or payment systems, allegedly partners of the Black Friday sales campaign, while in fact these are carefully crafted copies of legitimate pages and mailshots made by criminals. Emails or warnings may threaten to block the user’s account or promise some financial benefits by clicking on the email. These phishing emails make it seem like all you have to do is follow the link and log in to your account.

However, if you do log in to these sites with your credentials, all your bank account or payment card data — such as card numbers or usernames and passwords — will be leaked to the scammers.

Once they have this data, scammers could be able to withdraw money from your account, sell your bank card details on the dark web, or spend your money in various ways. This is often carried out by teams in other countries.

These scams come in a variety of forms. In one example, scammers offer goods at crazy discounts, encouraging the victim to share their bank card details, thereby risking losing all of their account funds and of course, not receiving their order. In another scheme, the victim might be tricked into transferring money to the attacker’s account, after which the fraudster breaks off all contact and the funds are lost.

There is also another widespread and very successful phishing scheme which asks users to complete a survey and fill in a large registration form, along with bank card details to take part in the promotion. After completing the form, you’re asked to send a link to the website to 10 friends via a messenger app.

Of course, victims of this scam won’t ever receive any prizes but instead end up bombarded with various links and emails for more useless surveys. Any additional clicks on these survey usually mean that scammers receive even more money. Because the survey is shared through messenger apps, more users, who often trust links that come from their friends, might also fall for the trick. And so the cycle continues.

Where are phishing scams occurring?

According to our statistics, more than half of phishing attacks carried out in the digital retail space are in the payment sector – online stores, payment systems and banks. Frequently, criminals use brands of Amazon, eBay and Alibaba to trick users. Amazon was used as a disguise in more than a million attacks in the first three quarters of 2019 alone, as the graph below shows.

Online retailers most hit by phishing attacks during Q1-Q3 2019

Notably, the share of phishing incidents in the online retail space during the peak sales period significantly increased compared to what happens during the rest of the year. For instance, attacks that were using the eBay brand reached nearly 25,000 during the week of November 4th, 2018, two weeks before Black Friday, after experiencing minimal disruption in the preceding days. The Amazon disguise was also a key target for scammers too – facing more than 20,000 phishing attacks during the week of November 19th, 2018, which was the week of Black Friday last year.

Spikes in phising attacks on online marketplaces from August – December 2018

These 2018 findings allow us to predict that in 2019 the situation may repeat.

Banking trojans

Similarly to phishing scams, Banking Trojans also target e-commerce brands so that they can track down user credentials – like banking login details, passwords, bank card numbers or phone numbers.

But with Trojans, the malware can intercept data fields on targeted websites. This means they can modify online page content and steal credentials entered, while the victim will keep thinking that they enter login and password to legitimate fields on the website. Because of this, cybercriminals can monitor a hacked user’s online behavior, such as which sites they visit while on the infected device.

Once the user browses to one of the targeted e-commerce websites, the Trojan activates its form-grabbing functionality and saves all the data a user inputs on the website. On an e-commerce website, this means a credit or debit card number, expiration date and CVV, as well as your site login credentials.

If the site or user’s bank doesn’t feature two-factor authentication, then the criminals behind the Trojan will have access to all this data and can use it to empty the user’s bank account or use their card details for purchases.

In the first three quarters of 2019, Kaspersky discovered 15 families of financial malware targeted at users of popular brands. In addition to the already known banking families such as Zeus, Betabot, Cridex and Gozi, this year, we have also seen two mobile banking Trojans joining our list: Anubis and Gustuff.

Last year’s report saw a 10% increase in the detection rate of financial malware between 2017 and 2018[1], but over the course of the full year that growth was a far more significant 24%. More than 15 million attacks by banking Trojans have been registered in the first three quarters of 2019. This means we have already seen a nine percent increase on what was found during 2018.

Overall number of attacks by Banking Trojans, 2015 – 2019

Mobile Trojans are also able to steal user credentials. The common scenario for user account theft on mobile devices is an overlay-attack, which overlays windows from the hacker’s program on top of the app, or window the user is browsing. Often the overlayed window or data input form is identical to the real one and the user enters their data believing that they are dealing with the original program.

Targeted e-commerce categories

In 2019, we found those 15 malware families were targeting a total of 91 consumer e-commerce sites and mobile apps across the world.

Of those, consumer goods websites such as fashion and clothing, or toys and jewelry, were the most commonly targeted, with 28 websites falling into this category. Also popular with phishing scams are entertainment websites with 20 examples found and travel bookings with 15 in that category.

Surprisingly, sites which sell big ticket items, such as consumer electronics (two websites found) and telecoms (12 websites), which are popular purchases on Black Friday, are at the bottom of the list.

Proportion of e-commerce categories targeted by malware in Q1-Q3 2019

Consumer apparel (fashion, shoes, gifts, toys, jewelry, department store) 28 Entertainment (cinema, games etc.) 20 Travel (Flights, taxi, hotels, etc.) 15 Online retail platform (eBay, Alibaba group etc.) 14 Telecoms 12 Consumer electronics 2

Proportion of e-commerce categories targeted by malware in 2019, by number of targeted brands

Advice and recommendations

As shown in this overview, Black Friday offers a golden opportunity for fraudsters and scammers to steal consumers’ cash. Sometimes a deal can seem too-good-to-be-true, but retailers still offer great discounts at this time of year, so it’s important to examine every deal closely. Shopping around for a bargain can still be enjoyable, it just needs extra vigilance to make sure you can tell the difference between the must-have offers and fake promotions. With incidents of phishing and banking Trojans on the rise, it’s important to stay safe from cyberthreats during the peak Black Friday shopping season.

To stay safe and keep your hard-earned money secure while shopping online, Kaspersky recommends taking the following security measures:

If you are a consumer:

  • Avoid shopping from websites that appear suspicious or flawed, no matter how great their Black Friday deals are
  • Don’t click on unfamiliar links you receive in emails or social media messages, even from people you know, unless you were expecting the message
  • Double check the email address of the sender. If it not the official brand’s website domain, do not click on the link
  • Hover over the linked text in the email or message and see which URL it will actually open
  • Invest in a robust cybersecurity solution to protect all your devices you use to shop online
  • Think about how much money you wish to spend in an online payment transaction account at any one time
  • Reduce the amount of funds you have in your bank and online accounts. The greater the balance, the more can be lost to fraudsters
  • Restrict the number of attempted transactions on your bank card
  • Turn on and always use two-factor authentication (Verified by Visa, MasterCard Secure Code, etc.)

If you are an online brand or retailer:

  • Use a reputable payment service and keep your online trading and payment platform software up to date. Every new update may contain critical patches to make the system less vulnerable to cybercriminals
  • Use a tailored IT and cybersecurity solution to protect your business and customers
  • Pay attention to the personal information used by customers who buy from you. Use a fraud prevention solution that you can adjust to your company profile and the profile of your customers

All research used in this report is based on user data obtained with consent and processed using the Kaspersky Security Network (KSN). All referenced banking Trojan malware were detected and blocked by Kaspersky security solutions.

Russian Hacker Behind NeverQuest Banking Malware Gets 4 Years in U.S. Prison

The Hacker News - 2 hodiny 1 min zpět
A Russian hacker who created and used Neverquest banking malware to steal money from victims' bank accounts has finally been sentenced to 4 years in prison by the United States District Court for the Southern District of New York. Stanislav Vitaliyevich Lisov, 34, was arrested by Spanish authorities at Barcelona–El Prat Airport in January 2017 on the request of the FBI and extradited to the
Kategorie: Hacking & Security

T-Mobile Suffers Data Breach Affecting Prepaid Wireless Customers

The Hacker News - 4 hodiny 11 min zpět
Are you a T-Mobile prepaid customer? If yes, you should immediately create or update your associated account PIN/passcode as additional protection. The US-based telecom giant T-Mobile today disclosed a yet another data breach incident that recently exposed potentially personal information of some of the customers using its prepaid services. What happened? In a statement posted on its website
Kategorie: Hacking & Security

Senators Demand Amazon Disclose Ring Privacy Policies

Threatpost - 21 Listopad, 2019 - 23:07
Amazon's Ring data collection policies are in the spotlight.
Kategorie: Hacking & Security

Microsoft Outlook for Android Bug Opens Door to XSS

Threatpost - 21 Listopad, 2019 - 20:15
Successful exploitation allows attackers to steal potentially sensitive information, change appearance of the web page, and perform phishing, spoofing and drive-by-download attacks.
Kategorie: Hacking & Security

Bad Binder: Android In-The-Wild Exploit

Project Zero - 21 Listopad, 2019 - 19:58
Posted by Maddie Stone, Project Zero

IntroductionOn October 3, 2019, we disclosed issue 1942 (CVE-2019-2215), which is a use-after-free in Binder in the Android kernel. The bug is a local privilege escalation vulnerability that allows for a full compromise of a vulnerable device. If chained with a browser renderer exploit, this bug could fully compromise a device through a malicious website.
We reported this bug under a 7-day disclosure deadline rather than the normal 90-day disclosure deadline. We made this decision based on credible evidence that an exploit for this vulnerability exists in the wild and that it's highly likely that the exploit was being actively used against users.
In May 2019, Project Zero published a blog post and spreadsheet for tracking “in-the-wild” 0-day exploits. In July 2019, I joined Project Zero to focus on the use of 0-day exploits in the wild. We expect our approach to this work will change and mature as we gain more experience with studying 0-days, but the mission stays the same: to “make zero-day hard”. 
So far there are a few key approaches that we have started with:
  • Hunt for bugs based on rumors/leads that a 0-day is currently in use. We will use our bug hunting expertise to find and patch the bug, rendering the exploit benign.
  • Perform variant analysis on 0-days used in the wild. When looking for bugs, you often find more than one of a similar type at the same time. However, an exploit usually uses one instance of a possible pattern or variant. If we can find and resolve all of the similar variant bugs, then the effort involved in creating a new exploit will be higher.
  • Complete detailed analysis of the 0-days from the point of view of bug hunters and exploit developers and share it back with the community. Transparency and collaboration are key. We want to share detailed root cause analysis to inform developers and defenders on how to prevent these types of bugs in the future and improve detection. We hope that by publishing details about the exploit and its methodology, this can inform threat intelligence and incident responders. Overall, we want to make information that’s often kept in silos accessible to all. 

This is just the starting point of how we’re thinking about tactical work around 0-day exploits used in the wild, but we won’t make much progress if we try to do this alone. Whether you’re a vendor, defender, researcher, journalist, threat analyst, policy specialist, victims’ advocate, or someone else, we all have a role we can play to make it hard to exploit 0-days in the wild. Please feel free to reach out to me to explore how we may be able to work together.
The rest of this post is to drive this conversation forward by sharing one instance of such work: CVE-2019-2215. This blog post will explain the bug and the methodology for finding it, how the proof-of-concept exploit we released works, and the evidence and commentary on the use of this bug for in-the-wild exploitation.Hunting the BugIn late summer 2019, Google’s Threat Analysis Group (TAG), Android Security, and Project Zero team received information suggesting that NSO had a 0-day exploit for Android that was part of an attack chain that installed Pegasus spyware on target devices. We received details about the marketed “capability”. These details included facts about the bug and exploit methodology, including:
  • It is a kernel privilege escalation using a use-after-free vulnerability, reachable from inside the Chrome sandbox.
  • It works on Pixel 1 and 2, but not Pixel 3 and 3a. 
  • It was patched in the Linux kernel >= 4.14 without a CVE. 
  • CONFIG_DEBUG_LIST breaks the primitive.
  • CONFIG_ARM64_UAO hinders exploitation.
  • The vulnerability is exploitable in Chrome's renderer processes under Android's isolated_app SELinux domain.
  • The exploit requires little or no per-device customization.
  • A list of affected and unaffected devices and their versions, and more. A non-exhaustive list is available in the description of issue 1942.

Each of these facts gave us important information to scope down the potential bug that we were looking for.
  • “It is a kernel privilege escalation using a use-after-free vulnerability, accessible from inside the Chrome sandbox.”
We know that it’s a use-after-free in the kernel.
  • "It works on Pixel 1 and 2, but not Pixel 3 and 3a."
We can diff the Pixel 2 and Pixel 3 kernels looking for changes.
  • "It was patched in the Linux kernel >= 4.14 without a CVE."
The Pixel 3 is based on the Linux kernel 4.9 and doesn’t include the vulnerability, but the fix is not in the 4.9 Linux kernel, only 4.14.
  • "CONFIG_DEBUG_LIST breaks the primitive."
This was an extremely helpful tip. In the kernel, there are only two actions (three functions) whose behavior changes based on the CONFIG_DEBUG_LIST flag: adding (__list_add) and deleting (__list_del_entry and list_del) from a doubly linked list. Therefore, we could infer that the freed obj is a linked list and has an add or delete performed on it after the free occurs.
  • "CONFIG_ARM64_UAO hinders exploitation."
Likely means that the exploit is using the memory corruption to overwrite the address limit that is stored near the start of the task_struct. (It would normally be stored at the bottom of the stack on Linux <=4.9, but Android backported the change that moved it into task_struct to protect against stack overflows to older kernels.)
  • The exploit requires little or no per-device customization.
We can assume the bug and its exploitation methodology are in the common kernel rather than in code that is often customized, like the framework.
  • "A list of affected and unaffected devices and their versions."
Whenever there was a candidate bug that seemed to fit all the requirements above, I then vetted it against the list of affected and unaffected devices.
Based on these details, I began combing through changelogs and patches looking for the potential bug. Finding CVE-2019-2215 actually occured on my second attempt. I had originally thought the potential bug was a different issue, but then ruled it out based on the information above.
A few weeks after my first attempt at tracking down this bug, others recommended that I should look at Binder. Looking back, the detail that states “The vulnerability is exploitable in Chrome's renderer processes under Android's isolated_app SELinux domain.” should have caused me to look at the Binder driver first, but it didn’t.
When I diffed the Pixel 2 and Pixel 3 drivers/android/binder.c files and their changelogs, there were only a few significant changes. Commit 550c01d0e051461437d6e9d72f573759e7bc5047 stood out in the log because:
  1. It discusses fixing a  “use-after-free” in the commit message,
  2. It is a patch from upstream, and
  3. The upstream patch was only applied to 4.14.

I then began to evaluate this bug against the other requirements of the bug in the leads and found that it matched them perfectly. I also looked through every other change to Binder (~25) between the Pixel 2 and Pixel 3, and no other changes matched every detail.
We wrote a proof-of-concept of our own that demonstrates how this bug can be exploited. The Original Discovery of the Bug This bug was originally found and reported in November 2017 and patched in February 2018. Syzbot, a syzkaller system that continuously fuzzes the Linux kernel, originally reported the use-after-free bug to Linux kernel mailing lists and the syzkaller-bugs mailing list in November 2017. From this report, the bug was patched in the Linux 4.14, Android 3.18, Android 4.4, and Android 4.9 kernels in February 2018. However, this fix was never included in an Android monthly security bulletin and thus the bug was never patched in many already released devices, such as Pixel and Pixel 2.
Android provided the following statement on the original discovery of the bug.
"Android was informed of the security implications of this bug by Project Zero on September 26, 2019. Android partners were notified of the bug and provided updates to address it within 24 hours. Android also assigned CVE-2019-2215 to explicitly indicate that it represents a security vulnerability as the original report from syzkaller and the corresponding Linux 4.14 patch did not highlight any security implications. 
Pixel 3 and 3a were already protected against these issues. Updates for affected Pixel devices were available to users as early as October 7th, 2019.”Technical Details of the BugThe bug is a use-after-free (UAF) in the Binder driver. The binder_thread struct, defined in drivers/android/binder.c, has the member wait of the wait_queue_head_t struct type. wait is still referenced by a pointer in epoll, even after the binder_thread struct containing it is freed.
struct binder_thread {        struct binder_proc *proc;        struct rb_node rb_node;        struct list_head waiting_thread_node;        int pid;        int looper;              /* only modified by this thread */        bool looper_need_return; /* can be written by other thread */        struct binder_transaction *transaction_stack;        struct list_head todo;        bool process_todo;        struct binder_error return_error;        struct binder_error reply_error;        wait_queue_head_t wait;        struct binder_stats stats;        atomic_t tmp_ref;        bool is_dead;        struct task_struct *task;};
struct __wait_queue_head {        spinlock_t              lock;        struct list_head        task_list;};typedef struct __wait_queue_head wait_queue_head_t;
The BINDER_THREAD_EXIT ioctl calls the binder_thread_release function which frees the binder_thread struct. However, if epoll is called on this thread, binder_poll tells epoll to use wait, the wait queue that is embedded in the binder_thread struct. Therefore, when the binder_thread struct is freed, epoll is pointing to the now freed wait queue. Normally, the wait queue used for polling on a file is guaranteed to be alive until the file’s release handler is called. Rare cases require the use of POLLFREE. In contrast, the Binder driver only worked if you constantly removed and re-added the epoll watch. This is the underlying bug and the use-after-free is a symptom of that.
When we look at the stack trace from KASAN in the original report, we can see the use-after-free is in remove_wait_queue in kernel/sched/wait.c. The source code for the remove_wait_queue is below. In the remove_wait_queue function, q is the pointer to the freed wait_queue_head_t in the binder_thread struct and wait is an entry in the wait queue whose head has been freed. The use-after-free that triggered the KASAN crash is the call to spin_lock_irqsave with argument &q->lock when q is pointing to freed memory.
However, the __remove_wait_queue call is more interesting for exploitation. As shown below, __remove_wait_queue simply calls list_del on the task_list in the wait queue, giving us an unlinking primitive.
void remove_wait_queue(wait_queue_head_t *q, wait_queue_t *wait){        unsigned long flags;        spin_lock_irqsave(&q->lock, flags);        __remove_wait_queue(q, wait);        spin_unlock_irqrestore(&q->lock, flags);}
__remove_wait_queue(wait_queue_head_t *head, wait_queue_t *old){        list_del(&old->task_list);}
The bug can be triggered with the following code, which was also in the original report from syzkaller.
#include <fcntl.h>#include <sys/epoll.h>#include <sys/ioctl.h>#include <unistd.h>
#define BINDER_THREAD_EXIT 0x40046208ul
int main(){        int fd, epfd;        struct epoll_event event = { .events = EPOLLIN };                        fd = open("/dev/binder", O_RDONLY);        epfd = epoll_create(1000);        epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);        ioctl(fd, BINDER_THREAD_EXIT, NULL);}
I verified that the Pixel 2, running Android 10 with SPL September 2019, still included this bug. The KASAN output is included in the issue tracker.Exploiting the Use-After-FreeAfter confirming the bug and reporting to Android, I began working with fellow team member, Jann Horn, to write a proof-of-concept (PoC) exploit. The PoC we published on the issue tracker in comment #7 used the UAF described above to gain arbitrary kernel read and write from an unprivileged application context. In this section, I will explain how the PoC exploit that we wrote works. This section describes how we decided to exploit this bug and not necessarily how the in-the-wild exploit works.
This exploit triggers the UAF twice in order to overwrite the address limit to obtain arbitrary kernel read and write privileges. The first use of the UAF leaks the address of the task_struct, which contains the process’s address limit (addr_limit). The second use of the UAF overwrites the value of addr_limit. The addr_limit value defines which address range may be accessed when dereferencing userspace pointers. Usercopy operations only access addresses below the addr_limit. Therefore, by raising the addr_limit by overwriting it, we will make kernel memory accessible to our unprivileged process.
To trigger the UAF, we use vectored (scatter/gather) I/O in a somewhat similar way to what DiShen presented in his talk from Code Blue 2017, “The Art of Exploiting Unconventional Use-after-free Bugs in Android Kernel” [video].Triggering the UAFTo exploit the UAF bug, we reallocate the freed binder_thread memory as an I/O vector and then use the unlinking primitive to gain scoped kernel read to leak the task_struct address. We trigger the UAF again for scoped kernel write to then overwrite the addr_limit. This section describes how we use the UAF for the initial read and write.About Vectored I/OVectored I/O is also known as scatter/gather I/O. Vectored reads move data from a data source (here a file) into a set of disparate buffers (scatter), moving onto the next after each buffer is filled. A vectored write moves data from a set of buffers into a data sink (here a file) (gather). readv and writev are syscalls for performing vectored I/O. Their definitions from fs/read_write.c are below. 
SYSCALL_DEFINE3(readv, unsigned long, fd, const struct iovec __user *, vec,                unsigned long, vlen)
SYSCALL_DEFINE3(writev, unsigned long, fd, const struct iovec __user *, vec,                unsigned long, vlen)
The vec arguments are arrays of iovec structs where each iovec struct describes a buffer. The iovec struct definition from include/uapi/linux/uio.h is below.
struct iovec{        void __user *iov_base;         __kernel_size_t iov_len; };
We use writev to leak the address of the task_struct the first time we trigger the UAF. In addition to readv and writev, the recvmsg syscall for receiving a message from a socket also uses vectored I/O. In the msghdr, the second argument to recvmsg, there is a member named msg_iov that points to an array of iovec structs. We use recvmsg the second time we trigger the UAF to overwrite the addr_limit. Using vectored I/O for UAF write and readWe use the vectored I/O to gain UAF read (leaking the task_struct address) and UAF write (overwriting the addr_limit in the task_struct). Vectored I/O operations (like readv, writev, and recvmsg) import the user-space I/O vector array into kernel space and verify that all of the vector elements are in userspace in the call to rw_copy_check_uvector. If rw_copy_check_uvector returns successfully, the iovec array is now in kernel space and there will not be another verification on the pointer values in the iov_base fields. This means that while the I/O is blocking, we can overwrite the buffer pointers in the iovec array using our UAF read/write and then read from or write to a place in kernel memory. 
The iovec struct is of size 16 bytes and the binder_thread struct is 408 bytes. Therefore, we will create an array of 25 iovec structs in order to make the iovec array a similar size to the freed struct. The kernel allocates memory based on the size of the allocations so if we can control a struct of almost the same size as the freed memory, then there is a good chance that our controlled struct will be allocated into the same place. The iovec array is 8 bytes smaller than the binder_thread in order to not overwrite the task_struct pointer value at the end of the binder_thread struct, but that is still close enough to be allocated into the same slab, and thus the same position in kernel memory as the freed binder_thread struct. 
When the iovec array is allocated into the same memory as our freed binder_thread struct, the struct members will line up as below.
binder_thread struct
iovec array0x00
0x00: iovec[0].iov_base...
0x08: iovec[0].iov_len...
...0xA0: wait.lock
0xA0: iovec[10].iov_base0xA8:
0xA8: iovec[10].iov_len0xB0: wait.task_list.prev
0xB0: iovec[11].iov_base...
Once the vectored I/O has copied our iovec structs into kernel memory, we then want the I/O operation to block so that ep_remove_wait_queue can run from a separate thread. When ep_remove_wait_queue runs, it will perform a list_del operation on the values at offsets 0xA8 and 0xB0 in our diagram since ep_remove_wait_queue still believes these memory values to be a part of the wait_queue_head_t struct. 
ep_remove_wait_queue calls remove_wait_queue that calls __remove_wait_queue that calls list_del. 
static inline void __list_del(struct list_head * prev, struct list_head * next){        next->prev = prev;        WRITE_ONCE(prev->next, next);}
#ifndef CONFIG_DEBUG_LIST...static inline void list_del(struct list_head *entry){        __list_del(entry->prev, entry->next);        entry->next = LIST_POISON1;        entry->prev = LIST_POISON2;}
The UAF exploitation technique described in this blog post is not successful when CONFIG_DEBUG_LIST is enabled because list_del is implemented differently when it’s enabled. The implementation when CONFIG_DEBUG_LIST is NOT enabled is shown above.
The debug implementation, shown below, is found in lib/list_debug.c. In the debug version, list_del calls __list_del_entry which includes checks to ensure that prev->next == entry && next->prev == entry. If any of these checks fail, BUG_ON will be called and the process will die (and on Android devices, which usually set kernel.panic_on_oops=1, the entire device will reboot). This check is what prevents this exploitation method from working when CONFIG_DEBUG_LIST is enabled.
void __list_del_entry(struct list_head *entry){        struct list_head *prev, *next;
        prev = entry->prev;        next = entry->next;
        if (WARN(next == LIST_POISON1,                "list_del corruption, %p->next is LIST_POISON1 (%p)\n",                entry, LIST_POISON1) ||            WARN(prev == LIST_POISON2,                "list_del corruption, %p->prev is LIST_POISON2 (%p)\n",                entry, LIST_POISON2) ||            WARN(prev->next != entry,                "list_del corruption. prev->next should be %p, "                "but was %p\n", entry, prev->next) ||            WARN(next->prev != entry,                "list_del corruption. next->prev should be %p, "                "but was %p\n", entry, next->prev)) {                BUG_ON(PANIC_CORRUPTION);                return;        }
        __list_del(prev, next);}EXPORT_SYMBOL(__list_del_entry);
/** * list_del - deletes entry from list. * @entry: the element to delete from the list. * Note: list_empty on entry does not return true after this, the entry is * in an undefined state. */void list_del(struct list_head *entry){        __list_del_entry(entry);        entry->next = LIST_POISON1;        entry->prev = LIST_POISON2;}
The entry being passed to list_del is an entry in the wait queue list. The freed wait_queue_head_t struct contains the list head of which this entry is the only member. Prior to the list_del operation, the list looks like in the diagram below.

After the list_del the operation looks like the diagram below. The list head prev and next pointers have been set to point to the list head. This means that iov_base has been overwritten with a kernel address and we can now perform scoped read and write operations from the kernel space beginning at the list head. 

Leaking the task_struct pointerWe follow the process outlined above to use the use-after-free to leak the task structure pointer. In the Linux kernel, and thus in the Android kernel, the task_struct includes most of the important information about a process. In this case, we want to get the pointer to the task_struct because it includes the process’s address limit. 
The code to leak the task_struct pointer is in the function leak_task_struct in the PoC. The function starts by adding the binder file descriptor (fd) to the epoll’s interest list. We then create an array of 25 iovec structs. Next, we set the values of each of the iovec entries. For the first 10 entries, we set both the iov_base and iov_len to 0 so that the kernel skips them when processing the vector. iovec[10].iov_base is set to a value that will look like an unlocked spinlock. iovec[10].iov_len is set to the same size as the pipe such that when the pipe will block after moving all the contents from iovec[10].iov_base into the pipe. Once it unblocks, it will begin on iovec[11].
binder_thread struct
iovec array0x00
0x00: iovec[0].iov_base0x00000000 00000000...
0x08: iovec[0].iov_len0x00000000 00000000...
...0xA0: wait.lock
0xA0: iovec[10].iov_basedummy_page_4g_aligned0xA8:
0xA8: iovec[10].iov_len0x10000xB0: wait.task_list.prev
0xB0: iovec[11].iov_base0xDEADBEEF...
0xB8: iovec[11].iov_len0x1000...
We set iovec[10].iov_base to dummy_page_4g_aligned because we need the lower-half of the address value to be 0 for it to pass as a spinlock. In remove_wait_queue, we need spin_lock_irqsave to run successfully so that __remove_wait_queue is called.
For this to be successful, the call to remove_wait_queue from within the EPOLL_CTL_DEL execution must occur after the iovec array has been copied to kernel memory by rw_copy_check_uvector (called by writev) and iovec[10] has been processed (since its length will be clobbered by the UAF write), but before writev begins reading from the address at iovec[11].iov_base. 
Therefore, we need the writev call to block prior to trying to write the iovec[11] contents to the pipe. To do this, we fill the whole pipe with contents that we don’t care about. Because we completely fill the pipe, writev will block until something begins to read from the pipe. Therefore, we set iovec[10].iov_base to be the address of the buffer with these filler contents and we set its length to the same size as the pipe size. writev will put all of the dummy contents into the pipe and block, giving us time to change the address of iovec[11].iov_base with the unlinking primitive in remove_wait_queue. After remove_wait_queue finishes, we can read the dummy contents from the pipe, unblocking the write. The now-unblocked writev will begin reading from the address in iovec[11].iov_base, which has now been changed to the list head address, binder_thread + 0xa8, in the kernel.

Once the writev finishes, we read from the other end of the pipe. The value at offset 0xE8 is the task_struct pointer. (The wait queue list head is at 0xa8 in the binder_thread struct and the task_struct pointer is at 0x190.)
Overwriting the Address LimitNow that we have saved off the task_struct pointer, we trigger the UAF again in order to overwrite the address limit (at task_struct + 0x08), this time using recvmsg instead of writev. The process through the list_del is the same: the iov_base ends up pointing to the list_head of the wait_queue. At this point, though, instead of reading from that address, we begin to write the values below. 
  unsigned long second_write_chunk[] = {    1, /* iov_len */ (already used) */    0xdeadbeef, /* iov_base (already used) */    0x8 + 2 * 0x10, /* iov_len (already used) */    current_ptr + 0x8, /* next iov_base (addr_limit) */    8, /* next iov_len (sizeof(addr_limit)) */    0xfffffffffffffffe /* value to write - new addr_limit */  };
To understand how this overwrites the addr_limit, we need to remember how scatter I/O works: we will read from a unix domain socket to disparate buffers, filling up one before moving to the next. After the list_del, the scatter I/O is about to begin on the buffer at iovec[11].iov_base. The value at iovec[11].iov_base now points to the list head of the wait queue after the list_del operation. The first 5 values we are going to overwrite are our iovec structs. We originally set iovec[11].iov_len to 0x28 which means we write 0x28 bytes before moving to the buffer stored in iovec[12].iov_base. We want to overwrite iovec[12].iov_base to be the address of the addr_limit so that we can overwrite the address limit without having to overwrite everything between the list head and the address limit. This is why we set the length of the iovec[11] buffer to 0x28 bytes: 0x8 bytes each for iovec[10].iov_len, iovec[11].iov_base, iovec[11].iov_len, iovec[12].iov_base, and iovec[12].iovec_len. Then we move to write through the newly-overwritten address in iovec[12].iov_base. This writes 0xFFFFFFFFFFFFFFFE (one less than KERNEL_DS to bypass the segment_eq(get_fs(), KERNEL_DS) branch in iov_iter_init()) to the addr_limit, now making all memory (including kernel memory) accessible as part of the user-space memory range in our process and thus granting arbitrary kernel read and write. 
Values after list_del operation, prior to recvmsg
Values after recvmsg0x00
...0xA8: iovec[10].iov_len +0xA8 (points to itself) list head←            →0xA8: iovec[10].iov_len10xB0: iovec[11].iov_base+0xA8 (points to previous element)
0xB0: iovec[11].iov_base0xDEADBEEF0xB8: iovec[11].iov_len0x28
0xB8: iovec[11].iov_len0x280xC0: iovec[12].iov_base0xBEEFDEAD
0xC0: iovec[12].iov_basetask_struct + 0x80xC8: iovec[12].iov_len0x8
0xC8: iovec[12].iov_len0x8

task_struct + 0x8 (addr_limit): 0xFFFFFFFFFFFFFFFE
In-the-Wild AnalysisAs stated in the introduction, we deemed that there was enough credible evidence that CVE-2019-2215 was being used in the wild to support a 7-day disclosure deadline. This credible evidence included the leads and details outlined above in the “Hunting the Bug” section, and how after a detailed review of kernel patches, all requirements perfectly aligned with one bug (and only one bug). The examined information included marketing materials for this exploit, and that the exploit was used to install a version of Pegasus. With this evidence, we decided that although we did not have an exploit sample, the risk to users was too great to wait 90 days for a patch and disclosure, and thus reported this to Android under a 7-day deadline.
The 7-day deadline exists because “each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more devices or accounts will be compromised.” Therefore, we decided that this vulnerability required disclosure to the public as soon as possible.Variant AnalysisI think the most important “variant” that we can take away from this bug is that bugs are often patches in the upstream Linux and/or Android kernels that are not flagged as security bugs (though have security impact), so they are not included in the Android Security Bulletin and thus do not get patched in released devices. Sorting through Linux patches is a huge undertaking, so instead, one approach to address this issue could be addressed by regularly syncing with the upstream stable kernels. 
In addition, we also looked for other variants where the poll handler uses wait queues that are not tied to the lifetime of the file and no issues of similar significance have been discovered so far.ConclusionCVE-2019-2215 permits attackers to fully compromise a device with only untrusted app access or a browser renderer exploit and despite the patch being available in the upstream Linux kernel, it was left unpatched in Android devices for almost 2 years. In that time, we believe that attackers have been able to use this vulnerability to exploit users in the wild. Given the information in various public documents about the services that NSO Group provides, it seems most likely that this vulnerability was chained with either a browser renderer exploit or other remote capability.
Kernel vulnerabilities in Android are especially dangerous because they are largely the same across different devices, whereas other components on the device, such as the framework, SOC, or pre-installed apps, are often customized from one device to another and across different manufactures. With this single kernel vulnerability, the majority of Android devices manufactured prior to September 2018 were vulnerable. The patch gapping between the LTS Linux kernel, the Android common kernel, and the kernels running on end-users’ devices leaves a ripe surface area for exploitation. To prevent issues like this, Android could force all devices to sync to both upstream Linux and the Android common kernel at a regular cadence.
We publicly disclosed CVE-2019-2215 on October 3, 2019, 7-days after reporting to Android due to credible evidence of in-the-wild exploitation. We made this determination based on documents marketing and detailing an Android exploit “capability”. Our view is that it's often reasonable to infer that a vulnerability is being exploited in-the-wild from other forms of contextual information (such as the marketing materials seen in this case, combined with a deep analysis of patches) and that a binary/sample isn’t always required. Therefore, each day we waited to disclose meant another day that at-risk users were exposed to harm. 
On October 6, 2019, Android added updates to the October Android Security Bulletin and addressed the issue. Devices showing a security patch level on or after Oct 6, 2019 should be patched against CVE-2019-2215.
This bug highlights that in order to “make zero-day hard”, we need to work to learn as much as we can from 0-days used in the wild AND share it back with the community so that we can all work together to make this kind of exploitation that much harder. Please reach out and let’s collaborate!tl;dr
  1. Leads, even without samples, can help us find bugs and get security vulnerabilities patched. 
  2. The patch gap between released devices and the kernel leaves a ripe area for exploitation. The kernel is a key layer in Android’s security model.
  3. Project Zero is ramping up its in-the-wild 0day analysis work, and we're very open to collaboration. Please reach out!
Kategorie: Hacking & Security

Cybercrime Investigator Degree Requirements

InfoSec Institute Resources - 21 Listopad, 2019 - 18:18

Introduction Cybercrime Investigators provide valuable forensics, investigative, and incident response services to cases that involve computer-related crimes. It’s also a solid career choice; according to the Bureau of Labor Statistics, the information security field is projected to grow 32% by 2028.  If you’re considering a career as a Cybercrime Investigator, you probably have a lot […]

The post Cybercrime Investigator Degree Requirements appeared first on Infosec Resources.

Cybercrime Investigator Degree Requirements was first posted on November 21, 2019 at 11:18 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at
Kategorie: Hacking & Security

Expanding the Android Security Rewards Program

Google Security Blog - 21 Listopad, 2019 - 18:01
Posted by Jessica Lin, Android Security Team

The Android Security Rewards (ASR) program was created in 2015 to reward researchers who find and report security issues to help keep the Android ecosystem safe. Over the past 4 years, we have awarded over 1,800 reports, and paid out over four million dollars.

Today, we’re expanding the program and increasing reward amounts. We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million.

As mentioned in a previous blog post, in 2019 Gartner rated the Pixel 3 with Titan M as having the most “strong” ratings in the built-in security section out of all devices evaluated. This is why we’ve created a dedicated prize to reward researchers for exploits found to circumvent the secure elements protections.

In addition to exploits involving Pixel Titan M, we have added other categories of exploits to the rewards program, such as those involving data exfiltration and lockscreen bypass. These rewards go up to $500,000 depending on the exploit category. For full details, please refer to the Android Security Rewards Program Rules page.

Now that we’ve covered some of what’s new, let’s take a look back at some milestones from this year. Here are some highlights from 2019:

  • Total payouts in the last 12 months have been over $1.5 million.
  • Over 100 participating researchers have received an average reward amount of over $3,800 per finding (46% increase from last year). On average, this means we paid out over $15,000 (20% increase from last year) per researcher!
  • The top reward paid out in 2019 was $161,337.
Top Payout

The highest reward paid out to a member of the research community was for a report from Guang Gong (@oldfresher) of Alpha Lab, Qihoo 360 Technology Co. Ltd. This report detailed the first reported 1-click remote code execution exploit chain on the Pixel 3 device. Guang Gong was awarded $161,337 from the Android Security Rewards program and $40,000 by Chrome Rewards program for a total of $201,337. The $201,337 combined reward is also the highest reward for a single exploit chain across all Google VRP programs. The Chrome vulnerabilities leveraged in this report were fixed in Chrome 77.0.3865.75 and released in September, protecting users against this exploit chain.

We’d like to thank all of our researchers for contributing to the security of the Android ecosystem. If you’re interested in becoming a researcher, check out our Bughunter University for information on how to get started.

Starting today November 21, 2019 the new rewards take effect. Any reports that were submitted before November 21, 2019 will be rewarded based on the previously existing rewards table.

Happy bug hunting!

Kategorie: Hacking & Security

Linux Webmin Servers Under Attack by Roboto P2P Botnet

Threatpost - 21 Listopad, 2019 - 17:43
A newly-discovered peer-to-peer (P2P) botnet has been found targeting a remote code execution vulnerability in Linux Webmin servers.
Kategorie: Hacking & Security

Gnip Banking Trojan Shows Ongoing, Aggressive Development

Threatpost - 21 Listopad, 2019 - 17:35
The mobile malware, which incorporates Anubis source code, could evolve into a fully fledged spyware in the future.
Kategorie: Hacking & Security

Velvyslankyně USA při OSN zapomněla heslo, a tak tajné dokumenty poslala méně zabezpečenou linkou - bezpečnost - 21 Listopad, 2019 - 16:24
Největší slabinou každého počítačového systému je zpravidla jeho uživatel. A potvrzuji to i analýzy podle kterých za mnoha krádežemi databází aj. stálo nějaké to triviální nedodržení bezpečnostních pravidel. Aktuálně se tím baví Amerika na příkladu Nikki Haleyové, které v letech 2017-2018 ...
Kategorie: Hacking & Security

DNS-over-HTTPS is coming to Windows 10

Sophos Naked Security - 21 Listopad, 2019 - 16:22
Microsoft will soon add the ability to use DNS-over-HTTPS and DNS-over-TLS into its networking client.

Android camera bug could have turned phones against their users

Sophos Naked Security - 21 Listopad, 2019 - 15:56
Google has patched a bug in the Android camera app that allowed other applications to bypass the strict controls on camera and audio access.

Brave 1.0 is ready for privacy-loving web surfers> - 21 Listopad, 2019 - 15:40
Are you a privacy-conscious Linux user? If so, you may want to check out Brave 1.0, which is now out of beta and in stable release form. Learn more:
Kategorie: Hacking & Security

New Bill Would Require Federal Law Enforcement To Obtain Warrant Before Using Facial Recognition> - 21 Listopad, 2019 - 15:26
A new bill introduced by Sens. Chris Coons and Mike Lee would prevent “abuse” of facial recognition technology by federal authorities. Learn more in this Security Today article:
Kategorie: Hacking & Security

Malware Spotlight: What is APT?

InfoSec Institute Resources - 21 Listopad, 2019 - 15:01

Introduction For some things, the whole is greater than the sum of its parts. When it comes to cybersecurity, this saying is an appropriate description of Advanced Persistent Threat (APT) cyberattacks. Made up of a thoughtful combination of different tools and methods, sometimes rudimentary ones at that, the dreaded APT is magnitudes more of a […]

The post Malware Spotlight: What is APT? appeared first on Infosec Resources.

Malware Spotlight: What is APT? was first posted on November 21, 2019 at 8:01 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at
Kategorie: Hacking & Security

Download: 2019 Security Team Assessment Template

Threatpost - 21 Listopad, 2019 - 15:00
The Ultimate 2019 Security Team Assessment Template is a unique tool that encapsulates all the major KPIs of the organizational security team’s main pillars.
Kategorie: Hacking & Security

New Cisco Certifications and Changes Coming in 2020

InfoSec Institute Resources - 21 Listopad, 2019 - 15:00

Introduction: Jump start your career with vendor-specific Cisco certifications Cisco Systems, Inc. offers a line of vendor-specific certifications for its products. Cisco’s many credentials suit every level of IT practitioner, offering entry-level, intermediate, specialist or even expert-level credentials. Network professionals and managers who pursue any of their certifications will definitely bring value to the organizations […]

The post New Cisco Certifications and Changes Coming in 2020 appeared first on Infosec Resources.

New Cisco Certifications and Changes Coming in 2020 was first posted on November 21, 2019 at 8:00 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at
Kategorie: Hacking & Security

Official Monero site delivers malicious cash-grabbing wallet

Sophos Naked Security - 21 Listopad, 2019 - 13:18
If you downloaded the Monero command line wallet recently, check it before using it.
Syndikovat obsah