Information Security News
Bitcoin pool GHash.io announced on Wednesday that “it is not aiming to overcome 39.99 [percent] of the overall Bitcoin hashrate."
This marks a clear departure from the large pool’s recent flirtations with 51 percent. If that threshold is crossed for sustained periods of time, it concentrates power in ways that Bitcoin’s decentralized design normally does not allow.
“If GHash.io approaches the respective border, it will be actively asking miners to take their hardware away from GHash.io and mine on other pools,” the statement continues. “GHash.io will encourage other mining pools to write similar voluntary statements from their sides.”
By now, most readers know the advice cold. Use long, randomly generated passwords to lock down your digital assets. Never use the same password across two or more accounts. In abstract terms, the dictates are some of the best ways to protect against breaches suffered by one site—say, the one that hit Gawker in 2010 that exposed poorly cryptographically scrambled passwords for 1.3 million users—that spread like wildfire. Once hackers cracked weak passwords found in the Gawker database, they were able to compromise accounts across a variety of other websites when victims used the same passcode.
A team of researchers says the widely repeated advice isn't feasible in practice, and they've provided the math they say proves it. The burden stems from the two foundations of password security that (A1) passwords should be random and strong and (A2) passwords shouldn't be reused across multiple accounts. Those principles are sound when protecting a handful of accounts, particularly those such as bank accounts, where the value of the assets being protected is considered extremely high. Where things break down is when the dictates are applied across a large body of passwords that protect multiple accounts, some of which store extremely low-value data, such as the ability to post comments on a single website.
Employing even relatively weak, 40-bit passwords (say, one with eight lower-case characters) across 100 accounts is equivalent to recalling 1,362 randomly chosen digits or 170 random eight-digit PINs, something that's well beyond the capabilities of most people. Reducing the number of bits by choosing more memorable passwords such as "password123" and "123456" helps ease the burden. But even then, users must have under their control 525 bits just to remember which weak password goes with which account. That's more than double what's required to memorize the order of a shuffled deck of cards. Yes, people can use password managers, but those available in the cloud may be susceptible to online attacks, and those that aren't Web-based lose one of the major advantages of passwords, which is their ability to be entered across any client device.
Posted by InfoSec News on Jul 16http://www.wired.com/2014/07/google-project-zero/
Posted by InfoSec News on Jul 16http://www.nationaldefensemagazine.org/archive/2014/August/Pages/CyberLaborShortageNotWhatitSeemsExpertsSay.aspx
Posted by InfoSec News on Jul 16http://www.computerworld.com/s/article/9249738/Overreliance_on_the_NSA_led_to_weak_crypto_standard_NIST_advisers_find
Posted by InfoSec News on Jul 16Forwarded from: cfp (at) ruxcon.org.au
Posted by InfoSec News on Jul 16http://www.nytimes.com/2014/07/16/world/asia/chinese-hackers-extend-reach-in-us-government.html
Reader Jake sent us an awesome bundle of RAT-related mayhem collected during performance of his duties while investigating the unfortunate and prolonged compromise of a company we'll fictitiously call Hazrat Supply.
Guess what? The RAT that was plaguing the Hazrat Supply environment was proxying traffic back to a Chinese hosting company.
This is my shocked face.
Really, I'm shocked, can you tell?
With the plethora of malicious files shared with us in this package it represents a huge opportunity to create some related IOCs with Mandiant's IOCe as well as run some of this evil through my preferred toolkit with which to identify then build said IOCs. We'll do this in three parts as I'm handler on duty for the next three days (lucky you); there's lots here to play with (lucky me).
Let me give you a quick manifest first:
bybtt.cc3 MD5 c2f0ba16a767d839782a36f8f5bbfcbc
mylcx.exe MD5 4984fd547065ddcd781b068c4493ead6
PwDump7.exe MD5 d1337b9e8bac0ee285492b89f895cadb
svchost.exe MD5 20a6310b50d31b3da823ed00276e8a50
Ironically the RDP server the attackers used, RemoteMany3389.exe, is not flagged as malicious by AV detection. Apparently it's a legitimate tool...in China. :-)
Seemingly so too is the file locker they used, xlkfs.sys, courtesy of XOSLAB.COM (signed by Yang Ping). Hey, thanks for signing it, I trust it more.
I'm going to go out on a limb here (not really) and say treat these files as flagrantly hostile.
Hit the big red button if they happen to be on your systems along with their malicious compatriots cited above.
Here are their hashes regardless:
RemoteMany3389.exe MD5 c9913698afc7288b850f3af602f50819
xlkfs.sys MD5 4aa2d2975d649d2e18440da0f3f67105
Building IOCs with Mandiant IOCe is in many ways straight forward for simple logic, you'll need to understand AND and OR substructures to build more complex logic branches.
Read the user guide that's installed with the editor.
I took just a few attributes (MD5, SHA1, file size) to start my IOC file for HackTool:Win32/Zeloxat.A as seen in Figure 1.
I'll be populating this further and sharing the full IOC file set for each of these samples upon request after Friday's shift.
Tweet me for them @holisticinfosec or email me via russ at holisticinfosec dot org.
Tomorrow, I'll run Jake's dump file for svchost.exe through Volatility to see what we can further learn and use to create additional IOCs.