Shared posts

09 Jun 16:45

The mechanics of the iCloud “hack” and how iOS devices are being held to ransom

by Troy Hunt

If you’re an Aussie with an iPhone, there’s a chance you’ve been woken up in the middle of the night by this:

"Hacked" iPhone showing ransom message

Oh boy. What we’re looking at is an iPhone that has been remotely locked by “Oleg Pliss”. What we’re looking at is a modern incarnation of ransomware executed via Apple’s iCloud and impacting devices using the “Find my iPhone” feature. Perplexingly, this is predominantly impacting Aussie iCloud users and to date, there’s no clear reason why, rather we have 23 pages of reported hacks and general speculation on the Apple Support Community website.

I’ve been speaking to a bunch of people about this over the last couple of days about this attack so I thought I’d collate some info on how it works, what we know and what the possible sources of the attack may be

The “Find My iPhone” feature

Here’s the promise of the Find My iPhone (or iPad or Mac) service: if you’re like my wife who days after buying her iPhone lost it down the beach somewhere never to be found again, rather than combing through the sand and spending hours desperately searching for it, you can pinpoint it’s position using the Find My iPhone app (obviously on someone else’s phone!). It looks like this:

iPhone and iPad demonstrating the Find My iPhone app

Here the iPad is running the app (the phone is in “Lost Mode” so you can see where it’s been travelling over the last 24 hours) and the “lost” phone has had a message sent to it asking for the owner to be called (clearly on another number). You can also play a sound (great for those times when you've lost it down the back of the couch) or remotely erase all your data. And finally, if the phone doesn’t already have a PIN on it (you know, the one you should enter each time you turn it on), you can remotely set one.

Per Apple’s advice, here’s how to handle a lost phone:

If your device goes missing, put it in Lost Mode immediately. Enter a four-digit passcode to prevent anyone else from accessing your personal information.

Once you’ve locked it so that nobody else can gain access to it, you should send it a message:

Sending a message to the lost iPhone

And that’s that. The honest person who finds your phone won’t be able to access your data, will have a nice little message and a means of contacting you and just to be sure they know you’re looking for it, you can ask it to blare out a nice loud noise (yes, this still works when the phone is muted).

If you’re an attacker with access to someone’s iCloud, you can do exactly the same thing which brings us to the present spate of attacks.

How the attacks are being executed

The evidence at the moment suggest that the attacker is simply using the process above to remotely lock peoples’ devices and then demand cash in return for him unlocking the device. (Of course given the victim’s device is now locked, assumedly the attacker would have them use someone else’s machine to send payment.)

Let me walk through the attack from end to end using my primary phone as the attacker (an iPhone 5) and my backup phone (an iPhone 4) can be the victim. The whole thing may well be more sophisticated and automated than this, but here’s how to reproduce the process using the intended function of iCloud and Find My iPhone:

The attacker first compromises the victim’s iCloud account (more on how they might do that in a moment). Once they have access to the account, they fire up Find My iPhone on their own device and log in as the victim. They can now see all of the victim’s devices including where they are physically located (assuming they’re communicative, that is they’re turned on and have an internet connection via wifi or telco):

Devices managed by iCloud account

Here we’re seeing my iPad, my primary iPhone (the one that says “This Device) and my test iPhone that will be the “victim” (the one that’s “Updating Location…”). I’ve selected the victim’s device which now gives me as the attacker a number of options:

A device managed by the iCloud account

I’ve now put the phone into “Lost Mode” which begins a wizard with a series of steps, firstly confirming that I do indeed want to assume the device has been lost:

Turning on "Lost Mode"

Once confirmed, this is where things get nasty for the victim: the attacker can now define a PIN that will lock the phone:

Remotely setting a PIN on the "Lost" device

They can also provide a number which will be presented to the person who “finds” the lost phone which of course in this case, is actually the legitimate owner:

Setting a number to be contacted on when the phone is lost

The next step is to enter a message to be displayed and this is the one demanding the ransom:

Setting a message to send to the "lost" device

Once that’s done, iCloud will contact the “lost” phone and lock it with the PIN:

Result screen showing that the device will be put into "Lost Mode"

Next, as the hacker I hit the “Play Sound” button and the victim’s phone starts blasting at full volume (again, regardless of if it’s muted or not and regardless of the current volume setting). This is what many victims were reportedly woken up by at all hours of the night.

As for the victim’s phone, it now looks like this:

The "victim's" device showing the ransom message

Any attempt to unlock the phone now requires the PIN that only the attacker has. And that’s it – that’s how the attack is executed.

But of course it all begs the question – how is this attack happening? Isn’t iCloud “secure”? With no hard evidence we can only speculate, but there are some likely suspects.

Password reuse

In a situation like this, the answer which makes the least assumptions is probably the right one and on that basis the attacker is simply logging on with the victim’s username and password. This means of attack makes no assumptions about a direct vulnerability on Apple’s end, rather it recognises the reality that people make very, very bad password choices. Bad password choices include predictable passwords (keyboard patterns, common names, etc.) and of course, reusing the same password across multiple independent services.

But this alone doesn’t explain the sudden spate of attacks against iCloud in the last couple of days, instead there’d need to be some sort of precursor and in the context of password reuse, that would usually be the compromise of another service. Some people have suggested that the eBay attack from last week is just that – the means by which credentials were exposed upon which they were then used to gain access to iCloud accounts using the same username and password. This is unlikely for several reasons.

Firstly, eBay is obviously a global service and if indeed 145 million “active” users were compromised as they’ve said, it’s unlikely we’d see the data then used in attacks against an almost exclusively Australian audience. We have less than 1% of the global internet audience down here so short of the eBay compromise being isolated to an Aussie audience for some reason, this just doesn’t add up.

Secondly, whilst we don’t know the actual details of the cryptographic scheme, eBay has made assertions that the passwords were “encrypted” and shouldn’t be readily retrievable even when breached. Of course we’ve seen a lot of motherhood claims like this from a lot of companies that have turned out to be way too optimistic, but you’d expect eBay of all companies to more likely than not do a good job of this. Yes, they’ve done the arse-covering exercise of asking people to change passwords, but the likelihood of passwords being cracked and floating around in the clear is much lower than what we’re used to seeing.

Thirdly, the breach has never been made public like it was with Adobe and many, many other breaches both before and after them. This is not the common hacktivist pattern of, say, Bell in Canada where the attacker grabs all the passwords in an unencrypted format then posts them all up for public display. It’s not that by a long shot.

No, it’s unlikely eBay but it could be a breach of a local service containing predominantly Australian users. Whilst I’m not aware of any recent attacks that fit that criteria, there’s every chance there’s an as yet undiscovered breach somewhere, certainly that’s a common enough scenario. Mind you, we are seeing international iOS users beginning to be impacted by this breach as well (albeit in what appears to be comparatively small numbers), which is a bit of an exception to that theory, but we may yet find there’s still a commonality in a breach somewhere.

In terms of victims simply having weak passwords that were “brute forced” (i.e. the attacker just keeps trying different ones for a particular user), it’s unlikely Apple’s systems would have facilitated this, at least not by design. Multiple login attempts for a single user are easily detected and fraud protection measures are in place in most services of this nature.

Lost password process exploit

Another possibility is an exploit in the process that follows a “lost” password. Typically this involves an identity verification process and depending on the service, it may take on different forms. For example, in testing a random email address, Apple’s iForgot service offered to authenticate the user via their email:

Using the iForget feature to reset a password

Clearly the risk here is that if the user’s email has been compromised and again, this could be due to simple password reuse, then this provides the key to unlock the Apple account. I wasn’t able to proceed with this process because my Apple account uses 2 factor authentication (more on that later) and requires a special “recovery key”, but a common part of a lost password process involves both an email and then verification of a “secret question”.

I’ve written about this sort of process before and pointed out that particularly when it comes to secret questions, it’s easy to leave a gaping hole in the security profile. In that post I refer to the precedent of Sarah Palin’s Yahoo! email account being hacked by exploiting the password reset feature simply by the hacker being able to discover her high school and birthdate which are obviously both easily obtainable pieces of information, particularly for a public figure.

Alternatively, there may also be a flaw in Apple’s human support process and certainly we’ve seen that exploited in the past in order to compromise an Apple ID. But that would be a very laborious effort compared to what could potentially be automated in an attack and we’re more likely to see this in a spear phishing style compromise of an account.

While I mention phishing, of course this could all be the result of a very effective phishing attack, but it would have to have been very targeted at the Australian audience to result in the bias that we’re seeing in the victim’s location. Large lists of email addresses are very easily obtainable (there’s 152 million courtesy of Adobe that anyone can go and grab right now) and would be unlikely to see one both so localised and so effective against those of us down here. Not impossible mind you, just not a likely explanation.

Is there a vulnerability in iCloud?

Of course the first thing people assume when they see their locked device is that somehow, Apple is to blame. It must be a vulnerability in iCloud, right? Ben Grubb from the Sydney Morning Herald got this response from them earlier today:

Apple's response to the attacks blaming poor password practices

The generic and frankly meaningless “we take security seriously” statement aside, Apple is denying any compromise of iCloud and implying that weak user credentials are to blame. They may well be right, but the response reeks of a canned message with little attempt to actually address the specific concerns of users.

Personally I believe it’s less likely that iCloud has a vulnerability that’s causing this than it is that people simply make bad password choices, but their response is dismissive and does little to reassure their customers. For a company that’s so focussed on the overall user experience of their products, this is an odd response and I would have hoped for more. That said, they’re undoubtedly investigating this behind closed doors and if the attacks mount – particularly globally – at some point they may well be forced to respond in more detail.

Some people have speculated that last week’s news about an iCloud hack is related to this week’s events. This is a very different context – the research Doulci did refers to the ability to unlock phones they have in their hand thus circumventing the controls that are meant to deter theft (i.e. you steal someone’s phone and you won’t be able to do anything with it). This was not about the ability to remotely lock someone else’s phone they had no access to. Maybe there’s a connection somewhere – perhaps they discovered other risks at the same time (one that predominantly impacts Aussies…) – but for now these two incidents seem unrelated.

DNS poisoning

One of the suggestions that has regularly popped up in that original Apply support forum I referred to earlier is a possible “DNS poisoning” due to people using the popular Unblockus service  to circumvent geographic controls on foreigners watching US content such as Netflix. The service depends on customers changing their DNS settings or in other words, giving this third part control over the service which resolves names such as apple.com to actual servers on the web.

In a DNS poisoning attack, the hacker would compromise the DNS service such that a request for, say apple.com, would route to a server of the attacker’s choosing. In theory, this would then allow them to access traffic between the victim and the intended service.

This is unlikely for a couple of reasons. For one, the service is used broadly across the globe and Australia is but one of the countries with an audience routing their DNS through Unblockus. Most importantly though, this is the entire premise of encrypted communications on the web using SSL; even when the connection is compromised, the traffic remains secure between the client and the server. Short of a compromise of the certificates Apple uses or a compromise of a certificate authority which lead to the issuing of rogue certificates (DigiNotar is a good example of a precedent), this is highly unlikely.

Is it the Chinese / Russians / NSA?

They’re into everything anyway, right?! We tend to identify three common classes of online attacker:

  1. Hacktivists: often just kids out for kicks that are opportunistic and not particularly sophisticated
  2. Career criminals: the most likely scenario here given the attack is clearly financially motivated
  3. Nation states: the guys in the heading above (among others)

There’s a definite upside to nation states compromising iCloud and I’ll touch on those in the next section, but that upside doesn’t include trying to skim a hundred bucks a pop off victims. Indeed blasting out their presence is the last thing a nation state would want to do and slipping in under the radar is their entire MO so no, it’s almost certainly not these guys.

A ransom is just scratching the surface…

Locking a phone and asking for $100 is a fast grab for cash. Put the victim in a vulnerable position, offer a quick fix costing what for most is an easily obtainable amount of money and that’s it, job done. But access to someone’s iCloud offers much, much more potential than just a small ransom.

For starters, many people back up their devices automatically to iCloud so their entire iPhone and iPad contents are sitting up there in Apple’s cloud. An attacker with control over someone’s iCloud has the ability to restore one of these backups to their own devices which means they get the victim’s photos, videos, documents, iMessages, email stored on the device and basically any conceivable digital asset the victim has on their iPhone or iPad. It’s a very large collection of extremely personal data.

Beyond backups, an attacker also has the ability to silently track the movements of the victim. We saw that earlier on when I reproduced the attack and the Find My iPhone app presented the location of each device on a map. Clearly that creates the potential for a serious invasion of privacy, particularly when you consider that families often have multiple devices under the one iCloud account.

Of course it’s not just iDevices connected to iCloud either and indeed we’ve already seen Macs impacted as well. The reality is that our digital lives are so intrinsically chained together across otherwise independent devices that a breach of a common service like iCloud can have very broad-reaching ramifications. The Epic Hacking of Mat Honan a couple of years ago was a perfect example of the devastation this can cause; not only did the hacker compromise his Apple account (in that instance, via social engineering), he also compromised Mat’s Gmail and ultimately used his Twitter account to start sending out racist tweets. The hacking of an Apple ID can have a very long tail indeed.

Other ransomware attacks

This attack falls into a class we’d often refer to as ransomware, albeit not via malicious software which is how we’ve traditionally seen similar attacks launched. Regardless, the modus operandi is the same – the attacker locks up the victim’s files and won’t release them until a sum of money is paid. Ransomware attacks can be extremely effective in that they’re often not easily circumvented once mounted and indeed previous attacks that have relied on malware have used very effective encryption algorithms to lock up victim’s files.

These attacks often rely on malware like CryptoLocker and indeed they’ve impacted Aussies in the past. A couple of years ago it was a doctor’s surgery on the Gold Coast that got hit with demands of $4k in order to obtain the encryption key and release the victim’s files. This was one of the more high profile incidents, there have been a huge number of others that haven’t hit the headlines.

Clearly, holding digital assets for ransom can be a lucrative business.

Recovering from the attack

I’ll start by deferring to the Aus government’s advice on the Stay Smart Online websitedon’t pay the ransom! There are a couple of ways to recover from the attack and Apple outlines them in their Forgot passcode or device disabled knowledge base article. In short, one way around this is to simply restore from a backup via iTunes. Of course that’s dependent on you actually having a backup in iTunes and indeed Apple have regularly promoted backing up to iCloud as a preferable mechanism (remember, this is apparently the “post-PC” era). But even if there is a backup, there’s the question of how recent it is – have you possibly just lost a week of kid photos? A month? A year?

If you were backing up to iCloud then you can always restore from there. Of course that’s also dependent on actually being able to access iCloud in the first place, you know, the place the attacker already controls! If he’s elected to change the password (and so far I’ve not seen a report of that in this recent spate of incidents), then you might be in for a password recovery process assuming they haven’t also compromised your ability to do that. Oh – and of course all this assumes that they haven’t deleted the device backups from iCloud altogether.

It’s a nasty chaining of events and if it all seems a bit too much for some people, there’s always the option of a visit to the local Apple store who should be able to put them back on the right track.

Mitigating the risk: Strong password, PIN and 2 factor authentication

The defences against this threat are nothing new, indeed they’re the very ones that have so long been advocated by so many of us in the security field and they break into three simple steps:

  1. Use a strong password on the Apple ID: This is online security 101 and any reuse of a password across services is just asking for trouble, particularly when it’s protecting something as valuable as iCloud. Make it unique, make it long, make it random.
  2. Use a PIN on the device: iPhones and iPads that have a PIN don’t present the attacker with the ability to set their own. That screen earlier on where I remotely locked the device is only presented when it doesn’t already have a PIN so that immediately thwarts this attack. Even if the device is just for the kids, if you connect it to iCloud, put a PIN on it (don’t worry about it making life hard for them, kids have an uncanny ability to access a device protected by nothing more than four numbers).
  3. Enable 2 factor authentication on the Apple ID: This is another fundamentally good practice and it involves configuring the account such that any attempt to login from a web browser or a different device requires you to verify the login request using “something you have” and not just “something you know” which is the Apple ID password. This puts a dead stop to attacks that abuse credentials and you can read about it on Apple’s FAQ about two-step verification. Just one note on that – there’s a three day lead time to activate it so in the context of this risk, it doesn’t immediately grant you any protection so get the ball rolling now!

Again, these are all just fundamentally good practice that should be in place anyway. If you don’t have all these three boxes checked across all your devices, get them in place as a matter of priority.

Should you stop using iCloud?

I’m going to go with a “no” here with a preference to properly securing your iCloud as opposed to not using it at all and running other risks. Yes, you could avoid using it but then you have to weigh up the risk of losing your phone and not being able to find it again or the risk of not backing up the device then having it lost or corrupted and losing valuable digital assets.

When the aforementioned mitigations are in place, the security provisions offered by iCloud are in my opinion more than sufficient to adequately protect the device when you consider the risks you run without iCloud. That might sound like a very caveated statement and it is: that’s my view for my risk assessment and the value I place on the service, other people may be more wary or less worried about things like backups and the therefore take a different path.

The last thing I’ll say on this topic is that whilst the most likely explanations may be obvious, I’d keep an open mind regarding assumptions on how all these services work. Don’t discount as yet unknown flaws (at least unknown by everyone who isn’t the attacker), and exploits that may well circumvent what we otherwise hold to be truths about how the iCloud service works. We may well yet be surprised by the ingenuity this guy has shown to execute what has arguably been a very impactful attack against Apple device owners.

This still has a way to go before everything plays out and frankly, I doubt that anyone outside Apple and the hacker himself know exactly how this whole thing has been possible (and I’m not even that sure that Apple do). What I do know though is that it only appears to be impacting those who haven’t been able to tick all the usual security boxes and as inconvenient as the whole thing may have been for them, it should be of some reassurance for the rest of us.

Update, June 10: The attackers have now been caught and their means of hijacking iCloud accounts was... phishing. Why it was so targeted at an Australian audience is still not clear.
06 Jun 14:38

OSX malware and exploit collection (~100 files) + links and resources for OSX malware analysis

by Mila


'Tis the season.

Here is a nice collection of ~100 Mac OS malware and Word document exploits carrying MacOS payload (all are CVE-2009-0563) along with links for OSX malware analysis.

Please send your favorite tools for OSX if they are not listed.




CVE-2009-0563

CVE-2009-0563
Stack-based buffer overflow in Microsoft Office Word 2002 SP3, 2003 SP3, and 2007 SP1 and SP2; Microsoft Office for Mac 2004 and 2008; Open XML File Format Converter for Mac; Microsoft Office Word Viewer 2003 SP3; Microsoft Office Word Viewer; and Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP1 and SP2 allows remote attackers to execute arbitrary code via a Word document with a crafted tag containing an invalid length field, aka "Word Buffer Overflow Vulnerability."



Links



Some OSX malware analysis tools and links 


Tools


Malware in the provided package - links to research and news articles






Download



Download. Email me if you need the password
OSX_CrisisB_a32e073132ae0439daca9c82b8119009 
Additional older downloads

  1. OSX_Docklight payload  http://contagioexchange.blogspot.com/2012/05/019-speechdoc-macosxms09-027a-word.html 
  2. misc OSX malware on contagio http://contagiodump.blogspot.com/search/label/-%20OSX
  3. 30 samples of ancient Mac OS malware http://contagiodump.blogspot.com/2012/04/osxflashbackk-sample-mac-os-malware.html



List of files provided in this post


  1. OSX_AoboKeylogger_362D5DDB3924C625589B42030B66CA69
  2. OSX_BackTrack-A_B03276BFBF85CFDD7C8998004C1200DA
  3. OSX_Boonana_B3A0B0DA5AA01FF200CEBC8AF359A3C3
  4. OSX_ChatZum_487E5CD581587D63783CDD356DE9CF24
  5. OSX_ChatZum_57A4EB15CAA4FCC0A8F6AFBBD66C4859
  6. OSX_Clapzok_99FE5AD5FF514F5AAEA8E501DDBAF95B
  7. OSX_Crisis_04BBDA5B11FA0FD3C767CAF4719D6A4D
  8. OSX_Crisis_42C112036E319ED8DF0F55C7F4C0DA85
  9. OSX_CrisisBOSX_CrisisB_a32e073132ae0439daca9c82b8119009 _a32e073132ae0439daca9c82b8119009 
  10. OSX_Crisis_59FE83E0AE12E085E0FA301ECCA6776F
  11. OSX_Crisis_6F055150861D8D6E145E9ACA65F92822
  12. OSX_Crisis_A32E073132AE0439DACA9C82B8119009_Biglietto Visita
  13. OSX_Crisis_ACEC5F00057D3EC94849511F3EDDCB91
  14. OSX_Crisis_FAAB883598C8C379ACFD0B9DCCC93D0C
  15. OSX_Dockster_Backdoor_C6CA5071907A9B6E34E1C99413DCD142
  16. OSX_FkCodec_74812C7B6E0A55347284ABFA7D5670BF
  17. OSX_FkCodec_74812C7B6E0A55347284ABFA7D5670BF_Codec-M
  18. OSX_FkCodec_B4ECE10D1E706B87B065523A654D48A7_download.dmg
  19. OSX_FkCodec1C5AE9F1DD9FE6F506EAABD382925CA8_codec-M.safariextz
  20. OSX_Flashback_3DCB6D6A9EA8D9755EB61AE057B3D74A
  21. OSX_Flashback_9FCFE8EF92F51F1C29A26E1516EF7003_FlashPlayer-11-macos.pkg
  22. OSX_Flashback_C2819C3C183BBF7547CF76C6A004EA15_FlashPlayer-11-macos.pkg
  23. OSX_Fucobha_IceFog_A615DD792093191E9FC975132A2DB409A_CleanMyMac
  24. OSX_Fucobha_IceFog_B4249F9B49A9A177B4D2F4439373029A
  25. OSX_Fucobha_IceFog_CF1815491D41202EB8647341A8695E1E
  26. OSX_GetShell_68078CBD1A34EB7BE8A044287F05CCE4
  27. OSX_GetShell_AC99ACE403D31C7079C938F9B0FD0895
  28. OSX_GetShell_ACC2B4A595939F17F7D07DE2CF75CDC8
  29. OSX_Hacktool_Hoylecann_FED8E22AE6F080F9B05A309C7E48B5EF
  30. OSX_HellRaiser_CA74984601287459AFB7B39EBEBDD394
  31. OSX_HellRTS.AH_KeystrokeRecorder X Pref Editor_C19377D07A234D1585D85F8FA3CF77FB
  32. OSX_HellRTS_F1AD75AEB4B4C2883DF2221C8804DA2A.AH
  33. OSX_Hovdy_Backdoor_FED713CAC7012D25F60B236E6DDCF513
  34. OSX_Inqtana.zip
  35. OSX_Iservice_4C9E7EE7C0F5C19C68B45CA6C81F8D62
  36. OSX_Iservice_E34BA325F3EEB8DF07A09EE9FBF1071D
  37. OSX_Jahlav_12F32EACBB3CD2C5623EE6976A51913A_QuickTime.xpt
  38. OSX_Jahlav_CCB72243EF478EEFE90B5898EC32389B
  39. OSX_Jahlav_D7DDF72D17F889C2C5B302AC0A5FBDC5
  40. OSX_Jahlav_FB79A75A6152EF47BBF88AE8544545CC.pl
  41. OSX_Jahlav_flash.zip
  42. OSX_Kitmos_A_39FAA22EB9D6B750EC345EFCB38189F5
  43. OSX_Kitmos_A_3AA9C558D4D5F1B2A6D3CE47AA26315F
  44. OSX_Kitmos_A_B3D49091875DE190F200110C2F2032D4
  45. OSX_Lamadai_20F0D0CE8A413A51EB16DEE860021E6A
  46. OSX_Lamadai_DE90189F040494E3708D83A33E37E40E
  47. OSX_Leverage_A_Backdoor_C425D2BE8B4AF733A44EC1518F182BE8
  48. OSX_LocalRoot_3DC01743FB42E917E9F9EDE5009F10CD
  49. OSX_Macarena_A_BFC7B7B9D3E1DF9D6E1A31D3E7BED628
  50. OSX_MacDefender_8AE7163C7C3C02564A4C69DF1F7C483E_Archive.pax
  51. OSX_MacDefender_E187F4071723808560E135647245562A_Archive.pax
  52. OSX_MacKontrol_89C35C057655E67580EFD0FF8242D960
  53. OSX_MacKontrol_E88027E4BFC69B9D29CAEF6BAE0238E8_matiriyal.dmg
  54. OSX_Macsweeper_4836CC480796386ED6929C38E5AAD525
  55. OSX_Miner_DevilRobber_417369B713F1A5F3A3DC0DAF76BDCFD6
  56. OSX_Miner_DevilRobber_EE2BA586232007FA41703EB120AC7408
  57. OSX_Miner_F8EBF03E88928EBF91A8420E3D5993FE
  58. OSX_Olyx_Backdoor_93A9B55BB66D0FF80676232818D5952F
  59. OSX_Olyx_Backdoor_93A9B55BB66D0FF80676232818D5952F_Current events 2009 July 5
  60. OSX_OpinionSpy_C98AE54F4BE1082B4E82548D7511077E_Crystal-Clock-screensaver.zip
  61. OSX_OpinionSpy_CC33C95C59372AFCA60A0552A58D0EF8_Crystal-Clock-screensaver.zip
  62. OSX_PSides_32F4792B1141BA259067F9613E2E88B5
  63. OSX_PUP_AABEDBAAB63EF19657A3A82C930CCE18_Genieo_InstallGenieo.dmg
  64. OSX_PUP_PerfectKeylog_1B192319C8F41036A2D6B8E987809D42
  65. OSX_Renepo_80753666A54A8AE97BD6ED3A4E2F3702
  66. OSX_RevirA_FE4AEFE0A416192A1A6916F8FC1CE484_revir-a.dmg
  67. OSX_RevirC_Imuler_7DBA3A178662E7FF904D12F260F0FFF3
  68. OSX_Safari_B24C0E60AF3D3E836FBE8A92FBCC8EB7.dat
  69. OSX_SniperSpy
  70. OSX_Wirenet_50D4F0DA2E38874E417BD13B59F4C067
  71. OSX_Wirenet_B56AD86A4BACEF92EF46D36EABEF6467
  72. OSX_Wirenet_D048F7AE2D244A264E58AF67B1A20DB0
  73. OSX_Yontoo_16ACCB0ABC051D667640B1EE4FF3A7A1
  74. OSX_Yontoo_7C433B3AC0E8072BA5E6B57298E1B28B
  75. OSXWeapoX_7FDEBB5FEC63FB3739A79A66265BB765



EXPLOITS
OSX_CVE-2009-0563 targeting Tibetan and Uyghur activists (filenames shortened here)

  1. 0DA957B9B952420241F945A9A2C52A50_C2-alma.apple.cloudns.org_ParticipantsArrivalDeparture.doc
  2. 0E5110493FD197813068310E57467B44_C2-alma.apple.cloudns.org _Uighur Han unrest.doc
  3. 0E945428D07464EC33EBDFF5712FE788_C2-update.googmail.org_Jenwediki yighingha.doc
  4. 1218840F3B66832CC58C33C75AD3D419_C2-update.googmail.org_Uyghur_Xitayning Yengi Rehberlik.doc
  5. 1CE3C4A8907A242250D366586711CBDC_C2-alma.apple.cloudns.org _Rabiye_hanim_bilen_Dolkun_Isa.doc
  6. 2567399683111CFCB838C5DA80DF181D_Tibetan Parliament urges World to take concrete step on Tibet.doc
  7. 28821C5FD38B11EE630D87961C11A3D7_DUQning reyisi namzatlar isimliki.doc
  8. 3D28AE551B9BD4C62FFC6C72F5668D96_Tibet_The United Nations Commission for Human Rights.doc
  9. 3D90D04C09C6B4D5D52888C89BDE9685_Tibetan Parliament urges World.doc
  10. 567ECE88B2D6F4F12F0D0760C30605EE_C2-apple12.crabdance.com_list.doc
  11. 58A0A5824A6B30EA7EEBBB51818AE04B_uYGHUR_Jenwe yinghinining xeweri.doc
  12. 786A7D1A1DCEC50E6A89E3CC8F33A3AE_Uyghur_Dunya Uyghur Qurultayigha iane qilish toghrisida.doc
  13. 7D7A5C530A7DBF24C42145A0EFCC8669_kurban-bayrami.doc
  14. 8618BCCB98F7D20634EBEDC488981E86_C2-update.googmail.org_email73.doc
  15. 908116A30F53EDF9D1749E3F0F267680_Website-TGSL.doc
  16. 9F9F96D5C882528D08315201042647DF_C2-update.googmail.org_Uyghur_The Duke Program.doc
  17. BA76DE3471497A8B1858AF4A8C700AE1_www.uyghurcongress.org.doc
  18. C024E159A96F3292915B257070FC3325_Sartin-TGSL.doc
  19. DD7C486BC17772A5E96425271FA5ED4D_c2-apple12.crabdance.com_10. Jahresgedenktag.doc
  20. E510AE50B0344EFBE1F8888771C7446C_www.tughlan.com.doc
  21. E683339BCCFDEB0F06C7E567F2C284C5_Planning for action.doc
  22. ECE44C00D46BE019AFF38FD5D31B9110_C2-update.googmail.org_UAA 2012 Saylam Komtiti saylam.doc
  23. F81775C93F7337E0664F1D106E13C7B3_C2-update.googmail.org_Uyghur_Human Rights Education.doc
  24. FBE399BF714184ED7FEA313F36A86514_C2-apple12.crabdance.com_Uyghur_Putun Dunyadiki Sherqi.doc
  25. MacOSSabpub-A_43F281076E185E55BECE7EB2F0EC8164.doc


02 Jun 13:41

We're live from Apple's WWDC Monday at 1PM ET / 10AM PT!

by Jacob Kastrenakes

Monday is going to be big. Apple will be showing the next versions of iOS and OS X at its Worldwide Developers Conference, and The Verge is going to be there live with up-to-the-minute coverage of all the new features, apps, updates and everything else on show. The conference kicks off with a big presentation from CEO Tim Cook and other top Apple executives on Monday at 1PM ET (10AM PT). You'll be able to follow along with all the news right as it happens through our liveblog, and afterward, stay tuned for commentary and in-depth analysis from The Verge Live.

Continue reading…

02 Jun 12:56

Apache Patches DoS, Information Disclosure Bugs in Tomcat

by Chris Brook
Apache recently patched denial of service and information disclosure vulnerabilities in its Tomcat web server.
02 Jun 12:56

ZDI-14-159: (0Day) VMware vCenter Server Appliance Ruby vSphere Console Privilege Escalation Vulnerability

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of VMware vCenter Appliance. Authentication is required to exploit this vulnerability.
07 May 18:49

When a website forces me to create an account and then has really strict password requirements

animated rampage

07 May 16:10

Noisebridge Discuss

23 Apr 17:46

Frugal yet Fancy Homebrewing – with 30 Seconds of Work

by Mr. Money Mustache
juiced

discoSummer seems to have started a little early this year here in Colorado, and brought along all of its pleasant side effects. Abandoning the socks and shoes, gathering with local friends to play in the park and watch the sunsets, and of course an increased consumption of cold beverages.

Long ago, I wrote a post about brewing your own beer. It was an amazing experience and it produced great beer. Many readers are advanced brewers and they wrote in with advice and encouragement. It is still a great hobby for the many people who enjoy it. But unfortunately for my friends and me, we found that after a few batches the habit just didn’t stick.

It was all in the practicalities: the brewing process takes a couple of hours and involves quite a bit of repetitive labor that can be guilt-inducing for those of us who like to use all our time productively. Bottling is a particularly slow chore, and the more efficient alternative of keg storage encourages excessive beer consumption because you end up with your own refrigerated beer tap taunting you at all hours. To top it all off, the home-brewed beer was only slightly cheaper than the local microbrews, which can be found for just over a dollar a bottle around here if you pick them up during a sale.

To create a winning home brewing situation for lazy people like myself, I needed an impossible combination of attributes: a low time commitment, small batches, low cost, no major research, and no bottling. I didn’t think such a thing existed, but a local friend of mine who is known on this blog as The Honey Badger has proved me wrong. He has rediscovered an age-old method to convert good fruit juice into very good summer party beverages with about 30 seconds of work (plus of course two weeks of fermentation).

The end result is a sparkling beverage that is extremely tasty, much drier (less sweet) than the original fruit, and contains about 6% alcohol – the perfect level for adult relaxation and a factor in the easy breezy style of this very article which is being written with a large mug of cider right next to the laptop.

At less than 60 cents per 12 ounce serving, this is a truly frugal way to get the party started. Replacing a portion of your microbrew consumption with some innovative drinks you ferment yourself could save you hundreds per year. And pulling out a fresh gallon jug of this fine hard cider from the fridge is a prestigious way to impress your party guests. As long as you don’t use it as an excuse to consume more, something we laid down the rules for in the old Beer ‘o’ Clock article.

So let’s make some right now.

1: Procure the largest, fanciest bottle of juice you can find

yeastI chose this lovely one-gallon jug bottle of North Coast Sonoma County unfiltered apple juice from the new hipster market in town called Lucky’s. It runs about $5.99 for a bottle this size. The key is to look for something without preservatives, and with a very good natural taste. You can ferment pretty much anything with sugar in it, but we are fancy people here, so we use fancy juice. Apple, grape, mango, pineapple, pear, and berry juices work beautifully.

2: Take off the cap and dump in 1/2 teaspoon of Champagne Yeast
You might give it a little swirl or shake to disperse the yeast nicely through the juice. Save the cap, for you’ll be putting it back on once the brewing is done.

3: Put a cork with an airlock* in it.
stopperThen put an ounce of clean water (or a sterile liquid like whiskey as shown here) into the airlock. I recommend setting the bottle in the center of your kitchen table at this point so you can watch the show. Within 24 hours, it will start gently bubbling and fizzing, as the yeast works its incredible alchemy of turning the useless sugar molecules into useful alcohol ones. This bubbling will go on for about two weeks. At that point, you may notice that it slows down as the yeast runs low on sugar.

And you’re done! After those two weeks, put the cap back on, and put the jug in your fridge. A small amount of additional fermentation will happen, which will release more carbon dioxide that gets forced back into solution to make the mixture slightly bubbly. It will store well for many weeks in the fridge, or you can use it immediately. Dispense freely to self and friends, and watch the pleasant results.

Update: In response to the idea of in-bottle carbonation, some readers brought up the concern that it is possible to break certain bottles if the pressure grows too large. The thing is, you don’t know what “too large” is. Therefore, I will start a new dangerous experiment today that may cost me a whole bottle of cider: I’ll brew a new batch, cap the bottle tightly after two weeks, and leave it in a a protected enclosure in my warm garage for several additional days. Then see if it explodes, gets extremely fizzy, or just ends up perfectly carbonated. Plastic bottles will also eliminate the risk of dangerous explosions, because they have a great capacity to stretch.

juiced

The key to this whole deal is that we have eliminated the time-consuming parts of beer and wine brewing. Instead of boiling grains for hours and adding multiple ingredients, we use just one ingredient. Instead of washing carboys and siphoning from one to another, we ferment in just the bottle supplied with the juice. And instead of sterilizing and capping dozens of bottles afterwards, we just throw that same bottle in the fridge and serve directly from it. The result is obviously not beer, but the variety of fruits and other sweet things that Nature makes available will still keep your taste buds entertained.

I just started this experiment two weeks ago. We cracked the first bottle last night, and it was such a success that I decided to share the results with you as well as start a few more bottles for future use.

Bottoms up!

 

*The Honey Badger has been brewing interesting concoctions to share at his own parties for several years now, and he even started a website called Simple Brew Kits to sell the extremely simple parts needed to ferment beverages like this at home. A rubber stopper/cork, an airlock, and some yeast. Under 15 bucks and you’re set for the summer. 

** Mr. HB is also the guy I teamed up with for The Foreclosure Project, and the one who introduced me to the Badass nature of Fasting. He is also known occasionally as Poppa from Poppa’s Cottage and Hirsute Pursuit.

 

28 Feb 15:23

Tumblr | 7e4.png

7e4.png
28 Feb 15:23

zerostatereflex: Water Experiment No. 33 Automata What a...

John

wow.





zerostatereflex:

Water Experiment No. 33 Automata

What a beautiful work of craftsmanship.

By: Dean O’Callaghan