We discuss how Microsoft Word helped trap a multi-million dollar fraudster, how Amazon Ring may be recording more than you’re comfortable with, and how teens are flocking to TikTok (and why that might be a problem).
All this and much more is covered in the latest edition of the award-winning “Smashing Security” podcast by computer security veterans Graham Cluley and Carole Theriault, joined this week by Maria Varmazis.
Cisco Talos works with many organizations around the world, monitoring and protecting against sophisticated threats every day. As such, we are watching the current state of events in the Middle East very closely for our customers and partners who may be impacted by the ongoing situation. We are continuing to evaluate potential threats and attack vectors, especially related to critical infrastructure and high-profile businesses and industries.
A challenge with protecting against state-sponsored campaigns is that the primary and ideal targets are potentially already compromised, either by a specific adversary or their allies who would be amenable to acting on their behalf. In previous research, Talos has observed footholds like this that can go undetected for extended periods, waiting to be modified remotely to exact a variety of potential malicious activities.
It may be difficult for primary target organizations to detect activity and defend themselves at the perimeter. Hopefully, they have employed a layered defense, which should include two-factor authentication, network segmentation and endpoint protection.
Of course, the potential also exists for the adversary to move away from a targeted maneuver to more broadly focused disruptions that could incorporate a much wider array of businesses and even consumers. This means that everyone should view this as a wake-up call — shore up defenses, update/patch your devices and focus on cyber hygiene. Employ authentication everywhere, beware of suspicious links, emails, etc. — phishing/credential theft continues to be popular among attackers. Every business should at least take a second look at every strange thing they see — don’t ignore anomalous activities, take the time to see if there is something nefarious at the end of the tunnel.
While prior campaigns in the region have heavily relied on wiper malware, this is no guarantee that future campaigns will continue this trend. At times like this, vigilance is key.
The post Continued Escalation of Tensions in the Middle East appeared first on Cisco Blogs.
Most patients practice preventative care through regular trips to the doctor, catching minor issues before they turn into major medical problems. So, why don’t more organizations follow suit with security testing to prevent breaches and fortify the safety of patient information?
Too often, remediation is an afterthought as developers scramble to patch holes in their systems post-breach. A recent report in the journal of Health Services Research suggests that this herculean effort can put a strain on patient health when things slow down after a breach and new security measures are introduced. However, preventative care can work in the security world just as it does for your health.
Less isn’t more in healthcare cybersecurity
Some experts and industry thought leaders see unfortunate breaches as opportunities to better understand what went wrong and how it can be prevented in the future. Unfortunately, information from these breaches sometimes muddies the tumultuous waters of cybersecurity and can cause panic over increased security procedures.
Josephine Wolff, assistant professor of cybersecurity policy at Tufts Fletcher School of Law and Diplomacy, found that the 2019 report published in the journal of Health Services Research draws dangerous conclusions about the negative impacts of mitigating cyberattacks in healthcare. The HSR paper proposes that lost passwords and associated security measures—like two-factor authentication—hold up patient care with increased wait times for ECGs and result in higher rates of fatal heart attacks. A point, they suggest, that should lead to less aggressive security efforts.
In her article, Wolff proposes that a slower remediation process is precisely why more medical institutions should view this as a crucial pivot point, not a nuisance. She explains, “Undoubtedly, IT upgrades and updates can inconvenience workers and slow down operations in any workplace, but that is a reason to develop techniques and processes for implementing them more smoothly—not to write them off as harmful and counterproductive.” Even the most basic preventive actions are crucial best practices, and they’re just a starting point.
The cyberattack epidemic in healthcare
Data from the last decade shows just how damaging breaches can be for institutions and patients alike. According to HIPAA Journal, there were 2,546 healthcare breaches from 2009 to 2018 that exposed over 180,000,000 patient records to attackers, resulting in costly settlements and fines for HIPAA violations. Additionally, figures from the Protenus 2019 Breach Barometer report reveal that in 2018 alone, the healthcare sector saw a whopping 15,085,302 patient records breached—a number that nearly tripled from 2017 to 2018.
These trends are alarming but important to watch. Our 10th annual State of Software Security (SOSS) report examines trends in various industries, including healthcare, and the data sheds some light on why it’s so crucial for organizations to get a jump on security measures.
We found that healthcare institutions have the highest prevalence of severe flaws at 52 percent and are the slowest to fix said flaws, with a median time-to-remediation (MedianTTR) of 131 days. All this typically contributes to security debt, which accumulates over time as more and more flaws are left uncorrected.
Daunting security debt is a problem that your DevOps team can tackle with the right processes in place, including a steady cadence of scans. Our SOSS report found that those who conduct up to 12 scans per year have a MedianTTR of 68 days, while those who scan more than 260 times per year have a MedianTTR of just 19 days (that’s a substantial 72 percent reduction in remediation time).
Increasing the regularity of your scans can have a lasting impact on security debt. In fact, we found that frequent scanners carry 5x less security debt than sporadic scanners who lack a reliable testing process. The remedy is clear: scanning often and speeding up fix rates to mitigate severe flaws will cause far fewer headaches in the future and, ultimately, prevent downtrends in patient care.
A process-minded prognosis
The good news in this year’s SOSS report is that healthcare institutions have a fix rate of 72 percent, which is decent when compared to other industries. Still, hospitals and healthcare providers must stay on top of application scanning to increase frequency and efficiency, cutting down their MedianTTR.
The solution? Shifting DevSecOps behaviors from reactive to proactive through keener code management and more thorough remediation processes. This entails making sure security programs:
- Include a trained team of security-minded developers
- Cover all applications across your health organization
- Include a frequent and steady scanning cadence
- Have ample resources developers can tap into for testing and fixes
- Are adaptable enough to handle shifting landscapes in cybersecurity
- Are equipped to cover third-party vendors used by the organization
Taking steps towards a well-rounded security program not only bolsters your defense against attacks but also sheds light on wrinkles in your remediation process that need ironing. With these measures in place, if a breach or a cyberattack occurs, your healthcare organization will be better equipped to handle issues with minimal to no impact on patient care.
Learn more about cybersecurity in healthcare
Like what you see? Find more info about the state of cybersecurity for healthcare by downloading our SOSS Volume 10 Industry Snapshot, and then check out the full report to keep a pulse on the shifts in DevSecOps over the last ten years.
Just before the holidays, Citrix announced that their Citrix Application Delivery Controller (ADC) and Citrix Gateway are prone to a vulnerability which can allow remote unauthenticated attackers to execute code on vulnerable gateways. This led to a wave of alarming headlines about “80,000 firms” being exposed to hacking due to this flaw. What’s more interesting […]… Read More
The post Citrix NetScaler CVE-2019-19781: What You Need to Know appeared first on The State of Security.
In part one of this series, we focused on installing several tools that will be useful for reversing and exploiting security weaknesses on Windows. These tools are free to access, so anyone can use them to learn and try out the useful exercises that this article series will provide.
Before going into the exercises, let’s list and define some important concepts.
Bug: A bug is the result of a failure or deficiency during the process of creating computer programs (software). Such a failure can occur at any stage of the software's life cycle, although the most obvious ones occur at the development and programming stage.
Vulnerability: Vulnerabilities are a subset of bugs. A vulnerability is a certain type of bug in a piece of software that allows, through exploitation, the security of a computer system to be compromised.
Vulnerabilities allow threat actors to perform actions for which the software was not intended and abuse them.
While there are many types of vulnerabilities, we are going to focus on studying Windows exploits, and their exploitation techniques.
Exploit: An exploit is software code that tries to use a vulnerability of other software.
The goal of the exploit could be malicious, such as destroying or disabling the attacked system.
More typically, exploits are used to violate security measures in order to be able to gain unauthorized access to information and use it for one’s own benefit or as a source of other attacks on third parties.
Threat actors can exploit a vulnerability to crash an application or even the whole system. They can also execute code on local or remote machines. Difficulty varies depending on the vulnerability, the environment, and the mitigations that the target has at the moment of exploitation.
The first type of vulnerability we are going to study will be the buffer overflow, starting with the simplest example, building techniques step by step as we increase in difficulty. A buffer is a memory space of a certain size reserved for storing and managing data. A buffer overflow occurs when a computer program exceeds the amount of memory reserved for it by writing to the contiguous memory block.
Think of an empty 20 liter tank. You can store no more than 20 liters of liquid. If you want to store more in a single tank you need to find a larger buffer. Otherwise, when trying to store, say, 40 liters in that 20 liter tank, the liquid will overflow. This overflowing is the buffer overflow, or the overflow of the tank that exceeds the maximum capacity of it.
For instance, this can occur when a computer application doesn’t have the necessary security checks in its programming code, like measuring the amount of data that will be copied into a buffer ensuring that it does not exceed its size.
The most common types of buffer overflows are stack buffer overflows and heap buffer overflows.
A stack is used to store local variables of a function that are only needed while the function is executing. In most programming languages it is fundamental that we know a variable size for compile time if we want to store it in the stack.
The heap is used to reserve dynamic memory, whose need is not known in advance, but is expected to last a while. If we do not know a function’s size or it’s decided at runtime, it should be reserved in the heap.
It is also used for objects that vary in size, because we do not know at compile time how long they will last or what they will cover.
At Core Security, we often challenge new employees to solve the stacks and abos problem of one of our original founders, Gerardo Richarte. Challenge yourself to the stack exercises below.
Stack Exploitation Exercises
We will start step by step with the stacks that are the simplest, compiled with minimal protection to make it easier to start exploitation.
Let's see the source code of stack1.
Here we have the exercises folder and inside it is the source code of the stack1 called STACK1_VS_2017.cpp.
Let's try to understand this code and see where the buffer overflow can be produced, and if it will be an overflow buffer in the stack or in the heap.
A call to MessageBoxA that will show us a text that encourages us to solve it has been added to the code of the original stack1. It is just an addition that does not influence anything but is a standard call to Windows function that we will not analyze here.
We know that within a function, if there are local variables you must reserve space for them before starting with the instructions themselves.
Below is some original code, created by Gerado Richarte:
The first part, in red, reserves the space for local variables. In this case there are two local variables, cookie and buf.
You can find them in the table of data types.
In the case of buf, we see that it is an array or string of char so as a char it has one-byte size.
As an array, it has 80 chars, with 80 bytes length.
Creating an array can store many values of the same type of data. Begin with what type the data is and how many there will be.
In the first example, there is an array of100 ints. Since one int occupies four bytes, the total length would be 100 x 4= 400 bytes.
In the second example, one float occupies four bytes, so it would be an array of five floats. The final size would be 5 x 4 = 20 bytes.
When we analyze an array at a low level, we see that it is a reserved memory space or buffer, but it is not the only way to reserve space. There are other types of data variables that also require reserved space in the memory that will need buffers to keep its content.
Returning to our exercise:
This is a char array of 80 x 1 = 80 bytes long. Like our tank of 20 liters, if we try to keep more than 80 bytes it will overflow.
Next, we’ll discuss how the buffer or variable char array called buf (indicated below with red arrows) is used.
In the first instruction there is a printf that is used to show the string between the quotes as a console message
But printf not only prints the quoted string but also prints with formatting. The percentage characters inside tell us that it will form an output string. The string is just the first argument of the function and is in the output format. There can be several other arguments--one for each %.
in this case, there are two %x. Next, we’ll check the table of field types for printf.
We see that it will take those integers (int) and insert them into the output string with base16--hexadecimal. The 08 refers to the fact that if the number has less than 8 digits it will be filled with spaces.
This example is filled with spaces before the number, so there are several modifiers to change the output, referred to as format specifiers.
In our case, our format specifier was [width].
The result is not truncated, but instead only fills in with spaces if the length of the argument to insert is less than the value in front of the x.
Therefore, we know that it prints two hexadecimal numbers that come from the two arguments.
We know that a variable has a memory address and a value to store. Like our 20-liter tank, it has its contents or value, which are the amount of liters it stores inside. But if I have a garage full of similar tanks, I need to have some way of knowing where the tank I want is located out of all the tanks I own.
This is indicated by the & (ampersand symbol), which tells us the direction or location of the tank, but not its contents or value. The ampersand is used to indicate the memory address of the variable where the data will be stored.
For instance, if I run the executable on a console I'll see:
The above is merely one possible example. The output will vary depending on your environment.
The memory grows from zero upwards. The address of buf is less than the cookie address so it will grow.
And what do the addresses of both variables tell us? In my case they were &buf=0x19fed4 and &cookie= 0x19ff24. Both variables are represented in hexadecimal. In order to differentiate them from the decimal numbers, an 0x has been placed in front of them.
The subtraction can be completed in a Python console or in Pycharm itself:
The buffer size is 80 because cookie starts right where the buffer ends, so the difference gives us the buffer size.
Often, when we do these types of accounts based on the source code, it gives us a bigger size than the one reserved in the original code. The compiler ensures that it will reserve at least 80 bytes. It can reserve more, never less.
The point is that we already know some things about the code, the sizes of the variables and their location thanks to the printf command.
Now let's see the other place where the variable buf is used because for now it only prints its address but has not been used for saving anything in it.
The gets instruction in red is a keypad entry function, which will enter the amount that the user wants, until he presses the enter key.
There is no way for the program to limit the amount of data entered by the user, nor is there any way to check the data. As it is entered it is copied directly to the buffer buf.
This presents a problem. We said that buf can only store 80 bytes maximum, so if we enter more, we will produce a buffer overflow. Without a way to limit the incoming data, a user could easily write more than 80 bytes, overflowing our tank.
The point is that the cookie variable is under the buf so whatever overflows will step on it and fill it with a value that the user can control.
For example, if the user writes 80 A letters and 4 Bs the 80 As will fill buf and the 4 Bs will fill cookie. When one types a character in the console, at low level it will be saved as its ASCII value.
As cookie will have been filled with four B letters that are equivalent to the value 0x42, this means that the value of our cookie will be 0x42424242. In the case of our example, the address of cookie 0x19ff24 will have 0x42424242 as content.
We've now seen how to overflow and control the cookie value.
The goal of this exercise is to print "you win." In order to do that, cookie must be equal to 0x41424344. We can take advantage of the vulnerability of buffer overflow by making the program perform actions different from which it was programmed. This would not be possible without overflow because the value of cookie is never changed in the program code. If there is no overflow, we cannot get the "you win" message.
Instead of passing, for example, 80 As and 4 Bs to print "you win" you should pass 80 As and DCBA because that will save the cookie values ASCII as:
44 43 42 41
Here you can see the format in which the data is stored, in this case little endian, meaning they are stored backwards in the memory.
And if 0x41424344 is stored it will be stored in memory as:
44 43 42 41
For that reason, when copying in memory, we must type the value backwards, byte by byte, so that when reading it from memory it does it correctly.
Let’s run the executable in a console:
When the cursor flashes, asking us to type the input data, we’ll carefully type 80 As and then DCBA.
To simplify this, print the string in a Python or Pycharm console. Copy it without quotes and paste it in the console and press enter.
We see that we successfully printed, "you win!".
We can also see this in a debugger. For the sake of this example, we will use X64DBG.
Choose 32 bits version:
If it stops at ntdll. run it again by pressing F9.
It should stop in the entry point, which is the first instruction of the exercise.
This doesn't look like the original source code. The compiler adds a lot of code for the executable to work and start correctly. Find the main function to orientate yourself by looking at the strings of the program.
Choose only to search in the current region since they will be in this same section.
Here are the strings of the program, and others that the compiler added. Double click on some of your strings.
You can now clearly see the call to MessageBoxA, the printf, the gets, and the comparison with 0x41424344.
Add the snowman plugin to decompile and try to see how it tries to get the source code or something as similar as possible from the compiled file.
Put a breakpoint at the beginning of the function and press F9 until it stops there.
In this example, the main function has arguments but are not used within the function.
A function argument is seen below:
The above two arguments are passed through the stack in 32 bit compiled executables, just before the function call, which means they will be saved in the stack.
The first value in the stack at the start of a function will be the return address, which is where it will return after it finishes executing the function and its arguments.
Right click on the return address and choose follow DWORD in disassembler, to see where to return after finishing the function.
This means that the main function was called from the call that is just above, so you can put a breakpoint there, restart the exercise and verify.
Put a breakpoint there and restart.
This will save the arguments from the main function using those pushes.
As stated above, when entering a function, the first thing that will be in the stack will be the return address (in 32 bits compilation) and below there will be the function’s arguments, first the first argument and successively down the rest.
The second argument is an array of pointers. There are three pointers to the three strings passed as console’s arguments in memory.
Here is the beginning of the function. Just below there is the return address and the function’s arguments.
This 32-bit compilation is slightly different than the 64-bit compilation, because the function’s arguments are passed in another way that will be discussed later.
Once the function begins to execute, starting with the prologue, which stores the EBP value of the function that called.
That will cause the stored EBP value to be stored just above the return address.
Execute the instruction by pressing F7.
To see that the stored EBP value is located in the stack just above the return address.
The next prologue instruction is:
This sets the EBP for the current function. The one that was saved (stored EBP) to the address of the parent that called this function. In this example the function is EBP based, in other cases it may differ,
We can create the framework for our current function by putting EBP at the current ESP value.
Within the EBP based function, the EBP value will be maintained and be taken as a reference, while ESP will vary.
A very important point is that the EBP value is taken as a reference. In the EBP based functions, the variables and arguments can be named by their distance to the address that will be stored in the EBP value until the epilogue is reached. Several variables in the list are marked as EBP-4 or EBP-54, referring to the current EBP value.
Once EBP takes its value after the prologue, it will be like a watershed and the arguments will always be down that direction. The saved ebp and return address are also below but will have no references in the code. So EBP+XXX (something added to EBP), refers to arguments, while the variables will be above this address. So a reference to EBP - XXX (subtracting), refers to some local variable.
In the following applies as a general rule for EBP based functions:
EBP + XXXX = arguments passed to the function
EBP - XXXX = local variables of the function
After the prologue, there will be some way to reserve space for the variables. For this example, ESP is moved up so that space left below is reserved for the sum of all the lengths of the variables. Sometimes, a little more space is left, just in case, depending on the compiler.
ESP will be located above EBP, which remains as a reference. Additionally, 0x54 converted to decimal is 84, which is the sum of the length of buf (80) and cookie (4).
Upon executing this instruction, a space will be created for the buf and cookie variables of 84 bytes. Click on the first column on the stack and look at the EBP value, which will be displayed lower in the stack.
Double click to show the values with respect to EBP also in the stack within the first column.
For example, ebp-4 is displayed in the list, in the first column of the stack. It also appears as ebp-4 in the clarification.
The position where ESP is located to reserve variables will always move up because it must respect the space allocated for the variables. For instance, when making the 4 push for MessageBoxA it places them above the reserved space in the ESP.
Look at the stack below to see the four arguments, marked in green, that were added above the reserved space, which is marked in red.
When entering MessageBoxA, the return address of that function is stored on the stack.
Press F8 in MessageBoxA to find the return address of thr function.
Return just below the function call to MessageBoxA.
The “push”ed values saved for MessageBoxA and the return address of that function are ib use. The value of ESP is just above the reserved area as it was before calling any function. The call to printf will save the original function’s parameters with push and the return address. The ESP address will increase but when leaving the function it will lower again just above the reserved area.
Once you pass over the printf, the buf and cookie addresses are printed.
Addresses vary depending on the machine and set up. For instance, in the above example, the address of buf is 19fed4 and the address of cookie is 19ff24.
There we see that the application uses EBP-54. This is the address of our buf (19fed4 in this example). When you double click on the stack, the debugger will show the address as $-54.
See how bytes are saved elsewhere by placing the address where data is saved in the dump.
There it is, more up it’s not displayed because there is no more data below.
When you press F8 on the console, type the data you want to send and press enter. This will fill the buffer, as well as the cookie value.
In the above example, the cookie was at address 19ff24.
Next, we can compare the cookie with the address 0x41424344.
We see that EBP-4 says that it is a cookie, in addition to the address if we reset the HORIZON to the value of EBP as before.
Double click to see that EBP-4 is a cookie since it is in the -4 of the stack by zeroing the HORIZON.
The program will not jump and produces our desired output of ”you win!”
We have now both achieved the objective manually and dynamically analyzed stack1, using the X64dbg debugger. This debugger does not allow us to analyze an application without running it through the program. In order to conduct a static analysis, we must use other tools such as IDA PRO, GHIDRA or RADARE.
Next, make a script model to exploit the exercise from Python.
If using Python 3, place the parentheses in the print command and be careful when adding strings that must be bytes. Place a ‘b’ in front of strings that originated in Python 2).
I notice that the path is correct and when running it.
With a Python 3 script model ready to exploit stack1, you’re ready to move on to part three, where we will continue with static analysis of this exercise using IDA, RADARE and GHIDRA.
In addition to stack1 there is also stack2, stack3 and stack4, which can be solved as supplementary exercises.
In part three, we will see IDA FREE, RADARE, and GHIDRA.
For governments to function, the flow of data on a massive scale is required—including sensitive information about critical infrastructure, citizens, and public safety and security. The security of government information systems is subject to constant attempted attacks and in need of a modern approach to cybersecurity.
Microsoft 365 provides best-in-class productivity apps while protecting identities, devices, applications, networks, and data. With Microsoft 365 security services, governments can take confident steps to adopt a Zero Trust security model where all users and devices—both inside and outside the network—are deemed untrustworthy by default and the same security checks are applied to all users, devices, applications, and data.
The post Microsoft 365 helps governments adopt a Zero Trust security model appeared first on Microsoft Security.
It has been an exciting few years for privacy. The passing and enforcement of new laws (such as CCPA and GDPR) and modifications made to others have caused a flurry of activity across organizations of all sizes. Decisions have been made about how meeting the laws’ requirements by changing procedures and policies. Now it is […]
There's a new, practical, collision attack against SHA-1:
In this paper, we report the first practical implementation of this attack, and its impact on real-world security with a PGP/GnuPG impersonation attack. We managed to significantly reduce the complexity of collisions attack against SHA-1: on an Nvidia GTX 970, identical-prefix collisions can now be computed with a complexity of 261.2rather than264.7, and chosen-prefix collisions with a complexity of263.4rather than267.1. When renting cheap GPUs, this translates to a cost of 11k US$ for a collision,and 45k US$ for a chosen-prefix collision, within the means of academic researchers.Our actual attack required two months of computations using 900 Nvidia GTX 1060GPUs (we paid 75k US$ because GPU prices were higher, and we wasted some time preparing the attack).
It has practical applications:
We chose the PGP/GnuPG Web of Trust as demonstration of our chosen-prefix collision attack against SHA-1. The Web of Trust is a trust model used for PGP that relies on users signing each other's identity certificate, instead of using a central PKI. For compatibility reasons the legacy branch of GnuPG (version 1.4) still uses SHA-1 by default for identity certification.
Using our SHA-1 chosen-prefix collision, we have created two PGP keys with different UserIDs and colliding certificates: key B is a legitimate key for Bob (to be signed by the Web of Trust), but the signature can be transferred to key A which is a forged key with Alice's ID. The signature will still be valid because of the collision, but Bob controls key A with the name of Alice, and signed by a third party. Therefore, he can impersonate Alice and sign any document in her name.
From a news article:
The new attack is significant. While SHA1 has been slowly phased out over the past five years, it remains far from being fully deprecated. It's still the default hash function for certifying PGP keys in the legacy 1.4 version branch of GnuPG, the open-source successor to PGP application for encrypting email and files. Those SHA1-generated signatures were accepted by the modern GnuPG branch until recently, and were only rejected after the researchers behind the new collision privately reported their results.
Git, the world's most widely used system for managing software development among multiple people, still relies on SHA1 to ensure data integrity. And many non-Web applications that rely on HTTPS encryption still accept SHA1 certificates. SHA1 is also still allowed for in-protocol signatures in the Transport Layer Security and Secure Shell protocols.
Vendors are allowed to have 90 days to fix bugs, under adjustments to the transparency policies of Google Project Zero.
Project Zero, the team of elite security researchers from Google, has changed its disclosure policy to focus on allowing vendors to get patches right for security issues and distribute them to users.
Under the amendments introduced on Tuesday, any flaws will be disclosed to the public after 90 days, unless a prior agreement remains.
Previously, once a security fix was created, the issue would be made public by a Project Zero researcher on his bug tracker.
“Too many times, we’ve seen vendors patch reported vulnerabilities by ‘papering over the cracks’ and not considering variants or addressing the root cause of a vulnerability,” Project Zero manager Tim Willis wrote.
“One concern here is that our policy goal of ‘faster patch development’ may exacerbate this problem, making it far too easy for attackers to revive their exploits and carry on attacking users with little fuss.”
Willis added that vendors would be able to ensure that users install updates to patched versions before disclosure.
“End user security doesn’t improve when a bug is found, and it doesn’t improve when a bug is fixed. It improves once the end user is aware of the bug and typically patches their device,” he said.
The improvements would improve and make it more compatible with Project Zero, the blog post said.
“Some vendors considered our determination of when a vulnerability was fixed as unpredictable, especially when working with more than one researcher on the team at a given time,” Willis said.
“They saw it as a barrier to working with us on larger problems, so we’re going to remove the barrier and see if things improve.”
Project Zero said that nearly 96 percent of vulnerabilities are fixed in August before the lifting of the 90-day disclosure period. This number has been updated to 97.7 percent on Tuesday.
Project Zero only extended its 90-day deadline twice— for the 2016 iOS issue of task t and the 2018 flaws in Meltdown and Spectre.
The post Google Project Zero is moving to complete 90-day patch adoption appeared first on .
Cybercriminals are often seen as having the upper hand over the “white hat” community. After all, they’re anonymous, can launch attacks from virtually anywhere in the world, and usually have the element of surprise. But there’s one secret weapon the good guys have: Collaboration. That’s why Trend Micro has always prioritized its partnerships with law enforcement, academia, governments and other cybersecurity businesses.
We’re proud to have contributed to yet another successful collaborative operation with INTERPOL Global Complex for Innovation (IGCI) in Singapore that’s helped to reduce the number of users infected by cryptomining malware by 78%.
Cryptomining On The Rise
Also known as cryptojacking, these attacks have become an increasingly popular way for cybercriminals to make money.
Because victims don’t know they’ve been infected. The malware sits on their machine in the background mining for digital currency 24/7/365. Increasingly, hackers have taken to launching sophisticated attacks against enterprise IT systems and cloud servers to increase their mining and earning potential. But many still target home computer systems like routers, as these are often left relatively unprotected. Stitch enough of these devices together in a botnet and they have a ready-made cash cow.
That’s why cryptojacking remained the most detected threat in the first half of 2019 in terms of file-based threat components, according to our data.
Unlike serious data breaches, phishing attacks, ransomware and banking Trojans, cryptojacking doesn’t have major impact on the victim. They don’t lose sensitive personal data, there’s no risk of follow-on identity fraud and they’re not extorted for funds by being locked out of their PC.
However, it’s not without consequences: Cryptomining malware can slow your home network to a crawl while running up serious energy bills. It may even bring your home computers to a premature end. Also, there’s always the risk with any kind of malware infection that hackers may switch tactics and use their footprint on your home machines to launch other attacks in the future.
Enter Operation Goldfish Alpha
That’s why we were keen to offer our assistance to INTERPOL during this year’s Operation Goldfish Alpha. Thanks to our broad global visibility into attack trends and infection rates, we were able to articulate the scale of the cryptojacking threat and key mitigation steps, at a pre-operation meeting with ASEAN law enforcement officers in June.
Over the five months of Operation Goldfish Alpha, experts from national Computer Emergency Response Teams (CERTs) and police across 10 countries in the region worked to locate the infected routers, notify the victims and use our guidance document to patch the bugs and kick out the hackers.
Having helped to identify over 20,000 routers in the region that were hacked in this way, we’re delighted to say that by November, the number had reduced by at least 78%.
That’s the value of partnerships between law enforcement and private cybersecurity companies: They combine the power of investigative policing with the detailed subject matter expertise, visibility and resources of industry experts like us. We’ll continue to lend a hand wherever we can to make our connected, digital world a safer place.
The post INTERPOL Collaboration Reduces Cryptojacking by 78% appeared first on .
It’s the turn of a new decade and a new privacy law has gone into effect — the California Consumer Privacy Act or CCPA. A quick check with some of my fellow privacy pros on how many consumer information requests received at the end of the day on Jan. 1, puts retail at higher numbers […]
In the early hours of Tuesday morning, city officials in Las Vegas were alerted that their computer network had suffered a security breach.
If it’s a ransomware attack, it sounds unlikely that they’ll be willing to give in to the extortionists’ demands.
Security researchers have observed samples of the new SNAKE ransomware family targeting organizations’ entire corporate networks. Discovered by MalwareHunterTeam and analyzed by Vitali Kremez, SNAKE is written in Golang and contains a high level of obfuscation. Upon successful infection, the ransomware deletes the machine’s Shadow Volume Copies before terminating various processes associated with SCADA systems, […]… Read More
The post SNAKE Ransomware Targeting Entire Corporate Networks appeared first on The State of Security.
For days Travelex’s website has said it was down for “planned maintenance”.
Now it finally admits that the company is struggling with a ransomware outbreak that has disrupted its online services.
This is a blog post about disclosure, specifically the difficulty with doing it in a responsible fashion as the reporter whilst also ensuring the impacted organisation behaves responsibly themselves. It's not a discussion we should be having in 2020, a time of unprecedented regulatory provisions designed to prevent precisely the sort of behaviour I'm going to describe in this post. Here you're going to see - blow by blow - just how hard it is for those of us with the best of intentions to deal with organisations who have a very different set of priorities. This is a post about how hard disclosure remains and how Surebet247's behaviour now has them experiencing the full blown Streisand effect.
It began with this email:
I get these every single day. Seriously, the flood of data that reaches my inbox is hard to describe it's that incessant. It's not always legit, mind you, and I invest a great deal of effort in establishing the authenticity of an alleged breach before loading it into Have I Been Pwned (HIBP). I've written before about how I verify breaches and it didn't take long to be pretty confident that per the subject line of the email above, Surebet247 (a Nigerian gambling website) had suffered a data breach. I'm going to save how I established that for a little later as it'll form part of the subsequent messages I sent them, the main thing for now is that as soon as I was sufficiently confident of the data's authenticity I fired off an email to their published support address:
The message was received. It must have been because the following response immediately came back:
I don't know how much of Office 365 sending the email directly to junk can be attributed to its automated nature, how much is related to its country of origin and how much is due to a missing DMARC record. But that's not the point - the email was received and then... crickets. A couple of days later and without response, I sought the support of Tefo Mohapi, a journalist in South Africa I worked with on the massive Master Deeds breach in 2017. I often use journalists I trust like Tefo to get in touch with unresponsive companies as they're very good at making them sit up and pay attention. And that's where things started to get weird.
With his permission, I'm sharing some of the communication Tefo subsequently had with the company because it's an important part of the narrative as it relates to disclosure. He managed to get a response via Twitter DM pretty promptly, albeit one that didn't really inspire much confidence they were taking this seriously:
One thing you'll notice in Tefo's first message is the screen grab showing multiple difference database backups (and a single .sql file) indicating they came from different services (my original disclosure email also mentions this). You see, whilst the message that came to me only indicated Surebet247, the ZIP file I was sent included a total of 6 different databases from different services. You'll see those referenced again a little later on but the main thing for now is that regardless of the origin of the breach(es) or whose actual system suffered it, there was very likely data involved that customers had provided directly to Surebet247. They are the organisation people entrusted with their personal information and they are accountable for what happens to it after that.
Also experiencing nothing but crickets, a couple of days later Tefo follows up with Surebet247 to ask them how they're progressing:
"That is ours to decide." Seriously? That's how you're going to handle this breach? It was becoming apparent that Surebet247 was not intending to set an exemplary example of breach response. Now many days in and having exhausted all reasonable avenues to drive Surebet247 towards appropriate handling of the incident, Tefo wrote about how Nigeria's SureBet247 has suffered a potential security breach. He wrote about our attempts alert them to the incident, the contents of the breach and about their "nonchalant attitude". He also wrote about the other betting operators implicated in the database backups and how there appeared to be a common thread across them. Suddenly, he had their attention. And they weren't happy.
I'll refrain from posting the entire messages he received as they were a bit, well, "legal", but they came from a combination of Surebet247's founder, Sheriff Olaniyan, and a south African attorney they'd retained. The former stated that they "seriously frown at this malicious news been [sic] promoted by your organization" and that they "will not hesitate to take legal action if you don't stop and bring this down". It continued with "No customer data of ours was hacked or exposed" and that Tefo's story amounted to "fake news" (yes, seriously, they went Trump on him). Now, keep in mind that at this stage nobody from Surebet247 had replied to me and subsequently, nobody had seen the data I'd been sent. Yet somehow - magically - they had determined they were in the clear.
Changing pace for just a moment, I want to throw Surebet247 a bone (it's the only one they'll get) because it does look like they had reason for some initial suspicion. Within Sheriff's message to Tefo he also said that "your informant was asking for payment and this was demanded from us". In subsequent discussions, Tefo and I concluded that this was very likely correct: someone in possession of the data was shaking them down for cash. Clearly this is not only unethical but also outright illegal and it would help explain Surebet247's apprehension when approached by other parties about the incident. But that's where the bone-throwing ends as clearly both Tefo's and my own intentions were entirely ethical and it would take about 3 minutes of Googling to work out who we both were and where our moral compasses on such issues point. I understand them being skittish, but shooting the messenger doesn't make for good incident response.
Around the same time as the founder's threatening message, Surebet247 elected to go full Iraqi Information Minister on the situation:
Kindly ignore the information going round about a hack into our system which has exposed your information with us.— surebet247 (@surebet247) January 4, 2020
All sensitive private and financial information are stored on a secured server and protected by the best firewall to prevent intrusions.
Thank you. pic.twitter.com/YT0w2jRX9f
There were many very appropriate responses posted to that tweet (there's huge comedic value in that firewall comment), but I feel this one provides the best summary of their position:
Once again, keep in mind that as yet, Surebet247 had yet to reply to a single message I'd sent them and did not have the data I'd received, certainly not directly from me and I've seen no evidence to date they'd received it from anyone else either. Assuming they based that tweet on Tefo's story, there was absolutely no basis for them to make that statement.
Becoming increasingly frustrated, I tweeted but refrained from naming them specifically whilst I considered how to proceed:
Going through a painful disclosure process at the moment which is tracking perfectly to this old blog post "The 5 Stages of Data Breach Grief": https://t.co/GNhgrLgJDN— Troy Hunt (@troyhunt) January 4, 2020
Currently transitioning from "denial" to "anger", the remaining stages will follow, they always do...
My gut reaction was that if they wanted to take this discussion onto the public timeline then a series of rebuttal tweets would be appropriate. I drafted them, sat on them for a while then decided against it. I don't want to see this sort of thing play out on the public timeline, not unless other reasonable approaches have been exhausted so I took the drafts and 14 hours after their denial tweet, DM'd them instead:
There were 4 subsequent images in the DM thread, the first of which was of the original email to their support address. The second 2 demonstrated the enumeration vector on their password reset feature which confirmed emails in the alleged breach presently exist in their system. Conversely, fabricated emails which wouldn't exist on their system produced an error message. Here are those 2 images:
That alone gives me a huge degree of confidence in the legitimacy of the breach (I tested a handful of addresses and they consistently produced the same results), but hey, why stop there? I sent a 4th image showing the registration feature confirming that usernames in the breach exist in the online system:
A day passed. Two days passed. Nothing. These guys really want to do this the hard way, don't they?! Expecting them to go down kicking and screaming, I reached out to a handful of my HIBP subscribers who also appeared in the breach and asked them 3 simple questions:
With 3M subscribers in my service, I've always got a good sample set that crosses over with any sizeable breach I come across and as such, I've always got candidates willing to help with breach verification. I fired off the emails and waited.
At the same time, instead of acquiescing to Surebet247's bullying tactics, Tefo upped the ante further by writing a second article after reaching out to Nigeria's National Information Technology Development Agency (NITDA) who had the following to say:
The Director-General, and CEO of NITDA, Mr. Kashifu Inuwa Abdullahi, gave an order for the incident to be investigated by NITDA's Data Breach Investigation Team.
This, of course, is precisely what we'd expect of a regulator and I'll be eagerly awaiting the outcome of that investigation. Speaking of eagerly awaiting, it didn't take long to get a response to my HIBP subscriber outreach emails with a reply promptly coming back from a gentleman named Stefan. Stefan confirmed that he'd used the Surebet247 service in the past and gave me his month of birth. It matched perfectly to the data in the alleged breach. I reverted with his day of birth and in turn, he confirmed it was accurate. Lastly, curious about his European name, I asked him which country he was from and he replied with a single word:
Oh, now it's interesting! Once you start dealing with the personal information of EU data subjects it invokes the whole GDPR discussion, a fact that Tefo quickly jumped on and used as material for a third article about how Surebet247 is in violation of the European Union's GDPR.
I also asked another question in the original email I haven't touched on yet: "approximately when did you register"? In Stefan's initial response, he advised that "The first newsletter I found is from 13 feb 2014" (obviously Stefan likes to hold onto all his mail). However, this didn't line up with the data which suggested the registration date was "2016-09-19". I shared that data point with him and he came back with a really interesting explanation:
On 27 sep 2016 I got an email concerning "Migrations Challenges" (telling me that all balances are secure). So, maybe on 19 sep 2016 they migrated to another platform and "registered" everyone per that date?
Sure enough, further inspection of the data showed thousands of records all "registered" on that same day: 19 September 2016, a mere 8 days before the company sent an email about "Migration Challenges".
Another HIBP subscriber responded:
Yes, I know surebet247 service, a betting bookmaker based in my country Nigeria. I cannot recall the date I registered, but I know that it's earlier than 2019, my account there should be over 2 years old. My month of birth is October.
Surebet247 user? Check.
Registered more than 2 years ago? Check.
Born in October? Check.
Every single response I got from every single subscriber that replied to my request for support confirmed precisely the information contained in the "alleged" breach. Now, I ask you: what are the chances that someone sent me a trove of data with so many independently correlating points and yet "no customer data of ours was hacked or exposed", as Sheriff phrased it? If Surebet247 was to offer odds on the likelihood that they'd been breached, they'd be very short odds indeed!
So it's back to Twitter to DM them again, however...
And that's when I decided to write this blog post. 8 days after first attempting to alert them privately to a serious security incident that would not only impact their customers but also impact their own business interests, they decided that this was the most appropriate course of action:
Now remember, this is a company that handles other people's money! Granted, gambling merely amounts to a tax on people who can't do maths but regardless, you'd expect at least a vague attempt at professionalism. It wasn't just me that was blocked either, I was originally alerted to Surebet247's propensity to silence bearers of bad news by Tefo who'd just discovered he'd lost his primary channel of communication with them. It wasn't just us either, they were on a rampage to drown out other voices they didn't like too:
Oh yeah. You must have hit a nerve. pic.twitter.com/VNZNuYr1fv— Matt (@undulanti) January 7, 2020
Oh no they got me!! pic.twitter.com/pAfyT4MxZi— Scott Helme (@Scott_Helme) January 7, 2020
Mention “breach” they block. Got us too pic.twitter.com/DWPirXyOor— iAfrikan.com (@iafrikan) January 7, 2020
Welp!!! pic.twitter.com/AvpBCiP8V3— Angry Wizard (@0xRogue) January 7, 2020
Same here. pic.twitter.com/d3IrcwbTsd— Omokolade Ogunleye (@kolade_ogunleye) January 7, 2020
They blocked me pic.twitter.com/QO2PvsDVKC— Chris Sylcox [No. 1042994a] (@ChrisSylcox) January 8, 2020
1 tweet was all it took pic.twitter.com/fuAAtmZ5ea— Baikunth (@baikunth) January 8, 2020
Took less than 2 minutes 😆 pic.twitter.com/z1LVWYu8kW— John Shepherd (@john_shepherd) January 8, 2020
It took me 4 tweets the last one input the you have been hacked gif on! 😂😂😂😂 pic.twitter.com/jiDE2FlnGr— mRr3b00t (@UK_Daniel_Card) January 8, 2020
Blocked within a few mins of my post 😳 pic.twitter.com/wuDjLCvg9q— Stephen Marriott (@stephenmarriott) January 8, 2020
Sure, here you go. pic.twitter.com/ruIgMM0Wb1— Tony Sutton (@tony_sutton) January 8, 2020
Took only minutes pic.twitter.com/WjkPppswag— Peter Tonoli (@peter_tonoli) January 8, 2020
And now here we are, Streisand'd all over the place.
The Streisand effect is a phenomenon whereby an attempt to hide, remove, or censor a piece of information has the unintended consequence of publicizing the information more widely, usually facilitated by the Internet.
Because of Surebet247's attempts to censor discussion on this incident, they're getting more of it than ever with the press now starting to jump onto it well beyond Tefo's initial 3 stories:
SureBet247 suffers data breach and leaks customers’ gambling information https://t.co/xJieqOf9Y6— Alexa Gómez (@AlexaGm33043450) January 3, 2020
Bad corporate behaviour like this is no longer something you simply sweep under the rug; it needs to be broadcast far and wide as a cautionary tale for the next organisation that elects to follow the same strategy. Per my earlier tweet about data breach grief, the outcome of this process is a foregone conclusion and assuming I haven't made a massive series of errors in the workings explained above, Surebet247 will ultimately come clean about the breach and take responsibility for their actions.
I'll leave you with a quote I've said many times now and it's more relevant in this situation than ever before:
We are now in an era where people are no longer judging organisations as harshly because they had a breach, but are judging them more on the way they handle it.
Today, yet again, I'd like to share with you a simple Trillion $ question, one that I had originally asked more that 10 years ago, and recently asked again just about two years ago. Today it continues to be exponentially more relevant to the whole world.
In fact, it is more relevant today than ever given the paramount role that cyber security plays in business and national security.
So without further adieu, here it is - Who needs WMDs (Weapons of Mass Destruction) Today?
Ans: Only those who don't know that we live in a digital world, one wherein virtually everything runs on (networked) computers.
Why would an entity bother trying to acquire or use a WMD (or for that matter even a conventional weapon) when (if you're smart) you could metaphorically stop the motor of entire organizations (or nations) with just a few lines of code designed to exploit arcane but highly potent misconfigured security settings (ACLs) in the underlying systems on which governments, militaries and thousands of business organizations of the world operate?
Today, all you need is two WDs in the same (pl)ACE and its Game Over.
Puzzled? Allow me to give you a HINT:.
Here’s a simple question: What does the following non-default string represent and why should it be a great cause of concern?
(A;;RP;;;WD)(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA)(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)(A;CI;LC;;;RU)(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU) (A;CI;RPWDLCLO;;;WD)(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(A;;RC;;;RU)(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
Today, this one little question and the technicality I have shared above directly impacts the cyber security of the entire world.
If you read my words very carefully, as you always should, then you'll find that it shouldn't take an astute cyber security professional more than a minute to figure it out, given that I’ve actually already provided the answer above.
Today, the CISO of every organization in the world, whether it be a government, a military or a billion dollar company (of which there are dime a dozen, and in fact thousands worldwide) or a trillion dollar company MUST know the answer to this question.
They must know the answer because it directly impacts and threatens the foundational cyber security of their organizations.
If they don't, (in my opinion) they likely shouldn't be the organization's CISO because what I have shared above could possibly be the single biggest threat to 85% of organizations worldwide, and it could be used to completely compromise them within minutes (and any organization that would like a demo in their real-world environment may feel free to request one.)
Some of you will have figured it out. For the others, I'll finally shed light on the answer soon.
PS: If you need to know right away, perhaps you should give your Microsoft contact a call and ask them. If they too need some help (they likely will ;-)), tell them it has to do with a certain security descriptor in Active Directory. (There, now that's a HINT the size of a domain, and it could get an intruder who's been able to breach an organization's network perimeter to root in seconds.)
PS2: If this intrigues you, and you wish to learn more, you may want to read this - Hello World :-)