Live data from Hacker News

A fraudster got $12M out of a Canadian university

thestar.com

101–110 of 119 posts

Re: A fraudster got $12M out of a Canadian university

#101

Earlier quoted context omitted.

> they can't tell me because that would violate my privacy or something If someone can't tell you why you owe a bill, don't pay it. If they can't tell you, they can't tell a court.

The thing is, they probably could tell the court, if it came to that (nevermind that most people couldn't afford the time or money to take it that far) . Just because someone isn't being candid about why you owe them money, doesn't mean you don't still technically owe them money in a way that can be proven. I don't know if a judge would have the discretion to waive a debt that wasn't fairly "divulged".

Perhaps a good tactic would be to ask them in writing what the bill is for.

Re: A fraudster got $12M out of a Canadian university

#102
post #98

Earlier quoted context omitted.

But the process is broken by people not realizing that invoices are fraudulent. The method of delivery, be that email or some other system, is completely orthogonal. Running their invoices through SAP or having gpg signed pdf invoices or using more node.js would not help because all of those solutions fail to address the fact that people are dumb and need to be trained to avoid scams.

If a (insert centralized service here) friend tells me about a change of plans, and I know that messages with that contact were successful in the past, then plans indeed changed because it's spoof-proof so long as you didn't make friends with two accounts that end up sharing a name and so long as the sender didn't fall victim to phishing of creds. If an email from a contact comes in, the from/sender headers can be sp…

All you've done is moved the problem from your organization to theirs.

Phishing can still pwn you.

Re: A fraudster got $12M out of a Canadian university

#103
post #71
post #21

Earlier quoted context omitted.

While I think everyone should be aware of phishing, I don't think any amount of education can reliably prevent this sort of fraud. I see this fundamentally as a process problem, as I assume email was a common way of changing payment information. Email needs to be taken out of the loop.

I disagree. Taking email out of the loop is a technical solution to a problem that is inherently social, not technical.

As is, say, bathing.

Re: A fraudster got $12M out of a Canadian university

#104
post #70

Earlier quoted context omitted.

No, because SMTP "accounts" are trivially spoofable as well. (Edit: Although you wouldn't want to spoof that if you need to get replies, so maybe there is something the client can do here.) Maybe you could try to do some kind of trust-on-first-use on the chain of Received headers but that's going to generate false positives.

We do have several solutions in place for that, though. SPF, DKIM, among others. If this University were running on gmail I suspect this email would have been flagged for phishing (the builder did publish an SPF record), or outright rejected. However they run their own email servers[1]. [1] - They could of course do the same checks and even more, but among self-hosted installs it is common to disregard those addition…

What about PGP? No signature, immediate red flag.

Re: A fraudster got $12M out of a Canadian university

#105
post #102

Earlier quoted context omitted.

If a (insert centralized service here) friend tells me about a change of plans, and I know that messages with that contact were successful in the past, then plans indeed changed because it's spoof-proof so long as you didn't make friends with two accounts that end up sharing a name and so long as the sender didn't fall victim to phishing of creds. If an email from a contact comes in, the from/sender headers can be sp…

All you've done is moved the problem from your organization to theirs. Phishing can still pwn you.

True, but making credential theft a prerequisite is helpful.

Re: A fraudster got $12M out of a Canadian university

#107
post #9
post #2

This seems like a technology problem, not a personnel problem. There should be more checks in a system when you are changing bank accounts where so much money is going to be deposited.

Seems like it should be more of a process and personnel problem, and one that should account for the problem of social engineering. > As a result, one particular email, sent June 27, didn’t set off any alarms. Sent by a James Ellis of Clark Builders, a construction company working on the project, the email opened with the affable “Hiya” before asking the school’s accounts receivable department to reroute payments to…

"such as a phone call (from the CFO's office)"

Caller ID is trivial to spoof. What you want is a phone call to the CFO's office, not from.

Re: A fraudster got $12M out of a Canadian university

#108
The technical solution is easy and it is the same solution as when we make bank transactions online: one time pin codes.

If another company wants you to send payments to another bank account, then you mail back the received pin code to that other company via another known email account.

If the known email account responds that the pin is legit, then go ahead and change the payment details.

Also, before changing the payment details, do send a small amount first, have it confirmed with the other company and then proceed with the test of the payment.

Re: A fraudster got $12M out of a Canadian university

#109
post #98
post #83

Earlier quoted context omitted.

I don't see it as a technical solution, but fixing a broken process .

But the process is broken by people not realizing that invoices are fraudulent. The method of delivery, be that email or some other system, is completely orthogonal. Running their invoices through SAP or having gpg signed pdf invoices or using more node.js would not help because all of those solutions fail to address the fact that people are dumb and need to be trained to avoid scams.

Yes, the problem is people on the paying side not realizing that payment change requests are fraudulent. So a better process removes people on the paying side routinely changing payment information. Require that payees sign into a separate service and they change the payment information themselves.

Re: A fraudster got $12M out of a Canadian university

#110
post #85

Earlier quoted context omitted.

Which is why I said it's a process problem. But you definitely want email out of the process since it's not reliable.

OK, but what would you replace it with that was more reliable? If a company takes the time to, say, use GPG then email is probably the most reliable method available.

A service where the payees have to sign in and change the payment information themselves.
Post reply on HN