Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Memory Gaffe Leaves Aussie Bank Accounts Open To Theft

timothy posted about a year ago | from the willie-sutton-down-under dept.

Security 69

mask.of.sanity writes "A researcher has found flaws in the way major Australian banks handle customer login credentials which could allow the details to be siphoned off by malware. He built proof of concept malware to pull unencrypted passwords, account numbers and access credentials from volatile memory of popular web browsers every two hours."

Sorry! There are no comments related to the filter you selected.

Careful Reporting These (5, Informative)

Anonymous Coward | about a year ago | (#43880857)

In the 80s, my comp sci partner and I discovered a similar case at Acadia University. We reported it to the head of the computer center. He told us it wouldn't work, it couldn't be done. I left that meeting feeling betrayed. My partner decided to write a proof of concept. He was successful and to prove it logged in as the main admin account. Days later he decided to try it again to see if they still hadn't fixed it or changed the password. They were waiting. He was expelled from Acadia. He was a brilliant honors student.

It's worse these days. They will charge you for cybercrimes, or treason, and sentence you to decades in prison. Or hold you without trial. Be careful when you do the right thing and report these. Just report them, don't "proof of concept" or you could be charged. It's unfair and immoral but it's what they'll do to you, mostly out of their own shame and embarrassment.

Re:Careful Reporting These (1, Insightful)

Anonymous Coward | about a year ago | (#43881343)

This is why whenever I expose security flaws I do so anonymously. If it isn't fixed within the first couple days I just make it public knowledge and instigate the first attack myself. They had their fair warning, and now they get the shit storm they deserve.

Re:Careful Reporting These (4, Insightful)

darkfeline (1890882) | about a year ago | (#43881595)

I hear about these kinds of things all the time. It's utter bullshit; they're literally making it more appealing for people to anonymously sell these exploits on the black market. "No, we don't want to know if our software has an exploit. If you've found one, go ahead and sell it to whoever you want, as long as we don't know, it's cool, we can keep deluding ourselves, thanks."

It reminds me of, among other counterproductive measures, media conglomerates pushing oppressive DRM on consumers as if to drive them toward piracy or forcing drug addicts to carry their criminal status with them as if to force them back toward poverty and drug abuse. If an alien race were to monitor us, they'd probably assume we're running some sort of elaborate self-extermination campaign.

Re:Careful Reporting These (0)

Anonymous Coward | about a year ago | (#43881837)

No, it's not shame or embarrasment. You have a mind geared towards exploitation. Normal people are "doves", and get wildly confused when something "bad" happens. They're, metaphorically, "night-blind" and can't reason morally under such circumstances. As such, they lash out at the first possible target and then pat themselves on the back. It's nothing you can blame them for really.

Re:Careful Reporting These (1)

Shavano (2541114) | about a year ago | (#43882525)

Whatever his intentions, he broke the law. It's important to remember that you can be prosecuted for breaking the law even if you consider yourself a "white hat." Instead, he should have sent the demonstration code in hardcopy without ever actually intruding on the system he was trying to help improve.

Re:Careful Reporting These (0)

Anonymous Coward | about a year ago | (#43882623)

Intent is usually the best defence anyone has against charges brought against them.

Re:Careful Reporting These (1)

Sarten-X (1102295) | about a year ago | (#43882787)

The fact that he did it for a noble cause is irrelevant. What matters is "criminal intent" - whether he intentionally broke the law.

The expelled student intended to gain unauthorized access to the computer system. He knew that the malware he wrote would harvest credentials of other users, and he knew that he wasn't allowed to log in as someone else. Yet he did so anyway. That certainly seems intentional to me, and that's what matters to prosecutors (and college judiciaries).

Re:Careful Reporting These (1)

Velex (120469) | about a year ago | (#43883643)

Yes, but that's not even good enough. You and I both know how these arrogant pinheads work. They have a social status and nothing more. If some damned kid can just show them up, what would that mean about them? Sure we can call the kid a "genius" or a "wiz" and dress him up in other terms to attempt to shield the pinhead's social status, but at the end of the day the fact remains that the pinhead got shown up by a damned kid barely out of diapers.

It seems the only correct answer is to either do nothing or as another poster suggested, sell the information to others.

Now imagine the threat to the social status of a billionaire if some faggot like me found an exploit. Total social status inversion. I'm supposed to be an AIDS-infested nobody who's too incompetent to do anything. Imagine how embarassing that would be to a billionaire to get shown up by an AIDS-infested (presumably) faggot.

It's all about social status. The taller they are, the harder they fall. Fortunately for them, we live in a culture that can shoot the messenger so they don't have to fall.

Those evil hackers, I'll tell ya. They're genius mutant autistic savants from the 9th dimension who never get laid. That's the only reason they can show up our best and brightest.

Re:Careful Reporting These (1)

Shavano (2541114) | about a year ago | (#43883993)

Why don't you climb down off that high horse and join the rest of us in the real world, where breaking the law is a risky move and publishing a cookbook showing how to penetrate somebody else's computer network is considered antisocial behavior?

Re:Careful Reporting These (0)

Anonymous Coward | about a year ago | (#43884449)

Technically, these days you get sent to prison merely for reporting the problem (since it means you figured it out somehow).

and now he be researching the side of jail down un (2)

Joe_Dragon (2206452) | about a year ago | (#43880865)

and now he can be researching the in side of jail down under hands on.

Re:and now he be researching the side of jail down (4, Insightful)

Frobnicator (565869) | about a year ago | (#43880961)

Sadly, he probably will.

Financial institutions want to keep their vulnerabilities quiet. People who shout them to the world face lawsuits

If you are smart enough to discover a major exploit, also be smart in how you notify them. There are many great security companies who work as middle-men to help submit the bugs to the corporations and at an appropriate time make the information public so it gets fixed.

Going through a security company is free, and means you won't get the big splash on news sites or all the public attention, but it also means you can generally avoid hiring a lawyer, or worse, having he cops knock at your door with warrants.

Re:and now he be researching the side of jail down (1)

Architect_sasyr (938685) | about a year ago | (#43881383)

Not really a banks fault though - why is the browser hanging on to post'd data after it's been post'd??

Re:and now he be researching the side of jail down (4, Insightful)

FireFury03 (653718) | about a year ago | (#43881419)

Not really a banks fault though - why is the browser hanging on to post'd data after it's been post'd??

So that when you hit refresh on the page, the browser can pop up its usual "you'll need to repost to refresh this page, are you sure?" and do the repost if you tell it to.

Re:and now he be researching the side of jail down (1)

Architect_sasyr (938685) | about a year ago | (#43881591)

The Bendigo at least set those fields to autocomplete off - so should the browser actually be doing that then... or even keeping it for two hours plus.

Re:and now he be researching the side of jail down (0)

Anonymous Coward | about a year ago | (#43882381)

It has nothing to do with autocomplete. Reposting data when you refresh the page is a completely different feature.

Already running? (5, Insightful)

Anonymous Coward | about a year ago | (#43880873)

You have to be infected first for your credentials to be stolen? Couldn't the hacker just have installed a key logger?

If you can't trust the machine, don't put your sensitive data on the thing.

Re:Already running? (2)

slashmydots (2189826) | about a year ago | (#43881005)

And yet regardless, he's not getting in. If I so much as log into my online banking from another computer let alone another state or country, I have to enter multiple security question answers as well. Almost every bank does it that way. If yours doesn't, get a new bank.

Re:Already running? (5, Insightful)

You're All Wrong (573825) | about a year ago | (#43881249)

So you're saying that if you log in from a new infected machine, your bank obliges you to leak sensitive security information to the keylogger that's been installed there?

Congratulations for feeling all warm and fuzzy from your bank's security measures whilst gaining very little actual security against real threats - that's what they were hoping you'd feel, you're a good customer.

*One time* passwords are the *only* thing that *can't* be re-used. By definition. If your bank does not use them, get a new bank.

Re:Already running? (0)

Anonymous Coward | about a year ago | (#43883195)

and man in the middle phishing would still work with one time passwords

Re:Already running? (1)

You're All Wrong (573825) | about a year ago | (#43894477)

Correct. MITM is a real threat.

However, it's one that has been mostly solved. Never bank with a bank that logs you in over anything but HTTPS POSTs. Do not accept certificates by default. Do not accept CA certificates by default (apart from Honest Achmed - I bought a scooter from him, he's trustworthy). Verify new certificates - check the identities of both parties (site + CA). Do not run javascript or other scripts from arbitrary sites. For paranoia, use NoScript's additional protections for XSRF, etc.

You may call me paranoid. I prefer to call it "safe". (In fact, the only reason I accept certificates is as a promise of protection against MITMs. I do not interpret it as in anyway meaning that I actually trust the site to not send me malicious data, for example.)

Re:Already running? (1)

Impy the Impiuos Imp (442658) | about a year ago | (#43881707)

Based on how this works, I've hashed out a method to spy on the president:

1. Sneak into the White House
2. Hide under the oval office desk.
3. Now the tricky part -- listen to conversations.

Re:Already running? (1)

gl4ss (559668) | about a year ago | (#43882601)

You have to be infected first for your credentials to be stolen? Couldn't the hacker just have installed a key logger?

If you can't trust the machine, don't put your sensitive data on the thing.

well, it sort of matters if you can log back into the bank again with those credentials after you've signed out. that means you're note really signed out.

that is a big deal, actually.

How bloody embarrassing! (4, Informative)

beaverdownunder (1822050) | about a year ago | (#43880883)

Aussie IT is a bit Mickey Mouse all around, sadly -- especially in the banks, oddly (you'd expect a higher standard where billions of dollars are concerned, but no...)

As for the researcher, they didn't actually 'hack' into anything, merely scraped their own computer for data, so I wouldn't expect them to face any problems over revealing the exploit. Probably hasn't won them any friends in the banking sector though...

Re:How bloody embarrassing! (4, Insightful)

bloodhawk (813939) | about a year ago | (#43881577)

While this isn't exactly shining a pleasant light on the quality of the banks code. It is still very much a storm in a teacup, if you have access to scrape the memory of the computer then you could have gotten access to credentials in a far simpler means such as keylogging. The simple fact is if you can't trust the machine you are using you're already boned and no amount of secure coding from the bank is going to save you. Besides which I believe most of those banks (if not all) do 2 factor auth to transfer funds to accounts you haven't previously transferred too. (at least the 2 of them I use do).

Re:How bloody embarrassing! (1)

mathew42 (2475458) | about a year ago | (#43882033)

Westpac are reported not to be vulnerable to this hack, but their online banking usernames are a 8 digit number and the password are only six characters. The available characters are [a-z] and [0-9]. This is the login page [westpac.com.au] .

Re:How bloody embarrassing! (1)

skegg (666571) | about a year ago | (#43882519)

But I presume you only get 3 attempts before the account is locked-out. Even 10 attempts would be safe.

Re:How bloody embarrassing! (0)

Anonymous Coward | about a year ago | (#43881695)

Aussie IT is a bit Mickey Mouse all around, sadly -- especially in the banks, oddly (you'd expect a higher standard where billions of dollars are concerned, but no...)

As for the researcher, they didn't actually 'hack' into anything, merely scraped their own computer for data, so I wouldn't expect them to face any problems over revealing the exploit. Probably hasn't won them any friends in the banking sector though...

Which simply goes to show don't hire morons and expect them to write good javascript, php or whatever or think about how script functions can be exploited on the remote node. Sounds like they hire anyone down there with the ability to write a server side script and most likely the cheapest coding farms they can find!

And he's gone... (-1)

Anonymous Coward | about a year ago | (#43880897)

Went after the banks? Damm that's really stupid.

And you TOLD people you did this? Damm... Amazingly stupid.

And now you'll goto jail. And i'm ok with this... Stupid that monumental should be punished.

Messed with the money... You're lucky you're not in america.. You'd be shipped off to gitmo.

Wait, so your machine is already compromised? (3, Insightful)

complete loony (663508) | about a year ago | (#43880921)

So he's running malware that's sniffing your browsers memory? If your machine is already compromised, there are easier ways to get access to login credentials.

Re:Wait, so your machine is already compromised? (0)

Anonymous Coward | about a year ago | (#43880951)

These banks generally require a second factor of authentication for risky transactions, so username and password is not enough for the bad guy to get money.

Re:Wait, so your machine is already compromised? (1)

Anonymous Coward | about a year ago | (#43882269)

so keyboard logging AND screenscraping? Now enough info for the bad guy to get money?

Careful! (0, Troll)

Anonymous Coward | about a year ago | (#43880969)

In the Down Under, the brain of most business owners is located in their arse and this researcher could soon be sued for hacking the banks.

Re:Careful! (0)

TapeCutter (624760) | about a year ago | (#43881495)

This ain't the US mate, there is absolutely nothing illegal about "hacking" 127.0.0.1 to find your own password, the only people who will give a rat's arse about that are the tinfoil hat types. Even they will forget about it next week when they're busy building their sadomasochistic fantasies around the next "cyber war" story.

It's so fucking simple even a US senator could understand it. If someone has control of your machine then of course they can scrape it's memory, but a run of the mill keylogger would be much less hassle and far more useful.

Re: Careful! (0)

Anonymous Coward | about a year ago | (#43881841)

Not so simple. This could be considered reverse engineering - just ask mr Conroy, he'll tell you.
As part if the Free Trade Agreement(or some such horseshit), we blindly accepted the DMCA and other such draconian laws in Australia. This guy could easily be boned.

My bank doesn't seem vulnerable (4, Interesting)

jonwil (467024) | about a year ago | (#43881089)

My bank uses POST in the login form which means that sniffing memory for URLs (which is what this malware seems to do) wont get you a login.
Plus, in order to actually transfer money to someone you haven't transferred money to before you have to input a second password.

The biggest failing of the bank in question is that it has a 10 char maximum on passwords for some stupid reason.

Re:My bank doesn't seem vulnerable (0)

Anonymous Coward | about a year ago | (#43881145)

These are POST variables, which basically look the same as GET variables (key1=value1&key2=value2), just not passed in the URL.

Also a second password is almost worthless since the attacker can just reuse it once they get their hands on it.

Re:My bank doesn't seem vulnerable (0)

Anonymous Coward | about a year ago | (#43881395)

Also a second password is almost worthless since the attacker can just reuse it once they get their hands on it.

the second password is a one-time transaction token. do anything regarding moving money out of your account to a "new" destination, or change any detail used to identify or communicate with you, and the system sends an sms to your mobile with a confirmation code. that code must be entered in order for any transactions or changes to go through.

Re:My bank doesn't seem vulnerable (2)

chrismcb (983081) | about a year ago | (#43881587)

The biggest failing of the bank in question is that it has a 10 char maximum on passwords for some stupid reason.

I've always assumed that anyone that limits the password to an arbitrarily small number, or limits what characters you can use, does so because of incompetence. And so it makes me wonder what other security vulnerabilities there are.

Re:My bank doesn't seem vulnerable (2)

DarkOx (621550) | about a year ago | (#43881839)

I agree its major red flag. Yes there needs to some limit; you don't ever want to take user input of undefined maximum length, but in the case of passwords a sane max is like 255 bytes, which might be a bit shorter than 255 chars if you are running utf8, and is probably still enough if you need to use a two byte character encoding.

When you lengths like 8 or 10 it leads one to assume passwords probably are being stored insecurely; after all if they were hashing passwords like they should be the final storage requirement would not depend on the size of the original password string.

Its like hanging a sign out "Hey pen testers compromise this box, good password list to try on everything else can be found here!"

Limited password length (1)

140Mandak262Jamuna (970587) | about a year ago | (#43881871)

It is really dumb to limit the password to something so small as 8 or 10 char. Or disallowing non-alpha numberics like $ + - @ # % .

But one of the common vulnerabilities is buffer overrun. So they want to limit the read to some fixed number instead of looking for the trailing null, in an unlimited loop. So the right thing to do is set the limit to some moderately large number, like 128, allocate space, write nulls into it and then read the data into that buffer. Why it can't be really big like 1K or 2K? Well, it is possible to pack lots of instructions into a 1K or 2K buffer, and we dont want to provide that much of memory in a user writable space. Of course a well written authenticator will immediately clear every user written buffer as soon as they are done reading.

In reality some UI designer limits the amount of data to be entered limited to the space provided in the edit box in the GUI. By default most screen controls like buttons and edit boxes are sized by the string buffer allocated for it. It is always possible to change the size of the control explicitly, but there are many programmers who are lazy or incompetent and don't use it,

Re:Limited password length (0)

Anonymous Coward | about a year ago | (#43883185)

The limiting factor for passwords is the encryption algorithm and the DB, not buffer space. Most web programs want to shove the password into a varchar field in the DB and that's limited to 255 characters. That's 255 after encryption. And the encryption takes more CPU time the longer the password... So you say "but CPU time is cheap now and they can store the password in a text field," and you're right except that all the commonly used web software is still based on older tech, so it's more about entropy than anything... So they really need to rewrite the password handling software, but that won't do any good because no matter how strong your password is, it'll never be good enough to make your account entirely secure.

Passwords are there to stop your ex from logging into your account, not to stop hackers.

For real security read the last paragraph in this comment [slashdot.org] .

In reality some UI designer limits the amount of data to be entered limited to the space provided in the edit box in the GUI. By default most screen controls like buttons and edit boxes are sized by the string buffer allocated for it. It is always possible to change the size of the control explicitly, but there are many programmers who are lazy or incompetent and don't use it

Bullshit. 1. The only lazy and incompetent programmers are those in charge of the common browsers and the web standards who still haven't incorporated anything other than the most basic UI elements into the web standards. E.g. there are still no combo box or slider controls defined in the HTML Form standards or natively supported by the browsers. That's the real crime. 2. You want to make your user interface consistent with other websites out there, especially when you're dealing with the general public. If you create a login page that looks very different than the thousands of existing login screens, some visitors may freak out and think they've hit a phishing website.

Re:My bank doesn't seem vulnerable (2)

WD (96061) | about a year ago | (#43882707)

You're joking, right? Please tell me that you don't think you're protected from banking malware because your bank uses POST instead of GET.

Strengthening Ties with Scrumptious Cakes (-1)

Anonymous Coward | about a year ago | (#43881163)

Cakes are the most important choices for celebrating occasions like birthdays, weddings, success and many other special days. Now you can Send Cakes to Thane with the impressive network and astonishing services of the www.cakesdeliverythane.com that has so many sections containing such a great variety of cakes.

Re:Strengthening Ties with Scrumptious Cakes (-1)

Anonymous Coward | about a year ago | (#43881213)

Excellent, I will order 100 cakes with all this free money I just got from the Australian Memory Giraffe.

horses and barns (3, Informative)

stenvar (2789879) | about a year ago | (#43881217)

If malware has access to the RAM of another process, the horse has left the barn.

Re:horses and barns (0)

Anonymous Coward | about a year ago | (#43881245)

better: if your computer is infected, the wolf is already in the hen house.

Re: horses and barns (2)

starsky51 (959750) | about a year ago | (#43881281)

And if the user is gullible enough to run any exe that they come across, then the sheep is sitting to close to the barbecue.

Re: horses and barns (0)

Anonymous Coward | about a year ago | (#43881305)

And if the user is gullible enough to run any exe that they come across, then the sheep is sitting to close to the barbecue.

Heathen... mutton and lamb should be slow roasted - at LEAST 4 hours, preferably 6. Any other method of cooking (especially barbecue) is barbarous waste of food that could have been heavenly but instead tastes like left over scraps of dog food.

Umm - all banks worldwide? (1)

Anonymous Coward | about a year ago | (#43881355)

This would probably affect every single Internet site in existence. And there is no solution, nor can there be

There is a company in Australia selling JavaScript that encrypts form field - I assume this guy is associated to that company & trying to drum up a sale, while hiding the fact they are selling snake oil.

Re:Umm - all banks worldwide? (0)

Anonymous Coward | about a year ago | (#43881491)

This would probably affect every single Internet site in existence. And there is no solution, nor can there be

Wouldn't affect most Swedish banks, they tend to use OTP/two factor logins.

Re:Umm - all banks worldwide? (1)

Anonymous Coward | about a year ago | (#43882021)

I beg to differ ! This is half the browsers fault and the other half Banks/sites ... The browsers should not store the memory that long, and the sites should atleast use similar coding as to the way in that dudes video with the Jscript encoding. Sure there is other ways to grab those details but in way what your saying sounds the same as "There is a cure for for liver cancer, but don't get THAT because there's other cancers that can kill you!"

Re:Umm - all banks worldwide? (1)

Anonymous Coward | about a year ago | (#43885517)

I actually do this as well on a site I'm about to release. I use Javascript RSA library from some students at standford (http://www-cs-students.stanford.edu/~tjw/jsbn/). What I do is, hide the signup & login forms if the user has javascript disabled. I create an SSH Private/Public key pair for the user server side and pass the rsa_e & rsa_n modulus (public key) to the Javascript library. When the user exits a particular field such as a password field or more importantly an credit card related field, I use jQuery to convert the field to password type and I also encrypt the data in the field with the generated SSH public key. I also use end to end SSL. The reason I do this is to make Man in the middle attacks on CC Data and login credentials that much more complicated. The encrypted form values are then sent encrypted to the server and then decrypted by my server side code.

The only downside I have found so far is if the form fails, it makes it impossible to pass back validated data so the user doesnt have to re-enter. I have come up with a somewhat elegant solution for that as well.

After reading this, im hoping anything stored via memory will be stored encrypted as well as that is what would be displayed if the form is refreshed.

I'm starting to be sick (4, Insightful)

trifish (826353) | about a year ago | (#43881375)

I am really starting to be sick of these "security researchers" who don't know that the 1st law of the computer security is:

If malware is running on your computer, it is not your computer anymore.

It follows that no matter what you do, malware will win. Discovering that malware can "siphon" memory is really... uh, groundbreaking.

What makes me even more sick is the incredibly amount of various BlackHat "security conferences" and supposedly geek-oriented media like Slashdot that let those people present this kind of "discoveries" as legitimate, notable, noteworthy, important and new.

I am really, really, sick of you.

Re:I'm starting to be sick (0)

Anonymous Coward | about a year ago | (#43881409)

What’s even more pathetic is the man’s YouTube video-as-article.

Re:I'm starting to be sick (0)

Anonymous Coward | about a year ago | (#43881659)

I am really, really, sick of you.

Just wait. In a few years you'll be sick of virtually everything that happens on Slashdot.

Indeed, the only reason I'm still here is because the rest of the internet is just a tad more idiotic.

This article lacks key information (1)

Gumbercules!! (1158841) | about a year ago | (#43882343)

*All* of those banks insist on two factor authentication for money transfers. I use 2 of them and every single person I know (here in Australia) is either issued an RSA token or has SMS alerts on money transfers (an SMS is sent to you with a code that must be entered before the transfer will take place). So even with the password, you can't transfer money out of an Australian bank.

Re:This article lacks key information (0)

Anonymous Coward | about a year ago | (#43882987)

Your kidding right?

How on earth do you think wire fraud is actually commited. You think all the cases of transfer fraud is oz is done without a password... Errr. Sure its two-factor but you need the password as much as you need the sms code.

Transfer 101 - got the pass? And access to box (not needed but helps) all you need now is to port the mobile number...

1. Go to carrier shopfront ask for blank sim
2. Call carrier from wherever you like
3. Use - dob, license number, address that's the norm for aus carriers
4. Ask to "port" your number over ( you lost your phone )
5. Use password to login banking and send away son

Txts will go to you. I'd suggest you do your homework on wire fraud and just admit the banks should just fix it and move on. Ill admit its no great discovery from this guy but if they can fix it hell why not.

Re:This article lacks key information (1)

Gumbercules!! (1158841) | about a year ago | (#43896371)

Yes, everyone has heard of cases where this has happened however they're few and far between - and generally historic (as in at least 3 - 5 years ago). This is why Telco's are supposed to have passwords on phone accounts, required before you can port. Speaking as someone who regularly ports numbers for customers at work, it's not longer a simple process - you are required to verify ownership of a number before it can be ported. I'm not saying it can't be done but it's not as easy as it was before a high profile case of it happening broke about 3 years back

However my point was, and remains, relating to this article - taking someone's bank password does not automatically mean you can transfer money out of their account. In the case of these banks, it's unlikely someone who had your password alone could even transfer money. The Commonwealth issues RSA tokens, not SMS verification, for example.

Most money fraudulently obtained from Australian banks - in fact the vast, vast majority of it - just uses plain old social engineering (i.e. dating site scams on lonely people or too good to be true purchases from Gumtree or eBay that people still fall for).

Government will steal it anyway (1)

CuteSteveJobs (1343851) | about a year ago | (#43882411)

Australian government is now seizing bank accounts by declaring them 'inactive' if they haven't had a transaction in three years. Financial planner found $150K vanished and they also shafted a pensioner who got back from heart surgery to find his account seized. Probably hit other people who won't know yet, or elderly whose relatives won't even know the money is missing. Sure it'll be put to good use refurnishing bureaucrats offices: http://www.couriermail.com.au/news/queensland/brisbane-woman-has-had-more-than-150000-taken-from-bank-account-under-recent-law-changes/story-e6freoof-1226654782499?from=trendinglinks [couriermail.com.au]

Re:Government will steal it anyway (1)

kermidge (2221646) | about a year ago | (#43885365)

Three years? I wonder how long one must be missing to be declared dead. Seems to me the bank account should wait for probate or the equivalent.

Could I get a copy. (1)

Ralph Ostrander (2846785) | about a year ago | (#43882939)

:) Oh I would have paid.

easy fix (0)

Anonymous Coward | about a year ago | (#43883089)

the bank should just have you call in and give the username and password over the phone, that will fix the problem. lol

Could someone explain this? (0)

Anonymous Coward | about a year ago | (#43883429)

Excuse my naiveté, but how is this "so easily avoidable?" Lets put aside the fact that malware is already on the machine. How does one cause the browser to encrypt what it stores in memory. I don't believe that that a bare bore HTML form would protect from this kind of attack. The browser might encrypt the memory pages when push out to disk but thats not the issue here. At some point, for a plain HTML form, the browser must store the info in memory.

The possible solution I see is that encryption is performed via javascript, then a forensic analyst would have to go in and check that nothing was missed. If it was written in C this wouldn't be a problem. I imagine that javascript objects are copied around to different parts of memory for their GC algorithms. Therefore, this solution seems very error prone to me.

Any explanations, articles, resources that people could point me too would be much appreciated. Yes I already tried googling for it already.

Really? (0)

Anonymous Coward | about a year ago | (#43883443)

Is this software logging FORM (POST) requests and claiming that it is a vulnerability? Are there more than 20 websites (outside Singapore) on the planet that encrypt credentials on the client prior to sending them to the server? I can demonstrate this on my machine for pretty much every US bank. Did I miss the point?

Focus on the Solution, not the Problem. (1)

VortexCortex (1117377) | about a year ago | (#43884547)

It would be great if financial companies were required to make a publicly accessible testing site, in order to qualify for benefits from government, like insurance. The testing site would be a mock-up of the current system. Just copy the code over keep a separate database, it wouldn't have to be large because it won't do the same volume and we don't all need unique accounts. I mean, there is testing and production systems already, right? So, after pushing to production you also push to public testing. This way, I can hack your systems all day and night, and not worry about going to jail for trying out the exploits I think exist -- Some are even just changing URL parameters...

The government insures the banks, but the banks aren't setting up a system where it's easy for folks to test and report vulnerabilities. It should be a no-brainer. You want car insurance? You have to drive safely and get your car inspected, also anyone can report your bad driving or smoking engine via your mandatorily exposed license plate number... Since everyone can't just visibly inspect the live version of the online systems without falling afoul of the law, then we need a mock-up.

I mean, they let me inspect the vault where my safe deposit box is... I don't get to swing a hammer, but at least I can see if the door is made of steel, and the guard is armed and paying attention. We should be able to knock on the digital vault door to ensure it's not wafer thin. I don't trust the bank to put items in my safe deposit box for me, I do that myself. Just because I put my money in the bank, doesn't mean I trust their security practices completely. I don't think we should be trying to hack the live systems because it could cause disruption, but in the current system if we notice a damn exploit we can't even report it. It would be like noticing the guards are just distracted teens with cell phones instead of guns or batons, and that there's a huge hole in the side of the vault with muddy footsteps leading in and out through it, but you'll get thrown in jail if you say anything about it at all!

Back when this online banking thing started I accidentally changed the URL parameters while logged into one of my banks' online portals. I was trying to copy paste the URL field, but ended up changing the digits in my user ID. Suddenly, my account balance was drained!? I brought up a few more account pages and my savings account wasn't just drained, it was GONE!! Wait, no, the name in small print under the company logo wasn't mine! Another users account had been pulled up. Whew.... Oh Shit! I just accessed another users account AND rummaged around looking at all the funds! I immediately logged out. I did not report anything to anyone. I was afraid that accidentally discovering a vulnerability could land me in jail if I reported it, even if I never intended to "hack" anything. It was still accessing an account without permission, a violation of the US's computer fraud and abuse act -- Similar to using a browser that someone is still logged into, you see their "private" social media stuff because they're not logged out; The bar for triggering the CFAA violation is ridiculously low. Since the bank had crappy security, and incompetent web developers I closed my account the next day. When asked why I was leaving their service, I said in the sternest voice I could conjure, "There is a large theoretical hole in the side of your bank's vault, apparently no one can see it but me, and I can't even legally show you where it is." The look on the clerks face was priceless. These banks shouldn't qualify for government benefits, IMO. I mean, security audit? No, that's obviously not working, or you wouldn't have been able to drain any account by changing a number in the URL bar... The public would do a better job for less.

I would have loved to be able to log into a mock-up site. Perform the "exploit", show them what's happening, and give them all the info they need to fix the problem. In TFA, it would be great if there were a way to actually test the security they say these tokens provide. The key should NEVER be in plain-text in RAM. That's just DUMB. The way I do it is that the key stays encrypted, and is decrypted one byte at a time, as each byte is fed into the cipher that performs the key expansion. This way, you have to not only be scanning RAM for a key that works, but you have to also hook the execution stack. Look, all digital security is security through obscurity. One or two extra bits of obscurity doubles or quadruples the difficulty. 512 bits of obscurity is what some folks consider secure. 513 bits is twice as hard to crack, every little bit counts. That's why we should be able to poke around and examine things. We could find that half of those 512 bits don't even exist, or that the bits don't actually secure what you think they do.

How to prevent this? (0)

Anonymous Coward | about a year ago | (#43884687)

Are you telling me the solution to this is to encrypt the password in javascript? How do you manage the keys? If someone could explain how your supposed to write your code to prevent this on the client side, it would be much appreciated.

Put your claws back in, Fix the problem, Move on (1)

kojimasec (2891815) | about a year ago | (#43887525)

few people commenting saying that it's no danger since all Aussie banks use 2-factor SMS etc. They seem to think the password is worth nothing, That's fine however i doubt these people actually know how transfer fraud works. Meaning you need the password just as much as you need the SMS-code, And if you have access to the machine or at least password, It increases your chances to be able to port the SIM-CARD. It usually works like this FYI - 1. Got login pass for Bank, even better if they use same for e-mail ( You can delete the money transfer notification ) 2. Depending on access be it E-mail or just PC access remotely chances are you can be crafty enough to get the details needed to port the SIM-CARD 3. DOB, License No., Address etc 4. Go to carrier shopfront request blank sim-card 5. Call carrier saying you lost your phone and you need to transfer sim 6. After 20-45 minutes, Victims phone will lose connectivity which can be combined with a bogus message from attacker warning of network drop-outs 7. Login with harvested pass, SMS security message comes to you. 8. Bobs your uncle. References - http://www.bankwest.com.au/media-centre/media-releases/mobile-phone-porting-new-type-of-scam-to-look-out-for-1292493597511 [bankwest.com.au] - http://www.scmagazine.com.au/News/282310,45k-stolen-in-phone-porting-scam.aspx/0 [scmagazine.com.au] - http://www.flyingpenguin.com/?p=14540 [flyingpenguin.com] Put your claws back in, and focus on the problem here, If one bank can avoid it they all should.

What about me... (1)

PuZZleDucK (2478702) | about a year ago | (#43893693)

... I'm with a credit union? :p
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?