Cyberweekly #100 - What's next?

Published on Sunday, May 03, 2020

Project MUSE - Trusting Infrastructure: The Emergence of Computer Security Incident Response, 1989–2005

https://muse.jhu.edu/article/752964

Nonetheless, many elements of incident response infrastructure remain locally or regionally bounded. This includes not only the tools that systems administrators use to patch local computer networks, but also forums for building trusted relationships among incident responders, data exchange formats and applications, and training materials. We have argued that this boundedness resulted not from the inevitably local nature of maintenance, but rather from the historical process of infrastructure development, which was shaped by regionally based interpersonal trust networks, institutions and needs. The development of incident [End Page 199] response standards and infrastructure was driven from the bottom-up by trusted networks of colleagues and friends. Transnational organizations such as IETF and FIRST enabled the formation of relationships across vast geographic and political differences, but trusted relationships were deepest and most common among colleagues in the same region.

This is a fascinating history of incident response from the late 80s up to present day. What’s interesting to me is that in reality none of the problems have changed. The difficulty in coordinated incident response is the lack of trust between members, and the lack of a coherent ability to describe what they are seeing.

There are standards upon standards, but they often struggle with the same problem, they come out of a trusted group who know how to work together already, and therefore don’t fit other disconnected groups very easily.

It turns out, if you want to build an efficient incident response capability, the most important thing you just do is network with key individuals you’ll be working with, build trust over time, and work on those personal relationships.

DNS for red team purposes | BLOG.REDTEAM.PL

https://blog.redteam.pl/2020/03/dns-c2-rebinding-fast-flux.html

Our payload will be extracted line by line from payload.txt file and put into consecutives DNS queries. After each DNS response, the line that has been sent in response is removed from the file. Before putting our payload into IPv6 records we need to encode it. At the beginning \x char is removed from the payload and if a line contains less than 26 characters it is padded using 0’s. A date in a MMDD format and a 2 digit number will be appended to each string. These 2 digits may be used as identifiers for payload parts etc. When a complete payload has been transferred, DNS server will start to respond with a static IPv6 address (in our case deadbeef [https://en.wikipedia.org/wiki/Hexspeak]) – in a real attack scenario this IPv6 address should have a less conspicuous value, e.g. some trusted IPv6 address of Google.

This is a good demonstration of how to infiltrate data, such as command and control traffic into a network that has good network blocking. DNS queries are rarely blocked, and encoding the data into IPv6 addresses, which are already 32 bytes long allows you to encode quite a lot of control commands quite simply.

This has a limited throughput, as referenced further down, you probably don't want your malware pinging more often than once every 10 minutes or so.

There's some other neat demonstrations of hiding data in DNS queries and responses in the article. It's a good technical reference for blue and red teams.

Using AWS Workspaces to control access to documents

https://medium.com/@bruntonspall/using-aws-workspaces-to-control-access-to-documents-5e0498fdcfe2

We had a smallish set of data that we wanted to do some data science on, that is running some scripts that might parse the files, look for commonalities and so on. Of course, in order to do that the developers need to be able to look at the files, so they know what they’re looking at. We could allow individual developers to see a handful of files by using a client laptop, but that laptop is restricted in running code, so we selected AWS Workspaces as a way of triaging access. Our first step therefore is to migrate data into somewhere accessible by the Workspaces computers. We picked an S3 bucket for this. We were able to create the S3 bucket with ACL’s set to disallow public access.

Yes, this is my own blogpost, yes I'm that shameless!

This is a good example of how to perform threat modelling, work out what your worries are (in this case, accidental data loss is the biggest) and then build something that meets the needs of the users while mitigating the threat.

Whether all that comes through is dependent on the writing skills of the author however!

Warwick University was hacked and kept breach secret from students and staff | Science & Tech News | Sky News

https://news.sky.com/story/warwick-university-was-hacked-and-kept-breach-secret-from-students-and-staff-11978792

Several sources told Sky News that during the final meeting concluding the ICO's audit, the regulator made what was perceived to be a recommendation that Ms Sandby-Thomas be removed as chair of the university's data protection privacy group (DPPG).

To a room of more than 20 people, including Ms Sandby-Thomas, the auditor recommended that the group should be chaired by someone with data protection expertise.

The university told Sky News: "The registrar fully agreed with the report's finding that we should give those areas of responsibility to someone with a specialist skill set and experience."

Despite not having this "specialist skill set and experience", Ms Sandby-Thomas had been the executive lead for IT and data protection at the university since 2016 - a period during which multiple security incidents occurred.

After the recommendation was made that she stand down from chairing the DPPG, the registrar disbanded the committee.

Good job there. Multiple breaches and a complete failure to follow any sensible procedure is bad enough. But when the audit findings come in and say that the data protection officer is lacking the specialist skills (in data protection) needed to do the job, they disband the committee. Not appoint someone who can do the job, they simply disbanded the privacy and data protection committee.

They have replaced it with two committees, one of which includes a leading cybersecurity professor. Now call me cynical, but in my experience, many academics and professors are very good at analysing others work, but often not good at doing it themselves. Secondly, many cybersecurity professionals have little to no understanding of data protection. It really is a separate discipline in its own right.

This will be one to watch to see how the ICO reacts and whether the full power of GDPR will be applied in these cases

FT suspends journalist accused of listening to rival outlets' Zoom calls | Media | The Guardian

https://www.theguardian.com/media/2020/apr/27/ft-suspends-journalist-mark-di-stefano-accused-listening-papers-zoom-calls-independent-evening-standard

The Independent claimed Zoom log files showed an account registered to Di Stefano’s FT.com email address joined the video call for Independent staff last week for 16 seconds.

The caller’s video was disabled, but some journalists apparently saw his name flash briefly on screen before he left the meeting.

Minutes later a separate account joined the call, this time unnamed, the Independent said. It claimed the caller remained in audio-only mode with a black square displayed to journalists on the video call.

The anonymous user account, which remained in the meeting until the end, was later shown to be linked to a mobile phone used by the same FT reporter.

Was this in your threat model? This isn't a zoom specific problem, this is the case for almost all audio and video conference tools. There's a need to allow users to join the calls, often from their mobile phones, and that means sharing the PIN and Access Codes.

I've worked with a lot of clients over the last 5 years, and the routine sharing and reuse of these rooms and PINs is terribly common. I've been sent a dial in details for a procurement process where I know that if I were to dial back 5 minutes after my slot ended, I'd hear the next supplier going through the same process.

The thing that makes this mostly ok is that the majority of people we interact with are surprisingly ethical, and don't abuse the knowledge that they come across. The fact that this is a big story is because everybody agrees that it's crossing a journalistic ethical line.

Nine million logs of Brits' road journeys spill onto the internet from password-less number-plate camera dashboard • The Register

https://www.theregister.co.uk/2020/04/28/anpr_sheffield_council/

An infosec researcher who asked not to be named looked at the server hosting the ANPR dashboard, and told us its configuration revealed the existence of an SFTP account as well as the address of a storage drive filled with raw ANPR images. In addition, we were told the IPv4 addresses of each and every camera was exposed through the dashboard.

The more of this story I read, the more depressed I get. Yet another database left wide open to the internet, but of course, in that database was configuration details (for which, they almost certainly mean publically accessible addresses and username and password) for further storage systems.

As I've said before, you probably worry about the advanced capabilities of nation states when in reality, this is exactly the sort of "basics" that you should be worrying about instead. Would you know if this was the case on your estate? How? What confidence do you have and how do you maintain it?

Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams | CyberArk

https://www.cyberark.com/threat-research-blog/beware-of-the-gif-account-takeover-vulnerability-in-microsoft-teams/

The fact that the victim only needs to see the crafted message to be impacted is a nightmare from a security perspective. Every account that could have been impacted by this vulnerability could also be a spreading point to all other company accounts. The GIF could also be sent to groups (a.k.a Teams), which makes it even easier for an attacker to get control over users faster and with fewer steps.

While limiting your organization to internal communication will reduce your exposure, we found that it is still possible to communicate with an outsider and any interaction that includes a chat interface with an outsider is enough to be affected by this vulnerability. A good example of this would be an invitation to a conference call with an outsider for a job interview.

First things first, this is a nasty attack, but it required a domain takeover of a few DNS records on the teams estate. Those are now fixed up and there's a patch as well. But it goes to show that it's not just Zoom that you have to worry about, but all messaging tools. We'll see more of Zooms competitors undergoing security research soon and you'll see that there's bugs in all software.

But what really stood out to me in this report was the fact that CyberArk seems to think that the solution here is to prevent people talking to one another and using collaboration tools. And they discovered that even if you lock down collaboration tools, there's still legitimate business needs for those tools to allow external collaboration. What's the takeaway that CyberArk highlights?

In this post, we aimed to demonstrate what could have happened if an attacker had managed to exploit this vulnerability. Treat your internal communication platforms like they contain your most top-secret and privileged information – because they actually might.

This is ridiculous and bad advice. If you treat your communication platforms like it contains the most top-secret and privileged information, then you will require access control and need to know rules on every individual message, and nobody will ever talk to anyone else in your company. It's akin to the old adage that the only secure computer is one that is turned off and buried in a hole. Technically correct, but ultimately useless advice

‘I Could Solve Most of Your Problems’: Eric Schmidt’s Pentagon Offensive - The New York Times

https://www.nytimes.com/2020/05/02/technology/eric-schmidt-pentagon-google.html

“You absolutely suck at machine learning,” Mr. Schmidt told General Thomas, the officer recalled. “If I got under your tent for a day, I could solve most of your problems.” General Thomas said he was so offended that he wanted to throw Mr. Schmidt out of the car, but refrained.

Four years later, Mr. Schmidt, 65, has channeled his blunt assessment of the military’s tech failings into a personal campaign to revamp America’s defense forces with more engineers, more software and more A.I. In the process, the tech billionaire, who left Google last year, has reinvented himself as the prime liaison between Silicon Valley and the national security community.

[...]

Mr. Schmidt acknowledged that progress was slow. “I am bizarrely told by my military friends that they have moved incredibly fast, showing you the difference of time frames between the world I live in and the world they live in,” he said.

But he said he had little intention of backing down. “The way to understand the military is that the soldiers spend a great deal of time looking at screens. And human vision is not as good as computer vision,” he said. “It’s insane that you have people going to service academies, and we spend an enormous amount of training, training these people, and we put them in essentially monotonous work.”

I don't think you could sum up the Google way more than this quote. It is however, probably a fair assessment, that the Us Department of Defence just doesn't have enough understanding of AI to even know where or when to use it appropriately, let alone the expertise to implement it. These are things that are being fixed, both within the US defence complex and in the UK with the Defence Digital initiative.

Artificial Intelligence and the Integrated Review: The Need for Strategic Prioritisation | RUSI

https://rusi.org/commentary/artificial-intelligence-and-integrated-review-need-strategic-prioritisation

Human expertise is the single most important component of any AI project. Cultivating technical expertise and developing a workforce of data-literate practitioners must therefore be a core objective of any future AI development strategy.

The UK government should invest in developing a core cell of data-science expertise to lead the development and deployment of new AI applications in the defence and security sector. This should be achieved by recruiting new talent, retraining current practitioners and partnering with academic institutions. Many of the AI capabilities the defence and security sector may wish to implement could be developed in-house without reliance on third-party providers, minimising costs and enabling a more agile approach to testing, evaluation and validation. The initial investment of developing this in-house technical expertise will therefore be more than recuperated by the cost savings made in the long term.

This RUSI article hits the nail on the head perfectly here. The problem with the adoption of AI within defence systems is not because they lack the technology or the money or even the will to do so. I'm sure that if you were able to look, you'd find millions sent to big defence contractors over the last decade to use "advanced AI technology" in their defence procurement processes.

The issue is that, in order to actually take advantage of AI, the organisation needs the skills to understand the technology, but even more importantly, it needs a core skill in understanding the data that it holds. Machine Learning is so dependant on good data, good labelling and good people, far more so than it's dependant on the technology.

Once you have those people, you can start to engage your defence contractors by asking them to use AI effectively, rather than just general statements like adding "The system must use AI" to page 672 of the procurement contract. Internal skills enabled you to ask the right questions, demand the right kinds of answers, and use your commercial partners in a far more effective way.

Avoid learning too many lessons from these ‘unprecedented times’ – Digital by Default

https://digitalbydefault.com/2020/04/27/avoid-learning-too-many-lessons-from-these-unprecedented-times/

The big thing I just want to keep reminding people though is while there will be lessons to learn from all this we need to take them with a grain of salt. There are not normal times and I think the change in attitudes is probably a lot more fragile than some people think. Digital services and ways of working are going to come in for a lot of scrutiny after things settle down and for many people they will forever be associated with a crisis response – not business as usual. We’ll need to pick our battles – this isn’t going to mean carte blanche for every digital transformation plan that has previously stalled.

I'm going to keep on predicting this, in the contrary to a lot of online voices. A lot of the post-crisis behaviour is actually going to be a springing back to normal, to back to the way we were before the crisis hit. There will be some seismic shifts in organisations I'm sure, but a lot less than is currently being predicted.

If you've been campaigning for a long time for the adoption of video conferencing, remote work or digital collaboration tools, you are probably enthusiastic about this new normal and you are seeing everybody using the tools you want. What you probably don't see, partly due to confirmation bias, and partly due to rose tinted glasses, is just how many people are mentally associating these tools and these ways of working with exhausting stressful anxious times.

I think that digital transformation adoption efforts, particularly in the remote working area, are far more likely to be hampered by COVID-19 experiences rather than increasing adoption. Hopefully I'm just cynical and will be proven wrong.

How to create real, lasting change after Covid-19 - RSA

https://www.thersa.org/discover/publications-and-articles/rsa-blogs/2020/04/change-covid19-response

As we think of ‘bridges to the future’, we are thinking too of the variety of measures and activities that have been put in place during the crisis response, from those which may be most promising signs of new ways of doing things to those we see as only ever temporary. Here’s one framing we’re working up that might help make sense of the crisis-response measures we are seeing:



Obsolete activity The crisis has afforded us the ability to stop doing some things, either because we already knew they were not fit for purpose or because the crisis has rendered them obsolete.

We might look at the internal NHS market that has trusts competing against each other for scarce PPE, or the combative relationship fostered within local voluntary organisations by outdated commissioning approaches.  

Post-crisis the challenge is to let go of these obsolete aspects of pre-existing systems - not only those things the crisis has rendered impotent but also those things we know are no longer fit for purpose.

As Peter Drucker said, the greatest danger in times of turbulence is not the turbulence, it is to act with yesterday’s logic.

This analysis is super useful. As the crisis starts to lessen for many of us, we are thinking about what happens next. This diagram and post captures the problem we face. There are old practices that we should stop, they’re no longer fit for purpose, and indeed may not have been for some time. The crisis showed that we can cope without, and so we shouldn’t restart them. But there are also old processes that we’ve put on hold that we need to restart. Disambiguating between these is the hard job that faces us going forward, far more than determining which new processes to continue in my view.