Our favourite infosec books

We have a clever bunch working here at Asterisk. From directors to testers, consultants, and business development managers, everyone is passionate about information security. There may be regular debates over music, coffee vs tea, and the best place for lunch in the city, but we’re all on the same page when it comes to information security.

To share our love of all things infosec, we surveyed some of the team on their favourite books. These 11 titles have educated, enlightened and entertained and come highly recommended for anyone interested in information security…

 

I loved ‘The Cuckoo’s Egg’ by Cliff Stoll. In the 80’s Stoll was an admin for a university shared computing system and investigating a minor accounting discrepancy led to him basically uncovering a spy ring working for the Russians. True story.

Mike Loss, Senior Security Consultant

 

‘Future Crimes’ by Marc Goodman is the book that sparked my initial interest in infosec and gave me the urge to explore a career in the industry. I picked it up at an airport book store (I actually thought it was a true crime book – didn’t realise it had anything to do with infosec) but was hooked from the first few pages. It made me realise that just about everything is connected, and as a result just about everyone is vulnerable. I made a decision there and then to try and learn more/get involved in the industry. Also, I encourage anyone who assumes that information security is purely about technology to give ‘Social Engineering: The Art of Human Hacking’ by Christopher Hadnagy a read. It uses a lot of a real world examples and made me question why we so often focus on information security strategies that tend to address technology and product as opposed to people and process.

Sam Moody, Business Development Manager

 

‘Firewalls and Internet Security: Repelling The Wily Hacker’ by William R. Cheswick and Steven M. Bellovin was the book that started it all. First published in 1994, it was one of the earliest (and definitely one of the greatest) books on network security. ‘The Web Application Hacker’s Handbook’ by Marcus Pinto and Dafydd Stuttard was (is) the bible for web application security testing. It’s a little dated now (published in 2011), but still very relevant and full of some great knowledge. Another favourite is ‘The Browser Hacker’s Handbook’ by Christian Frichot, Wade Alcorn and Michele Orru – because Christian is a hipster God, and we all miss him very much.

David Taylor, Principal Security Consultant

 

I read ‘The Cathedral and the Bazaar’ by Eric S. Raymond almost 20 years ago and it was an insight into the world of monopolies and how to succeed without selling code – how Netscape survived, and the differences between top-down and bottom-up approaches to development.

Daniel Marsh, Security Consultant

 

I usually get bored of “career advice” books pretty quick but I picked up ‘Women in Tech’ by Tarah Wheeler after following Tarah and some of the other contributors on Twitter. The advice in the book is stellar, but what I loved most were the personal stories from successful women in tech like Brianna Wu and Keren Elazari woven through.

Cairo Malet, Security Consultant

 

‘Gray Hat Python: Python Programming for Hackers and Reverse Engineers’ by Justin Seitz is a good way to learn both scripting/programming and practical offensive security. Some of the content is a little dated, and for the most part better tools exist to do the tasks that are covered. However, the step-by-step approach provides a great foundation for some common offensive security tools and processes.

Clinton Carpene, Security Consultant

 

The novel ‘Neuromancer’ by William Gibson tells the story of a washed-up computer hacker hired by a mysterious employer to pull off the ultimate hack. The Matrix, cyberpunk, implants – Gibson’s dystopian future is a classic. Another novel, ‘Snow Crash’ by Neal Stephenson, presents the Sumerian language as the firmware programming language for the brainstem, which is supposedly functioning as the BIOS for the human brain. Stephenson is next level Gibson and features the Matrix (Metaverse) and cyberpunk references. Stephenson can get heavy, and satiric, but again it’s a classic for the genre.

Steve Schupp, Managing Director

 

What’s your favourite infosec book?

 

Book covers image source – Booktopia

 

Server-side request forgery in Sage MicrOpay ESP

Asterisk Senior Security Consultant Mike Loss shares a story from a testing engagement that was fun for us, moderately bad news for our client and ultimately worse news for a vendor. Spoiler alert – this story has a happy ending.

During a testing engagement last year I was working on a web app called “Sage MicrOpay ESP”. ESP stands for Employee Self-service Portal, and it’s a pretty standard HR web app, allowing employees to enter timesheets, book leave, etc.

Looking at the first handful of requests made by the browser when loading the page, one stood out immediately as… odd.

https://esp.REDACTED.com.au/ESP/iwContentGen.dll/start?InitialPage=100&NOLOGIN=Y&PageReadOnly=N&MAE=N&HAE=N&CommonDatabase=53227%20EvolutionCommon&CommonServer=REDACTED-SQL02&US=03dbbb66-cf9b-46de-97cb-cfa450de93bf

There are a few file extensions that really set the spidey-sense tingling when it comes to web apps. The list is long, but classics include pl, sh, exe, and in this instance, .dll.

Image Source

Looking through the URL parameters in the request, something else stood out – the ‘CommonDatabase’ and ‘CommonServer’ parameters. It seemed pretty odd that the user would be in control of a web app’s database connection. At first I doubted that was what was actually happening but once I noticed that the value in ‘CommonServer’ matched the naming convention of the target organisation’s server fleet, I became more confident that I was on to something.

Put simply, it turns out that one of ESP’s very first actions upon loading was to tell the client’s browser: ‘Hey I need you to tell me to connect to a database server. You should tell me to connect to this one!’.

There’s essentially no reason for a web application of this type to ever ‘ask’ a regular client which database on which server the application should connect to. In any sane application this value would be in a configuration file, somewhere inaccessible to normal users of the application.

So of course I did what any normal tester would do, I threw a bunch of garbage at the interesting parameters to see what would stick.

Most things I tried at first resulted in the request timing out, but we maintain a pet DNS server for just such an occasion. Keeping an eye on the query logs for the server and sending the request again with our DNS name in the ‘CommonServer’ parameter resulted in a lovely sight.

At the very least we have some kind of server-side request forgery in play. The obvious next step for us was to see what else we can get the server to talk to. Internal hosts? Hosts out on the Internet?

The thing clearly wants to talk to a database server… let’s give it a database server. The .dll file extension tells us it’s on Windows, so MSSQL is an obvious place to start.

Starting up a netcat listener on port 1433 on a host in AWS and then sending our DNS name in the ‘CommonServer’ field generated exactly the result we’d hoped for.

So we have a web application on the inside… and it thinks I’m it’s database server…

Image Source

I wonder if I can get it to send me credentials?

The obvious tool for the job here is Responder. It’ll happily impersonate a server, then negotiate and accept more or less any authentication request that a client is willing to send it, then serve up the resulting credentials on a platter.

After repeating the process with Responder in place of our netcat listener, we get some creds!

Fun for us, but moderately bad news for our client.

At this stage I was moderately disappointed by the quality of the very obviously default creds, especially since they were no good to me in terms of further attacks on the target infrastructure.

I started goofing around with the format of the server address, trying out UNC addresses, internal addresses, specifying ports, that kind of thing, and eventually hit on formatting it like this:

…which made my Responder go off like crazy.

Image Source

For those not familiar with NTLM authentication, it APPEARS that the application has interpreted our gently mangled server name as a UNC path, in such a way that it thinks it needs to get to the database via SMB.

As a result, it’s connected to my Responder listener on port 445, and Responder has told it to authenticate via NTLM. The application has kindly obliged and we end up with a NetNTLMv2 hash – that long string of yellow alphanumerics at the end of the image.

Now, a NetNTLMv2 hash is quite a lot slower to crack than a regular NTLM hash if you want to actually recover the password, but if you notice that ‘$’ at the end of where I’ve redacted the username? That means the account being used to authenticate is the AD account of the actual server itself. That means the password is randomly generated and LOOOONG.

Never going to crack it. Just not gonna happen.

What we COULD do however is relay the authentication attempt… IF the target organisation had any services facing the internet that used NTLM authentication AND allowed connections from computer accounts. This might seem unlikely at first, but ‘Authenticated Users’ includes computer accounts, and heaps of sysadmins grant rights to ‘Authenticated Users’ where they should really use ‘Domain Users’. In any case, our target organisation didn’t have anything else with NTLM auth facing the Internet so it’s at this point that the attack becomes kind of academic.

In addition to this particularly entertaining issue, we also identified a number of other issues with the application, including unauthenticated access to staff names, phone numbers, addresses, and other sensitive PII.

After delivering the report to our client we began the least fun part – the disclosure to the vendor.

It turns out that ‘Sage’ is a pretty big company, and finding anyone responsible for infosec matters was non-trivial.

I started with the support email on the website. While the staff at the other end responded very quickly, there seemed to be a breakdown in communications.

Sage support continued to insist that I needed to provide a customer number before they would provide me with any support services. I tried explaining that I wasn’t asking for support services…

And then they stopped replying to my emails. 🙁

So I tried the traditional “security@” email address… Not a peep.

I asked around with some industry contacts… Nobody knew anybody who worked at Sage.

Finally I resorted to what I think of as ‘the Tavis’.

Turns out Tavis is a smart guy (who knew, right?) because this worked… real fast.

Without boring you to death with details, I almost immediately received a phone call from an actual dev, who was actually familiar with the app, and who actually wanted to fix the problem!

I passed through the details, they fixed the issues, and a patch came out about a month later.

Finally, because we’re meant to be trying to actually make things better when we hack stuff, I’d like to go over a quick summary of the ways this could have been prevented.

On the dev side, the most obvious part is that the client should not have ever been given the opportunity to choose the back-end database server. It should have been set in a config file somewhere.

Of course, we can’t expect vendors and developers to always do the right thing. Strict outbound network filtering would’ve prevented both the MSSQL and NTLM credential exposures. Your computers almost certainly do not need to talk to things on the public Internet on tcp/445 and tcp/1433, so don’t let them!

Sage were very helpful and friendly (and appreciative) once I actually made contact with the right group within the company, but getting there was unnecessarily difficult. Monitor your security@ address and publish a contact on your website for vulnerability disclosure.

 

Notifiable Data Breach Scheme

What is it?

The Notifiable Data Breach (NDB) Scheme is an amendment to the Privacy Act 1988 that comes into effect from 22 February 2018. The NDB scheme sets out the obligations of organisations to notify individuals after a data breach has disclosed their personal information and that disclosure is likely to cause serious harm to the individual. Notification of the breach must also be provided to the Office of the Australian Information Commissioner (OAIC).

Who does it apply to?

The scheme applies to all entities that are currently subject to the Privacy Act – as a general rule, this includes all Australian government, business or not-for-profit organisations with an annual turnover of $3 million or more.

What needs to be addressed?

To ensure that applicable organisations are able to respond appropriately in the event of a breach, the following needs to be addressed:

• The ability to identify and respond to security incidents in a timely manner;
• Implement processes to assess if a breach is likely to cause serious harm to individuals;
• Develop a communication plan for notifying relevant parties;
• Ensure your notifications meet minimum requirements as defined by the OAIC;
• Implement remediation activities to avoid the incident reoccurring in the future.

How to notify?

When an organisation suspects or has confirmed that a data breach has occurred, it will need to promptly notify individuals that are likely at risk of serious harm. The Commissioner must also be notified as soon as practicable with a statement outlining the data breach.

Notifications must include the following information:

• The identity and contact details of the organisation;
• A description of the data breach;
• What personal information has been breached;
• Steps that individuals should take in response to the data breach.

How to comply?

General guidance is provided by the OAIC and can be found here: https://oaic.gov.au/privacy-law/privacy-act/notifiable-data-breaches-scheme

If you need assistance with meeting your notification obligations, Asterisk can assist with implementing incident detection and response procedures and communications plans to ensure your organisation is ready to take action should a breach occur.*

* If you have not yet sought legal advice on your organisation’s exact eligibility and obligations under the Privacy Act, Asterisk recommends consulting an appropriate legal professional to ensure all legal requirements have been considered.

#krackattack WiFi encryption “Key Reinstallation Attack”

What happened?

A flaw has been discovered and widely reported as breaking WiFi encryption. The attack is a client-based attack and exploits vulnerabilities in the 4-way handshake of the WPA/2 protocol.

As the problem lies within the WiFi standard, the potential impact is widespread, affecting just about every smartphone and PC. The exploit could allow attackers to read WiFi traffic between devices and wireless access points. Certain implementations on Linux and Android devices are more severely impacted, allowing attackers to modify network traffic.

No need to panic

The flaw is not as ubiquitous and severe as the headlines suggest. The following context has been made public:

• Secured protocols (for example, HTTPS) still provide protection for applications.
• Attackers require close proximity to the wireless network – they need to be in range of the WiFi client.
• The attack is complex to execute and there are no public exploit tools currently available to facilitate the exploit (though this will likely change soon!).
• The exploit was responsibly disclosed, so vendors have already released patches (Microsoft) or intend to release soon (Android, Apple).

What can you do?

1) Implement patches when released.
2) Encrypt critical data in motion, independent of the network.
3) Ensure encryption is properly implemented to good standards (don’t invent your own!).
4) Use a virtual private network (VPN) solution on your devices, especially on public WiFi hotspots.
5) Advise users to only access secure sites, with https:// instead of http:// at the start of the address and check for a locked padlock or key in the browser address bar.

If you’re worried about the protection of your sensitive information, ask us how we can help.

The End is Nigh?

We are not usually in the business of making bold predictions about future developments in cyber security. But recent internal discussions about WannaCry and Petya/Nyetya have got us all thinking about an entirely plausible and frankly terrifying possibility for where crypto malware could go next.

Here’s the short version:
DeathStar + basic crypto malware variant = complete encryption of the entire AD environment.

DeathStar is an extension to the Empire post-exploitation framework that was released by byt3bl33d3r in May 2017. It builds on previous tools like BloodHound to identify and automate privilege escalation within Active Directory. Basically, “push button, receive domain admin”.

DeathStar (and BloodHound) don’t rely on exploiting any actual vulnerabilities. Rather DeathStar leverages Active Directory configuration and allocation of privilege in order to find and exploit a path of domain joined systems that can be travelled, one hop at a time, in order to eventually obtain DA privileges. The BloodHound github page probably explains this approach most succinctly:
“BloodHound uses graph theory to reveal hidden relationships and attack paths in an Active Directory environment.”

Our predicted scenario plays out something like this:
1. Despite your organisation’s best efforts with security education and awareness, a low privileged user opens a malicious executable email attachment.
2. The attachment first runs DeathStar, which eventually obtains domain admin privileges.
3. Once DA has been obtained, the payload reaches out to every domain-joined Windows system and executes a crypto malware payload, as DA, on every host simultaneously.

Taking this one step further…
Couple this attack with a basic password spraying attack against Remote Desktop Services or Citrix  (or even OWA followed up with Ruler) and you remove the need for any phishing or other user interaction. One minute you’re fine – the next minute every machine on your AD has crypto malware.

So what can be done?

  1. Excellent, frequent, offline and offsite backups. Definitely NOT on local, online, domain-joined backup servers.
  2. Proactively test your Active Directory with tools like Bloodhound and DeathStar. If you can prevent these tools from achieving DA through derivative administrator relationships, chances are good that the predicted malware won’t be able to either.
  3. Use cloud-based / SaaS services where possible.
  4. Follow ‘best practice’ advice like the Top 35 / Essential 8 provided by ASD. Specifically: patch OS and applications, implement application whitelisting, use 2FA for all remote access (including OWA), limit the allocation of administrative rights, and monitor the shit out of your environment.

If this prediction eventuates it could have staggering consequences for individual organisations and possibly for the global economy. We don’t want this to happen, but it just seems like the next logical step in the evolution of crypto malware. Hopefully by highlighting the possibility we can get ahead of the curve before the risk is realised.