Bill Gates offers $5000 for Facebook sharing? It's just not that funny

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Bill Gates may be a billionaire, but if he's going to splash his cash around he's got better things to do with it than give it to people who simply share a photo of him on Facebook.

That hasn't, however, stopped almost 400,000 people on Facebook from sharing an image of the Microsoft founder, holding an (obviously Photoshopped) message:

Hey Facebook,

As some of you may know, I'm Bill Gates. If you click that share link, I will give you $5,000. I always deliver, I mean, I brought you Windows XP, right?

Clearly, no-one is going to receive any money for sharing the image. And chances are that the picture was meant as a joke (although it would have been funnier if the message hadn said Windows Vista rather than Windows XP, or referenced Microsoft Bob, or reminded people of Bill Gates's claim that spam would be killed off by 2006).

On this occasion, the message being spread across is harmless. It doesn't trick users into clicking on a dangerous link, or fool them into installing a rogue application. It is, of course, adding to the general "noise" on Facebook and some might consider it unwanted spam.

But the more you share "jokes" like this, and the more used your friends and family become to you spreading such material, the more likely it is that you're fostering an atmosphere where forwarding chain letters, hoaxes and jokes is considered the norm.

And the more you share material like the picture above, the *less* out of place a *real* scam or malicious link will appear to your friends and family when your Facebook account gets compromised.

So, call me a kill-joy if you like, but jokes like this aren't necessarily going to end up with everyone amused.

Don't forget you should join the Naked Security from Sophos Facebook page, where we keep you up-to-date on the latest hoaxes, scams, security and privacy issues affecting Facebook users.

Follow @gcluley

View the original article here

Microsoft to issue 9 security updates on Tuesday, critical for all IE versions, reboot required

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Microsoft has issued its routine advance notification for the coming week's Patch Tuesday.

As usual, the "pre-announcement" is a bit like a bikini: interesting more for what it conceals than what it reveals.

Nevertheless, there's enough to make sure you're ready for Tuesday 09 April 2013 (or Wednesday, of course, if you live at the longitude of about Thailand or further east).

This month's nine updates don't sound too onerous, with just two at critical level and the remaining seven important, but the critical ones affect Internet Explorer (IE) and Windows itself, and the IE fix will require a reboot.

Just so you know.

Importantly, the IE update applies to all supported versions of the browser, from IE 6 to IE 10, on all supported version of Windows, from XP and Server 2003 to Eight and Server 2012, in both 32-bit and 64-bit flavours.

Server Core installs, happily, aren't affected by either of the two critical flaws.

? Internet Explorer isn't part of a Core install, which doesn't support GUI applications for safety's sake. This reduces your attack surface area tremendously and you should go for a Server Core installation whenever you can.

As you may have seen, there has been plenty of speculation that the critical updates will include patches for the IE vulnerabilities exploited in the recent PWN2OWN competition.

Mozilla and Google triumphantly rushed out patches to the holes in Firefox and Chrome that were found at PWN2OWN, closing down the vulnerabilities within 24 hours.

As we remarked at the time, this certainly threw down the patching gauntlet to Microsoft, though we also pointed out that:

Redmond, to be fair, has many more products with much more complex inter-relationships to juggle than Mozilla, and even Google.

With the PWN2OWN rules this year requiring responsible disclosure, meaning that winners had to reveal their attacks to the affected vendors and allow time for a considered and tested fix, it wasn't actually necessary for Microsoft to rush.

If Redmond's security team does fix IE's PWN2OWN bugs on its offical April patch day, it will in my opinion have done a timely job, but until Tuesday, Microsoft is keeping the details up its sleeve.

Note that five of the non-critical patches fix what's known as elevation of privilege, a trick that allows untrusted software to do things beyond its official authority.

Usually, that means a program running as a regular user can complete operations that would normally require administrator privileges, such as modifying system settings or altering critical files,

As you can imagine, attackers often combine RCE, or remote code execution, with EoP, or elevation of privilege.

They use the RCE to escape from the strictures of your browser, or some other interactive application, and then the EoP to escape from the limitations of your regular login account.

Either sort of exploit is dangerous on its own, but together they are much more harmful.

So plan to patch all the holes, not just the critical ones, and watch out on Naked Security and the SophosLabs Vulnerabilities page for our analysis and assessment of the updates once we're clear to publish.

(We have to wait until Microsoft has made the updates live before we give away any details.)

Bonne chance!

Follow @duckblog

View the original article here

Rohypnol, rape and other disturbing content. Isn't it about time Facebook cleaned up its act?

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

"People use Facebook to stay connected with friends and family, to discover what’s going on in the world, and to share and express what matters to them."

Those are the words of Facebook itself. And there's nothing wrong with that.

But, unfortunately, it doesn't tell the whole story.

There are also people who use Facebook to bully others, to spread hate speech, to defraud, spam, and commit online crimes.

In October 2012, when Facebook reached one billion active monthly users, CEO Mark Zuckerberg said he was "committed to working every day to make Facebook better for you".

If compared to the populations of countries, Facebook's more than a billion users dwarfs the likes of the United States, Indonesia and Brazil and is only outranked by China and India. In short, Facebook is colossal.

But what marks out Facebook for special attention is how it polices those many many millions of people.

A quick search on Facebook, using the most obvious of search terms, finds plenty of ghastly content that many good-minded people would find disturbing.

I'm not talking about Facebook pages like "Embarrassing Nightclub Photos", whose whole raison d'être appears to be to humiliate "tired-and-emotional" party-goers - many of whom probably wouldn't have given permission for a photograph of them to be shared on Facebook, if anyone had bothered to ask.

"Embarrassing Nightclub Photos" isn't my cup of tea, but clearly there's an audience for this kind of material (the page has over 160,000 Likes) who have no qualms about checking out and sharing images of people unconscious through over-drinking, who are so drunk they've become incontinent, or have been snapped midway through a vomit.

What is more disturbing to me are pages which take things a sinister step further.

For instance, there are pages extolling the virtues of the date-rape drug Rohypnol which use images of young women in either a drunken or comatose state.

In the following, and other examples used in this article, we have pixellated out the faces of individuals - something which the original posters on Facebook seemingly didn't care enough to do.

ROHYPHNOL

When traditional dating methods just aren't cutting it!

Is that a funny joke to you? An ill-conceived bad taste joke about rape? Or something more sinister? No doubt, you have your own point of view, and whether Facebook should do more to prevent this kind of content from being shared.

In case you forgot, here's how Facebook describes what it is used for:

"People use Facebook to stay connected with friends and family, to discover what’s going on in the world, and to share and express what matters to them."

One wonders how that sentiment sits alongside the "Roofies" page on Facebook, which has over 650 Likes, and a motto which appears to condone use of the Rohypnol date rape drug.

"Roofies", for the uninitiated, is slang for Rohypnol and other sedative pills that can be used to facilitiate sexual abuse.

ROHYPNOL ROOFIES When "Nooosshh..zzzzz means "Yes"

Pretty unsavoury stuff, I'm sure many of you'll agree. And there are plenty of other posts on the page which can only be described as pro-rape and against a woman's right to decide if she wants to have sex or not.

And there's more. A simple search of Facebook using offensive phrases can bring up no end of unpleasantness.

If you were a Facebook advertiser, how would you feel about your advertisement appearing on Facebook pages containing that kind of content? Is it something your brand would like to be associated with?

If it only took me a few seconds of searching to find content like this on Facebook, why can't Facebook search for similarly offensive phrases and take action against unsavoury content.

It's not as though only the only users of Facebook are broad-minded, unoffendable, adults.

Although young people under the age of 13 years old aren't allowed to log into Facebook, it's estimated that millions of pre-teens do go onto the social network every day. They, like the rest of us, can easily come into contact with this kind of offensive material on Facebook. They may even end up the victims of some of it.

Sadly, the onus is on Facebook users themselves to report abuse - which (might) then be followed-up by Facebook's four different abuse teams.

According to Facebook, abuse complaints are normally handled within 72 hours, and the teams are capable of providing support in up to 24 different languages.

If posts are determined by Facebook staff to be in conflict with the site's community standards then action can be taken to remove content and - in the most serious cases - inform law enforcement agencies.

Facebook has produced an infographic which shows how the process works, and gives some indication of the wide variety of abusive content that can appear on such a popular site.

The graphic is, unfortunately, too wide to show easily on Naked Security - but click on the image below to view or download a larger version.

Of course, you shouldn't forget that just because there's content that you might feel is abusive or offensive that Facebook's team will agree with you.

As Facebook explains:

Because of the diversity of our community, it's possible that something could be disagreeable or disturbing to you without meeting the criteria for being removed or blocked. For this reason, we also offer personal controls over what you see, such as the ability to hide or quietly cut ties with people, Pages, or applications that offend you.

My own experience from a few years back (when my wife's life was threatened, I was labelled a paedophile, and Facebook users warned that they would burn my house), was that Facebook chose to take no action until the press got wind of the story.

I would like to think things have got better since then - but the emails we receive at Naked Security from Facebook users suggest many still feel they aren't being properly protected from Facebook abuse.

The sheer amount of offensive material residing on Facebook says to me that leaving it up to the community to report offending content isn't working.

In my opinion, Facebook needs to invest resources and technology into pro-actively cleaning up its community, rather than relying on the community to police itself.

We would be interested in hearing about your experiences when you report abusive content to Facebook. Were you happy with Facebook's reponse? Join the discussion on our Facebook page

Follow @gcluley

View the original article here

Anatomy of a bug - misplaced parenthesis threatens NetBSD's random numbers

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Oh, frailty, thy name (with apologies to [William {The Bard}] Shakespeare) is parenthesis.

What a difference a misplaced bracket makes!

As our friends at The Register reported last week, the NetBSD coders recently patched a programming bug in their kernel that affected the sanctity of the operating system's random numbers.

And, as we have explored before on Naked Security, good quality random numbers are a vital aspect of modern computing.

In particular, cryptography requires random numbers that are not only random (meaning that there is no bias towards ones or zeros in the bits that appear), but also unpredictable (meaning that you can't guess what comes next even if you have an extensive collection of previous output).

Modern Unix and Unix-like operating system kernels typically provide two commonly-used sources of randomness, named /dev/random and /dev/urandom.

Both mix in input that isn't entirely dependent on software, such as mouse movements, disk latency measurements, network traffic, keyboard activity, and more.

? Mouse and keyboard movements are not a terribly good source of entropy, as "lack of order and predictability" is called in the field of random numbers. Indeed, user interaction never happens on headless servers. But mixing in at least some data extracted from the real-time behaviour of the underlying hardware, especially measurements that are affected by external factors such as temperature or load imposed by other devices on the network, helps to reduce the predictability of algorithmically generated output.

In practice, the difference between urandom and random is that the former continues unabated even if the external entropy feed runs dry, falling back on purely software-based output, while the latter stream of data may block, meaning that a program reading it will freeze until the entropy pool acquires some new input.

You can demonstrate this on a Unix-like system by running the command od -Ax -t x1 /dev/random and letting it run:

Every now and then, you should see the output pause for a while as the system's hardware-derived entropy pool dries up; wait a while (or wiggle the mouse to provide some external input to the pool) and the flow of random bytes should resume.

So, part of the promise of /dev/random is that it tries really hard to be random.

In NetBSD, which uses an AES-128-based random number generator keyed independently for each process that uses /dev/random, fulfilling that "promise" was done with code in C similar to this:

Turned into pseudocode, this is supposed to achieve the following result (the variable key is an AES-128 cipher key, 128 bits or 16 bytes in length):

read up to 16 bytes of high-quality random dataif we got fewer that 16 bytes then: produce a warning about entropy top up the 16 bytes with lower-quality data

Even if there is a shortage of high-quality entropy data, your random number stream will nevertheless consist of AES output keyed by a full 16 bytes of at-worst-pseudorandom data that is unique to your use of /dev/random.

Except that the C code above doesn't actually do what was intended. It was supposed to be:

Notice the subtle-yet-critical difference between sizeof(key-r) and sizeof(key)-r.

Due to the pecadilloes of C, sizeof(key) works out to be the size of the memory buffer key, which is defined in the NetBSD code similarly to this:

unsigned char key[16]; /* 128-bit AES */

Since r is the number of high-entropy bytes read in so far, sizeof(key)-r, which is what the programmer meant to write, works out to be the number of bytes by which r fell short of 16.

So, topping up the original r bytes of random data with a further sizeof(key)-r bytes of pseudorandom data ensures that a full 16 bytes of random data (whether of GOOD or ANY quality) are always used to seed the random generator.

This is so because, perhaps rather obviously, r plus sizeof(key)-r is equal to sizeof(key), i.e. 16.

But the programmer wrote sizeof(key-r) by mistake.

That doesn't really make sense, at least to a human, since sizeof() in C usually produces a constant determined at compile time, while r is the variable amount of data read in at runtime.

Sadly for NetBSD, however, a fixed memory address (in this case, the address of key) plus or minus a variable integer (in this case, r) is considered by the C compiler to be an address with an offset: in other words, just another memory address.

And so sizeof(key-r), computed at compile time, is equivalent to sizeof(the space needed to store any memory address), i.e. the sie of a pointer variable.

That is not the same thing as sizeof(memory actually dedicated to the array variable key).

Indeed, on a 64-bit system, sizeof(key-r) is 8; on a 32-bit system, with 32-bit memory addresses, it's only 4.

So, in the worst case, the erroneous code might perform as follows:

read up to 16 bytes of high-quality random dataoh dear, no high-quality data at all, so: produce a warning about entropy rely on just 4 bytes of lower-quality data

The bug was easily fixed, although it has been fixed again since The Register's article last week, following a decision that the original fix wasn't entirely satisfactory:

The good news is that in fixing the fix, the coder reviewing the original error came to the conclusion that even an ineptly-keyed random stream would probably not be predictable.

That's because the random generator continues mixing in additional input between the initial "keying" stage and the point at which the user starts getting data from it, adding entropy over and above the minimum four starting bytes.

Nevertheless, there are two lessons here that every C programmer needs to remember:

Watch those brackets.The sizeof() operator isn't a function.

Follow @duckblog

View the original article here

"We apologise for the previous apology" - NZ gov dept in email CC: double-blunder

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

When you send an email to a group of recipients who don't already know each other, you use BCC:.

Don't you?

Let us quickly revise why.

The users in the To: field (primary recipients) and the CC: field (secondary recipients) of an email get a copy of the message, including the headers To: and CC: themselves.

(CC means "carbon copy", by analogy with old-school carbon paper.)

That means they can each see the names of all the other primary and secondary recipients.

For an email such as the minutes of a meeting, it's often desirable to CC: all those who were present, since it means that everyone can see that everyone else got a copy of minutes.

The BCC: list (blind carbon copy), however, is not included in the email, so that:

The primary and secondary recipients don't know that the BCC: recipients saw the email.The BCC: recipients don't know who else was BCCed.

For this, reason, BCCing emails that already have a small, closed circulation list is often considered slightly devious or underhand: the sort of thing you might do to curry secret favour with your boss, or to leak the minutes of an internal communication to an outsider.

On the other hand, CCing a mailing list where each user has signed up independently is considered unsatisfactory.

That's because the mailing list database is supposed to be private, yet CCing everyone on the list publicises the whole list to everyone on it.

And CCing one customer's email address to another, or a list of customers to a competitor, isn't likely to make any of those customers very happy.

Even worse, of course, is that inappropriately CCing emails to an entire mailing list publicises the whole list to any spammer or scammer who gets hold of any of those emails.

And since emails frequently get forwarded, or saved on hard disks that later get scoured for email addresses by spam-sending malware, or uploaded onto online forums with all their content intact, CCed lists of email addresses aren't just a security irrelevancy.

? It might not sound too serious to CC an email to 20, 50 or 100 people who don't already know one another, but even if nothing deleterious happens as a direct result, it's a bad look for the sender.

So we had to smile (wryly, of course) when Naked Security reader hotdoge3 pointed us at a story from New Zealand in which a government department made a carbon-copy blunder by sending a "thanks for submitting your comment" email via CC to everyone who had submitted a comment via its website.

Assuming that the submissions were supposed to be anonymous, or at least private and individual, that's a mistake that really ought to have been avoided.

Thankfully, with only 150 people allegedly on the CC: list in the first place, the scale of the leakage was small.

But the story took an amusing twist when the Ministry for the Environment followed up with an "our fault, really sorry about that" email that was itself CCed to everyone.

And this, in turn, prompted a third email (apparently avoiding yet another round of recursion by correctly using BCC:, not CC:) to apologise, in a way that would have made Monty Python proud, for the previous apology.

The lessons to be learned are:

The To: and CC: headers are revealed to every recipient.The BCC: header is not.Don't put multiple recipients in CC: unless you intend them to see each others' addresses.Leaking email address lists via CC: helps spammers and scammers, even if only slightly.CCing customers' email addresses to other customers is unlikely to make a good security impression.Think before you send, and if in doubt, use BCC: .

Follow @duckblog

View the original article here

"Rude password - login denied": the AT&T April Fool that wasn't

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Earlier today, fellow Naked Security writer Graham Cluley pointed me at a fantastic April Fool's story.

AT&T, the tall tale told, had introduced a policy that prohibited passwords that "contain obscene language."

There was even a handy screenshot to add some vernal veracity (or autumnal authenticity in the Southern Hemisphere):

"Very droll," I thought.

After all, it surely wasn't true, since:

How would they tell? (Computers aren't yet that smart at understanding the nuances of human language.)Why would they care? (Passwords aren't for other people to know.)Who would ever see it? (Passwords aren't stored in plaintext. They're salted and hashed.)

In short, unless a human, fluent in dozens of languages, were to review your choice, there wouldn't be much hope of reliably and usefully detecting a password couched in obscene terms.

Anyway, no human except you is ever going to see your password in cleartext, and even you will probably only ever see it as a series of **** characters in a password entry dialog.

But it looks as though this is a true-but-wacky story rather than an April Fool.

Some of AT&T's other limitations make sense, such as preventing your username and password from being the same, and checking against a list of commonly-used bad choices to urge you in the right direction when picking a new password.

For web-based logins, much of that sort of validation can be done in client-side JavaScript, so that poorly-chosen passwords never leave your browser but are rejected (presumably with some helpful explanation) straight off the bat.

But how, and for that matter why, would you go about weeding out every password that might contain obscene language?

Would you back yourself to write computer software that could sensibly detect text that "offends against moral principles" or is "repugnant", in the no-nonsense terminology of the New Oxford American Dictionary?

Or would place names like Scunth0rp3 and M1dd13s3x fall feebly foul of the regulations, as they used to in the early days of naive obscenity filters?

? Those are poor choices for passwords, if only because they're words from a dictionary, or at least from a gazeteer. But they should fail on those grounds, not because they fall foul of some kind of substring or regular expression match against swear-words.

The problem is, of course, that a "no obscene language" rule introduces more concerns that it will ever solve, including the following:

The more extensive the server-side obscenity checking, the more likely it is that the plaintext of your password will needlessly be written to disk or sent off to other run-time verification scripts.The desire to have visually inoffensive passwords raises the concern that the intention is to store them reversibly, accessible to support staff for password recovery purposes, rather than salted and hashed for safety.Many strong and randomly generated passwords will be rejected because they contain some sort of potential "obscenity", thus needlessly reducing the available password entropy and assisting password crackers to skip over known-prohibited combinations.

In fact, a Twitter network engineer claims to have spotted this AT&T limitation when a randomly-generated password was rejected:

In short, it's good to prevent your users from choosing obviously-risky passwords such as letmein and pa$$word.

But rules that illogically reject a potentially large swathe of letter and number combinations serve only to reduce the range of otherwise-excellent passwords available for use, and to simplify the task of password crackers in pre-filtering their own lists of password candidates.

And there's that nagging suspicion that the requirement for "obscenity-free" passwords implies that someone else might see them some day and be outraged, or that they might end up mailed to you in plaintext and blocked by a naive spam filter somewhere on the way.

And that shouldn't be possible, since your password shouldn't be stored reversibly in the first place.

Follow @duckblog

View the original article here

TDoS attacks target US emergency call centers

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Emergency call centers in the US are suffering a rise in TDoS (telephony denial of service) attacks, according to an alert issued recently by the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI).

According to the alert, reposted [PDF] on security journalist Brian Krebs's site, dozens of attacks have targeted PSAP administrative lines (not the 911 emergency line), tying up the system from receiving legitimate calls.

Air ambulance, ambulance and hospital communication lines have been targeted, in addition to various businesses and public entities, the alert goes on, including the financial sector.

The recent attacks are aimed at extortion. Here's how they work, according to DHS and the FBI:

An individual calls, claiming to represent a payday loan collections company.The caller typically has a strong accent and asks to speak with a current or former employee about an outstanding debt.The caller demands payment of $5,000 because an employee (who no longer works for the company or never did) defaulted on a loan. When the target fails to cough up the money, the attacker launches a TDoS.The organization is then inundated with a continuous stream of calls for an unspecified but lengthy period of time.Phone service is disrupted, preventing incoming and/or outgoing calls.

The agencies are speculating that these businesses and emergency services in particular are being targeted because phone lines are crucial to their operations.

The current TDoS attacks are, at this point, skipping over emergency service 911 lines.

Emergency hotlines aren't always spared in TDoS attacks, of course.

UK police last year arrested two teenage boys following a series of prank calls and TDoS attacks launched against the Anti-Terrorist Hotline.

More recently, as CSO's Antone Gonsalves notes, last month, the Louisiana State Analytical and Fusion Exchange, a center for distributing information across law enforcement offices, reported a similar extortion scheme against two public sector entities, including a 911 call center.

The current attacks against US emergency services, which last for intermittent time periods over several hours, are creating a deluge of calls large enough to force roll-over to alternate facilities, the FBI and DHS reported.

The attacks are sporadically re-starting over weeks or months.

While these attacks are clearly profit-motivated, past TDoS attacks have been, apparently, pranks, albeit on the malicious side.

In 2008, it was the Gladys Porter Zoo in Houston, Texas that suffered a barrage of calls after cryptic SMS text message spam was sent to thousands of people, saying things like:

Call now someone is looking for you.Call now and we will settle this.Somebody talking down on you, look for themHey y is someone calln me and lookn for u n askn me where r u at n where u live heres tha # tell then to stop calln me

...and telling them to call the zoo's number. The phone-clogging continued on into May, when the zoo eventually threw in the towel and called in the FBI to help.

Dublin Zoo suffered a similar fate around the same time, with at least 5,000 people receiving SMS text message spam that prodded them to urgently ring the zoo's phone number and ask for a fictitious person (Rory Lion, Anna Conda, C Lion or G Raffe according to news reports such as this one from the Irish Independent).

Whether TDoS attacks are launched as pranks, as vendettas, or as extortion schemes, they serve to cripple their targets.

Zoos don't deserve that any more than ambulance services or the like.

The stakes, however, are potentially higher when you're talking about crippling life-saving businesses. Even if these attacks aren't targeting 911 emergency lines, they still reflect a blatant disregard for humanity.

Please, if you can help the DHS or FBI pull the plug on these malicious schemes, fill them in on the details of any attacks that have targeted your business, and encourage your peers to do the same.

The agencies have offered these recommendations for targeted organizations:

Don't pay the blackmail. Report all attacks to the FBI by logging onto the website http://www.ic3.gov/default.aspx. Use the keyword "TDoS" in your report title. Identify your organizations as a public safety answering point (PSAP) or Public Safety organization. List as many details as possible, including: Calls logs from the “collection” call and TDoS Time, date, originating phone number and traffic characteristicsCall-back number to the “collections” company or requesting organizationMethod of payment and account number where the “collection” company requests the debt to be paidAny information that you can obtain about the caller, or his/her organization Contact your telephone service provider; they may be able to assist by blocking portions of the attack.

Follow @LisaVaas
Follow @NakedSecurity

Red telephone, call center operators and text message images from Shutterstock

View the original article here