Comments
Sacramento Bee Databases Hit with Ransomware Attack
Newest First  |  Oldest First  |  Threaded View
alphaa10
50%
50%
alphaa10,
User Rank: Strategist
2/17/2018 | 12:23:13 AM
Re: Profound solution?
The measure announced was not to recover the lost data, but to frustrate inevitable future attempts to make the same threat, perhaps with more damage. Once a ransom demand is met, there is nothing to dissuade the same or similar groups from another attack.

Did the newspaper promise a return to paper records? Not at all, but simply a more layered and distributed system, with multiple checkpoints.

Under the circumstances, the Bee declaration helps the newspaper isolate itself from further extortion attempts.

 
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
2/12/2018 | 6:07:58 PM
Looking for correlations
@DR staff: Elements of this story are repeated in any number of cybersecurity articles, surveys, reports, etc..  What I haven't seen is analysis on how specific data storage choices correlate with attack frequency, type, detection, and other characteristics and metrics. 

In this story "...its databases, both on a third-party server...", raises the above questions as regards to use of third party servers; but also leads to questions about attacks and the specifics of type, location, infrastructure, etc.., of such servers. 

Perhaps what I'm looking for is a multidimensional map showing just what particular dangers are known to inhabit various (metaphorical as well as actual), regions.  In other words, are there safer places and containers to bury your treasure? 

I realize this is far from a simple question.  For starters, a single vendor might offer several types of relational and non-relational patterns and management options; and might have options for restricting use to certain geo-located datacenters - and a single organization might use different options, from different vendors, as well as combine public-cloud with in-house storage options. 

Is anyone work on this type of multi-factor threat assessment for data storage choices? 
REISEN1955
50%
50%
REISEN1955,
User Rank: Ninja
2/12/2018 | 3:14:51 PM
Profound solution?
The database data is deleted to prevent future theft.  Wow!!!!   What an idea.  Lock the barn door after the theft is done.  Brilliant.  Of course, the data is already out there so who ares about deletion.  Hey, shore up the walls would be a good idea too.  


'Hidden Tunnels' Help Hackers Launch Financial Services Attacks
Kelly Sheridan, Staff Editor, Dark Reading,  6/20/2018
Inside a SamSam Ransomware Attack
Ajit Sancheti, CEO and Co-Founder, Preempt,  6/20/2018
Tesla Employee Steals, Sabotages Company Data
Jai Vijayan, Freelance writer,  6/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12697
PUBLISHED: 2018-06-23
A NULL pointer dereference (aka SEGV on unknown address 0x000000000000) was discovered in work_stuff_copy_to_from in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30. This can occur during execution of objdump.
CVE-2018-12698
PUBLISHED: 2018-06-23
demangle_template in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30, allows attackers to trigger excessive memory consumption (aka OOM) during the "Create an array for saving the template argument values" XNEWVEC call. This can occur during execution of objdump.
CVE-2018-12699
PUBLISHED: 2018-06-23
finish_stab in stabs.c in GNU Binutils 2.30 allows attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact, as demonstrated by an out-of-bounds write of 8 bytes. This can occur during execution of objdump.
CVE-2018-12700
PUBLISHED: 2018-06-23
A Stack Exhaustion issue was discovered in debug_write_type in debug.c in GNU Binutils 2.30 because of DEBUG_KIND_INDIRECT infinite recursion.
CVE-2018-11560
PUBLISHED: 2018-06-23
The webService binary on Insteon HD IP Camera White 2864-222 devices has a stack-based Buffer Overflow leading to Control-Flow Hijacking via a crafted usr key, as demonstrated by a long remoteIp parameter to cgi-bin/CGIProxy.fcgi on port 34100.