Pokémon Go—the best thing since sliced bread (or Tinder)

By now you’ve undoubtedly heard about Pokémon Go, the ridiculously popular new phone app based on the Pokémon franchise. In the relatively new development space of augmented reality it blends fantasy characters with the real world. It uses your phone’s GPS and superimposes Pokémon[1] on a map, like this:

Near CIT

This is a screenshot taken outside my office, standing next to I-94 at Woodward.

It was released last week and is now more popular than Tinder, and is rapidly catching up with active users of Twitter. Since I’ve only just begun playing I can’t report a great deal about what it does (there are various kinds of critters that you can ‘capture’, and there are ‘gyms’ where you can have fights (the platform-like object in the image above is a gym at the church across the street from the main C&IT building at Woodward and 94), and I’m told there’s one near the Science and Engineering Library. In addition there are ‘Pokespots’ all over campus, including one inside UGL.

Here is an excellent, if a little snarky, introduction to the whole thing.

The social fall-out from Pokémon Go has been quite astonishing. There are stories of folks making friends through the app (which is perhaps why it’s surpassed Tinder 🙂 ), and a few cases of accidents of various types. Apparently, in the space of a week some folks have started playing a NSFW[2] version. There was originally a security issue because the first version of the app was able to access all your Gmail contacts if you had an iPhone, but an update has assigned appropriate security levels.

There is going to be a Pokémon Go event here in the Cultural Center on Friday.

So it really seems to be ‘a thing’, and probably worth learning more about. I haven’t yet had a chance to wander around looking for Pokespots yet, but probably will. Don’t forget to be very careful if you are walking around holding your phone. There are two dangers:

  1.  Apple Picking
  2. Immovable objects

In the end, have fun. And let me know what you think. Is this the greatest thing since Twitter? Or a flash in the pan?
_____________________________________________________________________

[1]  Since I’m a linguist you’re gonna get some linguistic commentary here too. Like several other words borrowed from Japanese (emoji, for example), purists insist that the plural is unmarked (that is, that you don’t add an ‘s’). This is analogous to those who insist that ‘data’ is plural and that the correct plurals are ‘stadia’, ‘podia’ and ‘octopi’. Or perhaps it’s analogous to the animals that have what we call ‘zero plurals’, like ‘sheep’ or ‘deer’.

[2] ‘Not safe for work’. You can probably figure out why, given that the game uses your phone’s camera, which can take selfies.

The IRS is coming and they want to help–really!

As I mentioned in an earlier post and also here, a number of Wayne State employees were hit by an IRS hack that stole their identities and attempted to claim refunds. Wayne State C&IT and Internal Audit have investigated these hacks and have found no evidence that the source of the leaks was located at Wayne State, but nonetheless the IRS has volunteered to send an agent to campus to talk about how to avoid this kind of attack in the future.

We have contacted all the victims that we know of, but have also decided to open the IRS agent’s talk to the campus at large. Here are the details:

Tuesday, July 12, 10:00 AM

Partrich Auditorium (located in the Law School).

No need to RSVP—just come.

If you have any questions, you can contact the Office of Internal Audit at (313) 577-2128 or Carolyn Hafner at ab0414@wayne.edu.

The latest on the Apple-FBI Battle

Last week I noted that the FBI claimed that they were only interested in this one iPhone, and the claim that that they had no intention of using this case as a precedent was clearly not true. This was because they were already using the same request to get into a number of other iPhones.

Yesterday a Federal judge in the New York Eastern District ruled against the FBI in a similar case. The judge ruled that the Government’s expansive use of the ‘All Writs’ Act (passed in the eighteenth century) did not include the ability to force Apple to write new software to break the ‘nine strikes and you’re out’ feature of older iPhones — the feature that prevents multiple tries at guessing passwords.

It’s almost certain that this case will eventually end up before the Supreme Court, as it places the reliable security of our mobile devices in conflict with the government’s desire to search them. The FBI claims that they will be really, really careful with these tools, but the mere fact that they exist means that they will leak. Here’s a somewhat radical comment on that likelihood.

Go here for a comprehensive guide to all the issues.

Tim Cook and the FBI will testify before Congress this afternoon.

The terrorist’s iPhone is probably just a ruse.

Now that it’s getting national play, people have noticed that this isn’t the first time the Government has attempted to get Apple to break their own iPhone security. Months before the San Bernadino attacks they tried a couple of times to get Apple to do the same thing. A  judge for the US District Court refused the same order in a case unrelated to national security in October of last year.

So one could conclude that the government’s purpose here is to wrap itself in the flag because it really doesn’t like the idea of security without back doors. If they win this case, of course, the world will continue to write secure software. Since the number of iPhones in the world is nearly 50 million that’s an enormous market for truly secure smartphones, and if the the US government breaks them I’m sure there will be Chinese, Indian or Finnish companies eager to supply truly secure phones we can use for online banking, shopping at Amazon, remote desktop connections and other totally legitimate reasons to have security without back doors floating around waiting to be exploited.

Log in more safely

Starting today you’ll see a new log-in screen when you go to the web-based version of Wayne Connect. This is part of a long-term project to unify the log-in screens of all of Wayne’s major services, Blackboard, Academica, and Wayne Connect. Although there are esthetic (and ‘branding’) advantages, the main reason is to help all WSU users make sure they are on the right page for logging in. This is crucial because of the innumerable phishing attempts we seem to be getting these days, all of which encourage us to log in to fake WSU pages.
You don’t actually need to do anything different. The log in process is identical—put in your AccessID and password as before. But if you’re worried, look to see that the address bar in your browser is green, it says https, and that there’s a padlock symbol visible. These are the signals that you are actually connecting to Wayne State, and not a sketchy phishing site in Lower Slobbovia.
Here’s what to look for:

Chrome Log-in

 

Another advantage to this system is that our security office will be able to recognize hacking attempts more easily and will be able to recognize when people have forgotten their passwords and therefore help them in a secure fashion.

The new log-in screen now shows up when you go to Academica and Wayne Connect, and will be phased in for Blackboard and other systems shortly.

Don’t share passwords, even with yourself…

You have probably noticed Wayne State has been inundated lately with phishing messages. Some of these have been from ‘compromised’ (that is hacked) computers on campus, while others were disguised to elude our spam filters.

In any case, Provost Winters sent out a message explaining how we can all help keep this deluge down to a manageable level. One of her points, however, might seem strange, and I’d like in this post to explain the rationale behind it.

We all know that passwords are a pain in the neck. Remembering a password is not too difficult, but remembering more than one gets to be a strain on our memories. And, since we have passwords for lots of functions it’s very tempting to reuse them. That is, it’s tempting to use the same (memorable, complex) password for a number of different sites.

Unfortunately, that turns out not to be a good idea, because some websites are not very good at properly protecting your password. Normally passwords are stored on the servers that run websites in an encrypted form (that is, they are scrambled by a computer algorithm that is very difficult to unscramble without a key). There are complex technical details in Bruce Schneier’s first book if you are interested in pursuing this.

The important point is that website owners have a choice about how they store the passwords their customers set up, and they don’t always make the most secure choices. This became clear when a very widely used professional social networking site, which many of us use, LinkedIn was hacked and the encrypted password file was stolen, decrypted and posted online on a Russian site.

While we don’t know exactly how many further breaches and identity thefts occurred because of this break-in, it’s clear that many people got access to pairs of email addresses and passwords. If any of those email addresses were also used to log in to credit card sites, or bank sites hackers had access to lots of sources of money.

So, the ideal solution is not to reuse passwords at all. Just use a different password for every site you visit. This, of course, is highly impractical if that’s all you do. But there are two different ways you can manage this task and still keep your passwords safe.

First, use long passwords that include information about which site they are for. One trick I learned from an IT policy buddy of mine is to start with some string of letters and numbers that is very memorable (your nickname, for example, or your first girl/boyfriend’s name or something) and perhaps the current date, but then to append some reference to the website as part of the password. Say, for example, your first girlfriend’s name was Suzy. Then you could have passwords that look like this:

Facebook: $uzyFB2015
Bank: $uzymybankJune15
Amazon: $uzyBooks15
These are very secure passwords because they have at least ten characters, mixed case and numbers and ‘special’ characters.

Of course, it’s still a non-trivial cognitive task to remember all these passwords, which brings us to the second option: a ‘password wallet’. There are a number of these on the market. They require that you set one memorable, but complex password for the manager itself, and then store all your other passwords in the wallet. They all have the same features—a spreadsheet-like interface that includes the name of the website, its URL and your username and password. They always have some button that copies the password to your computer’s memory, so you can just paste it into the relevant box on the website you’re logging in to. The advantage to this system is that you can have very long, totally non-memorable and therefore completely uncrackable passwords. As long as you can open the wallet, you can just copy the password without your even having seen it. This means you can actually have lots of passwords you don’t even know. Talk about a secure password….

Of course, you really need to remember the password to your manager or you are out of luck. Some of them are free, and some have free and relatively low-cost premium editions. Here are several password wallet apps that I and Kevin Hayes, our Chief Security officer, recommend:

Lastpass https://lastpass.com/
Keepass http://keepass.info/ (this one is free)
PC Magazine recently rated a number of premium managers.

Finally, here’s XKCD’s thoughts on the matter:

https://xkcd.com/792/

Anatomy of a Phishing Onslaught

Recently Wayne State University was attacked, a small skirmish in a diffuse, ongoing cyberwar, albeit without a single, defined enemy. This is an account of what happened, why it happened, and how the university responded. I have tried to make the explanation of each event relatively non-technical, but a certain amount of geekery seems unavoidable.

On May 11, at 9:48 in the morning 182 University computers received an email message from a computer belonging to a local contractor who was doing work on the WSU campus. The message had the subject line ‘invoice’, and the text of the message said merely ‘Check invoice’. There was a zip file attached. A zip file is a data file that has been ‘compressed’ so it can travel more easily over the tight ‘passages’ of the email system. It’s a perfectly respectable way of making large files (such as pictures, pdf files and such) fit within email size limits.

However, when the recipients clicked on the file labeled ‘invoice123.zip’ it extracted into a file named ‘e9058.pdf’, which showed up on the screen as a file with an attached (blurry) image of the Adobe Acrobat logo, making it look like a real pdf. When the respondents with Windows computers (but notably not Macs or Linux machines) then ‘opened’ the pdf file, the following things happened:

  1. that person’s computer connected to some external websites
  2. from which it then downloaded additional malware, which proceded to search their computer for personal banking logins
  3. it then connected to remote ‘command and control’ servers. passing control of the computer overseas.
  4. finally it looked in the local Outlook address book and used it to send the infecting email message to addresses it found there.

It took about an hour for the first three computers to get infected, but the attack was discovered by the C&IT Security office after the second computer began spreading the virus. Between the time that the second computer was detected and when it was shut off the network, seven minutes elapsed, and during those seven minutes that computer sent out 4462 virus emails.

By the time the third computer was infected, C&IT’s security office was able to take action to stop the further spread of the virus. A set of filters on the WSU email system blocked transmission of the zip file, but by noon 150 computers had been infected, and 111 of them were sending out email with the attached zip file.

You might wonder why our Symantec antivirus software didn’t detect the infection when the attachment was opened. The answer is that Symantec (and all other antivirus systems) rely on known virus ‘signatures’ (identifying features), and this was what is known as a ‘zero-day’ attack—a brand new virus never before seen ‘in the wild’. It takes the antivirus people a day or so to develop the specific tools needed for each new virus and distribute them to their users.

In addition, because the virus relied on Outlook address books, people got email from people they knew, who did occasionally send them invoices.

The spread of the virus was effectively stopped by 11:50. Our security team isolated it and determined that it was connecting our computers to Serbia and Ukraine. The Security team then set the university firewall to block connections there, and identified all of the infected computers.

In order to clean up the infection those machines maintained by C&IT (i.e. managed by the DeskTech unit) were reformatted, and outside of the DeskTech domain local administrators were given guidance on how to clean the machines under their control.

In addition, within the DeskTech domain a program called AppLocker was turned on. This prevents computers from running software that did not have an appropriate signature, or which were installed in nonstandard places in a computer (i.e. not in Program Files). Unfortunately this broke a number of specialized programs that various people around campus relied upon, and special rules had to be written to fix this.

By the evening only a few infected computers were not yet fixed,and the original attacker used that to their advantage. Overnight new instructions were passed down to these few straggling machines, and the next day a new attack was launched, sending attachments with different names, but the same modus operandi. These were blocked within 20 minutes of the first occurrence, but to ensure no further attacks, there was a temporary block placed on all zip files sent through the email system. Since there are many legitimate uses of zip files, this block will be ended shortly.

Meanwhile, everyone who was affected was required to change their WSU passwords. Careful examination of system logs showed that four of those AccessID’s were tried from Russia (while their owners were at work on campus) but none of the logins succeeded, so apparently no passwords were compromised.

What can we learn from this adventure?

The faster the IT security guys can act the less harmful the infection. Forwarding suspicious emails to the Security Office (or dragging them to the Phishing applet in Wayne Connect) is valuable. A delay of even an additional hour could have been catastrophic for the campus.

Smooth coordination between the security office and desktop support enabled the spread of the infection to be halted quickly.

We continually remind folks not to click on attachments they don’t expect from people they don’t know. Now we need to modify this—don’t click on any attachment, regardless of sender, unless you are sure it is safe. The text of the email message should reference the content of the attachment and you should be expecting that content. If it doesn’t either phone the sender or just delete it.

Finally, if you’d like to learn more about how to resist phishing attempts, you can take the anti-phishing training we make available through Accelerate, HR’s online training system. To get there, log in to Academica, then search for ‘Accelerate’ in the search box (unless you’ve already been there, in which case it should show up in your personalized links). Start Accelerate, then Browse the Catalog, C&IT Security Awareness Program, and finally PhishProof (Part 3), Launch.

Don’t open mystery attachments, and don’t send them either

Most people know that a sophisticated phishing attack has hit the campus over the past few days. It came from within the campus, and consisted of a message saying ‘Check invoice’ and had an attachment that was a .zip file. If you clicked on the link (say because it came from someone you knew, and did occasionally receive invoices) your computer was infected and it immediately began spreading the infection further.

So, for right now C&IT is blocking all .zip file attachments. And it just reinforces the message that we have been sending: ‘Don’t click on attachments you aren’t expecting’.

But there’s another lesson also. If you do need to send an attachment (and it’s not inherently a bad thing to do) say something in the email message itself about what the attachment is and why you are sending it. So instead of ‘Check invoice’ say something like ‘Here’s the invoice from the Blixeldorf Corporation that we were waiting for’. That kind of text in an email message is impossible to fake (and, of course, if the recipient wasn’t waiting for that invoice they’ll know it’s fake).

So don’t open mystery attachments, and make sure any that you send aren’t mysteries to the people you send them to.

If you do need to send a .zip file in the coming days, you can do so via Wayne Connect Briefcase.

Recent dealings with Stingray

So a guy selling pot is robbed by two other guys. And the police use a Stingray to track the robbers down. Then it went to court. The seller was charged with drug distribution, the other guys with felonies.

A couple of weeks ago a judge asked the police to let him see the famous Stingray device I blogged about last. Turns out the police and prosecutors were so loathe to permit the machine to see the light of day that they offered all the putative criminals plea-bargains and they all ended up with probation.

Whole story here.

It will be interesting to see how many of these cases show up in the next year, as Stingray gets better known, and the ‘non-disclosure’ agreements that police departments sign with the FBI when they get the devices get challenged by judges not impressed with secret superpowerful technologies used to conduct simple criminal investigations.