Daily Archives: September 1, 2020

Cyber Security Roundup for September 2020

A roundup of UK focused Cyber and Information Security News, Blog Posts, Reports and general Threat Intelligence from the previous calendar month, August 2020.

Taking security training courses and passing certification exams are common ingredients in the makeup of the vast majority of accomplished cybersecurity and information security professionals. As such, two security incidents last month raised more than just a surprising eyebrow or two within the UK security industry. 

The first involved the renown and well respected United States security training company, The SANS Institue, announcing that a successful email phishing attack against one of its employees resulted in 28,000 personal records being stolenSANS classified this compromise as "consent phishing", namely where an employee is tricked into providing malicious Microsoft Office 365 OAuth applications access to their O365 accounts. In June 2020, Microsoft warned 'consent phishing' scams were targeting remote workers and their cloud services.

The second incident involved British cybersecurity firm NCC Group, after The Register reported NCC marked CREST penetration testing certification exam 'cheat cheats' were posted on Github. El Reg stated the leaked NCC marked document "offered step-by-step guides and walkthroughs of information about the Crest exams.  With those who posted the documents claiming that the documents contained a clone of the Crest CRT exam app that helped users to pass the CRT exam in the first attempt. CREST, a globally recognised provider of penetration testing accreditations, conducted their own investigation into the Github post and then suspended their Certified Infrastructure Tester (CCF Inf) and Certified Web Application Tester (CCT App) exams.

Reuters reported British trade minister Liam Fox email account was compromised by Russian hackers through a spear-phishing attack. This led to leaks of sensitive US-UK  trade documents in a disinformation campaign designed to influence the outcome of the UK general election in late 2019.

UK foreign exchange firm Travelex is still revelling from the double 2020 whammy of major ransomware outbreak followed by the impact COVID-19, and has managed to stay in business thanks a bailout arranged by their business administrators PWC. 

Uber's former Cheif Security Officer has been charged with obstruction of justice in the United States, accused of covering up a massive 57 million record data breach in 2016. Uber eventually admitted paying a hacking group $100,000 (£75,000) ransom to delete the data they had stolen.

The British Dental Association advised its dentist members that their bank account details and correspondence with them were stolen by hackers.  A BDA spokeswoman told BBC News it was possible that information about patients was also exposed, but remained vague about the potential context. The cyber breach was likely caused by a hack of the BDA website given it was taken offline for a considerable amount of time after reporting the breach.

Its seems that every month I report a huge cloud misconfiguration data beach, typically found by researchers looking for publicity, and caused by businesses not adequately securing their cloud services.  This month it was the turn of cosmetics giant Avon after researchers 'SafetyDetectives" found 19 million records were accessible online due to the misconfiguration of a cloud server.  Accurics separately reported misconfigured cloud services accounted for 93% of 200 breaches it has seen in the past two years, exposing more than 30 billion records. Also predicting cloud services data breaches are likely to increase in both velocity and scale, I am inclined to agree.
Crime Dot Com: From Viruses to Vote Rigging, How Hacking Went Global
Finally, I was invited to review a pre-release of Geoff White’s new book, Crime Dot Com: From Viruses to Vote Rigging, How Hacking Went Global”. I posted a book review upon its release in August, I thoroughly recommend it. The book is superbly researched and written, the author’s storytelling investigative journalist style not only lifts the lid on the murky underground world of cybercrime but shines a light on the ingenuity, persistence and ever-increasing global scale of sophisticated cybercriminal enterprises. While this book is an easily digestible read for non-cyber security experts, the book provides cybersecurity professionals working on the frontline in defending organisations and citizens against cyber-attacks, with valuable insights and lessons to be learnt about their cyber adversaries and their techniques, particularly in understanding the motivations behind today's common cyberattacks.

Stay safe and secure.

BLOG
NEWS
VULNERABILITIES AND SECURITY UPDATES
AWARENESS, EDUCATION AND THREAT INTELLIGENCE

Announcing new reward amounts for abuse risk researchers

It has been two years since we officially expanded the scope of Google’s Vulnerability Reward Program (VRP) to include the identification of product abuse risks.


Thanks to your work, we have identified more than 750 previously unknown product abuse risks, preventing abuse in Google products and protecting our users. Collaboration to address abuse is important, and we are committed to supporting research on this growing challenge. To take it one step further, and as of today, we are announcing increased reward amounts for reports focusing on potential attacks in the product abuse space.


The nature of product abuse is constantly changing. Why? The technology (product and protection) is changing, the actors are changing, and the field is growing. Within this dynamic environment, we are particularly interested in research that protects users' privacy, ensures the integrity of our technologies, as well as prevents financial fraud or other harms at scale.


Research in the product abuse space helps us deliver trusted and safe experiences to our users. Martin Vigo's research on Google Meet's dial-in feature is one great example of an 31337 report that allowed us to better protect users against bad actors. His research provided insight on how an attacker could attempt to find Meet Phone Numbers/Pin, which enabled us to launch further protections to ensure that Meet would provide a secure technology connecting us while we're apart.


New Reward Amounts for Abuse Risks


What’s new? Based on the great submissions that we received in the past as well as feedback from our Bug Hunters, we increased the highest reward by 166% from $5,000 to $13,337. Research with medium to high impact and probability will now be eligible for payment up to $5,000.


What did not change? Identification of new product abuse risks remains the primary goal of the program. Reports that qualify for a reward are those that will result in changes to the product code, as opposed to removal of individual pieces of abusive content. The final reward amount for a given abuse risk report also remains  at the discretion of the reward panel. When evaluating the impact of an abuse risk, the panels look at both the severity of the issue as well as the number of impacted users.


What's next? We plan to expand the scope of Vulnerability Research Grants to support research preventing abuse risks. Stay tuned for more information!


Starting today the new rewards take effect. Any reports that were submitted before September 1, 2020 will be rewarded based on the previous rewards table.


We look forward to working closely together with the researcher community to prevent abuse of Google products and ensure user safety.


Happy bug hunting!

Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863

Open Source projects are the building blocks of any software development process. As we indicated in our previous blog, as more and more products use open source code, the increase in the overall attack surface is inevitable, especially when open source code is not audited before use. Hence it is recommended to thoroughly test it for potential vulnerabilities and collaborate with developers to fix them, eventually mitigating the attacks. We also indicated that we were researching graphics libraries in Windows and Linux, reporting multiple vulnerabilities in Windows GDI as well as Linux vector graphics library libEMF. We are still auditing many other Linux graphics libraries since these are legacy code and have not been strictly tested before.

In part 1 of this blog series, we described in detail the significance of open source research, by outlining the vulnerabilities we reported in the libEMF library. We also highlighted the importance of compiling the code with memory sanitizers and how it can help detect a variety of memory corruption bugs. In summary, the Address Sanitizer (ASAN) intercepts the memory allocation / deallocation functions like malloc () / free() and fills out the memory with the respective fill bytes (malloc_fill_byte / free_fill_byte). It also monitors the read and write to these memory locations, helping detect erroneous access during run time.

In this blog, we provide a more detailed analysis for one of the reported vulnerabilities, CVE-2020-11863, which was due to the use of uninitialized memory. This vulnerability is related to CVE-2020-11865, a global object vector out of bounds memory access in the GlobalObject::Find() function in libEMF. However, the crash call stack turned out to be different, which is why we decided to examine this further and produce this deep dive blog.

The information provided by the ASAN was sufficient to reproduce the vulnerability crash outside of the fuzzer. From the ASAN information, the vulnerability appeared to be a null pointer dereference, but this was not the actual root cause, as we will discuss below.

Looking at the call stack, it appears that the application crashed while dynamically casting the object, for which there could be multiple reasons. Out of those possible reasons that seem likely, either the application attempted to access the non-existent virtual table pointer, or the object address returned from the function was a wild address accessed when the application crashed. Getting more context about this crash, we came across an interesting register value while debugging. Below shows the crash point in the disassembly indicating the non-existent memory access.

If we look at the state of the registers at the crash point, it is particularly interesting to note that the register rdi has an unusual value of 0xbebebebebebebebe. We wanted to dig a little deeper to check out how this value got into the register, resulting in the wild memory access. Since we had the source of the library, we could check right away what this register meant in terms of accessing the objects in memory.

Referring to the Address Sanitizer documentation, it turns out that the ASAN writes 0xbe to the newly allocated memory by default, essentially meaning this 64-bit value was written but the memory was not initialized. The ASAN calls this as the malloc_fill_byte. It also does the same by filling the memory with the free_fill_byte when it is freed. This eventually helps identify memory access errors.

This nature of the ASAN can also be verified in the libsanitizer source here. Below is an excerpt from the source file.

Looking at the stack trace at the crash point as shown below, the crash occurred in the SelectObject() function. This part of the code is responsible for processing the EMR_SELECTOBJECT record structure of the Enhanced Meta File (EMF) file and the graphics object handle passed to the function is 0x80000018. We want to investigate the flow of the code to check if this is something which comes directly from the input EMF file and can be controlled by an attacker.

In the SelectObject() function, while processing the EMR_SELECTOBJECT record structure, the handle to the GDI object is passed to GlobalObjects.find() as shown in the above code snippet, which in turn accesses the global stock object vector by masking the higher order bit from the GDI object handle and converting it into the index, eventually returning the stock object reference from the object vector using the converted index number. Stock object enumeration specifies the indexes of predefined logical graphics objects that can be used in graphics operations documented in the MS documentation. For instance, if the object handle is 0x8000018, this will be ANDed with 0x7FFFFFFF, resulting in 0x18, which will be used as the index to the global stock object vector. This stock object reference is then dynamically cast into the graphics object, following which EMF::GRAPHICSOBJECT member function getType ( ) is called to determine the type of the graphics object and then, later in this function, it is again cast into an appropriate graphics object (BRUSH, PEN, FONT, PALETTE, EXTPEN), as shown in the below code snippet.

EMF::GRAPHICSOBJECT is the class derived from EMF::OBJECT and the inheritance diagram of the EMF::OBJECT class is as shown below.

However, as mentioned earlier, we were interested in knowing if the object handle, passed as an argument to the SelectObject function, can controlled by an attacker. To be able to get context on this, let us look at the format of the EMR_SELECTOBJECT record as shown below.

As we notice here, ihObject is the 4-byte unsigned integer specifying the index to the stock object enumeration. In this case the stock object references are maintained in the global objects vector. Here, the object handle of 0x80000018 implies that index 0x18 will be used to access the global stock object vector. If, during this time, the length of the object vector is less then 0x18 and the length check is not done prior to accessing the object vector, it will result in out of bounds memory access.

Below is the visual representation of processing the EMR_SELECTOBJECT metafile record.

While debugging this issue, we enable a break point at GlobalObjects.find () and continue until we have object handle 0x80000018; essentially, we reach the point where the above highlighted EMR_SELECTOBJECT record is being processed. As shown below, the object handle is converted into the index (0x18 = 24) to access the object vector of size (0x16 = 22), resulting into out of bounds access, which we reported as CVE-2020-11865.

Further stepping into the code, it enters the STL vector library stl_vector.h which implements the dynamic expansion of the std::vectors. Since the objects vector at this point of time has only 22 elements, the STL vector will expand the vector to the size indicated by the parameter highlighted, accessing the vector by passed index, and will return the value at that object reference, as shown in the below code snippet, which comes out to be 0xbebebebebebebebe as filled by the ASAN.

 

The code uses the std:allocator to manage the vector memory primarily used for memory allocation and deallocation. On further analysis, it turns out that the value returned, 0xbebebebebebebebe in this case, is the virtual pointer of the non-existent stock object, which is dereferenced during dynamic casting, resulting in a crash.

As mentioned in our earlier blog, the fixes to the library have been released in a subsequent version, available here.

Conclusion

While using third party code in products certainly saves time and increases development speed, it potentially comes with an increase in the volume of vulnerabilities, especially when the code remains unaudited and integrated into products without any testing. It is extremely critical to perform fuzz testing of the open source libraries used, which can help in discovering vulnerabilities earlier in the development cycle and provides an opportunity to fix them before the product is shipped, consequently mitigating attacks. However, as we emphasized in our previous blog, it is critical to strengthen the collaboration between vulnerability researchers and the open source community to continue responsible disclosures, allowing the maintainers of the code to address them in a timely fashion.

The post Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863 appeared first on McAfee Blogs.

New Book! The Best of TaoSecurity Blog, Volume 2


 

I published a new book!

The Best of TaoSecurity Blog, Volume 2: Network Security Monitoring, Technical Notes, Research, and China and the Advanced Persistent Threat

It's in the Kindle Store, and if you're Unlimited it's free. Print edition to follow.

The book lists as having 413 pages (for the Kindle edition at least) at it's almost 95,000 words. I started working on it in June after finishing Volume 1.

Here is the book description:

Since 2003, cybersecurity author Richard Bejtlich has been writing posts on TaoSecurity Blog, a site with 15 million views since 2011. Now, after re-reading over 3,000 posts and approximately one million words, he has selected and republished the very best entries from 17 years of writing. 

In the second volume of the TaoSecurity Blog series, Mr. Bejtlich addresses how to detect and respond to intrusions using third party threat intelligence sources, network data, application and infrastructure data, and endpoint data. He assesses government and private security initiatives and applies counterintelligence and counteradversary mindsets to defend digital assets. He documents the events of the last 20 years of Chinese hacking from the perspective of a defender on the front lines, in the pre- and post-APT era. 

This volume contains some of Mr. Bejtlich’s favorite posts, such as histories of threat hunting, so-called black and white hat budgeting, attribution capabilities and limits, and rating information security incidents. He has written new commentaries to accompany each post, some of which would qualify as blog entries in their own right.  Read how the security industry, defensive methodologies, and strategies to improve national security have evolved in this new book, written by one of the authors who has seen it all and survived to blog about it.

I have a third volume planned. I will publish it by the end of the year. 


If you have any questions about the book, let me know. Currently you can see the table of contents via the "Look Inside" function, and there is a sample that lets you download and read some of the book. Enjoy!

2020 NICE K12 Cybersecurity Education Conference: Registration Open

2020 NICE K12 Cybersecurity Education Conference Early Bird Registration is NOW OPEN. The 2020 NICE K12 VIRTUAL Cybersecurity Education Conference takes place December 7-8, 2020. Pre-Conference Workshops will take place on December 5-6. This year's event will provide education and learning tools that educators and schools can use immediately. You can access it all from the convenience of your home or office! The 2020 NICE K12 Virtual Cybersecurity Education Conference will be jam-packed with keynote speakers, presentations, panels, and break-out sessions covering five tracks: Increasing