Monthly Archives: November 2018

SaferVPN review: This newcomer is off to a good start

SaferVPN in brief:

  • P2P allowed: Netherlands server only
  • Business location: Tel Aviv, IL
  • Number of servers: 700
  • Number of country locations: 34
  • Monthly cost: $65.88 billed annually, or $78.96 for two years
  • VPN protocol: IKEv2 (default with OpenVPN as fallback)
  • Data encryption: AES-256
  • Data authentication: SHA-256
  • Handshake encryption: 2048-bit

Editor’s Note: This review was updated November 29, 2018 to reflect changes to infrastructure, improved speed scores, and a new overall review score.

To read this article in full, please click here

Affected by a Data Breach? 6 Security Steps You Should Take

It’s common for people to share their personal information with companies for multiple reasons. Whether you’re checking into a hotel room, using a credit card to make a purchase at your favorite store, or collecting rewards points at your local coffee shop, companies have more access to your data than you may think. While this can help you build relationships with your favorite vendors, what happens if their security is compromised?

A high-profile hotel and another popular consumer brand’s perks program recently experienced data breaches that exposed users’ personal information. If you think you were affected by one of these breaches, there are multiple steps you can take to help protect yourself from the potential side effects.

Check out the following tips if you think you may have been affected by a data breach, or just want to take extra precautions:

  • Change your password. Most people will rotate between the same three passwords for all of their personal accounts. While this makes it easier to remember your credentials, it also makes it easier for hackers to access more than one of your accounts. Try using a unique password for every one of your accounts or employ a password manager.
  • Place a fraud alert. If you suspect that your data might have been compromised, place a fraud alert on your credit. This not only ensures that any new or recent requests undergo scrutiny, but also allows you to have extra copies of your credit report so you can check for suspicious activity.
  • Freeze your credit. Freezing your credit will make it impossible for criminals to take out loans or open up new accounts in your name. To do this effectively, you will need to freeze your credit at each of the three major credit-reporting agencies (Equifax, TransUnion, and Experian).
  • Consider using identity theft protection. A solution like McAfee Identify Theft Protection will help you to monitor your accounts, alert you of any suspicious activity, and help you to regain any losses in case something goes wrong.
  • Update your privacy settings. Be careful with how much of your personal information you share online. Make sure your social media accounts and mobile apps are on private and use multi-factor authentication to prevent your accounts from being hacked.
  • Be vigilant about checking your accounts. If you suspect that your personal data has been compromised, frequently check your bank account and credit activity. Many banks and credit card companies offer free alerts that notify you via email or text messages when new purchases are made, if there’s an unusual charge, or when your account balance drops to a certain level. This will help you stop fraudulent activity in its tracks.

And, of course, to stay updated on all of the latest consumer and mobile security threats, follow me and @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Affected by a Data Breach? 6 Security Steps You Should Take appeared first on McAfee Blogs.

Are US hacker indictments more than Justice Theater?

Hacker indictments by U.S. Justice Department haven’t proven effective and now the Treasury Department is also getting in on the act with questionable sanctions.

In the past five months alone, the U.S. Department of Justice has indicted at least 30 foreign individuals in connection with various cyberattacks, but only three of those individuals were arrested and extradited to the U.S., which puts into question if legal action is little more than “justice theater,” akin to Bruce Schneier’s “security theater” put on by the likes of the TSA.

In July, special counsel Robert Mueller indicted 12 Russian intelligence officers in connection with the DNC and DCCC hacks; in September, one member of the North Korean Lazarus Group was indicted; in October, seven more Russian officers were indicted; and November saw eight Russian nationals indicted for running a massive botnet — three of whom are in custody — and two Iranians in connection to the SamSam ransomware.

Before this month, in order to find a foreign national that was indicted and detained — not considering his trial proceedings have begun — you have to go back to Aug. 2017 with Marcus Hutchins, aka MalwareTech, a British security researcher detained after attending Defcon 2017 in Las Vegas.

Along with the latest hacker indictment of two Iranian nationals, the Treasury Dept. designated two additional Iranian men for their role in exchanging the bitcoin earned in ransomware attacks into Iranian rial.

According to the Treasury Dept., a designation action means, “all property and interests in property of the designated persons that are in the possession or control of U.S. persons or within or transiting the United States are blocked, and U.S. persons generally are prohibited from dealing with them.”

However, considering the “property” in this context is a decentralized cryptocurrency, it’s unclear what — if anything — this action means in real world terms. Unlike assets held by a U.S. bank or bank in a friendly nation, a bitcoin wallet doesn’t fall under any authority’s jurisdiction.

Making the case worse for the Treasury Dept., neither bitcoin wallet had a meaningful balance at the time of the designation announcement. One of the wallets hadn’t seen activity since Dec. 2017 — until receiving two payments the day after the Treasury announcement — and the other had a balance equivalent to just over $3 as of Nov. 11, before receiving two payments each on the day of and the day after the announcements.

The two bitcoin wallets combined received a total of 5901.4 BTC while in use, but the value of that is difficult to calculate because of the high volatility of bitcoin prices over the past year and the owners of the wallets always being quick to send funds to other accounts. It’s possible the amount of bitcoin was worth tens of millions of U.S. dollars.

That’s tens of millions of dollars sent to dozens or hundreds of different accounts going back to 2013, and all but about $3 of which was gone before the Treasury Dept. announced any actions.

At least with the indictments, the DoJ can theoretically limit the travel of the individuals charged or seize assets in America. The Treasury Dept. has put sanctions on two men who most likely won’t be extradited, and are attempting to “block” property that was gone before any action was taken. That feels like peak justice theater.

The post Are US hacker indictments more than Justice Theater? appeared first on Security Bytes.

Top Australian Soldier Accused of War Crimes

You may have noticed a post the other day about a decorated SEAL charged with war crimes. Some have decried this investigation as political maneuvering by those serving with the accused, while others have said they simply do not believe in challenging the accuracy of decorated war veteran records. Meanwhile I noticed a similar story … Continue reading Top Australian Soldier Accused of War Crimes

OSSEC For Website Security: PART II – Distributed Architectures Using Agents and Managers

This article assumes you already have OSSEC deployed. If you need a refresher, refer to the Part I of OSSEC for website security, written March 2013. OSSEC is popular open-source...

Read More

The post OSSEC For Website Security: PART II – Distributed Architectures Using Agents and Managers appeared first on PerezBox.

Hacker hijacks 50,000 printers to tell people to subscribe to PewDiePie

Over the course of this week, some printers have been printing out a strange message asking people to subscribe to PewDiePie's YouTube channel. The message appears to be the result of a simple exploit that allows printers to receive data over the internet, including print commands. A person with the online handle TheHackerGiraffe has claimed responsibility for the attack.

Via: The Verge

Source: TheHackerGiraffe

Marriott Hotels 4 Year Hack Impacts Half a Billion Guests!

A mammoth data breach was disclosed by hotel chain Marriott International today (30 Nov 18), with a massive 500 million customer records said to have been compromised by an "unauthorized party". 
Image result for marriott
The world's largest hotel group launched an internal investigation in response to a system security alert on 8th September 2018, and found an attacker had been accessing the hotel chain's "Starwood network" and customer personal data since 2014, copying and encrypting customer records. In addition to the Marriott brand, Starwood includes W Hotels, Sheraton, Le Méridien and Four Points by Sheraton. 

Image result for starwood
You are at risk if you have stayed at any of the above hotel brands in the last 4 years

The Marriott statement said for around 326 million of its guests, the personal information compromised included "some combination" of, name, address, phone number, email address, passport number, date of birth, gender and arrival & departure information. The hotelier also said encrypted payment card data was also copied, and it could not rule out the encryption keys to decrypt cardholder data had not been stolen.

The hotel giant said it would notify customers affected and offer some a fraud detecting service for a year for free, so I expect they will be making contact with myself soon. In the meantime, Marriott has launched a website for affected customers and a free helpline for concerned UK customers 0808 189 1065.

The UK ICO said it would be investigating the breach, and warned those who believe they are impacted to be extra vigilant and to follow the advice on the ICO website, and by the National Cyber Security Centre
. The hotel chain could face huge fines under the GDPR, and possibly a large scale class action lawsuit by their affected guests, which could cost them millions of pounds. 

What I really would like to know is why the hotel chain had retained such vast numbers of guest records post their stay. Why they held their customer's passport details and whether those encryption keys were stolen or not. And finally, why the unauthorised access went undetected for four years.

Tom Kellermann, Chief Cybersecurity Officer for Carbon Black, said "It appears there had been unauthorised access to the Starwood network since 2014, demonstrating that attackers will get into an enterprise and attempt to remain undetected. A recent Carbon Black threat report found that nearly 60% of attacks now involve lateral movement, which means attackers aren’t just going after one component of an organisation - they’re getting in, moving around and seeking more targets as they go."

The report also found that 50% of today’s attackers now use the victim primarily for island hopping. In these campaigns, attackers first target an organisation's affiliates, often smaller companies with immature security postures and this can often be the case during an M&A. This means that data at every point in the supply chain may be at risk, from customers, to partners and potential acquisitions.”

Jake Olcott, VP of Strategic Partnerships at BitSight, said "Following the breaking news today that Marriott’s Starwood bookings database has been comprised with half a billion people affected, it highlights the importance of organisations undertaking sufficient security posture checks to avoid such compromises. Marriott’s acquisition of Starwood in 2016 allowed it to utilise its Starwood customer database. Therefore, proactive due diligence during this acquisition period would have helped Marriott to identify the potential cybersecurity risks, and the impact of a potential breach".

“This is yet another example of why it is critical that companies perform cybersecurity analysts during the due diligence period, prior to an acquisition or investment. Traditionally, companies have approached cyber risk in acquisitions by issuing questionnaires to the target company; unfortunately, these methods are time consuming and reflect only a “snapshot in time” view.

“Understanding the cybersecurity posture of an investment is critical to assessing the value of the investment and considering reputational, financial, and legal harm that could befall the company. After an investment has been made, continuous monitoring is essential.”

Injecting Code into Windows Protected Processes using COM – Part 2

Posted by James Forshaw, Project Zero

In my previous blog I discussed a technique which combined numerous issues I’ve previously reported to Microsoft to inject arbitrary code into a PPL-WindowsTCB process. The techniques presented don’t work for exploiting the older, stronger Protected Processes (PP) for a few different reasons. This blog seeks to remedy this omission and provide details of how I was able to also hijack a full PP-WindowsTCB process without requiring administrator privileges. This is mainly an academic exercise, to see whether I can get code executing in a full PP as there’s not much more you can do inside a PP over a PPL.

As a quick recap of the previous attack, I was able to identify a process which would run as PPL which also exposed a COM service. Specifically, this was the “.NET Runtime Optimization Service” which ships with the .NET framework and uses PPL at CodeGen level to apply cached signing levels to Ahead-of-Time compiled DLLs to allow them to be used with User-Mode Code Integrity (UMCI). By modifying the COM proxy configuration it was possible to induce a type confusion which allowed me to load an arbitrary DLL by hijacking the KnownDlls configuration. Once running code inside the PPL I could abuse a bug in the cached signing feature to create a DLL signed to load into any PPL and through that escalate to PPL-WindowsTCB level.

Finding a New Target

My first thought to exploit full PP would be to use the additional access we were granted from having code running at PPL-WindowsTCB. You might assume you could abuse the cached signed DLL to bypass security checks to load into a full PP. Unfortunately the kernel’s Code Integrity module ignores cached signing levels for full PP. How about KnownDlls in general? If we have administrator privileges and code running in PPL-WindowsTCB we can directly write to the KnownDlls object directory (see another of my blog posts link for why you need to be PPL) and try to get the PP to load an arbitrary DLL. Unfortunately, as I mentioned in the previous blog, this also doesn’t work as full PP ignores KnownDlls. Even if it did load KnownDlls I don’t want to require administrator privileges to inject code into the process.

I decided that it’d make sense to rerun my PowerShell script from the previous blog to discover which executables will run as full PP and at what level. On Windows 10 1803 there’s a significant number of executables which run as PP-Authenticode level, however only four executables would start with a more privileged level as shown in the following table.

Path
Signing Level
C:\windows\system32\GenValObj.exe
Windows
C:\windows\system32\sppsvc.exe
Windows
C:\windows\system32\WerFaultSecure.exe
WindowsTCB
C:\windows\system32\SgrmBroker.exe
WindowsTCB

As I have no known route from PP-Windows level to PP-WindowsTCB level like I had with PPL, only two of the four executables are of interest, WerFaultSecure.exe and SgrmBroker.exe. I correlated these two executables against known COM service registrations, which turned up no results. That doesn’t mean these executables don’t expose a COM attack surface, the .NET executable I abused last time also doesn’t register its COM service, so I also performed some basic reverse engineering looking for COM usage.

The SgrmBroker executable doesn’t do very much at all, it’s a wrapper around an isolated user mode application to implement runtime attestation of the system as part of Windows Defender System Guard and didn’t call into any COM APIs. WerFaultSecure also doesn’t seem to call into COM, however I already knew that WerFaultSecure can load COM objects, as Alex Ionescu used my original COM scriptlet code execution attack to get PPL-WindowsTCB level though hijacking a COM object load in WerFaultSecure. Even though WerFaultSecure didn’t expose a service if it could initialize COM perhaps there was something that I could abuse to get arbitrary code execution? To understand the attack surface of COM we need to understand how COM implements out-of-process COM servers and COM remoting in general.

Digging into COM Remoting Internals

Communication between a COM client and a COM server is over the MSRPC protocol, which is based on the Open Group’s DCE/RPC protocol. For local communication the transport used is Advanced Local Procedure Call (ALPC) ports. At a high level communication occurs between a client and server based on the following diagram:


In order for a client to find the location of a server the process registers an ALPC endpoint with the DCOM activator in RPCSS ①. This endpoint is registered alongside the Object Exporter ID (OXID) of the server, which is a 64 bit randomly generated number assigned by RPCSS. When a client wants to connect to a server it must first ask RPCSS to resolve the server’s OXID value to an RPC endpoint ②. With the knowledge of the ALPC RPC endpoint the client can connect to the server and call methods on the COM object ③.

The OXID value is discovered either from an out-of-process (OOP) COM activation result or via a marshaled Object Reference (OBJREF) structure. Under the hood the client calls the ResolveOxid method on RPCSS’s IObjectExporter RPC interface. The prototype of ResolveOxid is as follows:

interface IObjectExporter {
  // ...
  error_status_t ResolveOxid(
    [in] handle_t hRpc,
    [in] OXID* pOxid,
    [in] unsigned short cRequestedProtseqs,
    [in] unsigned short arRequestedProtseqs[],
    [out, ref] DUALSTRINGARRAY** ppdsaOxidBindings,
    [out, ref] IPID* pipidRemUnknown,
    [out, ref] DWORD* pAuthnHint
);

In the prototype we can see the OXID to resolve is being passed in the pOxid parameter and the server returns an array of Dual String Bindings which represent RPC endpoints to connect to for this OXID value. The server also returns two other pieces of information, an Authentication Level Hint (pAuthnHint) which we can safely ignore and the IPID of the IRemUnknown interface (pipidRemUnknown) which we can’t.

An IPID is a GUID value called the Interface Process ID. This represents the unique identifier for a COM interface inside the server, and it’s needed to communicate with the correct COM object as it allows the single RPC endpoint to multiplex multiple interfaces over one connection. The IRemUnknown interface is a default COM interface every COM server must implement as it’s used to query for new IPIDs on an existing object (using RemQueryInterface) and maintain the remote object’s reference count (through RemAddRef and RemRelease methods). As this interface must always exist regardless of whether an actual COM server is exported and the IPID can be discovered through resolving the server’s OXID, I wondered what other methods the interface supported in case there was anything I could leverage to get code execution.

The COM runtime code maintains a database of all IPIDs as it needs to lookup the server object when it receives a request for calling a method. If we know the structure of this database we could discover where the IRemUnknown interface is implemented, parse its methods and find out what other features it supports. Fortunately I’ve done the work of reverse engineering the database format in my OleViewDotNet tool, specifically the command Get-ComProcess in the PowerShell module. If we run the command against a process which uses COM, but doesn’t actually implement a COM server (such as notepad) we can try and identify the correct IPID.


In this example screenshot there’s actually two IPIDs exported, IRundown and a Windows.Foundation interface. The Windows.Foundation interface we can safely ignore, but IRundown looks more interesting. In fact if you perform the same check on any COM process you’ll discover they also have IRundown interfaces exported. Are we not expecting an IRemUnknown interface though? If we pass the ResolveMethodNames and ParseStubMethods parameters to Get-ComProcess, the command will try and parse method parameters for the interface and lookup names based on public symbols. With the parsed interface data we can pass the IPID object to the Format-ComProxy command to get a basic text representation of the IRundown interface. After cleanup the IRundown interface looks like the following:

[uuid("00000134-0000-0000-c000-000000000046")]
interface IRundown : IUnknown {
   HRESULT RemQueryInterface(...);
   HRESULT RemAddRef(...);
   HRESULT RemRelease(...);
   HRESULT RemQueryInterface2(...);
   HRESULT RemChangeRef(...);
   HRESULT DoCallback([in] struct XAptCallback* pCallbackData);
   HRESULT DoNonreentrantCallback([in] struct XAptCallback* pCallbackData);
   HRESULT AcknowledgeMarshalingSets(...);
   HRESULT GetInterfaceNameFromIPID(...);
   HRESULT RundownOid(...);
}

This interface is a superset of IRemUnknown, it implements the methods such as RemQueryInterface and then adds some more additional methods for good measure. What really interested me was the DoCallback and DoNonreentrantCallback methods, they sound like they might execute a “callback” of some sort. Perhaps we can abuse these methods? Let’s look at the implementation of DoCallback based on a bit of RE (DoNonreentrantCallback just delegates to DoCallback internally so we don’t need to treat it specially):

struct XAptCallback {
 void* pfnCallback;
 void* pParam;
 void* pServerCtx;
 void* pUnk;
 void* iid;
 int   iMethod;
 GUID  guidProcessSecret;
};

HRESULT CRemoteUnknown::DoCallback(XAptCallback *pCallbackData) {
 CProcessSecret::GetProcessSecret(&pguidProcessSecret);
 if (!memcmp(&pguidProcessSecret,
             &pCallbackData->guidProcessSecret, sizeof(GUID))) {
   if (pCallbackData->pServerCtx == GetCurrentContext()) {
     return pCallbackData->pfnCallback(pCallbackData->pParam);
   } else {
     return SwitchForCallback(
                  pCallbackData->pServerCtx,
                  pCallbackData->pfnCallback,
                  pCallbackData->pParam);
   }
 }
 return E_INVALIDARG;
}

This method is very interesting, it takes a structure containing a pointer to a method to call and an arbitrary parameter and executes the pointer. The only restrictions on calling the arbitrary method is you must know ahead of time a randomly generated GUID value, the process secret, and the address of a server context. The checking of a per-process random value is a common security pattern in COM APIs and is typically used to restrict functionality to only in-process callers. I abused something similar in the Free-Threaded Marshaler way back in 2014.

What is the purpose of DoCallback? The COM runtime creates a new IRundown interface for every COM apartment that’s initialized. This is actually important as calling methods between apartments, say calling a STA object from a MTA, you need to call the appropriate IRemUnknown methods in the correct apartment. Therefore while the developers were there they added a few more methods which would be useful for calling between apartments, including a general “call anything you like” method. This is used by the internals of the COM runtime and is exposed indirectly through methods such as CoCreateObjectInContext. To prevent the DoCallback method being abused OOP the per-process secret is checked which should limit it to only in-process callers, unless an external process can read the secret from memory.

Abusing DoCallback

We have a primitive to execute arbitrary code within any process which has initialized COM by invoking the DoCallback method, which should include a PP. In order to successfully call arbitrary code we need to know four pieces of information:

  1. The ALPC port that the COM process is listening on.
  2. The IPID of the IRundown interface.
  3. The initialized process secret value.
  4. The address of a valid context, ideally the same value that GetCurrentContext returns to call on the same RPC thread.

Getting the ALPC port and the IPID is easy, if the process exposes a COM server, as both will be provided during OXID resolving. Unfortunately WerFaultSecure doesn’t expose a COM object we can create so that angle wouldn’t be open to us, leaving us with a problem we need to solve. Extracting the process secret and context value requires reading the contents of process memory. This is another problem, one of the intentional security features of PP is preventing a non-PP process from reading memory from a PP process. How are we going to solve these two problems?

Talking this through with Alex at Recon we came up with a possible attack if you have administrator access. Even being an administrator doesn’t allow you to read memory directly from a PP process. We could have loaded a driver, but that would break PP entirely, so we considered how to do it without needing kernel code execution.

First and easiest, the ALPC port and IPID can be extracted from RPCSS. The RPCSS service does not run protected (even PPL) so this is possible to do without any clever tricks other than knowing where the values are stored in memory. For the context pointer, we should be able to brute force the location as there’s likely to be only a narrow range of memory locations to test, made slightly easier if we use the 32 bit version of WerFaultSecure.

Extracting the secret is somewhat harder. The secret is initialized in writable memory and therefore ends up in the process’ working set once it’s modified. As the page isn’t locked it will be eligible for paging if the memory conditions are right. Therefore if we could force the page containing the secret to be paged to disk we could read it even though it came from a PP process. As an administrator, we can perform the following to steal the secret:

  1. Ensure the secret is initialized and the page is modified.
  2. Force the process to trim its working set, this should ensure the modified page containing the secret ends up paged to disk (eventually).
  3. Create a kernel memory crash dump file using the NtSystemDebugControl system call. The crash dump can be created by an administrator without kernel debugging being enabled and will contain all live memory in the kernel. Note this doesn’t actually crash the system.
  4. Parse the crash dump for the Page Table Entry of the page containing the secret value. The PTE should disclose where in the paging file on disk the paged data is located.
  5. Open the volume containing the paging file for read access, parse the NTFS structures to find the paging file and then find the paged data and extract the secret.

After coming up with this attack it seemed far too much like hard work and needed administrator privileges which I wanted to avoid. I needed to come up with an alternative solution.

Using WerFaultSecure for its Original Purpose

Up to this point I’ve been discussing WerFaultSecure as a process that can be abused to get arbitrary code running inside a PP/PPL. I’ve not really described why the process can run at the maximum PP/PPL levels. WerFaultSecure is used by the Windows Error Reporting service to create crash dumps from protected processes. Therefore it needs to run at elevated PP levels to ensure it can dump any possible user-mode PP. Why can we not just get WerFaultSecure to create a crash dump of itself, which would leak the contents of process memory and allow us to extract any information we require?

The reason we can’t use WerFaultSecure is it encrypts the contents of the crash dump before writing it to disk. The encryption is done in a way to only allow Microsoft to decrypt the crash dump, using asymmetric encryption to protect a random session key which can be provided to the Microsoft WER web service. Outside of a weakness in Microsoft’s implementation or a new cryptographic attack against the primitives being used getting the encrypted data seems like a non-starter.

However, it wasn’t always this way. In 2014 Alex presented at NoSuchCon about PPL and discussed a bug he’d discovered in how WerFaultSecure created encrypted dump files. It used a two step process, first it wrote out the crash dump unencrypted, then it encrypted the crash dump. Perhaps you can spot the flaw? It was possible to steal the unencrypted crash dump. Due to the way WerFaultSecure was called it accepted two file handles, one for the unencrypted dump and one for the encrypted dump. By calling WerFaultSecure directly the unencrypted dump would never be deleted which means that you don’t even need to race the encryption process.

There’s one problem with this, it was fixed in 2015 in MS15-006. After that fix WerFaultSecure encrypted the crash dump directly, it never ends up on disk unencrypted at any point. But that got me thinking, while they might have fixed the bug going forward what prevents us from taking the old vulnerable version of WerFaultSecure from Windows 8.1 and executing it on Windows 10? I downloaded the ISO for Windows 8.1 from Microsoft’s website (link), extracted the binary and tested it, with predictable results:


We can take the vulnerable version of WerFaultSecure from Windows 8.1 and it will run quite happily on Windows 10 at PP-WindowsTCB level. Why? It’s unclear, but due to the way PP is secured all the trust is based on the signed executable. As the signature of the executable is still valid the OS just trusts it can be run at the requested protection level. Presumably there must be some way that Microsoft can block specific executables, although at least they can’t just revoke their own signing certificates. Perhaps OS binaries should have an EKU in the certificate which indicates what version they’re designed to run on? After all Microsoft already added a new EKU when moving from Windows 8 to 8.1 to block downgrade attacks to bypass WinRT UMCI signing so generalizing might make some sense, especially for certain PP levels.

After a little bit of RE and reference to Alex’s presentation I was able to work out the various parameters I needed to be passed to the WerFaultSecure process to perform a dump of a PP:

Parameter
Description
/h
Enable secure dump mode.
/pid {pid}
Specify the Process ID to dump.
/tid {tid}
Specify the Thread ID in the process to dump.
/file {handle}
Specify a handle to a writable file for the unencrypted crash dump
/encfile {handle}
Specify a handle to a writable file for the encrypted crash dump
/cancel {handle}
Specify a handle to an event to indicate the dump should be cancelled
/type {flags}
Specify MIMDUMPTYPE flags for call to MiniDumpWriteDump

This gives us everything we need to complete the exploit. We don’t need administrator privileges to start the old version of WerFaultSecure as PP-WindowsTCB. We can get it to dump another copy of WerFaultSecure with COM initialized and use the crash dump to extract all the information we need including the ALPC Port and IPID needed to communicate. We don’t need to write our own crash dump parser as the Debug Engine API which comes installed with Windows can be used. Once we’ve extracted all the information we need we can call DoCallback and invoke arbitrary code.

Putting it All Together

There’s still two things we need to complete the exploit, how to get WerFaultSecure to start up COM and what we can call to get completely arbitrary code running inside the PP-WindowsTCB process.

Let’s tackle the first part, how to get COM started. As I mentioned earlier, WerFaultSecure doesn’t directly call any COM methods, but Alex had clearly used it before so to save time I just asked him. The trick was to get WerFaultSecure to dump an AppContainer process, this results in a call to the method CCrashReport::ExemptFromPlmHandling inside the FaultRep DLL resulting in the loading of CLSID {07FC2B94-5285-417E-8AC3-C2CE5240B0FA}, which resolves to an undocumented COM object. All that matters is this allows WerFaultSecure to initialize COM.

Unfortunately I’ve not been entirely truthful during my description of how COM remoting is setup. Just loading a COM object is not always sufficient to initialize the IRundown interface or the RPC endpoint. This makes sense, if all COM calls are to code within the same apartment then why bother to initialize the entire remoting code for COM. In this case even though we can make WerFaultSecure load a COM object it doesn’t meet the conditions to setup remoting. What can we do to convince the COM runtime that we’d really like it to initialize? One possibility is to change the COM registration from an in-process class to an OOP class. As shown in the screenshot below the COM registration is being queried first from HKEY_CURRENT_USER which means we can hijack it without needing administrator privileges.


Unfortunately looking at the code this won’t work, a cut down version is shown below:

HRESULT CCrashReport::ExemptFromPlmHandling(DWORD dwProcessId) {
 CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
 IOSTaskCompletion* inf;
 HRESULT hr = CoCreateInstance(CLSID_OSTaskCompletion,
     NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&inf));
 if (SUCCEEDED(hr)) {
   // Open process and disable PLM handling.
 }
}

The code passes the flag, CLSCTX_INPROC_SERVER to CoCreateInstance. This flag limits the lookup code in the COM runtime to only look for in-process class registrations. Even if we replace the registration with one for an OOP class the COM runtime would just ignore it. Fortunately there’s another way, the code is initializing the current thread’s COM apartment as a STA using the COINIT_APARTMENTTHREADED flag with CoInitializeEx. Looking at the registration of the COM object its threading model is set to “Both”. What this means in practice is the object supports being called directly from either a STA or a MTA.

However, if the threading model was instead set to “Free” then the object only supports direct calls from an MTA, which means the COM runtime will have to enable remoting, create the object in an MTA (using something similar to DoCallback) then marshal calls to that object from the original apartment. Once COM starts remoting it initializes all remote features including IRundown. As we can hijack the server registration we can just change the threading model, this will cause WerFaultSecure to start COM remoting which we can now exploit.

What about the second part, what can we call inside the process to execute arbitrary code? Anything we call using DoCallback must meet the following criteria, to avoid undefined behavior:

  1. Only takes one pointer sized parameter.
  2. Only the lower 32 bits of the call are returned as the HRESULT if we need it.
  3. The callsite is guarded by CFG so it must be something which is a valid indirect call target.

As WerFaultSecure isn’t doing anything special then at a minimum any DLL exported function should be a valid indirect call target. LoadLibrary clearly meets our criteria as it takes a single parameter which is a pointer to the DLL path and we don’t really care about the return value so the truncation isn’t important. We can’t just load any DLL as it must be correctly signed, but what about hijacking KnownDlls?

Wait, didn’t I say that PP can’t load from KnownDlls? Yes they can’t but only because the value of the LdrpKnownDllDirectoryHandle global variable is always set to NULL during process initialization. When the DLL loader checks for the presence of a known DLL if the handle is NULL the check returns immediately. However if the handle has a value it will do the normal check and just like in PPL no additional security checks are performed if the process maps an image from an existing section object. Therefore if we can modify the LdrpKnownDllDirectoryHandle global variable to point to a directory object inherited into the PP we can get it to load an arbitrary DLL.

The final piece of the puzzle is finding an exported function which we can call to write an arbitrary value into the global variable. This turns out to be harder than expected. The ideal function would be one which takes a single pointer value argument and writes to that location with no other side effects. After a number of false starts (including trying to use gets) I settled on the pair, SetProcessDefaultLayout and GetProcessDefaultLayout in USER32. The set function takes a single value which is a set of flags and stores it in a global location (actually in the kernel, but good enough). The get method will then write that value to an arbitrary pointer. This isn’t perfect as the values we can set and therefore write are limited to the numbers 0-7, however by offsetting the pointer in the get calls we can write a value of the form 0x0?0?0?0? where the ? can be any value between 0 and 7. As the value just has to refer to the handle inside a process under our control we can easily craft the handle to meet these strict requirements.

Wrapping Up

In conclusion to get arbitrary code execution inside a PP-WindowsTCB without administrator privileges process we can do the following:

  1. Create a fake KnownDlls directory, duplicating the handle until it meets a pattern suitable for writing through Get/SetProcessDefaultLayout. Mark the handle as inheritable.
  2. Create the COM object hijack for CLSID {07FC2B94-5285-417E-8AC3-C2CE5240B0FA} with the ThreadingModel set to “Free”.
  3. Start Windows 10 WerFaultSecure at PP-WindowsTCB level and request a crash dump from an AppContainer process. During process creation the fake KnownDlls must be added to ensure it’s inherited into the new process.
  4. Wait until COM has initialized then use Windows 8.1 WerFaultSecure to dump the process memory of the target.
  5. Parse the crash dump to discover the process secret, context pointer and IPID for IRundown.
  6. Connect to the IRundown interface and use DoCallback with Get/SetProcessDefaultLayout to modify the LdrpKnownDllDirectoryHandle global variable to the handle value created in 1.
  7. Call DoCallback again to call LoadLibrary with a name to load from our fake KnownDlls.

This process works on all supported versions of Windows 10 including 1809. It’s worth noting that invoking DoCallback can be used with any process where you can read the contents of memory and the process has initialized COM remoting. For example, if you had an arbitrary memory disclosure vulnerability in a privileged COM service you could use this attack to convert the arbitrary read into arbitrary execute. As I don’t tend to look for memory corruption/memory disclosure vulnerabilities perhaps this behavior is of more use to others.

That concludes my series of attacking Windows protected processes. I think it demonstrates that preventing a user from attacking processes which share resources, such as registry and files is ultimately doomed to fail. This is probably why Microsoft do not support PP/PPL as a security boundary. Isolated User Mode seems a much stronger primitive, although that does come with additional resource requirements which PP/PPL doesn’t for the most part.  I wouldn’t be surprised if newer versions of Windows 10, by which I mean after version 1809, will try to mitigate these attacks in some way, but you’ll almost certainly be able to find a bypass.

Marriott Confirms Breach Impacts As Many As 500 Million Guests

Veracode Marriott Starwood Hotel Breach November 2018

Marriott International has disclosed that the guest reservation database of its Starwood division has been breached, affecting as many as 500 million guests. The company has also confirmed that there has been unauthorized access to the Starwood network since 2014.

According to a report from the BBC, for roughly 327 million guests, the attacker was able to access personally identifiable information including a combination of name, address, phone number, email address, passport number, account information, date of birth, and gender. In some cases, the compromised records also included encrypted credit card information. The company is still trying to determine whether or not the encryption keys have also been stolen.

In a statement, Marriott said that on Sept. 8 of this year, it received an alert from an internal security tool that an unauthorized user had attempted to access the Starwood database in the US. An investigation into the incident confirmed that an attacker had indeed copied and encrypted the information. Marriott was able to decrypt the information to confirm that the contents were from the Starwood guest reservation database.

While it is still unclear how the attackers penetrated the organization, Chris Wysopal, co-founder & CTO of Veracode, said that the breach could have gone undetected on the network for so long because attackers are getting better at making sure their attacks don’t contain indicators of compromise (IoC).

Marriott bought Starwood - which owns brands including the W Hotels, Sheraton, Le Méridien, and Four Points by Sheraton - in 2016 to create the largest hotel chain in the world. Marriott-branded hotels use a separate reservation system on a different network.

The incident has been reported to both law enforcement and regulatory authorities, and the UK's data regulator is investigating. While Marriott is headquartered in the US, it works with and hosts European citizens, so it must ensure that it meets GDPR compliance. It’s anticipated that Marriott International will receive a substantial penalty because of the size and scale of the breach. Wysopal said that given that this is one of the first major breaches under both GDPR and the new California Consumer Privacy Act, “it will be a bellwether for breaches to come.”

“On a scale of 1 to 10 and up, this is one of those No. 10 size breaches. There have only been a few of them of this scale and scope in the last decade,” Wysopal told AP in an interview.

Marriott is emailing guests affected by the breach and will not send emails with any attachments. Additionally, the company is offering its guests a free membership to WebWatcher, a personal information monitoring service, and is instructing guests to watch their loyalty accounts, change their passwords, and check credit card statements for unauthorized activities. An informational website and call center have also been set up to support guests during the investigation.

Playbook Fridays: OneMillion API Component

Using this Playbook Component, incident responders and analysts can check if a given domain exists on any lists of the most frequently visited hostnames

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

What?

This week, we are featuring a Playbook Component which finds the rank of a given host in a list of the one million, most visited hostnames. In this post, we are going to introduce why this component is useful, discuss why it is a Playbook Component rather than a Playbook, and show you how to use this component (if you have Playbooks enabled in your ThreatConnect instance, you can create a Playbook to use this component in less than five minutes).

Why?

If a Host Indicator is one of the top million, most visited domains, this usually merits further investigation. It could be that a host in the list is benign (perhaps it is a false positive or perhaps a malware sample calls back to a benign host to test its internet connection or get its IP address). It could alternatively mean that the host is malicious and simply getting a lot of traffic. Either way, it's helpful to have this information. This Playbook Component, built on the OneMillion API (which is not maintained by ThreatConnect), allows incident responders and analysts to check if a given domain exists on any lists of the most frequently visited hostnames.

Why a component?

Before we talk about how to use this component, let's address why this system was created as a Playbook Component rather than normal Playbook. The major benefit of components is that you can capture a common process you would like to repeat in multiple, diverse places. For example, if you are making a Playbook which requires you to get the length of a string, you could add apps to get the length of a string to that Playbook, but if you ever need to get the length of a string again, you will have to recreate what you have already done. Instead, if you are creating a generic function or one that you would like to use in multiple playbooks, consider creating a component. A component lets you perform an operation again and again without having to recreate anything (and by the way, there is a component to get the length of a string described here (this site is not maintained by ThreatConnect)). In the case of the OneMillion API Component, it was created as a component so that it is easy to plug into new and existing playbooks.

Using the component

So how do you use this component? In this section, we'll walk through the installation of the component and will create a Playbook to use the component to show you how easy it is to use components to expand the functionality of a Playbook.

  1. The first step is to install the component. You can download it from https://tc.hightower.space/post/playbook-components/onemillion-api-query/ (which is not maintained by ThreatConnect) or download the "Query OneMillion API.pbx" file from GitHub.
  2. Once you have downloaded the component, you can import it into ThreatConnect like a Playbook by going to the "Playbooks" tab in ThreatConnect and clicking "New" > "Import" (on ThreatConnect versions before 5.7, you can click the "Import" button). Then import the Query OneMillion API.pbx file.
  3. Turn it on and the component is ready to be used!
  4. Now that we have installed and activated the "Query OneMillion API" component, we need to create a Playbook to use it. To do this, go back to the "Playbooks" tab in ThreatConnect and create a new Playbook. For this example, we are going to create a Playbook with a User Action trigger that will allow users to submit a host indicator in ThreatConnect to the OneMillion API and return the result with a single click.
  5. To build this Playbook, select the "Trigger" tab in the pane on the left and select "UserAction". This will add the trigger to the design canvas. Now, double click on the new trigger to edit it. Rename the trigger in the "User Action Name" field (this name will show up for users when viewing Host indicators in ThreatConnect). Select "Host" for the "Type" field, click through the next section, and save the trigger.
  6. Now, click the "App" tab in the pane on the left and select the "Query OneMillion API" from the "Components" section. If it does not show up, this is probably the "Query OneMillion API" component you installed in step two is not turned on (as we did in step three). Assuming, you were able to find the "Query OneMillion API" component and add it to the design canvas, drag a line from the blue dot on the trigger to the component. Double click on the component to edit it. In the "Host" field, start typing "#" and a list of available options will show up. Select "trg.action.item" (this is the hostname which is captured by the User Action trigger); this means that the hostname from which the Playbook was triggered will be sent to the OneMillion API (if this doesn't make sense, watch the gif above for a demo that will clarify how this system works). Save the "Query OneMillion API" component.
  7. Now, draw a line between the blue dot on the "Query OneMillion API" component and the trigger. This allows us to send information back to the user via the trigger. Double click on the trigger to edit it. Click "Next" to move to the second stage (you should see a text area with the label "Body"). In the text area, start typing "#" (again, this shows you a list of available values you can send back to the user). Select "hostRank" and save the trigger.
  8. Turn the Playbook on by clicking the "Active" toggle in the upper right-hand corner.
  9. Now for the fun part: using the Playbook! Find or create a host indicator in your ThreatConnect instance. There should be a "Playbook Actions" card on the top-right side of the indicator's page and it should list the name of the User Action trigger you provided in step five (if you didn't change the name of the User Action trigger, it will probably show up as "UserAction Trigger 1"). When you click it, the Playbook will be executed and the rank of the host (if there is one) will be returned to the right of the trigger. You now have a Playbook which lets analysts query the OneMillion API!

If you have completed the steps above and would like to contribute your playbook with the trigger in it, there are instructions for contributing to our playbooks repository here: https://github.com/ThreatConnect-Inc/threatconnect-playbooks/wiki/Contributions-Workflow .

If you have any questions or run into any problems with this playbook component, please raise an issue in Github. As always, let us know if you have any questions!

 

 

 

 

 

The post Playbook Fridays: OneMillion API Component appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Lockly Secure Plus Review: Biometrics comes to the smart lock

Lockly’s big sell is that most smart locks aren’t very smart at all, that “90 percent of smart locks can easily be accessed by individuals who you do not want in your home or office.” Lockly hints at the reason for this problem (more on this later), but it’s ultimate claim is that Lockly’s devices are more secure. While that might be true, one has to wonder: With a lock so difficult to install and manage, how much security can it really provide if it never makes it out of the box?

Operationally, Lockly takes the smart lock in a few different directions than the typical lock. It has nearly all the features you could look for: Smartphone control, touchscreen access, a failsafe lock for a physical key, and even a 9-volt battery backup on the exterior if your AAs fail while you’re outside and you don’t have your key. The lock is available in six total combinations of door type (deadbolt or latch, with a sturdy handle), finish (satin nickel or Venetian bronze), and security level (Secure or Secure Plus). Secure Plus (reviewed here) includes a fingerprint reader—a rarity in smart locks—while the Secure version does not.

To read this article in full, please click here

NBlog Dec 1 – security awareness on ‘oversight’

We bring the year to a close with an awareness and training module on a universal control that is applicable and valuable in virtually all situations in some form or other.  Oversight blends monitoring and watching-over with directing, supervising and guiding, a uniquely powerful combination.
The diversity and flexibility of the risk and control principles behind oversight are applied naturally by default, and can be substantially strengthened where appropriate. Understanding the fundamentals is the first step towards making oversight more effective, hence this is a cracker of an awareness topic with broad relevance to information risk and security, compliance, governance, safety and all that jazz.
It’s hard to conceive of a security awareness and training program that would not cover oversight, but for most it is implicit, lurking quietly in the background.  NoticeBored draws it out, putting it front and center.  
In the most general sense, very few activities would benefit from not being overseen in some fashion, either by the people and machines performing them or by third parties.
To a large extent, management is the practical application of oversight.  It’s also fundamental to governance, compliance and many controls, including most of those in information risk and security. 
Imagine if you can a world without any form of oversight where:
  • People and organizations were free to do exactly as they wish without fear of anyone spotting and reacting to their activities;
  • Machines operated totally autonomously, with nobody monitoring or controlling them;
  • Organizations, groups and individuals acted with impunity, doing whatever they felt like without any guidance, direction or limits, nobody checking up on them or telling them what to do or not to do;
  • Compliance was optional at best, and governance was conspicuously absent. 
Such a world may be utopia for anarchists, egocentrics and despots but a nightmare scenario for information risk and security professionals, and for any civilized society!

Read more about December's NoticeBored security awareness and training module then get in touch to subscribe.

How to enable 2FA on Twitter with Authy, Google Authenticator or another Mobile Application

It’s been a long time since I have had to enable 2FA on Twitter and found the process completely infuriating. Twitter’s 2FA configuration uses SMS as the default option, this...

Read More

The post How to enable 2FA on Twitter with Authy, Google Authenticator or another Mobile Application appeared first on PerezBox.

AWS EC2 instance userData

In the effort to get me blogging again I'll be doing a few short posts to get the juices flowing (hopefully).

Today I learned about the userData instance attribute for AWS EC2.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

In general I thought metadata was only things you can hit from WITHIN the instance via the metadata url: http://169.254.169.254/latest/meta-data/

However, if you read the link above there is an option to add metadata at boot time. 


You can also use instance metadata to access user data that you specified when launching your instance. For example, you can specify parameters for configuring your instance, or attach a simple script. 

That's interesting right?!?!  so if you have some AWS creds the easiest way to check for this (after you enumerate instance IDs) is with the aws cli.

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX

An error occurred (InvalidInstanceID.NotFound) when calling the DescribeInstanceAttribute operation: The instance ID 'i-0XXXXXXXX' does not exist

ah crap, you need the region...

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX --region us-west-1
{
    "InstanceId": "i-0XXXXXXXX",
    "UserData": {
        "Value": "bm90IHRvZGF5IElTSVMgOi0p"}


anyway that can get tedious especially if the org has a ton of things running.  This is precisely the reason @cktricky and I built weirdAAL.  Surely no one would be sticking creds into things at boot time via shell scripts :-)


The module loops trough all the regions and any instances it finds and queries for the userData attribute.  Hurray for automation.

That module is in the current version of weirdAAL. Enjoy.

-CG

Hackers targeted Dell customer information in attempted attack

Earlier this month, hackers attempted to breach Dell's network and obtain customer information, according to the company. While it says there's no conclusive evidence the hackers were successful in their November 9th attack, it's still possible they obtained some data.

Via: The Verge

Source: Dell (1), (2)

Ivacy VPN review: A competent VPN that doesn’t mind cryptocurrencies

Ivacy in brief:

  • P2P allowed: Yes
  • Business location: Singapore
  • Number of servers: 459+*
  • Number of country locations: 55
  • Cost: $40 (billed annually)
  • VPN protocol: OpenVPN-UDP
  • Data encryption: AES-256-GCM 
  • Data authentication: MS-Chap v2 and TLS
  • Handshake Encryption: SHA-II

* Includes virtual server locations

Editors Note: This review was updated on November 29, 2018 to reflect changes to the Ivacy app. The review score has not changed.

To read this article in full, please click here

Two Iranian Hackers charged with $6 Million in SamSam Ransomware Attacks

Today the Department of Justice announced an indictment against two Iranian men: Faramarz Shahi Savandi and Mohammad Mehdi Shah Mansouri for their roles in stealing more than $6 Million in Ransom payments from a 34 month long ransomware campaign known as SamSam.

They were charged with:

18 U.S.C. § 371 - Conspiracy to Defraud the United States

18 U.S.C. § 1030(a)(5)(A) - knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;

18 U.S.C. § 1030(a)(7)(C) - demand or request for money or other thing of value in relation to damage to a protected computer, where such damage was caused to facilitate the extortion

18 U.S.C. § 1349 - Conspiracy

Victims were found in nearly every state:

Victim Locations from: https://www.justice.gov/opa/press-release/file/1114736/download


Piecing together the case involved gaining cooperation from two European VPN services, and apparently at least one search engine.   The indictment refers, for example, to the defendants using Bitcoin to pay for access to a European VPS, and then searching on May 15, 2016, for "kansasheart.com".  The same day, they accessed the public website of Kansas Heart Hospital, and on May 18th, encrypted many key computers on the network and sent their ransom note.

Another key part of the investigation was gaining the cooperation of a Bitcoin Exchanger, which was able to demonstrate that on July 21, 2016, the defendants cashed out at least some of their ransomed Bitcoin into Iranian Rials and deposited it into bank accounts controlled by MANSOURI and SAVANDI.

Chat logs were also available to the investigators, as the indictment mentions contents of chat consistently throughout their timeline.  Using the combination of events, some of the key dates were:

  • December 14, 2015 - Defendants chatting about the development and functionality of SamSam.
  • Jan 11, 2016 - Attack on Mercer County Business in New Jersey 
  • Feb 5, 2016 - Attack on Hollywood Presbyterian Medical Center 
  • March 27, 2016 - Attack on MedStar Health 
  • May 15, 2016 - Attack on Kansas Heart Hospital 
  • May 27, 2016 - Attack on University of Calgary 
  • July 27, 2016 - Attack on Nebraska Orthopedic Hospital 
  • April 25, 2017 - Attack on City of Newark, New Jersey 
  • January 18, 2018 - Attack on Allscripts Healthcare Solutions, Inc. 
  • February 19, 2018 - Attack on Colorado Department of Transportation 
  • March 22, 2018 - Attack on City of Atlanta, Georgia 
  • July 14, 2018 - Attack on LabCorp 
  • September 25, 2018 - Attack on the Port of San Diego 
FBI Wanted Poster from: https://www.justice.gov/opa/press-release/file/1114746/download

NBlog Nov 30 – P-day

The lack of blogging lately is due to working flat-out to complete December's NoticeBored security awareness module on oversight. 

Today, Friday the 30th of November, it's P-day here in the IsecT office:

  • Posters - two more poster designs are due in from the art department today. This close to the deadline I'd be worried except that, over the years, we have developed a close relationship and understanding with the supplier. I'm confident we'll get the stuff on time, and that it will be good.  Generally, it's right-first-time, which is nice. Our contingency plan involves crayons and a scanner - not pretty but, um, distinctive!
  • Proofreading - checking through the materials for errors and omissions, opportunities for improvement, loose ends to be tied-off and so on. This is oversight, in action. 
  • Polishing - tying-off those loose ends and finalizing the materials. Often I find that having prepared the content for the first stream, working on the second stream reminds me about stuff we should mention or incorporate into the first stream - and the same again with the third stream. There is some iteration, followed by a further round of checks to ensure that all three streams end up consistent, yet reflect the distinct perspectives of the three target audiences.
  • Packaging - we currently use WinZip to package and deliver the materials, an awkward, slow, costly and poorly-supported utility. We really ought to look for a better alternative. Suggestions welcome.
  • Publishing - uploading the materials to the server for customers, updating the NoticeBored website to describe the new module, and notifying subscribers is almost the last step, except for a quick update to this blog if I have time ... because it is ...
  • POETS day - once the month's work is done, it's play time, where 'play' partly involves catching up with all the other stuff that has been piling up on our to-do lists lately - ISO27k drafts to comment on, customers to contact, prospects to persuade, payments to chase. Plus a little R&R. Maybe a small dry sherry and an hour in front of the goggle-box if I'm lucky.
All too soon the cycle turns and it'll be time to start next month's juggling act, the final one of the year. I'll be blogging about our next awareness topic soon. Watch this space

Breaking down Dell’s “potential cybersecurity incident” announcement

With numerous regulations and laws like the European Union’s General Data Protection Regulation putting pressure on enterprises to go public with cybersecurity incidents, we’ve seen a trend of businesses disclosing breaches first and filling in the details later.

Dell provided the latest example of this trend Wednesday, announcing a “potential cybersecurity incident” that it detected earlier in the month. But despite the disclosure, it’s unclear if Dell should be celebrating or preparing for class action lawsuits. Let’s take a closer look at Dell’s notification.

First, there’s the headline — “Dell Announces Potential Cybersecurity Incident” – which is somewhat confusing because according to Dell itself, there most definitely was an incident. The company says “it detected and disrupted unauthorized activity on its network attempting to extract Dell.com customer information, which was limited to names, email addresses and hashed passwords.” It sounds like Dell thinks there was a potential breach rather than a potential cybersecurity incident.

Regardless, Dell apparently stopped the intrusion before attackers could steal any data, which is good news. But Dell qualified that statement with this portion of the announcement: “Though it is possible some of this information was removed from Dell’s network, our investigations found no conclusive evidence that any was extracted.”

The absence of evidence, however, doesn’t mean the attackers were unsuccessful. We don’t have any idea how long Dell thinks the intrusion lasted – only that it detected the unauthorized activity on Nov. 9. But we do know that the threat actor or actors attempted to extract customer data, and that it was limited to just names, email addresses and hashed passwords – though we don’t know how they were hashed (hopefully not MD5 or a similarly weak algorithm, and hopefully securely salted).

On the positive side, Dell seemed fairly confident about the scope of the intrusion. “Credit card and other sensitive customer information was not targeted,” the company said in its notification. “The incident did not impact any Dell products or services.”

The company added that it had “implemented countermeasures,” including “the hashing of our customers’ passwords and a mandatory Dell.com password reset.” Password resets are standard operating procedure for any incident, so it’s hard to judge just how severe this potential cybersecurity incident is for Dell based on those reactions. It’s also unclear what Dell means by “hashing the customer passwords.” (Did they rehash them after they were reset? Did they hash them with something different this time around? Did they add salt?)

Nevertheless, it sounds like Dell has contained the issue. The company said it’s investigating the intrusion, hired a third-party firm to conduct a separate, independent investigation, and also engaged law enforcement.

Dell’s announcement raises an important question: is this a cybersecurity win for the company? Based on the information available, Dell was able to detect threat actors on its network and stop them before they successfully extracted any data. That sounds like a win.

However, there are a lot of unknowns that could dampen the positives. We don’t know for sure that no customer data was exfiltrated, we don’t know how long the intrusion lasted, and we don’t know how the threat actors gained the unauthorized access in the first place (if it was, for example, a website flaw that was disclosed a year earlier but never fixed, then that would be bad). The answers to those questions could significantly alter the narrative.

It’s likely we’ll hear more from Dell about this incident down the road. For now, we’ll be left to wonder whether Dell gets to the chalk this up as a win or if it’s yet another negative cybersecurity headline.

 

The post Breaking down Dell’s “potential cybersecurity incident” announcement appeared first on Security Bytes.

Searching for Cisco Umbrella Alternatives? Your Affordable Option for DNS Security with Advanced Reporting.

Looking for an affordable alternative to Cisco Umbrella Enterprise's high cost? ThreatSTOP comes with advanced reporting and security research tools out-of-the-box. See blocked threats, remediate client machines faster and check IOC’s. Here's a breakdown of how ThreatSTOP and Cisco line up.

First Annual Cyberwarcon

Cyberwarcon is a brand new event organized yesterday in Arlington, Virginia, and delivered eight hours of fantastic content. “CyberwarCon is a one-day conference in the Washington D.C. area focused on the specter of destruction, disruption, and malicious influence on our society through cyber capabilities. We are increasingly concerned that aggressive behavior in this space is not abating and public discourse is necessary to shore up our defenses and prepare for inevitable incidents”. The list of speakers was diverse in their interests, from big data visualization technologies and analysis of social media misinformation campaigns, to incidents of Russian speaking APT in the US electrical grid. Thomas Rid keynoted with a presentation full of newly unearthed images and details on the earliest known misinformation campaign targeting the US, with some hints of what is to come for his upcoming book “Active Measures: A History of Disinformation”, certain to be another fascinating study and read. The full agenda can be found here.

Cyberwarcon badge

Our participation included my lightning talk presentation “Barely Whispering – Recent RU-speaking APT findings”. I attempted to clarify several transitively related clusters of RU-speaking APT activity and resources that we label Sofacy, BE/GreyEnergy, Zebrocy, and an advanced cluster, Hades, and introduced some data points new to public discussion about the groups. Three have exhibited disruptive and destructive behavior. It’s nice to see that some of the information I mentioned yesterday, Zebrocy’s nine month long and increasingly large wave of spearphishing, is in the news today. I briefly mentioned that their remote template spearphishing techniques, along with a switch back to the Delphi backdoor from a C# “Cannon” backdoor, was spreading to western networks. Timely stuff.

Check out the images and tweets at #CYBERWARCON. Hope to see you next year!

Announcing the Google Security and Privacy Research Awards



We believe that cutting-edge research plays a key role in advancing the security and privacy of users across the Internet. While we do significant in-house research and engineering to protect users’ data, we maintain strong ties with academic institutions worldwide. We provide seed funding through faculty research grants, cloud credits to unlock new experiments, and foster active collaborations, including working with visiting scholars and research interns.

To accelerate the next generation of security and privacy breakthroughs, we recently created the Google Security and Privacy Research Awards program. These awards, selected via internal Google nominations and voting, recognize academic researchers who have made recent, significant contributions to the field.

We’ve been developing this program for several years. It began as a pilot when we awarded researchers for their work in 2016, and we expanded it more broadly for work from 2017. So far, we awarded $1 million dollars to 12 scholars. We are preparing the shortlist for 2018 nominees and will announce the winners next year. In the meantime, we wanted to highlight the previous award winners and the influence they’ve had on the field.
2017 Awardees

Lujo Bauer, Carnegie Mellon University
Research area: Password security and attacks against facial recognition

Dan Boneh, Stanford University
Research area: Enclave security and post-quantum cryptography

Aleksandra Korolova, University of Southern California
Research area: Differential privacy

Daniela Oliveira, University of Florida
Research area: Social engineering and phishing

Franziska Roesner, University of Washington
Research area: Usable security for augmented reality and at-risk populations

Matthew Smith, Universität Bonn
Research area: Usable security for developers


2016 Awardees

Michael Bailey, University of Illinois at Urbana-Champaign
Research area: Cloud and network security

Nicolas Christin, Carnegie Mellon University
Research area: Authentication and cybercrime

Damon McCoy, New York University
Research area: DDoS services and cybercrime

Stefan Savage, University of California San Diego
Research area: Network security and cybercrime

Marc Stevens, Centrum Wiskunde & Informatica
Research area: Cryptanalysis and lattice cryptography

Giovanni Vigna, University of California Santa Barbara
Research area: Malware detection and cybercrime


Congratulations to all of our award winners.

Will cybersecurity safety ever equal air travel safety?

Aviation safety provides an aspirational model of a safety success story when you consider that over the past 50 years, even as total passenger miles have exploded, commercial airline fatalities have plummeted.

The commercial aviation industry has an admirable safety record, but can the lessons learned over the past decades in that industry be extended to improve the state of cybersecurity safety? When it comes to the ongoing discussion about issues related to cybersecurity safety, some of the most respected names in the business have been making an important case that we need to do much better.

The improvements in aviation safety are inarguably worth it: as the number of passengers carried annually has increased by an order of magnitude, the average number of fatal airline accidents has plummeted: flying is now anywhere from 100 to 1,000 times safer than driving, depending on the evaluation criteria used.

Former Facebook CISO Alex Stamos tweeted in October: “It would be great to move InfoSec norms closer to aviation safety, where close-calls are disclosed in a standard, centralized manner and discussed rationally by experts who extract lessons from the mistakes of others,” adding “we currently don’t live in that world.”

In the world we inhabit, cybersecurity safety seems to be modeled more on automotive safety than aviation safety, and that’s the problem.

The U.S. National Highway Traffic Safety Administration reported that 37,461 died in traffic accidents in 2016; the same year, the Aviation Safety Network reported that 258 people died in commercial airline accidents. Unlike drivers, pilots must undergo extensive and ongoing training, must perform extensive system checks on their aircraft before leaving the hangar, and are held accountable for any incident that occurs while the aircraft is under their control.

Clearly, cybersecurity safety has a long way to go, still. As Kevin Beaumont, the U.K.-based security researcher, pointed out in November: “Usually it’s us, the IT bods, being idiots for building a system so fragile one employee can bring down by clicking the ‘wrong’ link. Imagine if planes were built so the passenger could bring down a plane by pressing a button at their seat.”

Under the current model, cybersecurity safety depends on the expectation that billions of end users will be knowledgeable about cyber threats and how to defend against them as well as being aware of the need for antimalware software and patching and staying up to date on security practices and generally taking the initiative to maintain cybersecurity hygiene while also reporting any cyber incidents.

Put another way, every connected device is covered with buttons, any one of which, if pressed at the wrong moment, could “bring down” not just that device, but any number of other connected devices.

Cybersecurity safety is still up in the air, so to speak, for many reasons starting with a lack of sensible regulations and agencies to investigate, share and learn from failures. But disastrous cybersecurity safety failures aren’t seen as harming the whole industry. Consider what Mikko Hypponen, chief research officer at F-Secure, tweeted this week about one magnificent, ongoing failure of security: “I can’t believe that we are *still* fighting Office macro malware now, 20 years later.”

Airlines have a vested interest in keeping air travel safe because if passengers fear for their lives many of them will stop paying to fly. Even if they don’t particularly want to be regulated, those airlines will still accept government safety regulation because safer skies means less losses from crashed planes as well as more passengers willing to pay to ride on safer planes.

The tech sector needs to step up and accept responsibility for cybersecurity safety in the same way the aviation industry did for air travel safety, and that will only begin when vendors are held to higher standards; when vendors, enterprises and government agencies can agree to investigate cyber incidents and focus on cooperation in using that information to improve cybersecurity safety; and when consumers and all end-users can be confident that they can use their devices and the internet safely — and without being victim-blamed when things do, inevitably, go wrong.

The post Will cybersecurity safety ever equal air travel safety? appeared first on Security Bytes.

Obfuscated Command Line Detection Using Machine Learning

This blog post presents a machine learning (ML) approach to solving an emerging security problem: detecting obfuscated Windows command line invocations on endpoints. We start out with an introduction to this relatively new threat capability, and then discuss how such problems have traditionally been handled. We then describe a machine learning approach to solving this problem and point out how ML vastly simplifies development and maintenance of a robust obfuscation detector. Finally, we present the results obtained using two different ML techniques and compare the benefits of each.

Introduction

Malicious actors are increasingly “living off the land,” using built-in utilities such as PowerShell and the Windows Command Processor (cmd.exe) as part of their infection workflow in an effort to minimize the chance of detection and bypass whitelisting defense strategies. The release of new obfuscation tools makes detection of these threats even more difficult by adding a layer of indirection between the visible syntax and the final behavior of the command. For example, Invoke-Obfuscation and Invoke-DOSfuscation are two recently released tools that automate the obfuscation of Powershell and Windows command lines respectively.

The traditional pattern matching and rule-based approaches for detecting obfuscation are difficult to develop and generalize, and can pose a huge maintenance headache for defenders. We will show how using ML techniques can address this problem.

Detecting obfuscated command lines is a very useful technique because it allows defenders to reduce the data they must review by providing a strong filter for possibly malicious activity. While there are some examples of “legitimate” obfuscation in the wild, in the overwhelming majority of cases, the presence of obfuscation generally serves as a signal for malicious intent.

Background

There has been a long history of obfuscation being employed to hide the presence of malware, ranging from encryption of malicious payloads (starting with the Cascade virus) and obfuscation of strings, to JavaScript obfuscation. The purpose of obfuscation is two-fold:

  • Make it harder to find patterns in executable code, strings or scripts that can easily be detected by defensive software.
  • Make it harder for reverse engineers and analysts to decipher and fully understand what the malware is doing.

In that sense, command line obfuscation is not a new problem – it is just that the target of obfuscation (the Windows Command Processor) is relatively new. The recent release of tools such as Invoke-Obfuscation (for PowerShell) and Invoke-DOSfuscation (for cmd.exe) have demonstrated just how flexible these commands are, and how even incredibly complex obfuscation will still run commands effectively.

There are two categorical axes in the space of obfuscated vs. non-obfuscated command lines: simple/complex and clear/obfuscated (see Figure 1 and Figure 2). For this discussion “simple” means generally short and relatively uncomplicated, but can still contain obfuscation, while “complex” means long, complicated strings that may or may not be obfuscated. Thus, the simple/complex axis is orthogonal to obfuscated/unobfuscated. The interplay of these two axes produce many boundary cases where simple heuristics to detect if a script is obfuscated (e.g. length of a command) will produce false positives on unobfuscated samples. The flexibility of the command line processor makes classification a difficult task from an ML perspective.


Figure 1: Dimensions of obfuscation


Figure 2: Examples of weak and strong obfuscation

Traditional Obfuscation Detection

Traditional obfuscation detection can be split into three approaches. One approach is to write a large number of complex regular expressions to match the most commonly abused syntax of the Windows command line. Figure 3 shows one such regular expression that attempts to match ampersand chaining with a call command, a common pattern seen in obfuscation. Figure 4 shows an example command sequence this regex is designed to detect.


Figure 3: A common obfuscation pattern captured as a regular expression


Figure 4: A common obfuscation pattern (calling echo in obfuscated fashion in this example)

There are two problems with this approach. First, it is virtually impossible to develop regular expressions to cover every possible abuse of the command line. The flexibility of the command line results in a non-regular language, which is feasible yet impractical to express using regular expressions. A second issue with this approach is that even if a regular expression exists for the technique a malicious sample is using, a determined attacker can make minor modifications to avoid the regular expression. Figure 5 shows a minor modification to the sequence in Figure 4, which avoids the regex detection.


Figure 5: A minor change (extra carets) to an obfuscated command line that breaks the regular expression in Figure 3

The second approach, which is closer to an ML approach, involves writing complex if-then rules. However, these rules are hard to derive, are complex to verify, and pose a significant maintenance burden as authors evolve to escape detection by such rules. Figure 6 shows one such if-then rule.


Figure 6: An if-then rule that *may* indicate obfuscation (notice how loose this rule is, and how false positives are likely)

A third approach is to combine regular expressions and if-then rules. This greatly complicates the development and maintenance burden, and still suffers from the same weaknesses that make the first two approaches fragile. Figure 7 shows an example of an if-then rule with regular expressions. Clearly, it is easy to appreciate how burdensome it is to generate, test, maintain and determine the efficacy of such rules.


Figure 7: A combination of an if-then rule with regular expressions to detect obfuscation (a real hand-built obfuscation detector would consist of tens or hundreds of rules and still have gaps in its detection)

The ML Approach – Moving Beyond Pattern Matching and Rules

Using ML simplifies the solution to these problems. We will illustrate two ML approaches: a feature-based approach and a feature-less end-to-end approach.

There are some ML techniques that can work with any kind of raw data (provided it is numeric), and neural networks are a prime example. Most other ML algorithms require the modeler to extract pertinent information, called features, from raw data before they are fed into the algorithm. Some examples of this latter type are tree-based algorithms, which we will also look at in this blog (we described the structure and uses of Tree-Based algorithms in a previous blog post, where we used a Gradient-Boosted Tree-Based Model).

ML Basics – Neural Networks

Neural networks are a type of ML algorithm that have recently become very popular and consist of a series of elements called neurons. A neuron is essentially an element that takes a set of inputs, computes a weighted sum of these inputs, and then feeds the sum into a non-linear function. It has been shown that a relatively shallow network of neurons can approximate any continuous mapping between input and output. The specific type of neural network we used for this research is what is called a Convolutional Neural Network (CNN), which was developed primarily for computer vision applications, but has also found success in other domains including natural language processing. One of the main benefits of a neural network is that it can be trained without having to manually engineer features.

Featureless ML

While neural networks can be used with feature data, one of the attractions of this approach is that it can work with raw data (converted into numeric form) without doing any feature design or extraction. The first step in the model is converting text data into numeric form. We used a character-based encoding where each character type was encoded by a real valued number. The value was automatically derived during training and conveys semantic information about the relationships between characters as they apply to cmd.exe syntax.

Feature-Based ML

We also experimented with hand-engineered features and a Gradient Boosted Decision Tree algorithm. The features developed for this model were largely statistical in nature – derived from the presence and frequency of character sets and keywords. For example, the presence of dozens of ‘%’ characters or long, contiguous strings might contribute to detecting potential obfuscation. While any single feature will not perfectly separate the two classes, a combination of features as present in a tree-based model can learn flexible patterns in the data. The expectation is that those patterns are robust and can generalize to future obfuscation variants.

Data and Experiments

To develop our models, we collected non-obfuscated data from tens of thousands of endpoint events and generated obfuscated data using a variety of methods in Invoke-DOSfuscation. We developed our models using roughly 80 percent of the data as training data, and tested them on the remaining 20 percent. We ensured that our train-test split was stratified. For featureless ML (i.e. neural networks), we simply input Unicode code points into the first layer of the CNN model. The first layer converts the code point into semantically meaningful numerical representations (called embeddings) before feeding it into the rest of the neural network.

For the Gradient Boosted Tree method, we generated a number of features from the raw command lines. The following are some of them:

  • Length of the command line
  • The number of carets in the command line
  • The count of pipe symbols
  • The fraction of white space in the command line
  • The fraction of special characters
  • Entropy of the string
  • The frequency of the strings “cmd” and “power” in the command line

While each of these features individually is a weak signal and could not possibly be a good discriminator on its own, a flexible classifier such as a Gradient Boosted Tree – trained on sufficient data with these features – is able to classify obfuscated and non-obfuscated command lines in spite of the aforementioned difficulties.

Results

Evaluated against our test set, we were able to get nearly identical results from our Gradient Boosted Tree and neural network models.

The results for the GBT model were near perfect with metrics such as F1-score, precision, and recall all being close to 1.0. The CNN model was slightly less accurate.

While we certainly do not expect perfect results in a real-world scenario, these lab results were nonetheless encouraging. Recall that all of our obfuscated examples were generated by one source, namely the Invoke-DOSfuscation tool. While Invoke-DOSfuscation generates a wide variety of obfuscated samples, in the real world we expect to see at least some samples that are quite dissimilar from any that Invoke-DOSfuscation generates. We are currently collecting real world obfuscated command lines to get a more accurate picture of the generalizability of this model on obfuscated samples from actual malicious actors. We expect that command obfuscation, similar to PowerShell obfuscation before it, will continue to emerge in new malware families.

As an additional test we asked Daniel Bohannon (author of Invoke-DOSfuscation, the Windows command line obfuscation tool) to come up with obfuscated samples that in his experience would be difficult for a traditional obfuscation detector. In every case, our ML detector was still able to detect obfuscation. Some examples are shown in Figure 8.


Figure 8: Some examples of obfuscated text used to test and attempt to defeat the ML obfuscation detector (all were correctly identified as obfuscated text)

We also created very cryptic looking texts that, although valid Windows command lines and non-obfuscated, appear slightly obfuscated to a human observer. This was done to test efficacy of the detector with boundary examples. The detector was correctly able to classify the text as non-obfuscated in this case as well. Figure 9 shows one such example.


Figure 9: An example that appears on first glance to be obfuscated, but isn't really and would likely fool a non-ML solution (however, the ML obfuscation detector currently identifies it as non-obfuscated)

Finally, Figure 10 shows a complicated yet non-obfuscated command line that is correctly classified by our obfuscation detector, but would likely fool a non-ML detector based on statistical features (for example a rule-based detector with a hand-crafted weighing scheme and a threshold, using features such as the proportion of special characters, length of the command line or entropy of the command line).


Figure 10: An example that would likely be misclassified by an ML detector that uses simplistic statistical features; however, our ML obfuscation detector currently identifies it as non-obfuscated

CNN vs. GBT Results

We compared the results of a heavily tuned GBT classifier built using carefully selected features to those of a CNN trained with raw data (featureless ML). While the CNN architecture was not heavily tuned, it is interesting to note that with samples such as those in Figure 10, the GBT classifier confidently predicted non-obfuscated with a score of 19.7 percent (the complement of the measure of the classifier’s confidence in non-obfuscation). Meanwhile, the CNN classifier predicted non-obfuscated with a confidence probability of 50 percent – right at the boundary between obfuscated and non-obfuscated. The number of misclassifications of the CNN model was also more than that of the Gradient Boosted Tree model. Both of these are most likely the result of inadequate tuning of the CNN, and not a fundamental shortcoming of the featureless approach.

Conclusion

In this blog post we described an ML approach to detecting obfuscated Windows command lines, which can be used as a signal to help identify malicious command line usage. Using ML techniques, we demonstrated a highly accurate mechanism for detecting such command lines without resorting to the often inadequate and costly technique of maintaining complex if-then rules and regular expressions. The more comprehensive ML approach is flexible enough to catch new variations in obfuscation, and when gaps are detected, it can usually be handled by adding some well-chosen evader samples to the training set and retraining the model.

This successful application of ML is yet another demonstration of the usefulness of ML in replacing complex manual or programmatic approaches to problems in computer security. In the years to come, we anticipate ML to take an increasingly important role both at FireEye and in the rest of the cyber security industry.

The Best Security Podcasts in 2018 [Updated]

Whether you’re in vacation or you have a few days off, you can also relax and learn something new. Podcasts are one of the best ways to be informed and entertained, so we compiled below a list of the best cybersecurity podcasts we’ve listened to so far.

From the latest cybersecurity news to the best privacy tips, we tried to cover all areas but feel free to drop a comment and share some recommendations!


The best #cybersecurity #podcasts for this year. Learn something new!
Click To Tweet


1.Cyberwire Daily

cyberwire daily security podcasts

Want to start your day listening to the infosecurity news? The Cyberwire Daily podcast is probably your best option. This podcast already has over 600 episodes and Cyberwire also posts other insightful podcasts on longer topics.

We particularly loved the first episode of Hacking Humans and hope to hear more content there.

 

2.Risky Business

risky biz security podcasts

The Risky Biz podcast is one of the best resources for those working in information security but it’s also great for beginners or just curious onlookers, as it’s only once a week and up to an hour in length. The Risky Business podcasts cover cybersecurity news but also feature interviews with industry experts. If you don’t work in the industry, we’d recommend checking out their more political stuff, it reveals amazing insights into hacking (not as shown in Hollywood but just as much of a wild ride). The latest episode covers China’s hacker scene. Do also check out earlier episodes like North Korea, “cyber norms” and diplomacy, Kaspersky is officially toast or Actually yes, “cyber war” is real for Ukraine.

 

3. Complete privacy and security podcast

The Cambridge Analytica scandal revealed just how much the info you share on social media can be used for nefarious purposes, so investing in your online privacy is something all of us should do more of.

The Complete Privacy and Security podcast by Michael Bazzel really explains how to become digitally invisible. While the techniques discussed will take up a huge chunk of time to implement, some of them are essential if you value your own privacy. We particularly liked the episodes on New to Privacy, The Consequences of Leaving Facebook (we also wrote about how to control your Facebook privacy here) and A Conversation with the EFF.

 

4. Daily Information Security Podcast – Stormcast

isc.sans.edu_images_stormcast security podcast

While podcasts can be endlessly entertaining, it’s sometimes hard to find the focus to dedicate 30 minutes or a full hour in order to listen to one.

If you want to keep up with cyber security news and trends, the Stormcast from the Internet Storm Center is the best choice.

Security podcasts in that series are under 10 minutes, so they can be fit in any busy schedule.

5. Troy Hunt’s Weekly Update Podcast

For a weekly roundup, Troy Hunt’s podcast is always an entertaining listen. From cyber security news to recaps of all the major events from around the world, Troy covers mostly everything that’s happening in the infosec industry. Creator of Have I been pwned? and author of security courses on Pluralsight, Troy is definitely one of the best security influencers to follow – he just won the prize for the Best Overall Security Blog at the European Security Blogger Awards.

In no particular order, we bookmarked these episodes:

Weekly Update 63 with a US Congress testimony, Weekly Update 68 with a visit to Cloudflare headquarters and  Weekly Update 82 where he explains how password extortion is the latest online scam to avoid.

6. Unsupervised Learning Podcast

unsupervised learning cybersecurity podcast

Daniel Miessler is a legend in infosec circles, having covered technology and security for more than two decades. His blog is also a treat but the weekly podcast is a more pleasant way to digest current events.

We recommend giving a listen to episode 127 for the wrap-up on how Alexa leaked a private conversation, episode 119 for how Atlanta got hit with a devastating ransomware attack and and episode 113 which covers Android cryptojacking and the Huawei ban in the US.

7. Darknet Diaries

If you’re heading to the beach or planning a longer vacation, the Darknet Diaries security podcast can successfully replace the thriller book you’re planning to pack. While it only has 17 episodes so far, all of them cover the most exciting and twisted cyber security breaches and risks.

From the epic hack of Mt. Gox that resulted in 850,000 bitcoins being stolen or the Carna Botnet that did not have a malicious purpose, Darknet Diaries is always an entertaining listen.

We also recommend the Misadventures of a Nation State Actor, which really delves into the world of advanced, government-backed hacking.

8. 7 Minute Security

As the name indicates, this is a bite-sized podcast focused on learning more about infosecurity. It’s not quite 7 minutes long, but it’s an under 20 minute listen from Brian Johnson, a security consultant with a penetration testing background who does an amazing job of sharing what he learns about the field. The most fun listen is probably The CryptoLocker Song, where he goes into detail about a ransomware infection taking hold of an organization, followed by the PwnPro 101 for those who would like to improve their penetration testing skills.

We also recommend the GDPR Me ASAP episode for a fun, sing-song summary of the privacy regulation that resulted in you receiving a lot of emails.

9. The Social-Engineer Podcast

social engineer security podcast

When it comes to cybersecurity for beginners, one of the most entertaining fields is definitely social engineering or using psychological tricks and manipulation to gain access to an organization’s data. The Social-Engineer podcast is the best security podcast if this is something you want to find out more about, featuring plenty of fascinating interviews.

We recommend the interview with Jayson Street, who talks about how Diet Pepsi almost landed him in a Lebanese prison, or the Tim Larkin one that explains why situational awareness is extremely important for your safety.

10. Paul’s Security Weekly

A great weekend listen is Paul’s Security Weekly where Paul Asadoorian and other security experts gather around the table to discuss the headlines or interview various guests. While most other podcasts can be a great listen even if you don’t work in the infosecurity field, this one is aimed at professionals and can sometimes be a bit too “technical” for the layperson.

We recommend this episode about CIA’s Vault 7 leak and the one about Alexa spying on users.

11. Silver Bullet Security Podcast

Published by Synopsys once a month, the Silver Bullet Security Podcast hosted by Dr. Gary McGraw, a great author, is one of the most in-depth security podcasts we’ve found so far.

The May episode focuses on topics like the famous Spectre vulnerability and the rise of cryptocurrencies but we also recommend the Anonymity and Internet Privacy discussion – you might pick up a few more valuable tips on enhancing your own security setup.

12. Future Out Loud Podcast

future out loud cybersecurity podcast

Produced by IEE SSIT (Society on social implications of technology), the Future Out Loud Podcasts don’t always focus on cyber security but they always manage to pick a tangential (and fascinating!) topic.

One of the best episodes is definitely the Should We Trust Robots? discussion between cybersecurity expert Benjamin Turnbull and philosopher-ethicist Jai Galliott. Do make sure you also check out the WikiCyberLeaks episode, it contains a great discussion about how the CIA was hacking consumer devices to spy on US citizens.

13. The Human Factor

Another fascinating podcast on social engineering is The Human Factor by Jenny Radcliffe, also known as “The People Hacker.”

When she’s not delivering amazing keynotes at TEDx, Trend Micro or Infosec, she’s interviewing award-winning specialists in cybersecurity – and doing all this with a charming British accent. We highly recommend listening to her Kay Roer interview and the Holly Graceful episode, which explains more about the world of pentesting.

14. The Security Ledger

In general, The Security Ledger is a great infosecurity publication and their podcast is just as good. Covering everything from politics to hot topics like the standards of IoT security, this podcast is a weekly offering that’s always a great listen. We recommend episode 100 for an interview with Estonia’s former CIO about electronic voting, episode 91 about the epidemic of fake news and the treat of cryptojacking, and episode 88 for a fascinating look at how cyber criminals launder money after pulling off an online scam (we wrote about the most common scams here).

15. Source Code Podcast

source code security podcast

This security podcast is one of the newest on the list, so it doesn’t have a lot of episodes. The Source Code Podcast was started in 2017 by Chris Sanders, a trainer who created a great free online course for those who want to start working in information security.

What we like most about this podcast is the fact that it avoids news and focuses on security experts – how they started their journey in the field and what their daily challenges are. Many of you wrote to us to ask how to start a cyber security career, so we recommend listening to a few of these episodes to find the path that seems best for you. Episode 6 from season with Jennifer Kolde, who worked as an investigator for Mandiant/FireEye, is a great listen, as well as the fifth episode from season 1, which is a great interview with Gerald Combs, the original developer of Wireshark.

16. Smashing Security

cybersecurity podcast to listen to

Another cybersecurity podcast that should be on your list is the one hosted by one of the most known cybersecurity professionals and an award-winning security blogger, Graham Cluley. Featuring more than 100 episodes, all of them cover the most exciting and current cyber security issues, delving deep into topics such as password security, phising scams, sextorsion and many more. Each episode includes lots of useful resources and links which might help. We suggest listening to episode 104 in which you’ll discover phishing campaigns tests for employees and other useful examples.

This summer, the podcast also won the first prize at the “Best Security Podcast” category, during the European Security Blogger Awards announced at Infosec Europe, in London.

17. Security Now

a must-listened security podcast

Whether you work in cyber security for a few months or you are a veteran in the industry, you’ve probably heard about Steve Gibson , the man “who coined the term spyware and created the first anti-spyware program”. He’s also the host of a weekly infosec podcast called “Security Now” that we suggest to check out. The other host is Leo Laporte, and together they discuss hot topics in cyber security, focusing on practical examples and providing actionable advice on how to stay safe online. You can find here a list of all episodes available.

These are just a few security podcasts to enhance your knowledge during the more relaxing summer weeks. If you have any resources to add, including YouTube channels, do let us know, we’ll be happy to update the list.

The post The Best Security Podcasts in 2018 [Updated] appeared first on Heimdal Security Blog.

Kangaroo Motion Sensor review: This home security system only goes halfway

Motion sensors are an essential component of any home security system. But in Kangaroo’s current ecosystem, motion sensors are the only component.

On the upside, that means you don’t need a central hub, because the sensors connect directly to your Wi-Fi network. What’s more, a single motion sensor can cover an entire room, saving you from the expense of installing door/window sensors on every door and window leading into the room. On the downside, you won’t be notified of intruders in your home until they’re already in your home. And you get no protection at all when you’re at home.

You’ll need to install an app on your smartphone (Android and iOS are supported) to receive messages from the sensors, and you can invite third parties—such as a neighbor—to help you monitor your home by typing their mobile phone numbers into the app. Kangaroo will send them an invitation, and they will also need to install the app (you should of course ask them if they’re willing to do this for you ahead of time).

To read this article in full, please click here

McAfee Labs 2019 Threats Predictions Report

These predictions were written by Eoin Carroll, Taylor Dunton, John Fokker, German Lancioni, Lee Munson, Yukihiro Okutomi, Thomas Roccia, Raj Samani, Sekhar Sarukkai, Dan Sommer, and Carl Woodward.

As 2018 draws to a close, we should perhaps be grateful that the year has not been entirely dominated by ransomware, although the rise of the GandCrab and SamSam variants show that the threat remains active. Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

We have witnessed greater collaboration among cybercriminals exploiting the underground market, which has allowed them to develop efficiencies in their products. Cybercriminals have been partnering in this way for years; in 2019 this market economy will only expand. The game of cat and mouse the security industry plays with ransomware developers will escalate, and the industry will need to respond more quickly and effectively than ever before.

Social media has been a part of our lives for more than a decade. Recently, nation-states have infamously used social media platforms to spread misinformation. In 2019, we expect criminals to begin leveraging those tactics for their own gain. Equally, the continued growth of the Internet of Things in the home will inspire criminals to target those devices for monetary gain.

One thing is certain: Our dependency on technology has become ubiquitous. Consider the breaches of identity platforms, with reports of 50 million users being affected. It is no longer the case that a breach is limited to that platform. Everything is connected, and you are only as strong as your weakest link. In the future, we face the question of which of our weakest links will be compromised.

—Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research

Twitter @Raj_Samani

 

Predictions

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Artificial Intelligence the Future of Evasion Techniques

Synergistic Threats Will Multiply, Requiring Combined Responses

Misinformation, Extortion Attempts to Challenge Organizations’ Brands

Data Exfiltration Attacks to Target the Cloud

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Hidden hacker forums and chat groups serve as a market for cybercriminals, who can buy malware, exploits, botnets, and other shady services. With these off-the-shelf products, criminals of varying experience and sophistication can easily launch attacks. In 2019, we predict the underground will consolidate, creating fewer but stronger malware-as-a-service families that will actively work together. These increasingly powerful brands will drive more sophisticated cryptocurrency mining, rapid exploitation of new vulnerabilities, and increases in mobile malware and stolen credit cards and credentials.

We expect more affiliates to join the biggest families, due to the ease of operation and strategic alliances with other essential top-level services, including exploit kits, crypter services, Bitcoin mixers, and counter-antimalware services. Two years ago, we saw many of the largest ransomware families, for example, employ affiliate structures. We still see numerous types of ransomware pop up, but only a few survive because most cannot attract enough business to compete with the strong brands, which offer higher infection rates as well as operational and financial security. At the moment the largest families actively advertise their goods; business is flourishing because they are strong brands (see GandCrab) allied with other top-level services, such as money laundering or making malware undetectable.

Underground businesses function successfully because they are part of a trust-based system. This may not be a case of “honor among thieves,” yet criminals appear to feel safe, trusting they cannot be touched in the inner circle of their forums. We have seen this trust in the past, for example, with the popular credit card shops in the first decade of the century, which were a leading source of cybercrime until major police action broke the trust model.

As endpoint detection grows stronger, the vulnerable remote desktop protocol (RDP) offers another path for cybercriminals. In 2019 we predict malware, specifically ransomware, will increasingly use RDP as an entry point for an infection. Currently, most underground shops advertise RDP access for purposes other than ransomware, typically using it as a stepping stone to gain access to Amazon accounts or as a proxy to steal credit cards. Targeted ransomware groups and ransomware-as-a-service (RaaS) models will take advantage of RDP, and we have seen highly successful under-the-radar schemes use this tactic. Attackers find a system with weak RDP, attack it with ransomware, and propagate through networks either living off the land or using worm functionality (EternalBlue). There is evidence that the author of GandCrab is already working on an RDP option.

We also expect malware related to cryptocurrency mining will become more sophisticated, selecting which currency to mine on a victim’s machine based on the processing hardware (WebCobra) and the value of a specific currency at a given time.

Next year, we predict the length of a vulnerability’s life, from detection to weaponization, will grow even shorter. We have noticed a trend of cybercriminals becoming more agile in their development process. They gather data on flaws from online forums and the Common Vulnerabilities and Exposures database to add to their malware. We predict that criminals will sometimes take a day or only hours to implement attacks against the latest weaknesses in software and hardware.

We expect to see an increase in underground discussions on mobile malware, mostly focused on Android, regarding botnets, banking fraud, ransomware, and bypassing two-factor authentication security. The value of exploiting the mobile platform is currently underestimated as phones offer a lot to cybercriminals given the amount of access they have to sensitive information such as bank accounts.

Credit card fraud and the demand for stolen credit card details will continue, with an increased focus on online skimming operations that target third-party payment platforms on large e-commerce sites. From these sites, criminals can silently steal thousands of fresh credit cards details at a time. Furthermore, social media is being used to recruit unwitting users, who might not know they are working for criminals when they reship goods or provide financial services.

We predict an increase in the market for stolen credentials—fueled by recent large data breaches and by bad password habits of users. The breaches lead, for example, to the sale of voter records and email-account hacking. These attacks occur daily.

Artificial Intelligence the Future of Evasion Techniques

To increase their chances of success, attackers have long employed evasion techniques to bypass security measures and avoid detection and analysis. Packers, crypters, and other tools are common components of attackers’ arsenals. In fact, an entire underground economy has emerged, offering products and dedicated services to aid criminal activities. We predict in 2019, due to the ease with which criminals can now outsource key components of their attacks, evasion techniques will become more agile due to the application of artificial intelligence. Think the counter-AV industry is pervasive now? This is just the beginning.

In 2018 we saw new process-injection techniques such as “process doppelgänging” with the SynAck ransomware, and PROPagate injection delivered by the RigExploit Kit. By adding technologies such as artificial intelligence, evasion techniques will be able to further circumvent protections.

Different evasions for different malware

In 2018, we observed the emergence of new threats such as cryptocurrency miners, which hijack the resources of infected machines. With each threat comes inventive evasion techniques:

  • Cryptocurrency mining: Miners implement a number of evasion techniques. Minerva Labs discovered WaterMiner, which simply stops its mining process when the victim runs the Task Manager or an antimalware scan.
  • Exploit kits: Popular evasion techniques include process injection or the manipulation of memory space and adding arbitrary code. In-memory injection is a popular infection vector for avoiding detection during delivery.
  • Botnets: Code obfuscation or anti-disassembling techniques are often used by large botnets that infect thousands of victims. In May 2018, AdvisorsBot was discovered using junk code, fake conditional instructions, XOR encryption, and even API hashing. Because bots tend to spread widely, the authors implemented many evasion techniques to slow reverse engineering. They also used obfuscation mechanisms for communications between the bots and control servers. Criminals use botnets for activities such as DDOS for hire, proxies, spam, or other malware delivery. Using evasion techniques is critical for criminals to avoid or delay botnet takedowns.
  • Advanced persistent threats: Stolen certificates bought on the cybercriminal underground are often used in targeted attacks to bypass antimalware detection. Attackers also use low-level malware such as rootkits or firmware-based threats. For example, in 2018 ESET discovered the first UEFI rootkit, LoJax. Security researchers have also seen destructive features used as anti-forensic techniques: The OlympicDestroyer malware targeted the Olympic Games organization and erased event logs and backups to avoid investigation.

Artificial intelligence the next weapon

In recent years, we have seen malware using evasion techniques to bypass machine learning engines. For example, in 2017 the Cerber ransomware dropped legitimate files on systems to trick the engine that classifies files. In 2018, PyLocky ransomware used InnoSetup to package the malware and avoid machine learning detection.

Clearly, bypassing artificial intelligence engines is already on the criminal to-do list; however, criminals can also implement artificial intelligence in their malicious software. We expect evasion techniques to begin leveraging artificial intelligence to automate target selection, or to check infected environments before deploying later stages and avoiding detection.

Such implementation is game changing in the threat landscape. We predict it will soon be found in the wild.

Synergistic Threats Will Multiply, Requiring Combined Responses

This year we have seen cyber threats adapt and pivot faster than ever. We have seen ransomware evolving to be more effective or operate as a smoke screen. We have seen cryptojacking soar, as it provides a better, and safer, return on investment than ransomware. We can still see phishing going strong and finding new vulnerabilities to exploit. We also noticed fileless and “living off the land” threats are more slippery and evasive than ever, and we have even seen the incubation of steganography malware in the Pyeongchang Olympics campaign. In 2019, we predict attackers will more frequently combine these tactics to create multifaced, or synergistic, threats.

What could be worse?

Attacks are usually centered on the use of one threat. Bad actors concentrate their efforts on iterating and evolving one threat at a time for effectiveness and evasion. When an attack is successful, it is classified as ransomware, cryptojacking, data exfiltration, etc., and defenses are put in place. At this point, the attack’s success rate is significantly reduced. However, if a sophisticated attack involves not one but five top-notch threats synergistically working together, the defense panorama could become very blurry. The challenge arises when an attempt is made to identify and mitigate the attack. Because the ultimate attack goals are unknown, one might get lost in the details of each threat as it plays a role in the chain.

One of the reasons synergic threats are becoming a reality is because bad actors are improving their skills by developing foundations, kits, and reusable threat components. As attackers organize their efforts into a black-market business model, they can focus on adding value to previous building blocks. This strategy allows them to orchestrate multiple threats instead of just one to reach their goals.

An example is worth a thousand words

Imagine an attack that starts with a phishing threat—not a typical campaign using Word documents, but a novel technique. This phishing email contains a video attachment. When you open the video, your video player does not play and prompts you to update the codec. Once you run the update, a steganographic polyglot file (a simple GIF) is deployed on your system. Because it is a polyglot (a file that conforms to more than one format at the same time), the GIF file schedules a task that fetches a fileless script hosted on a compromised system. That script running in memory evaluates your system and decides to run either ransomware or a cryptocurrency miner. That is a dangerous synergistic threat in action.

The attack raises many questions: What are you dealing with? Is it phishing 2.0? Is it stegware? Is it fileless and “living off the land”? Cryptojacking? Ransomware? It is everything at the same time.

This sophisticated but feasible example demonstrates that focusing on one threat may not be enough to detect or remediate an attack. When you aim to classify the attack into a single category, you might lose the big picture and thus be less effective mitigating it. Even if you stop the attack in the middle of the chain, discovering the initial and final stages is as important for protecting against future attempts.

Be curious, be creative, connect your defenses

Tackling sophisticated attacks based on synergic threats requires questioning every threat. What if this ransomware hit was part of something bigger? What if this phishing email pivots to a technique that employees are not trained for? What if we are missing the real goal of the attack?

Bearing these questions in mind will not only help capture the big picture, but also get the most of security solutions. We predict bad actors will add synergy to their attacks, but cyber defenses can also work synergistically.

Cybercriminals to Use Social Media Misinformation, Extortion Campaigns to Challenge Organizations’ Brands

The elections were influenced, fake news prevails, and our social media followers are all foreign government–controlled bots. At least that’s how the world feels sometimes. To say recent years have been troubled for social media companies would be an understatement. During this period a game of cat and mouse has ensued, as automated accounts are taken down, adversaries tactics evolve, and botnet accounts emerge looking more legitimate than ever before. In 2019, we predict an increase of misinformation and extortion campaigns via social media that will focus on brands and originate not from nation-state actors but from criminal groups.

Nation-states leverage bot battalions to deliver messages or manipulate opinion, and their effectiveness is striking. Bots often will take both sides of a story to spur debate, and this tactic works. By employing a system of amplifying nodes, as well as testing the messaging (including hashtags) to determine success rates, botnet operators demonstrate a real understanding of how to mold popular opinion on critical issues.

In one example, an account that was only two weeks old with 279 followers, most of which were other bots, began a harassment campaign against an organization. By amplification, the account generated an additional 1,500 followers in only four weeks by simply tweeting malicious content about their target.

Activities to manipulate public opinion have been well documented and bots well versed in manipulating conversations to drive agendas stand ready. Next year we expect that cybercriminals will repurpose these campaigns to extort companies by threatening to damage their brands. Organizations face a serious danger.

Data Exfiltration Attacks to Target the Cloud

In the past two years, enterprises have widely adopted the Software-as-a-Service model, such as Office 365, as well as Infrastructure- and Platform-as-a-Service cloud models, such as AWS and Azure. With this move, far more corporate data now resides in the cloud. In 2019, we expect a significant increase in attacks that follow the data to the cloud.

With the increased adoption of Office 365, we have noticed a surge of attacks on the service— especially attempts to compromise email. One threat the McAfee cloud team uncovered was the botnet KnockKnock, which targeted system accounts that typically do not have multifactor authentication. We have also seen the emergence of exploits of the trust model in the Open Authorization standard. One was launched by Fancy Bear, the Russian cyber espionage group, phishing users with a fake Google security app to gain access to user data.

Similarly, during the last couple of years we have seen many high-profile data breaches attributed to misconfigured Amazon S3 buckets. This is clearly not the fault of AWS. Based on the shared responsibility model, the customer is on the hook to properly configure IaaS/PaaS infrastructure and properly protect their enterprise data and user access. Complicating matters, many of these misconfigured buckets are owned by vendors in their supply chains, rather than by the target enterprises. With access to thousands of open buckets and credentials, bad actors are increasingly opting for these easy pickings.

McAfee has found that 21% of data in the cloud is sensitive—such as intellectual property, and customer and personal data—according to the McAfee Cloud Adoption and Risk Report. With a 33% increase in users collaborating on this data during the past year, cybercriminals know how to seek more targets:

  • Cloud-native attacks targeting weak APIs or ungoverned API endpoints to gain access to the data in SaaS as well as in PaaS and serverless workloads
  • Expanded reconnaissance and exfiltration of data in cloud databases (PaaS or custom applications deployed in IaaS) expanding the S3 exfiltration vector to structured data in databases or data lakes
  • Leveraging the cloud as a springboard for cloud-native man-in-the-middle attacks (such as GhostWriter, which exploits publicly writable S3 buckets introduced due to customer misconfigurations) to launch cryptojacking or ransomware attacks into other variants of MITM attacks.

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

As tech fans continue to fill their homes with smart gadgets, from plugs to TVs, coffee makers to refrigerators, and motion sensors to lighting, the means of gaining entry to a home network are growing rapidly, especially given how poorly secured many IoT devices remain.

But the real key to the network door next year will be the voice-controlled digital assistant, a device created in part to manage all the IoT devices within a home. As sales increase—and an explosion in adoption over the holiday season looks likely—the attraction for cybercriminals to use assistants to jump to the really interesting devices on a network will only continue to grow.

For now, the voice assistant market is still taking shape, with many brands still looking to dominate the market, in more ways than one, and it is unclear whether one device will become ubiquitous. If one does take the lead, its security features will quite rightly fall under the microscope of the media, though not perhaps before its privacy concerns have been fully examined in prose.

(Last year we highlighted privacy as the key concern for home IoT devices. Privacy will continue to be a concern, but cybercriminals will put more effort into building botnets, demanding ransoms, and threatening the destruction of property of both homes and businesses).

This opportunity to control a home’s or office’s devices will not go unnoticed by cybercriminals, who will engage in an altogether different type of writing in relation to the market winner, in the form of malicious code designed to attack not only IoT devices but also the digital assistants that are given so much license to talk to them.

Smartphones have already served as the door to a threat. In 2019, they may well become the picklock that opens a much larger door. We have already seen two threats that demonstrate what cybercriminals can do with unprotected devices, in the form of the Mirai botnet, which first struck in 2016, and IoT Reaper, in 2017. These IoT malware appeared in many variants to attack connected devices such as routers, network video recorders, and IP cameras. They expanded their reach by password cracking and exploiting known vulnerabilities to build worldwide robot networks.

Next year we expect to see two main vectors for attacking home IoT devices: routers and smartphones/ tablets. The Mirai botnet demonstrated the lack of security in routers. Infected smartphones, which can already monitor and control home devices, will become one of the top targets of cybercriminals, who will employ current and new techniques to take control.

Malware authors will take advantage of phones and tablets, those already trusted controllers, to try to take over IoT devices by password cracking and exploiting vulnerabilities. These attacks will not appear suspicious because the network traffic comes from a trusted device. The success rate of attacks will increase, and the attack routes will be difficult to identify. An infected smartphone could cause the next example of hijacking the DNS settings on a router. Vulnerabilities in mobile and cloud apps are also ripe for exploitation, with smartphones at the core of the criminals’ strategy.

Infected IoT devices will supply botnets, which can launch DDoS attacks, as well as steal personal data. The more sophisticated IoT malware will exploit voice-controlled digital assistants to hide its suspicious activities from users and home-network security software. Malicious activities such as opening doors and connecting to control servers could be triggered by user voice commands (“Play music” and “What is today’s weather?”). Soon we may hear infected IoT devices themselves exclaiming: “Assistant! Open the back door!”

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Large-scale data breaches of identity platforms—which offer centralized secure authentication and authorization of users, devices, and services across IT environments—have been well documented in 2018. Meanwhile, the captured data is being reused to cause further misery for its victims. In 2019, we expect to see large-scale social media platforms implement additional measures to protect customer information. However, as the platforms grow in numbers, we predict criminals will further focus their resources on such attractive, data-rich environments. The struggle between criminals and big-scale platforms will be the next big battleground.

Triton, malware that attacks industrial control systems (ICS), has demonstrated the capabilities of adversaries to remotely target manufacturing environments through their adjacent IT environments. Identity platform and “edge device” breaches will provide the keys to adversaries to launch future remote ICS attacks due to static password use across environments and constrained edge devices, which lack secure system requirements due to design limitations. (An edge device is any network-enabled system hardware or protocol within an IoT product.) We expect multifactor authentication and identity intelligence will become the best methods to provide security in this escalating battle. We also predict identity intelligence will complement multifactor authentication to strengthen the capabilities of identity platforms.

Identity is a fundamental component in securing IoT. In these ecosystems, devices and services must securely identify trusted devices so that they can ignore the rest. The identity model has shifted from user centric in traditional IT systems to machine centric for IoT systems. Unfortunately, due to the integration of operational technology and insecure “edge device” design, the IoT trust model is built on a weak foundation of assumed trust and perimeter-based security.

At Black Hat USA and DEF CON 2018, 30 talks discussed IoT edge device exploitation. That’s a large increase from just 19 talks on the topic in 2017. The increase in interest was primarily in relation to ICS, consumer, medical, and “smart city” verticals. (See Figure 1.) Smart edge devices, combined with high-speed connectivity, are enabling IoT ecosystems, but the rate at which they are advancing is compromising the security of these systems.

Figure 1: The number of conference sessions on the security of IoT devices has increased, matching the growing threat to poorly protected devices. 

Most IoT edge devices provide no self-defense (isolating critical functions, memory protection, firmware protection, least privileges, or security by default) so one successful exploit owns the device. IoT edge devices also suffer from “break once, run everywhere” attacks—due to insecure components used across many device types and verticals. (See articles on WingOS and reverse engineering.)

McAfee Advanced Threat Research team engineers have demonstrated how medical device protocols can be exploited to endanger human life and compromise patients’ privacy due to assumed trust. These examples illustrate just a few of many possible scenarios that lead us to believe adversaries will choose IoT edge devices as the path of least resistance to achieve their objectives. Servers have been hardened over the last decade, but IoT hardware is far behind. By understanding an adversary’s motives and opportunities (attack surface and access capability), we can define a set of security requirements independent of a specific attack vector.

Figure 2 gives a breakdown of the types of vulnerabilities in IoT edge devices, highlighting weak points to address by building identity and integrity capabilities into edge hardware to ensure these devices can deflect attacks.

Figure 2: Insecure protocols are the primary attack surface in IoT edge devices.

IoT security must begin on the edge with a zero-trust model and provide a hardware root of trust as the core building block for protecting against hack and shack attacks and other threats. McAfee predicts an increase in compromises on identity platforms and IoT edge devices in 2019 due to the adoption of smart cities and increased ICS activity.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

HideIPVPN review: Great if you need a speedy connection via Germany

HideIPVPN in brief:

  • P2P allowed: Yes, on select servers
  • Business location: USA and Moldova
  • Number of servers: 29
  • Number of country locations: 11
  • Cost: $70 (billed annually)
  • VPN protocol: OpenVPN
  • Data encryption: AES-256
  • Data authentication: SHA 256
  • Handshake encryption: RSA 2048

Editor’s Note: This review was updated on November 7, 2018 to reflect changes to the HideIPVPN desktop app for Windows, improved speed scores, and a change to the review score.

To read this article in full, please click here

Imperva Integration With AWS Security Hub: Expanding Customer Security Visibility

This article explains how Imperva application security integrates with AWS Security Hub to give customers better visibility and feedback on the security status of their AWS hosted applications.

Securing AWS Applications

Cost reduction, simplified operations, and other benefits are driving organizations to move more and more applications onto AWS delivery platforms; because all of the infrastructure maintenance is taken care of by AWS.  As with migration to a cloud service, however, it’s important to remember that cloud vendors generally implement their services in a Shared Security Responsibility Model.  AWS explains this in a whitepaper available here.

Imperva solutions help diverse enterprise organizations maintain consistent protection across all applications in their IT domain (including AWS) by combining multiple defenses against Application Layer 3-4 and 7 Distributed Denial of Service (DDoS) attacks, OWASP top 10 application security risks, and even zero-day attacks.  Imperva application security is a top-rated solution by both Gartner and Forrester for both WAF and DDoS protection.

Visibility Leads to Better Outcomes

WAF security is further enhanced through Imperva Attack Analytics, which uses machine learning technology to correlate millions of security events across Imperva WAFs assets and group them into a small number of prioritized incidents, making security teams more effective by giving them clear and actionable insights.

AWS Security Hub is a new web service that provides a consolidated security view across AWS Services as well as 3rd party solutions.  Imperva has integrated its Attack Analytics platform with AWS Security Hub so that the security incidents Attack Analytics generates can be presented by the Security Hub Console.

Brief Description of How the Integration Works

The integration works by utilizing an interface developed for AWS Security Hub for what is essentially an “external data connector” called a Findings Provider (FP). The FP enables AWS Security Hub to ingest standardized information from Attack Analytics so that the information can be parsed, sorted and displayed. This FP is freely available to Imperva and AWS customers on Imperva’s GitHub page listed at the end of this article.

Figure 1: Screen Shot of Attack Analytics Incidents in AWS Security Hub

The way the data flows between Attack Analytics and AWS Security Hub is that Attack Analytics exports the security incidents into an AWS S3 bucket within a customer account, where the Imperva FP can make it available for upload.

Figure 2: Attack Analytics to AWS Security Hub event flow

To activate AWS Security Hub to use the Imperva FP, customers must configure several things described in the AWS Security Hub documentation. As part of the activation process, the FP running in the customer’s environment needs to acquire a product-import token from AWS Security Hub. Upon FP activation, the FP is authorized to import findings into their AWS Security Hub account in the AFF format, which will happen at configurable time intervals.

It’s critically important that organizations maintain robust application security controls as they build or migrate applications to AWS architectures.  Imperva helps organizations ensure every application instance can be protected against both known and zero-day threats, and through integration with AWS Security Hub, Imperva Attack Analytics can ensure organizations always have the most current and most accurate status of their enterprise application security posture.

 

Security Hub is initially being made available as a public preview.  We are currently looking for existing Attack Analytics customers that are interested in working with us to refine our integration. If you’re interested in working with us on this please get in touch.  Once SecurityHub becomes generally available we intend to release our Security Hub integration as an open source project on Imperva’s GitHub account.

The post Imperva Integration With AWS Security Hub: Expanding Customer Security Visibility appeared first on Blog.

US Updates Antique Safety Standards to Allow Modern Train Technology

Interesting news from Streets Blog about the change in security standards that now allows foreign train technology to the US Building trains to unusual U.S. safety standards for the small American passenger rail market made rolling stock purchases needlessly expensive. Opening the door to standardized European train specifications will significantly lower prices. Rail operators are … Continue reading US Updates Antique Safety Standards to Allow Modern Train Technology

Malcom – Malware Communication Analyzer

Malcom – Malware Communication Analyzer

Malcom is a Malware Communication Analyzer designed to analyze a system’s network communication using graphical representations of network traffic, and cross-reference them with known malware sources.

This comes handy when analyzing how certain malware species try to communicate with the outside world.

Malcom Malware Communication Analyzer Features

Malcom can help you:

  • Detect central command and control (C&C) servers
  • Understand peer-to-peer networks
  • Observe DNS fast-flux infrastructures
  • Quickly determine if a network artifact is ‘known-bad’

The aim of Malcom is to make malware analysis and intel gathering faster by providing a human-readable version of network traffic originating from a given host or network.

Read the rest of Malcom – Malware Communication Analyzer now! Only available at Darknet.

ThreatConnect’s RSA Archer Integration, Playbooks, and Apps (oh my!)

One of our top integration requests has been Playbooks for RSA Archer. Good News: we now have numerous out-of-the-box integration capabilities for connecting RSA Archer and ThreatConnect! These apps and playbooks templates allow you to perform a variety of use cases with Archer, from saving users time by automatically assigning relevant threat intelligence to cases, to instantly creating records in Archer tied to incidents in ThreatConnect.

With ThreatConnect and Archer, you can:

  • Leverage over 100 other ThreatConnect integrations to enrich information in Archer
  • Automate processes across the Archer and ThreatConnect platforms to save your team time and make them more efficient
  • Allow for easier collaboration and sharing of intelligence and information between teams and platforms

Below, you'll find an overview of the Apps and Templates available directly from ThreatConnect:

Apps

  • Get RSA Archer Record: This app retrieves an RSA Archer record. It's really important to look over the Import Archer Record Playbook if you're going to use the Get Archer Record app, as it details how to utilize the complicated Archer JSON structure within a Playbook.
  • Create RSA Archer Record: This app creates an RSA Archer record. Supported field types are Text, Numeric, Date, Values List, Attachment, IP Address, and User Lists.
  • Update RSA Archer Record:This app updates an existing RSA Archer record. Supported field types are Text, Numeric, Date, Values List, Attachment, IP Address, and User Lists.

Templates

RSA Archer | Import Archer Record

This Playbook starts with a HTTP Trigger which is intended to be triggered by an Archer advanced workflow. Once triggered, the Playbook will download and parse the Archer record based with the ID that was passed to it. From there it will create a ThreatConnect Incident and save appropriate the parsed fields in the Incident. Additionally, it will parse the Actor saved on the Archer record and either save or associated it to the Incident in ThreatConnect. Lastly, the Archer record is updated with the link back to the Incident in ThreatConnect.

https://github.com/ThreatConnect-Inc/threatconnect-playbooks/tree/master/playbooks/rsa-archer-import-record

 

RSA Archer | Create Archer Record from Incident

This Playbook starts with a User Action trigger tied to ThreatConnect Incidents. When triggered it will parse the Incident attributes and create an Archer record with relevant field.

 

https://github.com/ThreatConnect-Inc/threatconnect-playbooks/tree/master/playbooks/rsa-archer-create-record

 

Want to learn more about ThreatConnect? Join us for a quick 30-minute bi-weekly walkthrough of the ThreatConnect Platform. This is a live demo with one of our security engineers who will be happy to answer any questions about how ThreatConnect will fit into your current security program.

The post ThreatConnect's RSA Archer Integration, Playbooks, and Apps (oh my!) appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

The Spotify Phishing Scam: How to Reel in This Cyberthreat

Many music-lovers around the world use Spotify to stream all of their favorite tunes. While the music streaming platform is a convenient tool for users to download and listen to their music, hackers are capitalizing on the company’s popularity with a recent phishing campaign. The campaign lures users into giving up their account details, putting innocent Spotify customers’ credentials at risk.

So, how are the account hijackers conducting these phishing attacks? The campaign sends listeners fraudulent emails that appear to be from Spotify, prompting them to confirm their account details. However, the link contained in the email is actually a phishing link. When the user clicks on it, they are redirected to a phony Spotify website where they are prompted to enter their username and password for the hacker’s disposal.

This phishing campaign can lead to a variety of other security risks for victims exposed to the threat. For example, many users include their birthday or other personal information in their password to make it easier to remember. If a hacker gains access to a user’s Spotify password, they are given a glance into the victim’s password creation mindset, which could help them breach other accounts belonging to the user.

Fortunately, there are multiple steps users can take to avoid the Spotify phishing campaign and threats like it. Check out the following tips:

  • Create complex passwords. If a hacker gains access to a victim’s username and password, they will probably analyze these credentials to determine how the victim creates their passwords. It’s best to create passwords that don’t include personal information, such as your birthday or the name of your pet.
  • Avoid reusing passwords. If victims reuse the same password for multiple accounts, this attack could allow cybercriminals to breach additional services and platforms. To prevent hackers from accessing other accounts, create unique usernames and passwords for each online platform you use.
  • Look out for phishing red flags. If you notice that the “from” address in an email is a little sketchy or an unknown source, don’t interact with the message. And if you’re still unsure of whether the email is legitimate or not, hover your mouse over the button prompting you to click on the link (but don’t actually click on it). If the URL preview doesn’t seem to be related to the company, it is most likely a phishing email.
  • Be skeptical of emails claiming to come from legitimate companies. If you receive an email asking to confirm your login credentials, go directly to the company’s website. You should be able to check the status of your account on the company website or under the settings portion of the Spotify app to determine the legitimacy of the request.
  • Use security software to surf the web safely. Make sure you use a website reputation tool like McAfee WebAdvisor to avoid landing on phishing and malicious sites.

And, as always, to stay on top of the latest and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable?and ‘Like’ us on Facebook.

The post The Spotify Phishing Scam: How to Reel in This Cyberthreat appeared first on McAfee Blogs.

Amazon and Sophos increase visibility to applications and data security on AWS

Today, Amazon Web Services (AWS) announced the AWS Security Hub, with Sophos as a launch partner. Sophos supports this industry-wide effort to consolidate and bring focus to high-priority security alerts on AWS. We believe that visibility is the best defense against today’s threats, highlighting as early as possible any alerts and events that could represent […]

Understanding & Preventing Advanced Persistent Threats (APTs)

A guide to advanced persistent threats (APTs), a highly sophisticated, highly destructive form of cyber attack. What is an Advanced Persistent Threat (APT)? “Advanced persistent threat” is a broad term used to describe a cyber attack where hackers covertly gain access to a system and remain inside it, undetected, for a significant period of time… Read More

The post Understanding & Preventing Advanced Persistent Threats (APTs) appeared first on .

Headless Chrome: DevOps Love It, So Do Hackers, Here’s Why

Google Chrome is the most popular web browser and has been so for almost a decade. Each new version of Chrome brings new usability, security and performance features.

This article focuses on the “headless mode” feature that Google released more than a year ago; and, since day one has become very popular not only among software engineers and testers but also with attackers.

Off with their heads!

Headless mode is a functionality that allows the execution of a full version of the latest Chrome browser while controlling it programmatically. It can be used on servers without dedicated graphics or display, meaning that it runs without its “head”, the Graphical User Interface (GUI).

In headless mode, it’s possible to run large scale web application tests, navigate from page to page without human intervention, confirm JavaScript functionality and generate reports.


As with benign cases, the same functionality takes place in malicious scenarios, when an attacker needs to evaluate JavaScript or emulate browser functionality.

The practice of web browser automation isn’t new. It’s used in dedicated headless browsers like PhantomJS and NightmareJS, test frameworks like Capybara and Jasmin, and tools like Selenium that can automate different browsers including Chrome.

How popular is Headless Chrome?

The chart below shows the amount of traffic generated by Headless Chrome and other major headless browsers since its release date in June 2017. In comparison to other headless browsers and automation frameworks, Headless Chrome overtook the previous leader, PhantomJS, within a year of its release.

Automated browser trends over the last year

The data collected from our cloud WAF statistics, reinforced by data from Google Trends, highlight how the popularity of PhantomJS fades, while Headless Chrome’s trajectory keeps climbing.

PhantomJS and Headless Chrome: Google search trends

Automated browsers driving increased traffic

Apart from Headless Chrome’s popularity, and the degradation in the popularity of outdated tools, we observed an increase in total traffic generated by automated browsers compared to non-automated web surfing.

The chart below represents the percentage of automated browsers out of total traffic generated by web browsers:

Traffic ratio between automated and non-automated browsers

So, why is Headless Chrome so popular?

There are several reasons for Headless Chrome’s popularity; one being the support for Chrome’s new “out of the box” features, which constantly introduce new trends in web development. Another reason is the support for major desktop, server, and mobile operating systems. Headless Chrome also has convenient development tools and many additional useful features for Devs.

 

The release of Puppeteer a couple of months after the release of the headless functionality was a decisive push in Headless Chrome’s popularity. Puppeteer is a NodeJs library developed by the Chrome team, which provides a high-level API to control headless and full versions of the latest Chrome.

Enter Puppeteer

Puppeteer is a common and natural way to control Chrome. It provides full access to browser features and, most importantly, can run Chrome in fully headless mode on a remote server, which is very useful for both automation teams and attackers.

 

Without much difficulty, attackers can put in place an infrastructure with a host of nodes running Headless Chrome and orchestrated by one component (Puppeteer).

 

Apart from Puppeteer, Chrome can be automated using webdriver and automation frameworks like Selenium or by direct access through Command Line Interface (CLI). In this case, some Chrome functionality will be limited, but it offers the flexibility to write automation in any programing language besides NodeJS and JavaScript.

Just how popular is it among attackers?

By analyzing malicious activity generated by automated browsers, I found that PhantomJS was a leader not only in the amount of traffic it produced but also in malicious activity.


However, nowadays, Chrome occupies the top of the “attackers’ podium,” with half of the malicious traffic divided evenly between execution in headless and non-headless mode.

Taking a closer look at malicious traffic, however, I found that there are no specific trends indicating a preference among attackers for Headless Chrome to exploit vulnerabilities, inject SQL or carry out cross-site scripting attacks (XSS). That said, occasional spikes show attempts at targeting specific sites by using vulnerability scanners, or attempts to exploit newly released vulnerabilities using the “spray and pray” technique.

 

Using a web browser for vulnerability scanning is crafty, but not a new approach, as it can help to bypass some validation mechanisms based on validation of the legitimacy of the client.

WAF events generated by Headless Chrome

Analyzing traffic from the last year, I didn’t find any DDoS attacks performed from a botnet based on Headless Chrome. Nothing similar to the Headless Android Botnet that was discovered two years ago and since then all but vanished.

 

Usage of automated browsers in general, and Headless Chrome in particular, for DDoS, is not common practice. The reason for this is the low request rate to the server that browsers can generate. As Chrome receives the response from the server, evaluates it and only then performs the next request, its rate is very low in comparison to a simple script that floods with many requests and doesn’t “care” about the responses.

 

Having said that, we observe more than 10K unique IP addresses daily performing scraping, sniping, carding, blackhat SEO and other types of malicious activity where JavaScript evaluation is necessary to perform the attack. Distribution among the countries performing these malicious activities is presented in the chart below. While 7% of the traffic is coming from proxies or VPNs to hide the origin of the attack.

Geographical distribution of malicious Headless Chrome traffic

But what about legitimate services?

Headless Chrome isn’t only used by attackers but also by legitimate services. We observe dozens of legitimate well-known web tools that use it to access websites.

 

  • Search engines use it to render the page, generate dynamic content and index data from single page web applications.
  • SEO tools use it to analyze your website and help promote it better.
  • Monitoring tools use Headless Chrome to measure performance and JavaScript execution time of web applications.
  • Online testing tools render pages and compare it to previous versions to track regression or distortion in the user interface.

Ok, so how do we make sure we’re protected?

At this point, you’re probably asking yourself whether or not to block Headless Chrome or any other automated browsers.

 

The answer to this question is “yes… and no.”

 

Using Headless Chrome by itself is not malicious, and as stated earlier, there are legitimate scenarios and services that use this functionality to access websites. Whitelisting all legitimate services is tough work, as it requires constant mapping and maintaining the lists of such services and their IPs.

 

The decision to block Headless Chrome requests or not should be based on the intent and behavior of each IP and session individually.

 

Unless the payload is malicious (which is high evidence of malicious activity), it is better to pass some requests to the website, analyze the behavior and only then decide whether to block or not.

 

The reputation of IPs and their correlation, sophisticated heuristics, and machine learning algorithms can be implemented to make a deliberate decision, which will give better long-term results than aggressive blocking, at least in most cases.

 

For Imperva Incapsula users, a set of IncapRules can be implemented to block Headless Chrome from accessing your website. Starting from a simple rule based on client classification up to sophisticated rules including rates, tags, and reputation.

The post Headless Chrome: DevOps Love It, So Do Hackers, Here’s Why appeared first on Blog.

IDG Contributor Network: Has the word ‘breach’ has outlived its usefulness?

Security is an industry that changes rapidly, as should its terminology. Given the speed with which technology and its context evolves, it comes as no surprise that words that were once sufficient to express a security concept may before long cease to be useful in that same capacity. After a few significant, high profile privacy gaffes in the last few years, the word “breach” may either need to be expanded or replaced.

What is a breach?

A quick search for definitions of the word “breach” result in a few different, relevant options:

  1. A gap made by breaking through a wall, barrier, or defense.
  2. Breaking or failing to observe a law, standard, agreement, or code of conduct.

In a security context, “breach” has historically tended to fit the first meaning, though companies are often fined for being in violation of regulations after a breach. That said, recent privacy gaffes seem to be expanding the security-specific version to include violations of informal expectations of appropriate conduct as well.

To read this article in full, please click here

Florida Police Chief Sent to Jail For Conspiracy Against Black Men

The Biscayne Park police chief had tried to claim his department solved 100% of burglaries, when in fact the Justice Department reports he simply directed his staff to blame burglaries on black men and arrest them without evidence: Former Chief Atesiano previously pleaded guilty to acting under color of law as chief of police when … Continue reading Florida Police Chief Sent to Jail For Conspiracy Against Black Men

SN 691: ECCploit

  • Yesterday, the US Supreme Court heard Apple's argument about why a class action lawsuit against their monopoly App Store should not be allowed to proceed. How could this affect iOS security?
  • Google and Mozilla are looking to remove support for FTP from their browsers.
  • From our "what could possibly go wrong" department, we have browsers asking for explicit permission to leave their sandboxes.
  • The next step in the evolution of RowHammer attacks which do, as Bruce Schneier once opined, only get better... or in this case, worse!

We invite you to read our show notes.

Hosts: Steve Gibson and Leo Laporte

Download or subscribe to this show at https://twit.tv/shows/security-now.

You can submit a question to Security Now! at the GRC Feedback Page.

For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6.

Sponsors:

Risky Business #522 — Alex Stamos co-hosts the show, reflects on Snowden disclosures

We’ve got a slightly different edition of the show this week – Alex Stamos is filling in for Adam Boileau this week in the news slot.

Most of you know him as Facebook’s recently departed chief security officer. Alex also served as the CSO at Yahoo for a time, but his security career stretches back a long way. He co-founded iSEC Partners back in 2004, and before that he did some time with @Stake.

The @Stake mafia is everywhere.

These days Alex is an adjunct professor at Stanford University. He joined me to talk about the week’s security news, as well as to have a chat about the Edward Snowden disclosures, five years on.

This week’s show is brought to you by Thinkst Canary, big thanks to them for that. And instead of one of their staff being on the show this week in the sponsor chair, they asked me to interview this week’s sponsor guest, their customer, Mike Ruth, a security engineer with Cruise Automation.

Mike did a presentation at a conference called QCon recently all about automating the deployment of canary tokens at scale using some nifty CI/CD tricks. He’ll be joining us after the news to tell us all about that.

Items discussed in this week’s news:

  • NSO Group busted to selling to Saudi Arabia
  • NSO malware targets Mexican journalists
  • Edward Snowden claims NSO connection in Khashoggi case
  • Australia’s AA Bill latest
  • npm supply-chain attack targets Bitcoiners
  • Guardian reports Manafort met Assange, denials, lawsuits flying already
  • UK parliament seizes Facebook documents
  • Uber fined over 2016 breach coverup
  • UK cops decline to charge bug reporter
  • USPS finally fixes data exposure after Krebs intervention
  • Rowhammer attack bypasses ECC protections
  • Bloomberg is investigating its own reporting on Supermicro
  • Magecart is everywhere
  • Google, Mozilla plan browser access to file systems

Links to everything that we discussed are below and you can follow Patrick or Alex on Twitter if that’s your thing.

Show notes

Israeli hacking firm NSO Group offered Saudis cellphone spy tools - report | The Times of Israel
Edward Snowden: Israeli spyware was used to track and eventually kill Jamal Khashoggi | Business Insider
A Journalist Was Killed in Mexico. Then His Colleagues Were Hacked. - The New York Times
Home Affairs attempts to allay concerns about Australian exporters for encryption-busting Bill | ZDNet
Widely used open source software contained bitcoin-stealing backdoor | Ars Technica
I don't know what to say. · Issue #116 · dominictarr/event-stream · GitHub
Manafort held secret talks with Assange in Ecuadorian embassy, sources say | US news | The Guardian
UK parliament seizes cache of internal Facebook documents to further privacy probe | TechCrunch
Uber fined $1.17 million by U.K., Dutch authorities for 2016 breach
UK cops won't go after researcher who reported security issue to York city officials | ZDNet
USPS Site Exposed Data on 60 Million Users — Krebs on Security
Potentially disastrous Rowhammer bitflips can bypass ECC protections | Ars Technica
Bloomberg is still reporting on challenged story regarding China hardware hack - The Washington Post
Magecart group hilariously sabotages competitor | ZDNet
Amazon admits it exposed customer email addresses, but refuses to give details | TechCrunch
Google, Mozilla working on letting web apps edit files despite warning it could be 'abused in terrible ways' - TechRepublic
Germany proposes router security guidelines | ZDNet
Half of all Phishing Sites Now Have the Padlock — Krebs on Security
The Snowden Legacy, part one: What’s changed, really? | Ars Technica
QConSF18 - Canaries - Google Drive
Canary — know when it matters

Cisco Webex Meetings Desktop App Update Service Command Injection Vulnerability

A vulnerability in the update service of Cisco Webex Meetings Desktop App for Windows could allow an authenticated, local attacker to execute arbitrary commands as a privileged user.

The vulnerability is due to insufficient validation of user-supplied parameters. An attacker could exploit this vulnerability by invoking the update service command with a crafted argument. An exploit could allow the attacker to run arbitrary commands with SYSTEM user privileges.

While the CVSS Attack Vector metric denotes the requirement for an attacker to have local access, administrators should be aware that in Active Directory deployments, the vulnerability could be exploited remotely by leveraging the operating system remote management tools.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

After an additional attack method was reported to Cisco, the previous fix for this vulnerability was determined to be insufficient. A new fix was developed, and the advisory was updated on November 27, 2018, to reflect which software releases include the complete fix.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181024-webex-injection


Security Impact Rating: High
CVE: CVE-2018-15442

Industry collaboration leads to takedown of the “3ve” ad fraud operation



For years, Google has been waging a comprehensive, global fight against invalid traffic through a combination of technology, policy, and operations teams to protect advertisers and publishers and increase transparency throughout the advertising industry.

Last year, we identified one of the most complex and sophisticated ad fraud operations we have seen to date, working with cyber security firm White Ops, and referred the case to law enforcement. Today, the U.S. Attorney’s Office for the Eastern District of New York announced criminal charges associated with this fraud operation. This takedown marks a major milestone in the industry’s fight against ad fraud, and we’re proud to have been a key contributor.

In partnership with White Ops, we have published a white paper about how we identified this ad fraud operation, the steps we took to protect our clients from being impacted, and the technical work we did to detect patterns across systems in the industry. Below are some of the highlights from the white paper, which you can download here.

All about 3ve: A creative and sophisticated threat

Referred to as 3ve (pronounced “Eve”), this ad fraud operation evolved over the course of 2017 from a modest, low-level botnet into a large and sophisticated operation that used a broad set of tactics to commit ad fraud. 3ve operated on a significant scale: At its peak, it controlled over 1 million IPs from both residential malware infections and corporate IP spaces primarily in North America and Europe.

Through our investigation, we discovered that 3ve was comprised of three unique sub-operations that evolved rapidly, using sophisticated tactics aimed at exploiting data centers, computers infected with malware, spoofed fraudulent domains, and fake websites. Through its varied and complex machinery, 3ve generated billions of fraudulent ad bid requests (i.e., ad spaces on web pages that advertisers can bid to purchase in an automated way), and it also created thousands of spoofed fraudulent domains. It should be noted that our analysis of ad bid requests indicated growth in activity, but not necessarily growth in transactions that would result in charges to advertisers. It’s also worth noting that 3+ billion daily ad bid requests made 3ve an extremely large ad fraud operation, but its bid request volume was only a small percentage of overall bid request volume across the industry.
Our objective

Trust and integrity are critical to the digital advertising ecosystem. Investments in our ad traffic quality systems made it possible for us to tackle this ad fraud operation and to limit the impact it had on our clients as quickly as possible, including crediting advertisers.

3ve’s focus, like many ad fraud schemes, was not a single player or system, but rather the whole advertising ecosystem. As we worked to protect our ad systems against traffic from this threat, we identified that others also had observed this traffic, and we partnered with them to help remove the threat from the ecosystem. The working group, which included nearly 20 partners, was a key component that shaped our broader investigation into 3ve, enabling us to engage directly with each other and to work towards a mutually beneficial outcome.
Industry collaboration helps bring 3ve down

While ad fraud traditionally has been seen as a faceless crime in which bad actors don’t face much risk of being identified or consequences for their actions, 3ve’s takedown demonstrates that there are risks and consequences to committing ad fraud. We’re confident that our collective efforts are building momentum and moving us closer to finding a resolution to this challenge.

For example, industry initiatives such as the Interactive Advertising Bureau (IAB) Tech Lab’s ads.txt standard, which has experienced and continues to see very rapid adoption (over 620,000 domains have an ads.txt), as well as the increasing number of buy-side platforms and exchanges offering refunds for invalid traffic, are valuable steps towards cutting off the money flow to fraudsters. As we announced last year, we’ve made, and will continue to make investments in our automated refunds for invalid traffic, including our work with supply partners to provide advertisers with refunds for invalid traffic detected up to 30 days after monthly billing.

Industry bodies such as the IAB, Trustworthy Accountability Group (TAG), Media Rating Council, and the Joint Industry Committee for Web Standards, who are serving as agents of change and collaboration across our industry, are instrumental in the fight against ad fraud. We have a long history of working with these bodies, including ongoing participation in TAG and IAB leadership and working groups, as well as our inclusion in the TAG Certified Against Fraud program. That program’s value was reinforced with the IAB’s requirement that all members need to be TAG certified by the middle of this year.


Successful disruption

A coordinated takedown of infrastructure related to 3ve’s operations occurred recently. The takedown involved disrupting as much of the related infrastructure as possible to make it hard to rebuild any of 3ve’s operations. As the graph below demonstrates, declining volumes in invalid traffic indicate that the disruption thus far has been successful, bringing the bid request traffic close to zero within 18 hours of starting the coordinated takedown.
Looking ahead

We’ll continue to be vigilant, working to protect marketers, publishers, and users, while continuing to collaborate with the broader industry to safeguard the integrity of the digital advertising ecosystem that powers the open web. Our work to take down 3ve is another example of our collaboration with the broader ecosystem to improve trust in digital advertising. We are committed to helping to create a better digital advertising ecosystem — one that is more valuable, transparent, and trusted for everyone.

TA18-331A: 3ve – Major Online Ad Fraud Operation

Original release date: November 27, 2018

Systems Affected

Microsoft Windows

Overview

This joint Technical Alert (TA) is the result of analytic efforts between the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI). DHS and FBI are releasing this TA to provide information about a major online ad fraud operation—referred to by the U.S. Government as "3ve"—involving the control of over 1.7 million unique Internet Protocol (IP) addresses globally, when sampled over a 10-day window.

Description

Online advertisers desire premium websites on which to publish their ads and large numbers of visitors to view those ads. 3ve created fake versions of both (websites and visitors), and funneled the advertising revenue to cyber criminals. 3ve obtained control over 1.7 million unique IPs by leveraging victim computers infected with Boaxxe/Miuref and Kovter malware, as well as Border Gateway Protocol-hijacked IP addresses. 

Boaxxe/Miuref Malware

Boaxxe malware is spread through email attachments and drive-by downloads. The ad fraud scheme that utilizes the Boaxxe botnet is primarily located in a data center. Hundreds of machines in this data center are browsing to counterfeit websites. When these counterfeit webpages are loaded into a browser, requests are made for ads to be placed on these pages. The machines in the data center use the Boaxxe botnet as a proxy to make requests for these ads. A command and control (C2) server sends instructions to the infected botnet computers to make the ad requests in an effort to hide their true data center IPs.

Kovter Malware

Kovter malware is also spread through email attachments and drive-by downloads. The ad fraud scheme that utilizes the Kovter botnet runs a hidden Chromium Embedded Framework (CEF) browser on the infected machine that the user cannot see. A C2 server tells the infected machine to visit counterfeit websites. When the counterfeit webpage is loaded in the hidden browser, requests are made for ads to be placed on these counterfeit pages. The infected machine receives the ads and loads them into the hidden browser.

Impact

For the indicators of compromise (IOCs) below, keep in mind that any one indicator on its own may not necessarily mean that a machine is infected. Some IOCs may be present for legitimate applications and network traffic as well, but are included here for completeness.

Boaxxe/Miuref Malware

Boaxxe malware leaves several executables on the infected machine. They may be found in one or more of the following locations:

  • %UserProfile%\AppData\Local\VirtualStore\lsass.aaa
  • %UserProfile%\AppData\Local\Temp\<RANDOM>.exe
  • %UserProfile%\AppData\Local\<Random eight-character folder name>\<original file name>.exe

The HKEY_CURRENT_USER (HKCU) “Run” key is set to the path to one of the executables created above.

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run\<Above path to executable>\

Kovter Malware

Kovter malware is found mostly in the registry, but the following files may be found on the infected machine:

  • %UserProfile\AppData\Local\Temp\<RANDOM> .exe/.bat
  • %UserProfile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\<RANDOM>\<RANDOM FILENAME>.exe
  • %UserProfile%\AppData\Local\<RANDOM>\<RANDOM>.lnk
  • %UserProfile%\AppData\Local\<RANDOM>\<RANDOM>.bat

Kovter is known to hide in the registry under:

  • HKCU\SOFTWARE\<RANDOM>\<RANDOM>

The customized CEF browser is dropped to:

  • %UserProfile%\AppData\Local\<RANDOM>

The keys will look like random values and contain scripts. In some values, a User-Agent string can be clearly identified. An additional key containing a link to a batch script on the hard drive may be placed within registry key:

  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

There are several patterns in the network requests that are made by Kovter malware when visiting the counterfeit websites. The following are regex rules for these URL patterns:

  • /?ptrackp=\d{5,8}
  • /feedrs\d/click?feed_id=\d{1,5}&sub_id=\d{1,5}&cid=[a-f0-9-]*&spoof_domain=[\w\.\d-_]*&land_ip=\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
  • /feedrs\d/vast_track?a=impression&feed_id=\d{5}&sub_id=\d{1,5}&sub2_id=\d{1,5}&cid=[a-f\d-]

The following is a YARA rule for detecting Kovter:

rule KovterUnpacked {
  meta:
    desc = "Encoded strings in unpacked Kovter samples."
  strings:
    $ = "7562@3B45E129B93"
    $ = "@ouhKndCny"
    $ = "@ouh@mmEdctffdsr"
    $ = "@ouhSGQ"
  condition:
    all of them
}

Solution

If you believe you may be a victim of 3ve and its associated malware or hijacked IPs, and have information that may be useful to investigators, submit your complaint to www.ic3.gov and use the hashtag 3ve (#3ve) in the body of your complaint.

DHS and FBI advise users to take the following actions to remediate malware infections associated with Boaxxe/Miuref or Kovter:

  • Use and maintain antivirus software. Antivirus software recognizes and protects your computer against most known viruses. Security companies are continuously updating their software to counter these advanced threats. Therefore, it is important to keep your antivirus software up-to-date. If you suspect you may be a victim of malware, update your antivirus software definitions and run a full-system scan. (See Understanding Anti-Virus Software for more information.)
  • Avoid clicking links in email. Attackers have become very skilled at making phishing emails look legitimate. Users should ensure the link is legitimate by typing the link into a new browser. (See Avoiding Social Engineering and Phishing Attacks.)
  • Change your passwords. Your original passwords may have been compromised during the infection, so you should change them. (See Choosing and Protecting Passwords.)
  • Keep your operating system and application software up-to-date. Install software patches so that attackers cannot take advantage of known problems or vulnerabilities. You should enable automatic updates of the operating system if this option is available. (See Understanding Patches and Software Updates for more information.)
  • Use anti-malware tools. Using a legitimate program that identifies and removes malware can help eliminate an infection. Users can consider employing a remediation tool. A non-exhaustive list of examples is provided below. The U.S. Government does not endorse or support any particular product or vendor.

References

Revision History

  • November 27, 2018: Initial version

This product is provided subject to this Notification and this Privacy & Use policy.


Happy National Day of Giving!

Today is National Day of Giving. How are you celebrating?

At Verisign, we did a quick search on NameStudioTM, our easy-to-use, domain name suggestion tool to see what interesting .com and .net domain names were available to register today … and here are some of our favorites!

AVAILABLE .COM AND .NET DOMAIN NAMES*

.COM

onekindaction.com
thesharingme.com
truegivingnow.com
philanthropyfamily.com
whatsmycharity.com
donatingwithheart.com
ourfavoritegift.com
servingofkindness.com
sharedgenerosity.com
realdifferencemaker.com

.NET

onekindaction.net
thesharingme.net
truegivingnow.net
philanthropyfamily.net
whatsmycharity.net
donatingwithheart.net
ourfavoritegift.net
servingofkindness.net
sharedgenerosity.net
realdifferencemaker.net

 

What’s yours?

Tell us what great .com and .net domain names you’ve found on NameStudio here.

And check back soon to see what day we’re celebrating next. Better yet, subscribe to the Verisign blog to have the posts delivered directly to your inbox.

Happy National Day of Giving!


*Available as of November 27, 2018

The user is solely responsible for ensuring that the registration of any domain name listed herein or based on NameStudio domain search data does not violate any third-party trademarks or other intellectual property.

The post Happy National Day of Giving! appeared first on Verisign Blog.

Retailers Fix Software Flaws Quickly, Despite Continued Code Quality Issues

Veracode State of Software Security 2018 Retail Industry

The 2018 holiday shopping season is off to a record-breaking start, thanks to consumers’ growing comfort with making online purchases and an increasing number of retailers offering Black Friday pricing starting on Thanksgiving. In fact, in the first two days of the shopping season, online retailers saw nearly $10 billion sales, with Adobe reporting that consumers in the U.S. alone spent $6.2 billion on Black Friday. For many, the ability to complete holiday shopping online and avoid crowded parking lots and throngs of people in a shopping center or mall is a relief. This may even trump any concerns they may have about privacy or fraud as they use credit cards and apps to make their purchases.

Retail’s State of Software Security Receives High Marks – Yet There’s More to be Done

The good news is Veracode’s State of Software Security Volume 9 (SOSS Vol. 9) found that retail is faster than most industries – second only to healthcare – when it comes to addressing common vulnerabilities found in software, thereby reducing risk exposure. Through our flaw persistence analysis, or how long a flaw lingers after first discovery, we found that the retail industry remediates a quarter of its vulnerabilities in 14 days, and 50 percent of flaws in 64 days. Retail outpaced the average fix speed at every interval across all industries, keeping consistent with its urgency to close vulnerabilities.

However, two-thirds (66 percent) of applications retailers use are at risk from information leakage attacks. This means that an application may reveal sensitive data that an attacker can then use to exploit the web application, its hosting network, or the user. Retail reported the third-most information leakage issues after technology and financial services. SOSS Vol. 9 also shows that the retail industry has the highest number of code quality flaws when compared to all other verticals at 65 percent. Code quality is the third most common vulnerability category across the board, following information leakage and cryptographic issues, suggesting that developing quality, secure code is an industry-wide issue for the retail sector.

“Vulnerabilities in applications can allow attackers seeking sensitive information such as consumer payment data a way in,” said Paul Farrington, Director of EMEA and APJ at Veracode. “Many retailers are showing an aptitude for remediating flaws quickly to help improve security and protect their high value information. This is promising, yet the persistence and prevalence of vulnerabilities that continues to plague retailers calls for both increased speed of fix and better prioritizing which flaws to fix first.”

Secure Software Development Education and the Skills Gap

It is estimated 3.5 million cybersecurity jobs will go unfilled by the year 2020. Our research shows 76 percent of developers say that security and secure development education is necessary – but not offered in current curriculums – so this hardly comes as a surprise. The onus falls on organizations such as retailers to ensure that their development teams are receiving the education necessary, and are equipped with the appropriate tooling, to make security a priority in the software development process.

As the retail industry offers new ways to buy, pick up, and ship goods, it is also increasing the threat landscape by producing a wider portfolio of web applications. It will be critical for them to ensure their developers have what they need to keep their systems and their customers’ sensitive information safe from potential cyber attacks.

To learn more about the retail industry’s security hygiene, download the free Retail Industry Infosheet.

Introducing Incident Handling & Response Professional (IHRP)

We are introducing the Incident Handling & Response Professional (IHRP) training course on December 11, 2018. Find out more and register for an exciting preview webinar.

No matter the strength of your company’s defense strategy, it is inevitable that security incidents will happen. Poor and/or delayed incident response has caused enormous damages and reputational harm to Yahoo, Uber, and most recently Facebook, to name a few. For this reason, Incident Response (IR) has become a crucial component of any IT Security department and knowing how to respond to such events is growing to be a more and more important skill.

Aspiring to switch to a career in Incident Response? Here’s how our new Incident Handling & Response Professional (IHRP) training course can help you learn the necessary skills and techniques for a successful career in this field.

Incident Handling & Response Professional (IHRP) 

The Incident Handling & Response Professional course (IHRP) is an online, self-paced training course that provides all the advanced knowledge and skills necessary to:

  • Professionally analyze, handle and respond to security incidents, on heterogeneous networks and assets
  • Understand the mechanics of modern cyber attacks and how to detect them
  • Effectively use and fine-tune open source IDS, log management and SIEM solutions
  • Detect and even (proactively) hunt for intrusions by analyzing traffic, flows and endpoints, as well as utilizing analytics and tactical threat intelligence

This training is the cornerstone of our blue teaming course catalog or, as we called it internally, “The PTP of Blue Team”.

Discover This Course & Get An Exclusive Offer

Take part in an exciting live demonstration and discover the complete syllabus of our latest course, Incident Handling & Response Professional (IHRP), on December 11. During this event, all the attendees will get their hands on an exclusive launch offer. Stay tuned! 😉

Be the first to know all about this modern blue teaming training course, join us on December 11.
> RESERVE YOUR SEAT

Connect with us on Social Media:

Twitter | Facebook | LinkedIn | Instagram

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

Earlier this year, the Web3 Foundation (W3F) commissioned Trail of Bits for a security review and assessment of the risks in storing cryptocurrency. Everyone who owns cryptocurrency — from large institutions to individual enthusiasts — shares the W3F’s concerns. In service to the broader community, the W3F encouraged us to publish our recommendations for the secure use of hardware wallets: the small tamper-resistant peripherals that enable users to securely create and protect cryptocurrency accounts.

Whether your cryptocurrency holdings amount to a few Satoshis or a small fortune, you will find this post useful.

44917824762_dc1fa21afd_k

Today’s hardware wallets require diligent security procedures (Image credit: Gareth Halfacree)

The Advent of Hardware Wallets

In the early days of cryptocurrency, users simply generated their payment addresses (in cryptographic terms, their public/private key pairs) using the client software on a standard PC. Unfortunately, once cryptocurrency became a hot commodity, securely storing an account private key on a general-purpose computer — using a “software wallet” — became a liability. Software wallet files could be lost or deleted, and they were targeted for theft. Most users were unprepared for the hefty responsibility of securely and reliably storing their private keys. Partially, this drove the adoption of custodial storage services (such as at cryptocurrency exchanges).

Years of massive, unpunished thefts from these services convinced many users that they could never trust a third party with their cryptocurrency holdings the same way that they might trust a regulated bank holding fiat currency. So, in the past couple of years, hardware wallets have gained popularity as useful tools for protecting cryptocurrency accounts without relying on a custodial service.

A Foolproof Solution?

Hardware wallets are a kind of consumer-grade Hardware Security Module (HSM), with a similar purpose: a device that embodies a tamper-resistant vault, inside of which the user’s cryptographic identity (in this case, a cryptocurrency account) can be created and used without the private key ever leaving the device. Fundamentally, a hardware wallet only needs to take a transaction created on a host computer, sign it to make it valid, and output the signed transaction for the host computer to publish to the blockchain.

In practice, it’s not so simple. Users must properly initialize their wallets. Sometimes the devices have firmware updates. Then there’s the matter of recovery codes (also known as the BIP39 recovery phrase or seed words). Hardware wallets are a huge improvement over storing private keys on a sheet of paper in a fire safe, or in a directory on a laptop, but hardware wallets still carry risks. Users need to take some safety precautions. In the words of Bruce Schneier, “Security is a process, not a product.

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

1: Purchase the device from a trusted source, preferably direct from the vendor, new and unopened

Avoid any unnecessary supply-chain risk. Buying a device directly from the manufacturer (e.g., Ledger or Trezor) rather than from a reseller minimizes the risk of acquiring a counterfeit or a device tampered by a middleman. At least one malicious eBay reseller has reportedly devised clever schemes to defraud buyers even while selling them genuine and unopened products (see rule #3).

2: Never use a pre-initialized hardware wallet

If a user accepts a pre-initialized hardware wallet, they are putting their cryptocurrency into a wallet that is potentially just a copy of a wallet controlled by an attacker. Ensure that you (and only you) properly initialize your hardware wallet before use. Follow the initialization instructions from your hardware wallet vendor’s website (for example, the instructions for a Ledger brand wallet; instructions for a Trezor wallet).

IMG_4723

The kind of prompt you want to see, new out of the box (Ledger Nano S pictured)

3: Never use a pre-selected set of recovery words, only ones generated on-device

Never accept pre-selected recovery words. Always initialize a hardware wallet from a clean slate with on-device generation of new random recovery words. Anyone that knows the recovery words has complete control over the wallet, the ability to watch it for activity, and the ability to steal all of its coins. Effectively, the words are the secret key.

In December 2017, a hardware wallet reseller reportedly packaged a counterfeit scratch-off card in the box with each device delivered to their customers. The scratch-off card revealed a list of recovery words, and the card instructed the buyer to set up their device using a recovery step, rather than initializing it to securely generate a new set of words. This was a clever scam to trick users into using a pre-configured wallet (see rule #2).

fake-ledger-scam-768x1151 (source Reddit)

Beware reseller frauds like this one: official-looking pre-selected recovery words (Image credit: Ledger, Reddit user ‘moodyrocket’)

4: Prefer a device that is able to provide an attestation of its integrity

While resetting or initializing a device ought to be sufficient, there is hypothetically still a risk of buying a counterfeit or tampered hardware wallet. Before you buy one, confirm that you’ll be able to verify the provenance, authenticity, or integrity of the new hardware wallet. Look for software provided by the device maker that can interrogate a Secure Element on the device and provide an attestation of the device’s integrity. Follow the verification instructions from the vendor of your wallet (for example, Ledger’s instructions to use secure element attestation to check device integrity). There are, however, still gaps in the attestation capabilities of today’s wallets. Users ought to continue to demand better and more complete attestation.

5: Test your recovery words

Data protection 101 is “always test your backup”: in this case, your backup is the set of recovery words. Using a spare hardware wallet device, use the recorded recovery words to initialize the test wallet. Eliminate any doubt that the recorded words can successfully recover the original wallet’s state. After testing the correctness of the recovery words, reset/wipe this test device. Do not use a general-purpose computer or software wallet to verify the recovery words. Follow the instructions from your vendor for performing a recovery dry-run to test your seed words (the steps for Trezor wallet users and the steps for Ledger users).

6: Protect your recovery words separately and equally to the hardware wallet. Do not take a picture of them. Do not type them into anything.

Write the recovery words by hand — do not type them into a computer or photograph them to be printed — and then laminate the paper (preferably archival-quality acid-free paper for long-term storage). Store it in an opaque tamper-evident sealed envelope (example) for assurance that it has not been viewed without authorization. Remember that the device’s PIN code is no protection against an attacker with physical access if the recovery words are stored alongside the device. Do not store them together.

IMG_4726

Write the words down, but don’t take a photo like this one!

7: Verify the software you use to communicate with the hardware wallet; understand that a backdoored desktop UI is part of your threat model

Hardware wallets rely on desktop software for initiating transactions, updating the hardware wallet’s firmware, and other sensitive operations. Users of cryptocurrency software should demand reproducible builds and code-signed executables to prevent tampering by an attacker post-installation. The advantage of code-signing, relative to manual verification with a tool like GPG, is that code signatures are automatically verified by the operating system on every launch of the application, whereas manual verification is typically only performed once, if at all. Even verifiable software, though, can still be subverted at runtime. Recognize that general-purpose computing devices are exposed to potentially risky data from untrusted sources on a routine basis.

8: Consider using a high assurance workstation, even with a hardware wallet

By dedicating a workstation to the single task of operating the hardware wallet, it can be locked down to a greater degree because it is not used for day-to-day tasks, nor exposed to as many potential sources of compromise. Consider operating your hardware wallet only from an immutable host PC configuration. This workstation would be offline only, and dedicated to the task of transaction creation and signing using the hardware wallet. First, lock down the system’s firmware configuration (e.g., restrict boot devices, disable network boot, etc.) to ensure the integrity of the boot process. Then, the boot media can be protected either by Secure Boot using a TPM-backed encrypted SSD / hard drive, or — for true immutability — by burning and verifying a trusted OS image onto a write-once DVD-R media and storing the DVD-R in a tamper-evident bag alongside the hardware wallet.

9: Consider a M-of-N multi-signature wallet with independently stored devices

Multi-signature” refers to requiring more than one key to authorize a transaction. This is a fantastic protection against a single point-of-failure. Consider creating a multi-signature wallet with keys generated and kept in hardware wallets stored in physically separate locations. Note that if the devices will be in the custody of different individuals, carefully consider how to coordinate and make decisions to spend from the wallet. For added paranoia, the hardware wallets could be of different device brands. Then, even in the unlikely case that an employee at one of the hardware wallet manufacturers were to have successfully backdoored their devices, they would still only control one of the keys in your multi-signature wallet.

10: Consider manually verifying the generation of a new multi-signature address

Related to rules #7 and #8, note that multi-signature wallets are created by “joining” several private key-holders into a single address defined by a script. In the case of Bitcoin, this is called a P2SH address (“pay-to-script hash”). This part of the address creation is done in a the desktop software UI using public keys, and not on the hardware wallet. If a compromised workstation provides the script basis during the generation of a new P2SH address, then the attacker may be able to join or control the multi-sig wallet. For example, attacker-controlled or -subverted desktop software could secretly turn a 2-of-3 wallet into a 2-of-5 wallet with two additional public keys inserted by the attacker. Remember, a hardware wallet does not entirely preclude the need to secure the host that interfaces with it.

More Secure, More Usable Solutions Still Needed

This discussion of risks and recommendations in regards to cryptocurrency hardware wallets illustrates the challenges for the broader security industry in attempting to design other kinds of fixed-function devices for private key protection. For instance, U2F tokens and Secure Enclaves.

For well over a decade, security researchers have promoted the goal of “usable security.” Usable security is simply the idea that secure computing should be easy to do right, and hard to do wrong. Compare the usability of a modern secure messaging client, for example, with the cumbersome and error-prone key management required to use GPG. Getting usability right is the difference between protecting a few thousand technologists and protecting tens of millions of regular users.

Avoid complacency. Demand safer, better designed devices that aren’t prone to traps and mistakes. The best hardware wallet should be a little bit boring! We hope that in the future, safe and usable hardware wallets will be a commodity device that we can take for granted.

Until then, we will continue doing our part to build security awareness independently and in collaboration with organizations like the W3F. If you work for a company that creates hardware wallets, we welcome you to contact us for help protecting your users.

What will be hot for Cisco in 2019?

nw forecast intro mini logo IDG

Software, software, and more software. That seems to be the mantra for Cisco in 2019 as the company pushes software-defined WANs, cloud partnerships, improved application programs, and its over-arching drive to sell more subscription-based software licenses.

As the year closed on Cisco’s first quarter 2019 financials, the company was indeed touting its software growth, saying subscriptions were 57 percent of total software revenue, up five points year over year, and its application software businesses was up 18 percent to $1.42 billion. The company also said its security business, which is mostly software, rose 11 percent year over year to $651 million.

To read this article in full, please click here

(Insider Story)

DDoS protection, mitigation and defense: 8 essential tips

DDoS attacks are bigger and more ferocious than ever and can strike anyone at any time. According to Verizon's latest DDoS trends report, the first half of 2018 saw an increase of 111 percent in attack peak sizes, compared to last year.  "The attackers are getting their hands on more and more machines that they can misuse for DDoS attacks," says Candid Wueest, threat researcher with Symantec Security Response at Symantec.

To read this article in full, please click here