Cisco Midyear Cybersecurity Report

Posted on  by

We’ve got the tl;dr on Cisco’s 90 page midyear cybersecurity report for you! “Major Findings” on page five of the report can give you the gist of the report as well.

One of the bigger developments of note is the decline and stagnation of exploit kits. Due to multiple factors, mainly the hardening/reduced patch time/decline of Flash, Angler has disappeared from the landscape. Angler was the main innovator in the space and with their reduced presence, other kits don’t seem to be pushing for new and novel techniques. This trend isn’t expected to last, but it’s a welcome change for now.The decline of exploit kits coincides with an increase in spam, to potentially replace delivery mechanisms of malware.

It’s no surprise that ransomware is on the rise, with many variants being found in the wild. The careful selection of a price that a victim is willing to pay to get back to business can make this attack lucrative. The escalation of this is ransoming high value targets that generate large amounts of revenue, such as MRI machines(which are often operated by legacy operating systems, such as Windows XP).

On the vulnerabilities front, there has been an observed increase in particular attacks after vulnerabilities have been disclosed. This can be made as a case for the use of responsible disclosure in the time leading up to patch development/release, and a subsequent announcement of a vulnerability. With increased responsible disclosure, the real issue then becomes patch maintenance/management, which is a more routine and manageable task.

There is some cognitive dissonance in the report between Figure 41 on page 49, and statements made on page 50. Figure 41 claims that there were zero CWE-16 issues(configuration), while espousing the MongoDB(and other DBs) issues to particular DevOps stacks. The issues surrounding MongoDB and friends was most definitely insecure default configurations.

The section on IoT(Internet of Things) also makes a statement which is a bit confounding with regard to an IoT device to “have unpatched or outdated applications that are vulnerable, like Windows XP”. There are important distinctions between a consumer IoT device, like a thermostat, and a Windows XP machine that controls an MRI or baggage screening hardware. Consumer IoT devices are usually vulnerable through negligence - either by the owner, or the producer, while systems that need a standalone computer are more correctly defined as Industrial Control Systems(ICS). Lumping devices that cost less than $100 in with multi-million dollar installations does not illuminate the vast differences in the requirements of each. ICS installations are often governed by acceptance criteria, which may not allow for alterations of any sort, by either the customer, supplier, or a regulator. The lifespan and expected uptime of ICS installations also often runs into the span of decades, and expects near 100% availability at all times. ICS installations require robust controls to avoid ever exposing them to the world, and are largely to be used in strictly controlled environments.

The newly(?) coined acronym for Destruction of Service in the report, DeOS(or perhaps should be DeoS?), refers to the destruction, or “bricking”, of a device. The concept of bricking applies to IoT devices in the report, but its origins come from hardware hacking, where the penalty for failure turns working electronics into a non-functional brick. Bricking an IoT device with bad default passwords, or blatant security vulnerabilities prevents it from joining botnets, such as Mirai. Potential motivations for bricking devices could be twofold: 1. Keeping them out of the hands of DDoS operators, and 2. Creating a negative brand association to vendors with poor security practices. The second option in particular has the potential to not only damage the reputation of a hardware producer, but to also case massive warranty claims due to “broken” devices. Lax security practices are, most likely, going to end up having IoT vendors receiving regulation with regard to minimum security standards.

In a potential effort to redefine an existing attack, business email compromise(BEC) is made to sound as if it is something other than phishing. BEC is simply spear phishing, in which an employee, with the ability to release funds, is highly researched and targeted. BEC has yielded $5.3B USD between October 2013 and December 2016. Training to defend against this effective, and companies would be best served by setting guidelines for transaction verification by personnel that are able to release funds.

Overall, the report is illuminating, despite some of the attempts to reinvent, or redefine, terms/attacks that already exist. I found the most value to be in learning of the potential causal link between a decrease in exploit kits and the increase of spam volumes. I feel that the report could have easily been trimmed down to 30 pages and still be a great resource.


Security Roundup - 2017-07-20

Posted on  by , and

To start, if you need some summer reading, Humble Bundle has a CyberSecurity collection at a ridiculously low price this week.

After last week’s .io TLD takeover, the last thing I would expect is a follow up a week later. However, this week found numerous domains hijacked after an attacker compromised part of a provider and introduced a rogue DNS server, redirecting traffic to other servers to drive users to malware laden sites. This attack ultimately impacted 751 domains across 34 TLDs for up to 2.5 hours.

Another week brings another tale of slow patching cadence. This week’s story comes from Talos Intel, who decided to track the fix rate of a specific memcached bug they disclosed and was fixed last year. Over a six month period, they only saw a 10% change in vulnerable servers, despite having proactively contacted system owners. More discouragingly, a portion of the servers appeared to have been shut down, but overall vulnerability rates remained stable, indicating either than ip addresses changed, or that new vulnerable systems were deployed.

With so many devices on the internet, a vulnerability in a software package used across devices can pose a serious cross-device threat. This is what security researchers discovered this week with a flaw in a library called gSoap, used by many brands of security cameras, networking equipment, sensors and other IoT devices. If a malicious payload gets sent to the device the attacker can execute code, taking over the device. Thankfully, the payload size is 2GB, which reduces the ‘drive by’ ability to target devices, but does present opportunity for targeted attacks. The company behind gSoap promptly patched it’s software but the upgrades on the individual devices is left to the companies that produce the devices and the device owners themselves. With at least 34 device providers being paying customers of the library in question, which translates itself into thousands of devices fairly easily.

Troy Hunt has been following SSL trends, and sparked off a large discussion around the value of Extended Validation certificates last week. Partially tied to the uptick of Let’s Encrypt adoption, and the decrease in certificates issued by traditional Certificate Authorities, and recent comments about the “dangers” of free certificates, Troy distills a long conversation into a still very long, but definitely interesting post. Ultimately, it seems that the majority of users are not sure what EV certs are, so what are the tangible benefits?

Interested in the inner workings of Malware? Endgame Security has the post for you this week with “Ten Process Injection Techniques”, diving deep into various ways that malware hides its activities by getting other processes to run its payload.

Trend Micro recently discovered the third iteration of a malware named GhostCtrl. This malware is a variant of the commercially available omniRAT, and is generally hidden inside another fake application. Once infection occurs, it allows an attacker to control many aspects of the infected device including wifi and it’s able to record audio and video, as well as intercept texts and upload these to its C&C server.

Akamai Goes over the “Myth of the Self Tuning/Machine Learning Web Application Firewall”, discussing false positive and false negative rates vs service ability vs security.

In the last few weeks, we have noticed a few Cryptocoin based security issues.

The first one is the recent “Initial Coin Offering” of CoinDash. An “Initial Coin Offering” is when a new cryptocoin fund starts up and seeks investors. In recent months, many such ICOs of dubious nature have taken place, raising funds in the hundreds of millions. Even though many of the ICOs have little, if anything, to show for themselves, the fact that previous ICOs have made investors an impressive ROI seems to continue to bring in new investors who are looking to make a quick buck. In the CoinBase case, it was hackers who sought to make a quick buck, hacking CoinDash’s official homepage just minutes prior to their token sale. The hacker altered the Ethereum wallet address to which prospective buyers were meant to send their Ethereum, to which about $7.7m were sent. Many have voiced outrage at CoinDash’s seemingly lack of secure practices even before the ICO took place.

The second involves a cryptocoin wallet implementation, with an exploitable bug allowing a hacker to siphon funds from these wallets if they were set up to be multi-signature wallets. Several projects using Ethereum and this wallet type were impacted, to the tune of $30m.


Security Roundup - 2017-07-13

Posted on  by , , and

A breach involving credit card information occurred this week, and Troy Hunt contrasts the company’s response with the 5 stages of grief. Troy promptly posted a follow up on Data Breach coverups, as he has started seeing more and more companies opt to not inform customers of breaches /deny that breaches are as bad as they really are.

Checkpoint has provided the technical details of the “subtitle as an attack vector” discovery a month and a half ago. The various media players were actually exploited in different ways, though the vector of subtitle was the same in each case. 2 of the media players rely on them being able to render HTML from a subtitle file. Another involved parameter overloading, allowing a malicious attacker to actually overwrite functionality in the media player itself (to introduce a backdoor or other exploit). Finally, VLC’s exploits were much, MUCH more involved, with a much more carefully crafted payload to corrupt system memory and execute an arbitrary command.

Matthew Bryant, a security engineer at Uber, has been interested in methodologies in taking over complete Top Level Domain infrastructure. His research paid off recently when he discovered that several of the .io TLD name servers were up for grabs, their DNS entries having erroneously expired. He registered one in order to validate that this is indeed possible and upon realizing what had just occurred, reached out to the TLD’s to report the issue. After discovering the TLD’s support email was offline, he registered the rest of the available name servers to prevent a malicious entity from doing so, ultimately gaining control of more than 50% of the listed name servers.

Talos Intel has noticed a new, novel exploit mechanism for phishing emails. Rather than the payload being in the email, the exploit tries to download the payload over SMB, in an effort to also harvest user credentials.

Researchers at Recorded Future have discovered a new SQL injection scanner platform based on the Arachni Scanner product. Dubbed Katyusha, the scanner makes it easy to automate exploit discovery, and is somewhat novel as it allows users to control and receive results from the tool using Telegram.

MalwareBytes has released a “CyberCrime tactics and techniques” report for Q2. Unsurprising to this writer, there is quite a bit of ransomware coverage. All told, it is a fairly good reminder of all the incidents that have occurred over the last few months. Some facts: Tool leaks seem to be in vogue, between ShadowBrokers and Vault7. Expect to see more of these this year, and the chaos that ensues after. Mac Malware has hit an all time high, with more malware families appearing the first half of this year than all of last year. Browser exploit kits have stagnated, as browsers tighten up security, and some high profile arrests for those involved in their creation have occurred. Rate of breaches continues to accelerate, with more damaging information being regularly released, including financial details of users.

AVTest has put up a similar report, though annual in scope. Their 2016/2017 Security Report report is interesting, in that there is an overall downward trend in malware (though still 4 new samples a second!!), and that Ransomware only accounted for 1% of malware strains they observed, calling it ‘more of a marginal phenomenon’. There is also a heavy focus on the Android space, pointing out that discovered malware strains for Android have more than doubled year after year.

Kaspersky Lab also coincidentally released a Ransomware report recently, which lends itself to this being a growing problem with the number of impacted users having doubled year over year. However, that does mean that just over 1 million users were impacted by Malware in the 2016/2017 area they measured. They also pointed out that ransomware is evolving from “spray and pray” for the average user, and evolving into much more targeted attacks on businesses, who can ill afford the disruption to their day to day activities. Finally, ransomware is becoming commoditized, with more and more ‘ransomware-as-a-service’ groups popping up, causing not necessarily friendly competition

WikiLeaks published more Vault 7 materials this week, unveiling 2 exploits that attempt to steal SSH credentials and session data by hooking into SSH clients. The first exploit, called BothanSpy, targets the SSH client program Xshell on the Microsoft Windows platform and steals user credentials and keys for all active SSH sessions. The exploit can exfiltrate the keys to a control server or save them in an encrypted file. The CIA also created a similar exploit for Linux platforms. This exploit is called Gyrfalcon and it’s capable of stealing credentials of active OpenSSH sessions but also collecting session traffic. All the data can be stored on the local machine for later exfiltration.

Android users beware! A researcher uncovered a critical vulnerability, dubbed “Broadpwn,” in family of Broadcom WiFi chips present in millions of Android devices. The CVE could allow a party within wifi range of a device to gain access to the system and execute arbitrary code. Google is the only company that has released a patch to address Broadpwn so far, and any Android users who did not receive this month’s patch should only connect to trusted wifi networks. iOs devices are affected by the same CVE, but there is too little information available at this point to determine breadth of Apples devices affected or the availability of a patch. More information about Broadpwn will be presented at the Blackhat conference in Las Vegas at the end of July.

In other Android vulnerability news, a strain of malware called CopyCat affected 14 million devices in April and May 2016, primarily in Southeast Asia. The malware strain attempts to gain root privileges, and thus total access to activities on the phone, allowing it to do things such as perform ad fraud. Researchers believe this netted the operators up to $1.5 million dollars in a 2 month time period.


Security Roundup - 2017-07-06

Posted on  by

Scott Helme has been analyzing various internet security mechanisms over the last several years. His latest focus is TLS security, and he provides a great writeup on ‘Why TLS Revocation is Broken’. From why Certificate Revocation Lists (CRLs) are too cumbersome and Online Certificate Status Protocol (OCSP) is better for revocation, but worse for privacy, Scott covers the current problem and highlights a number of new options that can further mitigate man in the middle attacks against TLS communications.

Let’s Encrypt hits another milestone by having reached 100 MILLION generated SSL certificates. Given that Let’s Encrypt has only been in operation for a year and a half, this is a remarkable achievement. In that same time period, HTTPS adoption has increased 18% (essentially 1% every month!) to reach 58%, no doubt at least partially due to Let’s Encrypt’s free service. They have also announced they will start issuing wildcard certificates in the new year, citing it as a much requested feature, and their hope that it will help drive adoption of TLS closer to the 100% goal.

The end of this quarter actually saw a large amplification attack on Cloudflare’s infrastructure, crossing 100Gbps and lasting 38 minutes. SSDP is used for discovery of UPnP devices, and allows the query for ‘all’ devices. Since SSDP happens over UDP, the return address can be forged, allowing an attacker to make queries and redirect responses to their victim. We’ve previously covered a number of problems with UPnP, and this is just one more example of why it should be disabled. Cloudflare provides a number of other recommendations to eliminate/reduce the efficacy of these attacks.

A security researcher recently aided in making packages served from node package manager (npm) more secure. The researcher was able to access enough accounts to be able to hijack 14% of all packages, some of which are in use by millions of users. The majority of these accounts were not brute forced, but used involved password reuse from other accounts that were available in one of the many leaks in the last year (check your passwords!), by users publishing these passwords in their packages accidentally or accidentally uploaded to places like Github. 17% of accounts were brute forced, using embarrassingly bad password lists (one password was literally “password”). NPM has tightened password policies, as well as monitoring password based endpoints, and is working to roll out even more security improvements intended to increase account security and mitigate risk.

This week celebrated the 50th anniversary of the ATM. We’ve previously shared stories on ATMs and skimmers, and this week Brian Krebs gives us an update on the current state of ATM skimmer technology.

For those that love to dive into malware breakdowns, Palo Alto Networks provides one on OceanLotus. OceanLotus is a Mac backdoor and interesting for a few reasons, including a custom binary communication protocol with its C2s.

Finally, researchers have published a paper detailing information leak in libgcrypt’s implementation of RSA-1024 keys, resulting in excessive information leaking and allowing researchers to reconstruct the key in use. At time of writing, the library has issued a patch, and many linux providers have provided updates and/or other layers of protection.


Stubby McMockerface

Posted on  by

Stubby McMockerface

Guest post from rikonor/stubby-mcmockerface

The goal of this document is to make a case for using Go interfaces for:

  • dependency injection (DI)
  • Easily mocking interfaces
  • Augmenting an existing instance of an interface

1. Original Motivation - Dependency Injection (DI)

Dependency Injection is a Software Development technique whereby one object supplies the dependencies of another object. This is in contrast to the object building or finding it’s dependencies from some global scope.

Lets look at a simple example. We have a person that would like to introduce himself.

type Person struct {
  Name string

func (p *Person) IntroduceYourself() {
  fmt.Println("Hi, my name is " + p.Name + ".")

We actually want to support different kinds of people, e.g a loud person, a normal person and perhaps a mute person.

// say is how a normal person would speak
func say(msg string) {

// sayLoud is how a loud person would speak
func sayLoud(msg string) {

// sayMute is how a mute person would speak
func sayMute(msg string) {
  // Do nothing because you're mute

In this case it might be a good idea us to allow Person to have a Say function injected into it, rather then having one tightly coupled implementation.

// Define a type for Say functions
type SayFunc func(msg string)

// Make sure Person allows us to specify a Say function for it to use
type Person struct {
  SayFn SayFunc

// Make the person use the injected SayFn to introduce itself
func (p *Person) IntroduceYourself() {
  p.SayFn("Hi, my name is " + p.Name + ".")
p := &Person{
  Name: "Kip",
  SayFn: SayFunc(sayLoud), // Inject a Say function of our choice


// Output: HI, MY NAME IS KIP.

2. Mocking via DI

A common issue when testing software is dealing with external services that our code depends on. Having to depend on the availability of these services can complicate tests significantly. A few examples are disk resources, network resources, databases, API libraries and more.

Let’s examine how to solve this issue by mocking a service and providing the mocked version via dependency injection. In this way, the code receiving the injected dependency doesn’t even know that it did not receive the real service.

Example - http.Client

For our use-case we will examine http.Client which is a struct from the net/http standard Go lib which allows us to make network requests. The way we make a network request is by building an http.Request first and then providing it to the client to perform.

// Make a GET request to `url`
req, err := http.NewRequest("GET", url, nil)

// Perform the request
res, err := http.DefaultClient.Do(req)

http.Client does not satisfy any specific interface out of the box, but that doesn’t mean we can’t create an interface to match it.

// HTTPClient is a general interface for http clients
// Coincidentally, it is implemented by http.Client
// If we want to be more idiomatic it can also be named Doer
type HTTPClient interface {
	Do(req *http.Request) (*http.Response, error)

Now we’ll see a pattern that can be used to very generically mock an interface.

// MockHTTPClient is a mockable HTTPClient
type MockHTTPClient struct {
	DoFn func(req *http.Request) (*http.Response, error)

// Do calls the underlying Do method
func (c *MockHTTPClient) Do(req *http.Request) (*http.Response, error) {
	return c.DoFn(req)

MockHTTPClient takes in a generic DoFn, so we can create many different mock clients.

// FromString returns an HTTPClient which always returns a response with the given string
func FromString(s string) HTTPClient {
	return &MockHTTPClient{
		DoFn: func(req *http.Request) (*http.Response, error) {
			// convert the given string to a ReadCloser (same as Response.Body)
			body := ioutil.NopCloser(strings.NewReader(s))

			// Just return a response with the given string
			return &http.Response{
				Body: body,

				// Can mock other fields as well: StatusCode, etc
			}, nil

Notice there are lots of options for mocking HTTPClient: FromStatusCode, FromCookies, FromHeaders, etc. We can also just create a MockHTTPClient on the fly with some special custom logic.

Let’s say we have a function FetchSomeNetworkResources, which accepts an HTTPClient. Although, under normal circumstances we would give it an http.Client, during tests we can just give it one of our mock clients.

c := FromString("data: boop")

data, err := FetchSomeNetworkResources(c)
if data != "boop" {
  t.Fatal(...) // fail the test

We can follow the same pattern to mock any interface.

3. Enhancing existing interfaces

Another cool aspect of this pattern is that it can be used for much more then just mocking. Note: It’s been debated that in the context of “enhancing/augmenting” StubXXX is more appropriate then MockXXX. That said, we will keep using MockXXX for the sake of demonstration.

Example - RetryHTTPClient
// RetryHTTPClient wraps an HTTPClient with retry functionality
func RetryHTTPClient(c HTTPClient, retries int) HTTPClient {
	return &MockHTTPClient{
		DoFn: func(req *http.Request) (*http.Response, error) {
			var res *http.Response
			var err error

			// try `retries` times
			for i := 0; i < retries; i++ {
				// attempt the request
				res, err = c.Do(req)
				if err != nil {
					// retry on failure

				return res, nil

			// we made `retries` attempts and never succeeded
			return nil, err
Example - RewriteHostHTTPClient
// RewriteHostHTTPClient will rewrite the host of any request passing through it
func RewriteHostHTTPClient(c HTTPClient, host string) HTTPClient {
	return &MockHTTPClient{
		DoFn: func(req *http.Request) (*http.Response, error) {
			// Rewrite the Host portion of the request
			req.Host = host
			req.URL.Host = host

			// Send the request
			return c.Do(req)
Example - Publisher and friends

Let’s define a Publisher interface.

type Publisher interface {
  Publish(msg Message) error

And a generic mock publisher.

type MockPublisher struct {
  PublishFn func(msg Message) error

func (p *MockPublisher) Publish(msg Message) error {
  return p.PublishFn(msg)


// TransformFunc is a function that changes a message and returns the changed version
type TransformFunc func(msg string) string

// TransformPublisher wraps a given Publisher with a message TransformFunc
func TransformPublisher(p Publisher, tfn TransformFunc) Publisher {
	return &MockPublisher{
		PublishFn: func(msg string) error {
			// transform the message using the given transform function, then send it along
			return p.Publish(tfn(msg))


// Lets try and create a Publisher that will transform our messages before sending them out
tp := TransformPublisher(p, func(msg string) string {
  // as an example, lets capitalize the message
  return strings.Title(msg)

// Should publish: "Hello"


// MultiPublisher wraps all given Publishers into one Publisher
func MultiPublisher(ps ...Publisher) Publisher {
	return &MockPublisher{
		PublishFn: func(msg string) error {
			// iterate over all publishers and send to each in turn
			for _, p := range ps {
				// there's multiple possible error handling strategies here
				// in this case we'll just return the first encountered error
				if err := p.Publish(msg); err != nil {
					return err
			return nil


mp := MultiPublisher(p1, p2, p3)

// Should publish to `p1`, `p2` and `p3`


// BatchPublisher batches messages together before sending them out
func BatchPublisher(p Publisher, batchSize int) Publisher {
	// hold our batched msgs somewhere
	msgs := []string{}

	return &MockPublisher{
		PublishFn: func(msg string) error {
			msgs = append(msgs, msg)

			// if enough messages have been batched, we can send them out
			if len(msgs) == batchSize {
				// there's multiple ways to batch the messages
				// in this case we'll just concatenate them
				batchMsg := strings.Join(msgs, ",")
				return p.Publish(batchMsg)

			// Note: It's also possible to flush the batch publisher after some pre-defined time duration
			// but to keep the example simple we will not do so

			// still waiting for batch buffer to fill up
			return nil


bp := BatchPublisher(p, 3)

bp.Publish(msg) // Won't publish yet
bp.Publish(msg) // Won't publish yet
bp.Publish(msg) // Will publish all three now