image

UPDATE:

Authenticated or Un-authenticated? That is the question….

Initial indications were that the vulnerability was authenticated RCE (i.e. you needed an account to exploit the vulnerability), but this is now no longer the case for Bamboo, FishEye and Crucible. On subsequent reading of the security updates by Atlassian and comparing the wording between each product advisory, it seems Atlassian have been a bit sneaky and are trying to hide the real impact. In the Confluence advisory it states:

“The attacker needs to have an account and be able to access the Confluence web interface.”

Whereas the Bamboo (and Fisheye and Crucible) advisory has:

“The attacker needs to be able to access the Bamboo web interface.”

No account needed! Yes everyone should read the advisories in full, but I’m sure Atlassian could have done more in highlighting the significant differences between Confluence and sister products advisories!

Sorry for any confusion and in future I’ll read each advisory in full before reporting.

 

Yesterday, Atlassian announced a critical vulnerability in its flagship product Confluence [1]. The vulnerability allows an authenticated attacker to run remote Java code on the hosting server. Confluence is a popular wiki and knowledge management solution utilised by over 10,000 companies worldwide. This vulnerability also affects their sister products Bamboo, [2] FishEye, [3] and Crucible [4].

Yesterday, Atlassian announced a critical vulnerability in its flagship product Confluence [1]. The vulnerability allows an authenticated attacker to run remote Java code on the hosting server. Confluence is a popular wiki and knowledge management solution utilised by over 10,000 companies worldwide. This vulnerability also affects their sister products Bamboo, [2] FishEye, [3] and Crucible [4].

Atlassian have communicated with registered customers saying all hosted solutions have been patched and the company is urging customers with in-house solutions to upgrade or apply workarounds.

While full details are still emerging; it is unclear how Atlassian was initially made aware of this, however the bug-track ticket was created on the 9th January 2015. In a short space of time, Atlassian have already made necessary changes on all affected services – hopefully suggesting the issue did not have time to be exploited in the wild.

Fingers crossed!

[1]https://confluence.atlassian.com/display/DOC/Confluence+Security+Advisory+-+2015-01-21
[2]https://confluence.atlassian.com/display/BAMBOO/Bamboo+Security+Advisory+2015-01-21
[3]https://confluence.atlassian.com/display/FISHEYE/FishEye+Security+Advisory+2015-01-21
[4]https://confluence.atlassian.com/display/CRUCIBLE/Crucible+Security+Advisory+2015-01-21


Written by
Ant-frame2Anthony Dickinson
Security Consultant
Corsaire

illusionist-149195_640
Using a simple trick I can guess your PIN for your debit card.
This normally works around 30% of the time. So here goes…

I’m seeing a 7, a 1, a 4 and finally a 5. Yes your PIN is
7145
Magic! Impressed?

Of course this is utter bullshit and I just randomly picked a number. I’m playing the numbers here. If enough people read this blog article, then probability says that I would be right some of the time!

This is how many online accounts are hacked; instead of targeting a single account and trying to guess the PIN or password, hackers select a simple PIN or common password and target a million accounts. Try 1234, fail? Move onto the next account and so on.  It’s a simple numbers game.

By using this method, hackers avoid common security measures to prevent brute forcing of an account, such as ‘account lock-out’ after 5 attempts etc.

In fact, the *game* can be made easier if the account identifier (username, email address, unique ID) is guessable or vulnerable to enumeration.

Use a strong, secure password!


Written by
Ant-frame2Anthony Dickinson
Security Consultant
Corsaire

Welcome to the Real World

Posted: 15 January 2015 in Uncategorized

Laurence-Fishburn-as-Morpheus

Hi, I’m Rowena, one of the newest members of the Corsaire team. This is my first ‘proper’ job as I’ve been at university for the past five years (first a Physics degree, followed by an Information Security Masters), so the world of work is a whole new ball game to me!

Expectations vs Reality

If I’m honest, I didn’t really know what to expect before I started this job. Having never worked in this field before, I wasn’t completely sure what working would be like.
I didn’t think my degree would help or prepare me, apart from some of the theory I learnt, so I expected it to be hard at first, as I had no prior experience. But I guess my main expectation of working at Corsaire was that I would be learning.

In reality, yes it was hard at first, and I have definitely had times where I’ve had no idea what I’m doing, but I’ve settled in and got comfortable in my role quicker than I thought I would. My learning expectations have all been met; I am continually learning, and as the field of Information Security is vast and changes constantly, so is everyone else around me.

My first few months have been spent training, learning methodologies and filling in gaps in my knowledge. Corsaire has given me my first opportunity to do security testing in practice and has introduced me to some great people who are always teaching me and keeping me on my toes.

So how does working compare to academia?

Well firstly, making money as opposed to spending thousands on degrees, is nice after five years!
Secondly, it’s more structured, I definitely prefer having a (somewhat) 9-5 day and my weekends free from assignments or lab reports.
Thirdly, there is more hands on practical experience with exciting and current projects, with more immediate job satisfaction where I don’t have to wait years for an idea on my progress or results.

Although the working world is different to academia, I have found my University experience to be more helpful than I originally thought. Deadlines, writing lab reports, problem sheets and the three hour lectures I sat through have given me time management, report writing and problem solving skills with a good theoretical foundation for security testing.

Leaving academia behind has been a bit of a struggle since it was the only lifestyle I have known for the past five years, but these past three months at Corsaire have brought me new challenges, new experiences and a new family. A very unique, bacon-filled family.


Written by
Rowena-frame Rowena Harrison
Security Consultant
Corsaire

Moonpig-dead

Happy New Year everyone, we’re only seven days in, and once again the news is filled with tales of woe that has security researchers cackling round our collective fire pits.

Moonpig, a London based company that is the UK’s largest personalised greeting cards specialist, have been caught out with an absolute shocker. The android application distributed by Moonpig used a RESTful Application Program Interface (API) to communicate with the endpoints and allow users to place and view orders and modify their accounts.

Security researcher Paul Price[1] identified a flaw in this API. The authorisation header sent by the application was a static username and password sent by every request within the application (which was latterly identified as not being needed at all). Further testing showed that modification of the ‘customer ID’ parameter of the request (a sequential value) allowed access to any users details including the ability to; easily place orders on other customers’ accounts, add/retrieve card information, view saved addresses and view orders.

The target site was configured to return a 404 error page that contained a link to help pages regarding the Moonpig API and other potentially sensitive details including internal DNS setup. This presented further API calls to test, such as the ‘getCreditCardDetails’ call, which returned; card type, customer ID, expiry date, last four digits and the card owners name.

Further chilling news comes within the disclosure timeline for this vulnerability. Turns out it was initially reported to Moonpig on the 18th August 2013 and blamed on legacy code within the environment. Moonpig stated that they would ‘get right on’ fixing the issue, however further notification was sent in September 2014 when the issue had yet to be resolved.

Moonpig finally took the API servers offline on the 6th January 2015, over a year after the initial report of the vulnerability, and sent out a less than assuring tweet, stating that ‘all password and payment information was and always had been safe’.

moonpig tweetWhich has been less than happily received by members of the public, several variations of ‘not quite true’ were uttered in reply.

This once again displays the criticality of ensuring that security is at the forefront of your development practices, both within the development life cycle and as a stage in and of itself. This particular vulnerability is clearly a breach of the Data Protection Act in the UK, which may levy a harsh fine on Moonpig that could be avoided with proper penetration testing, and probably cost decidedly less than the possible fine.

Security processes should be in place within any environment so that any detail of security vulnerabilities are addressed, as detailed above the initial report was submitted 18 months ago, only yesterday was action taken to mitigate the risk present.

The final message of this is simple: if a vulnerability is brought to your attention, do not simply ignore it, it could come back to bite you.

[1] http://www.ifc0nfig.com/moonpig-vulnerability/


Written by
Emma McCall
Security Consultant
Corsaire

Man-Pushing-Rock-Up-Hill

I naively thought the other day that I had come up with an original thought, namely that of an impending “informational” crisis. A quick Google search revealed however that the boffins at Gartner have been studying this for a while:

“Gartner predicts that, by 2017, 33 percent of Fortune 100 organizations will experience an information crisis, due to their inability to effectively value, govern and trust their enterprise information.”

Now, let’s be clear here, we’re not “just” talking about the rate of technological progress. While impressive, comparisons between the processing power of an old “room-filling” mainframe computer and the modern “fits in your pocket” smartphone simply aren’t illustrative enough to capture the mind-boggling growth of information.

If you hadn’t stopped to consider it before, take a look at this info-graphic from Intel. No that’s not a typo – 639,800 GB of global IP data is transferred every minute (not counting all the data in private networks). In this context, Gartner’s findings are hardly surprising.

If this makes you feel slightly queasy as an Information Security professional, I don’t think you’re alone. Even at a corporate level, the notion of trying to secure this amount of information is almost absurd. It brings to mind Albert Camus’ pondering on existentialism and more specifically absurdism as discussed in “The Myth of Sisyphus”.

“There is a fundamental conflict between what we want from the universe (whether it be meaning, order, or reasons) and what we find in the universe (formless chaos).”

Transposing this from the existential to the “informational” …

“There is a fundamental conflict between what we want from the technology (whether it be meaning, order, or security) and what we find in the technology (formless chaos and lolcatz).”

What options does this leave us with? Camus identified three (which I have warped to continue my analogy):

  1. Denial - Deceive ourselves into believing in a Magic Bullet which will deliver absolute security.
  2. Surrender - Conclude that progress is unstoppable and simply give into the overwhelming rate of information growth.
  3. Acceptance - Come to terms with and understand the fundamental contradiction of absolute security in the information age and vow to: reject any Magic Bullet solutions; act freely and innovatively to tackle emerging threats; and passionately engage in solving the diverse challenges.

I’m not sure about you but the right course of action seems quite clear to me… Who else is ready for the fight?


Written by
Jan-FrameJan Fry
Security Consultant
Corsaire

security-assurance

Why spend so much time implementing security solutions but not assessing them to verify they do what they should do, or at the least, what you intended them to?

The one thing that is evident from my last year assessing networks and systems is, just because you have introduced security systems or already have them in place does not mean your network or application is secure.

This may put a few non-technical managers on edge, but be aware that a firewall or security appliance does not inherently introduce security if it has not been configured or implemented in the right way.

It’s not unusual to have an Adaptive Security Appliance (ASA) [1] on the network, which should provide some form of segregation. However, in most cases the rules are not adequately configured, for example allowing ‘any’ to ‘any’ [2] rules, which usually results in any traffic allowed. In this scenario the ASA is just an overpriced fancy device producing no security benefits. In management terms, let’s just say your return on Investment is nil!

Another area worth highlighting is outsourcing, particularly cloud solutions and third party providers. Using such providers in your technology delivery does not necessarily shift the risk.  For instance, if your development process is outsourced and your application is compromised, it’s your brand/company that takes the primary hit.

What does this mean?
Security systems or devices by themselves do not provide any security assurance. A web application investment (WAF) [3] does not mean that your applications are automatically immune and neither does an intrusion prevention system (IPS) [4] automatically block attacks if not adequately configured and maintained. In other words, security appliances may not necessarily provide security by default.

Security testing is a way of assuring yourself that systems, devices and applications are able to withstand and neutralize attacks, proving the investment in security systems has been worthwhile.

 

[1] http://www.cisco.com/cisco/web/UK/products/security/asa_software.html
[2] http://www.firewalls.com/blog/firewall_rules_any/
[3] https://www.owasp.org/index.php/Web_Application_Firewall
[4] https://www.paloaltonetworks.com/resources/learning-cente r/what-is-an-intrusion-prevention-system-ips.html


Written by
Chioma-frameChioma Nwabuko
Security Consultant
Corsaire

Misfortune-cookie

What is it?
Misfortune Cookie is a critical vulnerability that gives an intruder the capability to remotely hijack home and business Internet routers. [1]

What does it do?
Once the attacker has commandeered the router, they have the ability to monitor your web browsing, access your credentials, distribute malware and even the ability to control any devices connected to the network (including tablets, security cameras and kitchen appliances such as toasters)!!

What is Vulnerable?
At least 200 different models of devices are currently exposing a vulnerable service on the public Internet address space, the majority of these are residential and small business networks.

What can you do?
Check your security settings – add passwords to sensitive data, don’t save your credentials to your browser and encrypt browsing data with HTTPS connections [2].
Patch it! – There are currently no patches available, but watch out for firmware updates from your device vendor and apply as instructed.
Endpoint Protections – Whilst your router has its own layer of security defences, further protecting your network with endpoint protections is vital (firewalls, anti-virus software and up-to-date operating systems).

Key signs to look out for:
There are no ways to trace the Misfortune Cookie, but look out for tell-tale signs such as a change of settings on your device and trouble logging into your web interface.

 

[1] http://mis.fortunecook.ie/
[2] http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/


Written by
faye-frameFaye Brennan
Marketing Assistant
Corsaire