Like in most professional sectors, penetration testers ask themselves whether machines are capable of taking over their job. In many sales speechs, customers are saying that you no longer need manual web security assessments because automated tools will the same job cheaper. Customers refer to so-called Web Application Security Scanners. These are programs that automatically scan web applications for security vulnerabilities. In the post, we will review the effectiveness and accuracy of web application scanner.
Can you tell how many devices are connected to your internal network at this moment? If so, how much do you know about these devices? Do you know which operating system is running on a specific IP address? Or when did this device first appear on the network? Which client has an important security patch missing?
This post is about identifying your IT assets (hardware, software, data), detecting unwanted devices and what Shadow IT means.
Distributed computing is an awesome approach to distribute workload of huge tasks and easily outsource them, if needed. It makes computing tasks scalable and cheap, as cloud computing is involved. Computing time can be rent, which is mostly cheaper compared to buying the necessary hardware. However, outsourcing into foreign networks comes with the advantages and drawbacks of public infrastructure. Public networks cannot be trusted, therefore, traffic should be encrypted and connections should be authorized, which sounds easier than it is when using Python frameworks such as Dispy, Celery or Twisted.
Although implemented in the core of the frameworks I used, security is optional, sometimes flawed (e.g asynchronous cryptography in Dispy which uses the same private as well as public key on client as well as on server side, otherwise it will not work) and often with lack of good documentation.
The main priority of official tutorials is to make it work, period – so developers test the shown code and use it, without bothering about further security steps. Tutorials showing working code with all needed encryption and authorization steps are rare. Often framework developers are showing the needed parts separated, but not the complete setup. So developers have to spend a lot of time puzzling all needed steps together. Security should be implemented by default, which unfortunately is not often the case in official framework tutorials. It was therefore not easy to find documented literature to implement the frameworks in a secure way. Sometimes, the frameworks did not even offer complete secure solutions. Let us have look at a framework called Twisted in combination with a JSON-RPC server and how to secure it. There is still room for improvement, but I hope this blog-post will help developers hardening and securing their software a little bit more.
The example code can be found here.
A penetration test – also known as a pentest – is a security and risk assessment of an application(s) and/or a system(s) performed by an IT security professional using manual, and sometimes, automated tests. While automated tests are meant to find low hanging fruits and maximize the coverage of the assessment, manual assessments are still required as many use cases cannot be tested or accurately identified with automated tests.
Anyone who has read the recent news of Yahoo’s data breach which affected around 500 million accounts will probably have questioned their own organization’s ability to defend itself against external attacks of all sorts.
The task of maintaining defences in the face of constant threats is often partly owned by two IT security groups, the “red”and “blue” team.:
Red: focused on testing the effectiveness of the organization by acting as hackers, using penetration testing techniques to identify and expose vulnerabilities. They will use offensive tools and use SQL injection, scan the network and be familiar with firewall and router commands.
Blue: take the role of defending the organisation, being constantly vigilant and ready to respond to any attacks. They will be expected to recognize unusual patterns, behaviours or outliers, and establish how and where attacks are about to take place. The blue team monitors the systems such as the central log file management system and scans this for signs of attempted entry.
Whilst this role playing is a familiar exercise, there are potentially dangers if the approach is not regularly reviewed:
- The mindset and culture developed in an organisation over time can inhibit fresh thinking both in terms of where and how to typically attack, and equally defend against these attacks. It does not prepare teams for a concerted attack by strangers who have no respect for the system.
- Teams can become stuck in their ways and “go through the motions”, repeating similar attacks to the last role play.
- As Einstein once said, “We can’t solve problems by using the same kind of thinking we used when we created them”. Unless exceptional, over time, many employees become conditioned by their surroundings and view situations based on their perception of established norms, and the prevailing culture. This can restrict fresh thinking and lead to a narrow testing focus.
There a number of activities which can help keep the red/blue team sharp and effective:
- Regular rotation: it is recommened to switch parts of each group g. 50% change sides on a frequent basis. This improves cross-team skills and also creates a view on how „the other half think“.
- Full debriefs: after each game play has taken place, each team should explain and document how they were successful (either in attacking or defending), so learnings are formalised and captured.
- Continuous learning: funds and time permitting, create an education budget for each team member where they can choose to attend a conference, external course or online learning and increase their knowledge base. It demonstrates investment in talent and also assists team morale.
- Incentivise: introduce a trophy that is passed between teams (e.g. for not being hacked this quarter/half year etc), with the red and blue team exchanging ownership based on which was successful in the last role play.
- Review the team composition: typically in a team of 10 people, three would be responsible for IT Sec Engineering, 5-7 would take a SecOps/Incident response (usually outsourced) role, and two would act as pen testers. How does your team’s make-up look?
- Explore 3rd party participation: a real attacker doesn’t play by the rules or follow established thinking, and is going to overlook any rule, etiquette, company guidelines and ethical issues. Sometimes a genuine outsider approach is needed that does the unexpected, not permitted, daring or simply blindsides the blue team.
FOXMOLE’s penetration testing team has extensive experience in responsibly attacking client sites to identify weaknesses, whether based on an open brief or a speciifc area of concern.
The greatest opportunity offered by commissioning an external group is the discovery of pervasive, underlying vulnerabilities that have not been addressed as these were simply not on the radar. Remedial action plans can be developed in conjunction with clients, with scheduled progress review points.
Lack of mitigations
One example of this is the absence of a patch process, which is surprisingly frequent. Once a vulnerability with an internal or external application has been identified, how is a patch issued, and how quickly is the fix implemented? The issue is that the processes are not reoccurring as frequently as they should, leaving a window of opportunity for an attacker to compromise the system with known vulnerabilities. FOXMOLE has also observed that the patch process does not address all layers, for example only the server patches are applied, but not the service-layer, the used frameworks or the applications are part of it.
Too often we see either a piecemeal approach that only addresses part of the network, or a reinvention of the wheel each time – as if a patch has never occurred before. With attacks more than likely to succeed at some point (however small), it is time to factor in how these would be remediated so minimize the chance of reoccurrence.
Insider threat often underestimated
In modern company culture that often stress (rightly) collaboration, assumption of best intent and HR/privacy guideline adherence, it can be hard to stress the need to factor in actions by a disgruntled employee. A Forrester Research report, “Understand the State of Data Security and Privacy,” showed that 25% of survey respondents the most common breach occurred in the past year at their company derived from abuse by a malicious insider. If that insider has privileged account access, the risk is particularly significant.
One failure FOXMOLE sees in this respect is a focus on policies and the main solution. Companies tend to protect against external threats; they patch every external server-system (available from the internet) and do not do that for internal systems (same applies to hardening…). In the end, the important systems (which often are not available from the internet such as SAP, HR-Systems, Customer Analytics,…) are in a weak security state (default passwords on the databases, old patch levels…). This means that anyone with access to the local network (an insider, subcontractor) has a very soft target which enables them to steal the data. In addition, if employees can bring their own devices (subcontractors with own laptops) they normaly have administrative rights with them and can bring their own attack tools and have all the time to exploit systems and extricate data – since no corporate compliance tool will typically check these BYOD devices.
Poor password practices
This seems like an old “classic”, but these present issues in multiple ways. A recent study in Luxembourg revealed that over 40% of respondents would share their passwords in return for chocolate. The significance of handing over a password still seems not resonate. Sharing password for admin accounts may be convenient and time-saving but presents major risks. Another challenge is laziness in creating passwords themselves, with “123456” or “welcome” remaining popular and of course easily hackable choices. Whilst it is hard to remember a wealth of complex passwords in work and personal life, using “password” for example, is not the smartest idea.
Linked to this is the fact that few companies seem to enforce strong passwords, or do not store the passwords in a secure manner (bcypt, scrypt with salts). It is essential to combine strong password policies with frequent password change requirements that will decrease the selected passwords to avoid predictability! Recent research showed that 63% of confirmed data breaches involved weak, default or stolen passwords.
General awareness of security
This may seem like a catch-all topic, but it’s really just a simple mindset issue. It’s about taking care of the basics such as locking the desktop, vetting sub-contractors, challenging non-familiar faces, not allowing visitors to walk around the building unescorted and not leaving valuables in the office. One service FOXMOLE offers is the “evil cleaner”; which involves consultants spending five minutes in an employee’s office to see how much could be taken by regular office presence with bad intentions.
Adherence to manual approaches
In a app-driven world, it is still a shock to witness the lack of automating of security and the modeling of this all into all processes. Addressing human weaknesses such as errors, laziness, absence of a repeated and consistent approach through automation is essential as the type, volume and complexity of security threats increase. FOXMOLE has observed on multiple occasions an absence of a defined, transparent and robust security framework.
There are no doubt many other common failings – look out for some more observations in a future blog!
During an internal evaluation of the social networking solution HumHub, the senior security consultant Eric Sesterhenn from LSE Leading Security Experts GmbH discovered an SQL injection vulnerability in versions 0.11.2 and 0.20.0-beta.2. The vulnerability allows read/write access to the underlying HumHub MySQL database. This includes full access to private user data and all conversations.
For further Informations about the LSE Leading Security Experts please visit our website www.foxmole.com
During an internal development project LSE Leading Experts GmbH employee Markus Vervier discovered a vulnerability in the Extension Data::Dumper which is contained in Perl-Core. When processing large recursive data structures, a Stack-Overflow is triggered, which could be used for attacks depending on context.
The issues have been found in PERL Core v5.20.1
Read more in the corresponding Security Advisory
Während eines internen Entwicklungsprojekts entdeckte der LSE Leading Security Experts GmbH Sicherheitsexperte Markus Vervier eine Schwachstelle in der Extension Data::Dumper, die in Perl-Core enthalten ist. Durch Anlegen von großen Daten Strukturen kann ein Stack-Overflow erzeugt werden, der abhängig vom Kontext für Angriffe verwendet werden könnte.
Die Sicherheitslücken wurden in Perl Version v5.20.1 gefunden.
Weitere Informationen können Sie dem von LSE bereitgestellten Security-Advisory entnehmen.
During an internal evaluation of the Granding Grand MA 300 Fingerprint Access Device, the LSE Security Consultant Eric Sesterhenn discovered multiple security issues regarding the administrative PIN authentication. The flaws in the authentication protocol allow to reconstruct the PIN from sniffed data and effective brute-force attacks.
The issues have been found in firmware version 6.60.
Read more in the corresponding Security Advisory