Discover Top Posts Tagged with #cyberparse

RHSA-2016:0071-1: Critical: firefox security update

Updated firefox packages that fix multiple security issues are nowavailable for Red Hat Enterprise Linux 5, 6, and 7.Red Hat Product Security has rated this update as having Critical securityimpact. Common Vulnerability Scoring System (CVSS) base scores, which givedetailed severity ratings, are available for each vulnerability from theCVE links in the References section.

Mozilla Firefox is an open source web browser. XULRunner provides the XULRuntime environment for Mozilla Firefox.Several flaws were found in the processing of malformed web content. A webpage containing malicious content could cause Firefox to crash or,potentially, execute arbitrary code with the privileges of the user runningFirefox. (CVE-2016-1930, CVE-2016-1935)Red Hat would like to thank the Mozilla project for reporting these issues.Upstream acknowledges Bob Clary, Christian Holler, Nils Ohlmeier, GaryKwong, Jesse Ruderman, Carsten Book, Randell Jesup, and Aki Helin as theoriginal reporters of these issues.All Firefox users should upgrade to these updated packages, which containFirefox version 38.6.0 ESR, which corrects these issues. After installingthe update, Firefox must be restarted for the changes to take effect. Red Hat Enterprise Linux (v. 5 server)

SRPMS: firefox-38.6.0-1.el5_11.src.rpm MD5: f0e82a35410772d553561dc21e90acebSHA-256: 155c96616eea445a7ce5c73bea1d67d2ca7f92e07a4aac5fa5ed3596f5d0654a IA-32: firefox-38.6.0-1.el5_11.i386.rpm MD5: 101bf01ecdcd7fc88e57eb892a2c5afdSHA-256: 57fc46fb4c9d3525176d5450082e20bea9817cf0d469800ecba9173cb4473357 firefox-debuginfo-38.6.0-1.el5_11.i386.rpm MD5: 1561afc89b38d0c3335c8ff9e5de00bdSHA-256: 5c7582ac4e97c2191295ac3f2b6a2d635c35ce1a9e3393b06aa2e0458ef141c9 PPC: firefox-38.6.0-1.el5_11.ppc64.rpm MD5: a75f7e6e54da41df77d6725935d385d5SHA-256: b54f1f2da07e4d9750921e101f8d603a74653c02894fdce8a2a0519844d13784 firefox-debuginfo-38.6.0-1.el5_11.ppc64.rpm MD5: 1f8b7d4145824cd8965ba907b4c25715SHA-256: 55ec2014b49718e9271d6d94a6fdf25b831e7d5beee482c800c22fb0353b43b7 s390x: firefox-38.6.0-1.el5_11.s390.rpm MD5: 347c1cc69fe5478895452805cbe41ad9SHA-256: b8e5721f28161fce0c59bb83b2bc3454ad3b372bf72ca1243ebae360c0e14fea firefox-38.6.0-1.el5_11.s390x.rpm MD5: c46eb4995c2276937ae792a73d55ef42SHA-256: 70e3868d9d29c3a5894e474a1e3dc8bed38ee37b3c337618e2701a63afb15abd firefox-debuginfo-38.6.0-1.el5_11.s390.rpm MD5: 4b299371b60d7083ed4cfc198aae7318SHA-256: fbac034d324225c8665c4ee8cedf500be456bb6ac317cff5b2c36ea88406e16d firefox-debuginfo-38.6.0-1.el5_11.s390x.rpm MD5: ef8f4cef9049cebd5145f70dc079189dSHA-256: 5178de25e21a5bea216ac624523fadbefb78f62e8a92b7f94916e95be6a3c720 x86_64: firefox-38.6.0-1.el5_11.i386.rpm MD5: 101bf01ecdcd7fc88e57eb892a2c5afdSHA-256: 57fc46fb4c9d3525176d5450082e20bea9817cf0d469800ecba9173cb4473357 firefox-38.6.0-1.el5_11.x86_64.rpm MD5: e0a620d940ad28508899e746c513ee0fSHA-256: c690df41ac92e7f1e540727aba5ec0e74ffbe958d900ed60acd33281a867ac77 firefox-debuginfo-38.6.0-1.el5_11.i386.rpm MD5: 1561afc89b38d0c3335c8ff9e5de00bdSHA-256: 5c7582ac4e97c2191295ac3f2b6a2d635c35ce1a9e3393b06aa2e0458ef141c9 firefox-debuginfo-38.6.0-1.el5_11.x86_64.rpm MD5: af323b5d2f2a35bb430e15b7ba4c87a2SHA-256: e74de4b36bf6aea98515d086a045c6a965e08fcf9feea1be07c5b71a483bc3d3 Red Hat Enterprise Linux Desktop (v. 5 client)

SRPMS: firefox-38.6.0-1.el7_2.src.rpm MD5: 807fa1a423522b6c63a6d7a9f0b39b7cSHA-256: d766d5620beeae63b7de02aaa18ee4bfd3fca10493c7986042c41da1b220a44a x86_64: firefox-38.6.0-1.el7_2.i686.rpm MD5: 4c46eda54d41966455ff2ce94cdaaf21SHA-256: ccfd30efaac0e3c07798c245e0eeed7d97cefc83420b1590b79acc78364df0d3 firefox-38.6.0-1.el7_2.x86_64.rpm MD5: 7fb5f9ca343db274e2aaabc6e25cdaffSHA-256: d3382b91ba87c7f066ef3c0ba116c7e3ac1ee5914a66c3a1fe364a414164eb6c firefox-debuginfo-38.6.0-1.el7_2.i686.rpm MD5: febb1cbe02ca43db4bdb6621be436372SHA-256: 131eabcb65370412a2d43ae5d474f35d47de1a85a58c0e8333fb183efdd2f5d4 firefox-debuginfo-38.6.0-1.el7_2.x86_64.rpm MD5: 2c69145db222b9d299233a3ba98a3817SHA-256: af2c61075fec0b5587090a88a83c2ae8bd2cd5774605ff48e111eb0a004cbf08 Red Hat Enterprise Linux HPC Node (v. 6)

SRPMS: firefox-38.6.0-1.el6_7.src.rpm MD5: 3d3fe6e673d282d3d826a280c7911dc2SHA-256: 6ffcb0c8c323decfb5928b221f88c2c215c551ee7616a22e9b336688fc2eed46 x86_64: firefox-38.6.0-1.el6_7.i686.rpm MD5: 891f4678aeaa82a48919f213979b6cbdSHA-256: 7ccdd2c48f645bce8298a6adc63ade240ba3ed03e82843afb7684c76e152c4bb firefox-38.6.0-1.el6_7.x86_64.rpm MD5: 42fc549d112f17f50ab13a9ee495bdbfSHA-256: e8639e50becc14c14c5350847a36c01a377234d830e6b3d02cd9daac5f37873e firefox-debuginfo-38.6.0-1.el6_7.i686.rpm MD5: 44effab75926eee889de9dca1bd4dbf0SHA-256: 0812e1ee6e2abfa89ccc9ba20f42f3f3096ac92ad2aeec068801867e656fda40 firefox-debuginfo-38.6.0-1.el6_7.x86_64.rpm MD5: 00df282ac66dcc5fbe9be61200189455SHA-256: ee72e5b43d3775328878fb2a2418ee1ebb29861e422234f2ed8dce3d9e0cbeb7 Red Hat Enterprise Linux Server (v. 6)

SRPMS: firefox-38.6.0-1.el6_7.src.rpm MD5: 3d3fe6e673d282d3d826a280c7911dc2SHA-256: 6ffcb0c8c323decfb5928b221f88c2c215c551ee7616a22e9b336688fc2eed46 IA-32: firefox-38.6.0-1.el6_7.i686.rpm MD5: 891f4678aeaa82a48919f213979b6cbdSHA-256: 7ccdd2c48f645bce8298a6adc63ade240ba3ed03e82843afb7684c76e152c4bb firefox-debuginfo-38.6.0-1.el6_7.i686.rpm MD5: 44effab75926eee889de9dca1bd4dbf0SHA-256: 0812e1ee6e2abfa89ccc9ba20f42f3f3096ac92ad2aeec068801867e656fda40 PPC: firefox-38.6.0-1.el6_7.ppc.rpm MD5: da37ac74bf17bba428bfd3f2feede018SHA-256: 64176ca1440986ad2d2c5bd4efab11c6896cd9a3a95ea274b767786194222eb0 firefox-38.6.0-1.el6_7.ppc64.rpm MD5: 1ef1bc939a4f8ebf477b1b4ed0ed211bSHA-256: 33e6810827ac0b792106ba4b4cb3e2622f4dad4eadb7bc30252db33423ece2af firefox-debuginfo-38.6.0-1.el6_7.ppc.rpm MD5: 08aeeb07da21ac3d241f27dae94fa5eaSHA-256: 3a6f95d4048b5903530bb86f1163c5ea4df8629999b36fc8c7d660c7d6e47951 firefox-debuginfo-38.6.0-1.el6_7.ppc64.rpm MD5: 644e7f40c6c84641f2b43df6f6481824SHA-256: 816bdadba26046e7efb518311fababeba93e2744e951f84d63556f4b62723554 s390x: firefox-38.6.0-1.el6_7.s390.rpm MD5: 03819cfc85d2104367dac08578d68b6eSHA-256: e2785ed2ebddd0d9717652fcfc7d89b75ec9078c6b538b2202e3c28cba2834ac firefox-38.6.0-1.el6_7.s390x.rpm MD5: 69e268631d8d9d0eba85372f01c9d09dSHA-256: 0f244dc53eccc6145795e5b5db6e4fc22b2063d8ec9bb598ce3920d48f30ce50 firefox-debuginfo-38.6.0-1.el6_7.s390.rpm MD5: b14e95b847c8c9de035ed9a461f4b034SHA-256: ddd7d717760ddab1256d117f8f16358d11b1447a9e1900d2ee3dbf55679fda89 firefox-debuginfo-38.6.0-1.el6_7.s390x.rpm MD5: eb5d73b02755538f288b1f0ab9225f32SHA-256: 11dd1c19d90713b6dfb7df80d09026c2ecc3b9cacac482119262fdecc0af4510 x86_64: firefox-38.6.0-1.el6_7.i686.rpm MD5: 891f4678aeaa82a48919f213979b6cbdSHA-256: 7ccdd2c48f645bce8298a6adc63ade240ba3ed03e82843afb7684c76e152c4bb firefox-38.6.0-1.el6_7.x86_64.rpm MD5: 42fc549d112f17f50ab13a9ee495bdbfSHA-256: e8639e50becc14c14c5350847a36c01a377234d830e6b3d02cd9daac5f37873e firefox-debuginfo-38.6.0-1.el6_7.i686.rpm MD5: 44effab75926eee889de9dca1bd4dbf0SHA-256: 0812e1ee6e2abfa89ccc9ba20f42f3f3096ac92ad2aeec068801867e656fda40 firefox-debuginfo-38.6.0-1.el6_7.x86_64.rpm MD5: 00df282ac66dcc5fbe9be61200189455SHA-256: ee72e5b43d3775328878fb2a2418ee1ebb29861e422234f2ed8dce3d9e0cbeb7 Red Hat Enterprise Linux Server (v. 7)

SRPMS: firefox-38.6.0-1.el7_2.src.rpm MD5: 807fa1a423522b6c63a6d7a9f0b39b7cSHA-256: d766d5620beeae63b7de02aaa18ee4bfd3fca10493c7986042c41da1b220a44a PPC: firefox-38.6.0-1.el7_2.ppc.rpm MD5: b0136a7824bd18e18d05129d25e6e76aSHA-256: 3294ffa185e76e066a948e7297bc5a9db122cc4131083882f291ee829847c541 firefox-38.6.0-1.el7_2.ppc64.rpm MD5: 7b56028deedad4d209e4ac352646f94dSHA-256: 3e8822581cc776441beddd58f215f4f1e6b43876ba5cf0c3e4736f377cdd5dcc firefox-debuginfo-38.6.0-1.el7_2.ppc.rpm MD5: f2ef0d84312757d3cbd99a7fad1e0d4dSHA-256: bffa6a86229b6273e31ff81a7cb47cea0042d3bf35d7c947214900075245cf9a firefox-debuginfo-38.6.0-1.el7_2.ppc64.rpm MD5: 9714771f980492586fd2b997c1b13670SHA-256: bd37b4c033a47da686ef841d369fa9aab045bc3f942ed2f141f8e93247ad6b59 s390x: firefox-38.6.0-1.el7_2.s390.rpm MD5: ac355bceda4371edd194f26e0a7da37eSHA-256: c0ad18ad1440923b85242aabf9c46181c7a0031622de7445eca20f0d7b4396c2 firefox-38.6.0-1.el7_2.s390x.rpm MD5: f47fe1ac95cdda0ab3a360dc94d303cdSHA-256: 2b49e5879843dadb5a825e81b637be5b3040b77500ed5854a4a3571a708604c6 firefox-debuginfo-38.6.0-1.el7_2.s390.rpm MD5: d599c0ca40a30d6ea72043b45ae849ccSHA-256: 02912d249fae0fcf861859d83704b0b17695397bbf3527a51b86c98b4c43531d firefox-debuginfo-38.6.0-1.el7_2.s390x.rpm MD5: 5fc5c079cc4376fc89ed71e85015da83SHA-256: 945247fef6ff07c9d6dbac1ebf0991754c328a1402f94cc29465d5355e71176d x86_64: firefox-38.6.0-1.el7_2.i686.rpm MD5: 4c46eda54d41966455ff2ce94cdaaf21SHA-256: ccfd30efaac0e3c07798c245e0eeed7d97cefc83420b1590b79acc78364df0d3 firefox-38.6.0-1.el7_2.x86_64.rpm MD5: 7fb5f9ca343db274e2aaabc6e25cdaffSHA-256: d3382b91ba87c7f066ef3c0ba116c7e3ac1ee5914a66c3a1fe364a414164eb6c firefox-debuginfo-38.6.0-1.el7_2.i686.rpm MD5: febb1cbe02ca43db4bdb6621be436372SHA-256: 131eabcb65370412a2d43ae5d474f35d47de1a85a58c0e8333fb183efdd2f5d4 firefox-debuginfo-38.6.0-1.el7_2.x86_64.rpm MD5: 2c69145db222b9d299233a3ba98a3817SHA-256: af2c61075fec0b5587090a88a83c2ae8bd2cd5774605ff48e111eb0a004cbf08 Red Hat Enterprise Linux Server EUS (v. 6.7.z)

RHSA-2016:0071-1: Critical: firefox security update was originally published on Cyber Parse

#redhat #Vulnerability #cyberparse

Twitter's two-factor system is more secure, but not necessarily better

Twitter came out earlier this week with a new version of its two-factor authentication system. Usually when I hear about such systems, I wonder whether they’re going to use the time-based one-time password algorithm (TOMP). TOMP is implemented by a couple of companies; among them, Amazon, Dropbox, Linode, Evernote, and Microsoft. The beauty of using the algorithm is that all of your tokens can be placed in the one application. But Twitter has decided not to take this approach, and, in fact, has said that its own implementation is more secure. And it is. In a nutshell, Twitter uses public/private key crypto, getting your device to create a keypair and telling Twitter’s servers what your public key is during setup. The secret private key is never revealed, and can be used to sign any request sent from the device, with the signature verified by the public key. The great thing about such a system is that even if Twitter were compromised, all that an attacker would end up with would be a bunch of public keys and nothing that could be used to impersonate a user.

But the bespoke nature of this approach means that anyone who is using two-factor authentication now has to install Twitter’s app. Given that Twitter wants people to use its own apps, and is limiting API calls as a disincentive to smaller developers to write their own platforms, this is no skin off its back. It actually creates another differentiation point for its client over others. Developers, however, miss out because as far as I can see, there is no way, as yet, for third-party clients to handle this new method of authentication. The users themselves are also left with having to install a client they’ll never use, or leaving two-factor authentication off the table in the first place. Or, perhaps, in Twitter’s ideal world, ditching their third-party client for Twitter’s.

And even if Twitter were breached, it would likely reset key pairs out of an abundance of caution, just like when we hear about hashed and salted passwords being stolen, which are mostly useless. Never mind the fact that we’re talking about a second factor of security here. The debate really seems to come down to keeping everything consistent, and while Twitter’s system of just pressing a button is pretty convenient, what everyone is used to are token systems, and not having to change their user experience with a different client. After all, if you’re someone who’s security-conscious enough to have two-factor authentication turned on, you’re going to be familiar with seeing TOMP-based systems. Security is all about managing your risk, which is why we don’t all store our mobile devices in radio-proof bunkers when we go to sleep at night. Is Twitter’s two-factor system more secure? Sure. Is it necessary to mitigate the risk for the average user? No. We’re again having other companies make our own security decisions for us, as if they know better — as if they know how we use our devices, the information we store on them, and how much we value it — and, sometimes, we don’t, which is why we use really dumb passwords at times. It all leaves a rather sour taste in my mouth — a more closed-off, proprietary system that subtly backhands developers, while being sold as more secure. Just because it’s true doesn’t justify kicking developers some more. Many people would have been satisfied to have a TOMP-based system in Twitter, even though it’s comparatively less secure. There simply isn’t much of a case for replacing it. Unlike passwords, which are fundamentally broken and need an alternative, the currently pushed argument for two-factor authentication is to actually have it in place. In an ideal world, maybe we’d have both options so we could choose to reduce our security for the sake of convenience. But businesses aren’t yet ready for user-tailored security.

Twitter’s two-factor system is more secure, but not necessarily better was originally published on Cyber Parse

#cyberparse

Labor not the only party clueless about its cybers

Security is not often seen as a driver for innovation. More often than not, it’s seen as the uncomfortable problem that needs to be solved in order to meet regulatory requirements, if there is regulation fo…

Labor not the only party clueless about its cybers was originally published on Cyber Parse

#cyberparse

A good password can still trump sketchy security

WatchGuard has been caught doing what a lot of first-timers to access control have done — simply hashing passwords as a means of implementing security — but perhaps all isn’t that bad in the world. Information security researcher Jérôme Nokin, who runs a blog on all the fun things you can do over IP, found that WatchGuard’s firewall appliances are taking a bit of a shortcut when it comes to storing passwords. It’s the typical mistake of recognising that storing plain text passwords is a big no-no, but not going any further than simply hashing the password. In WatchGuard’s case, it had been performing an NTLM hash of the password and that’s it. Some might recognise NTLM as being part of Microsoft’s old security protocol suite that, these days, is no longer recommended by Redmond because it is so outdated. As Nokin also learned, an NTLM hash is simply the password converted to Unicode, then MD4 applied to it. Microsoft is right to shun NTLM, as in 1995, Hans Dobbertin demonstrated that using a Pentium processor (which has far less processing power than can be found in a smartphone today), he could break MD4 in a matter of seconds. His paper (PDF) into the cryptanalysis of the algorithm stated, “Where MD4 is still in use, it should be replaced!” The exclamation mark is his, despite this being in a paper submitted to the Journal of Cryptography. That’s how strongly he felt about it.

Yet, here we are almost two decades later, and MD4 is still hanging around like a bad smell. I said earlier that perhaps this isn’t all that bad, and there’s a good reason for it. The credentials that Nokin broke aren’t actually for the management of the firewall appliance itself. As WatchGuard’s director of security strategy and research Corey Nachreiner pointed out, they’re used for an entirely different, and optional, purpose.

“Our devices offer the ability for you to create policies by user, not just by IP address. To do this, you have to set up authentication. In most cases, users choose to authenticate with their own internal Active Directory, LDAP, or Radius authentication server, in which case we don’t store any credentials. However, we also offer the local FireboxDB database for small customers who don’t have their own authentication server.” And the file that contains these credentials is only really accessible if you’ve gained access to the device itself. “The configuration file is normally saved to the laptop/PC of the person who already knows the password anyway. Best practice would ensure that administrators take protective measures to stop unauthorised access to the WatchGuard management computer anyway, including complex passwords and the latest Microsoft authentication protocols. Communication between the management PC and the WatchGuard is secured with AES encryption, so even the hashed password is only used with encryption and cannot be ‘sniffed’,” a WatchGuard spokesperson told ZDNet. Nachreiner also argued that although NTLM is showing its age, sufficiently strong passwords should offer reasonable protection. He defines a strong password as one that is a complex combination of 12 characters or more. A strong password is the critical factor here, because as recently as December last year, Stricture Consulting Group CEO and security researcher Jeremi Gosney demonstrated that a specialised hash-cracking rig (PDF) could churn through 348 billion NTLM hashes per second. If only lower-case characters were used (thus breaking the complexity requirement), a password of up to 12 characters in length could take a few days to brute force. Granted, not everyone has a 25 GPU setup like Gosney, but Nokin claims he was able to run through 12.7 billion hashes per second on his own dual-GPU setup. A poorly constructed password susceptible to a dictionary attack will be easily broken. Yes, the use of NTLM was a pretty dumb move, but, lucky for WatchGuard, I’d argue that the level of protection matches the risk. Nachreiner put it best when he said, “If an attacker already has enough access to the administrator machine you use to manage your network security appliance, you already have bigger problems.” And that lastly, had an administrator picked good passwords to begin with, this would still be a non-issue. Nevertheless, WatchGuard’s engineers are now looking at implementing Dobbertin’s advice from 1995 and Microsoft’s recommendation by getting rid of NTLM/MD4 and replacing it with something more suitable.

A good password can still trump sketchy security was originally published on Cyber Parse

#cyberparse

Having a bug bounty doesn't mean you take security seriously

If some guy walked into our office and offered started to write my articles for me, I’d be somewhat appreciative, if not worried for my job security. But if he then started asking the company for money, I’m pretty sure, and hopeful, that he’d be politely told to go through the regular channels and apply for a job. Depending on how the industry is going, maybe my employer might keep him on as a freelancer, but given they have a paid-for resource (me!) they’ll either thank him for his time and tell him to move along, or charge him some pitiful rate so as to make it worthwhile for the company. I’m not trying to get someone else to do my job (unless I’ve outsourced it to China or India), so why am I telling you this? Because it’s exactly what happens when security researchers submit vulnerabilities and then get all angry when they receive a pittance for pay. Take the perspective of companies like Cisco, IBM, Symantec, EMC and Huawei. These are large companies that arguably have a large investment in security if they are not security companies themselves. But they also do not pay or compensate security researchers that alert them to vulnerabilities. And why should they?

If they are already investing in a security team which is meant to be catching these issues, then why pay someone else, especially when it’s hard enough to get a job at these places? Yes, it’s nice to have another set of eyes on the issue, and yes, outsider help is appreciated, but outsourcing this work is not sound business logic. That said, most organisations that have a heart will realise that whether the researcher is a whitehat, greyhat or bluehat (as Microsoft puts it), they aren’t necessarily an arsehat. A word of recognition, a t-shirt in the mail, a nicely worded email are often all that some researchers are looking for. It is the equivalent of that guy being thanked and politely turned away.

When Yahoo sent researchers from High-Tech Bridge US$12.50 each for two cross-site scripting vulnerabilities, I don’t think it did anything wrong. I’m not about to applaud mediocrity, but they are doing more than IBM and the like. But it is wrong to believe that Yahoo thinks a cross-site scripting vulnerability is only worth US$12.50 because it assumes that Yahoo’s entire security relies completely on the reports of volunteers. That may actually be the case, if Yahoo simply doesn’t care about security, but no one really has any idea what happens on Yahoo’s own security teams. There appears to be a huge misconception that the size and presence of a bug bounty is proportionate to an organisation’s attitude towards security. On one hand, a startup like Etsy has a dedicated security team and offers bounties starting at US$500 across it’s site, API and mobile applications — pretty much anywhere. On the other, samsung has a US$1000 bug bounty, but it’s limited specifically to television sets launched in the past two years — an extremely limited scope. Etsy clearly has a strong security stance, even if its bug bounty is lower than samsung‘s, but there’s no telling what goes on at samsung, or if the limited scope will even mean anything significant gets reported. The bottom line is that despite similar rewards, there’s no telling what samsung is thinking. However, the researchers from High-Tech Bridge did do the right thing when they decided to hold off on their research after learning Yahoo pays a pittance. If Yahoo is serious about security and doesn’t need the help of researchers, then it’s not worth wasting time. There are many more organisations that would be happy to pay researchers more for their time. But if Yahoo isn’t serious about security and it really is in such a bad state that it relies on volunteered reports, perhaps the best thing to do is watch a company crash and burn. It’s a jungle out there, and only the strongest survive. Update (October 10, 2012): Director of Yahoo Paranoids (its security division) Ramses Martinez has responded, revealing he often sent the US$12.50 out of his own pocket and was not official company policy. It will soon have an official policy in place with rewards between US$150 and US$15,000 that will be back-dated to July 1, 2013.

Having a bug bounty doesn’t mean you take security seriously was originally published on Cyber Parse

#cyberparse

How vigilance saved a startup from a sophisticated robbery

Bitcoin and security tend to go hand in hand. The wallets are mostly electronic; there are no charge backs; and, done correctly, it can be impossible to track who stole what funds. That makes businesses tha…

How vigilance saved a startup from a sophisticated robbery was originally published on Cyber Parse

#cyberparse

Tin foil hats need to come back in style if we're to save our privacy

Every time another one of Edward Snowden’s leaked documents comes out, I’m met with a barrage of “How is this even new? Privacy died ages ago”, or “How can they even do this?! Those jerks are taking this too far!”. Editorially, I’ve been just as conflicted. On one hand, my peers (which are typically no stranger to privacy issues) have questioned the validity of covering such news about diplomatic facilities being used to spy on foreign nations given it should be a no-brainer. On the other hand, in news coverage, we’ve sometimes taken the view of informing readers that the “latest and greatest” controversial leak simply reaffirms what we already knew, but is important to know. The problem is, none of the people who have the most impact in doing anything about it seem to have any understanding of how rampant the issue is. They either don’t want anything to happen because it’s to their advantage, or they are unaware. Who am I talking about? Try Australian Ambassador to Indonesia Greg Moriarty, Australian and Indonesian foreign ministers Julie Bishop and Marty Natalegawa, and US and Australian country leaders Barack Obama and Tony Abbott. In the past week, Australia has been accused of having installed surveillance devices at its embassy in Jakarta with the purpose of spying on Indonesians and possibly sending this information to Australia’s allies, including the US. But consider what each of these key political leaders have said on the issue: Natalegawa is aware of the ability for nation states to spy on each other. Earlier this week he told journalists that “countries may have capacities, technical capacities, to intercept and to carry out the activity that’s been reported, and information may have been gathered.” Despite being armed with this knowledge, why has Indonesia allowed the activity to continue unchecked? Trust? That’s a naive excuse. I would better reckon that it resigned itself to knowing a certain level of privacy died long ago. Naturally, on the Australian side, Moriarty and Bishop are keeping their mouths sealed. The Australian embassy in Jakarta has a simple statement saying that Moriarty has taken “careful note of the issues raised”, while Bishop took the line that since no one else has ever commented on such issues neither will she.

Obama’s office, at least in the Merkel incident, pleads ignorance, stating that the President was not aware of phone tapping allegations. Perhaps that’s a little better than the naivety that Abbott shows when he states “every Australian governmental agency, every Australian official, at home and abroad, operates in accordance with the law.”

But whose law? What this country, and many other countries need, is a healthier supply of tin foil hats, and perhaps an injection of outrage — anything to get us past the apathy. Former Australian Prime Minister Julia Gillard has been quoted as saying “If my phone was intercepted while I was PM, all they would have heard was praise for Obama.” That’s the approach of laying down and handing over your rights. The tin foil hat nutters had it right all along, but now they’re nowhere in sight. I’m sure it feels great to bask in the I-told-you-so afterglow while they continue on their merry way, but society needs them now more than ever. It’s their prime time to gently educate, yet most of our world leaders seem so terribly misinformed, or completely naive. The level of naivety has gotten to the point where we could do with a little crazy, a little tin foil. If it makes society a little more paranoid, so be it. It’s better to be paranoid and maintain privacy than to be completely naive.

Tin foil hats need to come back in style if we’re to save our privacy was originally published on Cyber Parse

#cyberparse

Google, Nokia, Ericsson, Samsung clueless on NSA's phone stalking

According to the Washington Post, the US National Security Agency has had the ability to track mobile phones even when they are switched off. It’s not new news, with the Post’s article published July 22 and its source, troops from the NSA’s Joint Special Operations Command (JSOC), stating they’ve been able to do this since 2004. The problem is, almost a decade later, no one knows how it was done. Concerned with the NSA’s capability to use a system dubbed “The Find”, Privacy International research officer Dr Richard Tynan reached out to a number of handset manufacturers to determine if it was at all possible to track down a mobile phone, even if it was switched off. Tynan asked apple, Ericsson, Google, HTC, Microsoft, Nokia, RIM, and samsung. He received replies from four. Google’s reply was fairly brief, as one might expect considering its mobile operating system Android only began in beta form in November 2007, was only commercially available in September 2008, and didn’t even exist in 2004. Its reply was that once a device is powered off, there’s no part of the operating system that can remain on, and that it has no way of turning on a device. samsung was pretty convinced it was impossible. Its vice president Hyunjoon Kim wrote back stating that once turned off, all the transceivers additionally turn off and that there is no such way to emit a signal. While Nokia believed that its handsets could not be tracked while switched off, it admitted that there are some components inside devices that could continue to operate even once the device has been switched off.

“One example would be the real time clock, which ensures that when the device is switched on again the user does not have to re-enter the correct time. Another example would be the phone’s charging circuits. Depending on the model, connecting or disconnecting chargers including USB cables, or placing the phone on a wireless charging plate, may cause the device to register the change in charging state and display that to the user, for example by showing a charging symbol on the screen.” However, it stood by its position that the radio components in the device would not be able to transmit any signal to give away its location.

Ericsson was unable to comment on the specifics of its handsets since it is no longer in the business of manufacturing them, but said that in general, mobile phones shouldn’t be able to transmit any signals that could identify itself. It said that only the crystal oscillator that helps keep track of the time and minimal functionality for sensing charger connections and when the users presses the power button would be operational at most. Here we have four companies telling us it can’t be done, and the best tin foil hat theory I can summon revolves around the crystal oscillator. In the presence of an electromagnetic field, crystal oscillators’ physically distort, and then when that field is no longer present, they generate a corresponding voltage as they return to their original state. Whether it is powerful enough to activate the radio components in a device (even if it makes sense electronically), is beyond my engineering experience and perhaps not even necessary, but it could signal the start of using differential analysis to perhaps fingerprint a device in some general area. Like I said, tin foil. Either way, it doesn’t look like we’re going to get a response from the US government. Michael Morisy of open government news site MuckRock submitted two freedom of information (FOI) requests to the government. One was to the NSA, which refused to disclose whether or not The Find existed, as it is a classified in the interests of national defense and that if any such information was available, it would be an operational matter and thus not subject to US FOI laws. The second still sits with the US Special Operations Command, which had to reconfirm with Morisy that his request was in fact for devices that were switched off. Honestly? If the US could track phones that are switched off, why wouldn’t we have tracked down Edward Snowden, Bradley Manning or Julian Assange earlier? The counter argument to this is typically that the US would only use it where it deems it completely necessary — an ultimate weapon of sorts — but we have loud-mouths boasting about capabilities. For the truly paranoid, though, perhaps it’s time to start having those conversations without anything around, switched on or not.

Google, Nokia, Ericsson, Samsung clueless on NSA’s phone stalking was originally published on Cyber Parse

#cyberparse