Another week, another ransomware outbreak. On Tuesday, we saw another variant of ransomware spreading, worm-style, across unsecured networks within large organisations. As with the WannaCry outbreak in May, large global corporations have been affected, and infections have spread from their initially-compromised hosts across internal networks. NotPetya hasn't received as much press as WannaCry did, but from a security perspective it does, at the moment, look far more interesting.
Sanitisation of user input is essential for preventing SQL injection, regardless of the format of the supplied data. Today I'm going to look at SQL injection through a more obscure injection point: serialized PHP arrays. Taking inspiration from a finding in a recent test, I've created a small app which allows the user to upload a CSV file. This file is then converted to a PHP array, serialized and returned to the user as a hidden form field. Finally, this is posted back to the application where the supplied data is inserted into the MySQL database.
Outsourcing infrastructure to cloud service providers has fundamentally changed the face of information technology and corporate architectures in the last decade or so.
Flexible, fast-paced development. Rapid deployment. Scalability. Resilience. Minimisation of in-house hosted infrastructure. The growth of microservices and mobile technologies.
Another ransomware attack hits, this time on a scale never seen before. The spread has gone viral across a large and crucial network – the network underpinning the UK's National Health Service.
There are three main differences between this attack and previous ransomware incidents.
There are many tools available for automated testing of web applications. One of the best known is probably sqlmap. Sqlmap allows you to identify and exploit SQL injection vulnerabilities with ease from the command line. However, controls such as CSRF tokens or simple anti-automation techniques such as including a unique hidden value within the form can prevent automated tools from working correctly. Macros in Burp Suite are a great way to bypass these measures in order to carry out automated testing, although they can be complicated to implement.
You’ve had an incident. You’ve managed the fall-out, contained the outbreak and restored normal service. Now is the time to sit down with your incident response teams, your operational teams and other stakeholders and work out how to prevent a recurrence.
During an incident wash-up meeting, you should go over all evidence gathered during the incident, details of actions taken and the reasons why decisions were made given the information available at the time.
Situational awareness throughout incident response activities is of paramount importance. As activities are conducted, new information is likely to emerge. New information may completely change the objectives of your exercise, and teams need to be in constant communication in order to coordinate activities.
Actions assigned to responders during an incident will be informed by the systems and data at risk, business continuity plans for these systems, and the objectives of the incident response exercise.
You have an incident. You know you need to handle it. You’re under pressure, and your team is stressed.
This is often the most dangerous point in an incident response operation. Stressed people under pressure to respond quickly tend to make one of two mistakes:
At some point, your business is likely to have to deal with an incident. When this happens, being able to accurately identify and classify the incident is key to responding effectively with the minimum impact to your BAU operations. Yesterday, we discussed how proper planning will help you get a robust incident response framework in place. Today, we are going to look at the sorts of questions you need to ask yourselves in order to be able to identify and classify an incident, and hence tailor your response.
It is widely acknowledged that these days, it is not a question of 'if', but 'when' an organisation will need to handle a security incident, and as every project manager knows, Proper Planning Prevents Poor Performance.
When you are reviewing your security controls, planning for a security incident in advance is incredibly important.