The St. Louis Federal Reserve today sent a message to those it serves alerting them that in late April 2015 attackers succeeded in hijacking the domain name servers for the institution. The attack redirected Web searches and queries for those seeking a variety of domains run by the government entity to a Web page set up by the attackers in an apparent bid by cybercrooks to hijack online communications of banks and other entities dealing with the regional Fed office.

The communique, shared by an anonymous source, was verified as legitimate by a source at another regional Federal Reserve location.

The notice from the St. Louis Fed stated that the “the Federal Reserve Bank of St. Louis has been made aware that on April 24, 2015, computer hackers manipulated routing settings at a domain name service (DNS) vendor used by the St. Louis Fed so that they could automatically redirect some of the Bank’s web traffic that day to rogue webpages they created to simulate the look of the St. Louis Fed’s research.stlouisfed.org website, including webpages for FRED, FRASER, GeoFRED and ALFRED.”

Requests for comment from the St. Louis Fed so far have gone unreturned. It remains unclear what impact, if any, this event has had on the normal day-to-day operations of hundreds of financial institutions that interact with the regional Fed operator.

The advisory noted that “as is common with these kinds of DNS attacks, users who were redirected to one of these phony websites may have been unknowingly exposed to vulnerabilities that the hackers may have put there, such as phishing, malware and access to user names and passwords.”

The statement continues:

“These risks apply to individuals who attempted to access the St. Louis Fed’s research.stlouisfed.org website on April 24, 2015. If you attempted to log into your user account on that date, it is possible that this malicious group may have accessed your user name and password.

The St. Louis Fed’s website itself was not compromised.

“Out of an abundance of caution, we wanted to alert you to this issue, and also make you aware that the next time you log into your user account, you will be asked to change your password. In addition, in the event that your user name and password are the same or similar as those you use for other websites, we highly recommend that you follow best practices and use a strong, unique and different password for each of your user accounts on the Internet. Click https://research.stlouisfed.org/useraccount/forgotpassword/step1 to change your user account password now.”

According to Wikipedia, the Federal Reserve Economic Data (FRED) is a database maintained by the Research division of the Federal Reserve Bank of St. Louis that has more than 247,000 economic time series from 79 sources. The data can be viewed in graphical and text form or downloaded for import to a database or spreadsheet, and viewed on mobile devices. They cover banking, business/fiscal, consumer price indexes, employment and population, exchange rates, gross domestic product, interest rates, monetary aggregates, producer price indexes, reserves and monetary base, U.S. trade and international transactions, and U.S. financial data.

FRASER stands for the Federal Reserve Archival System for Economic Research, and reportedly contains links to scanned images (PDF format) of historic economic statistical publications, releases, and documents including the annual Economic Report of the President. Coverage starts with the 19th and early 20th century for some economic and banking reports.

According to the Federal Reserve, GeoFred allows authorized users to create, customize, and share geographical maps of data found in FRED.

ALFRED, short for ArchivaL Federal Reserve Economic Data, allows users to retrieve vintage versions of economic data that were available on specific dates in history.

The St. Louis Federal Reserve is one of twelve regional Fed organizations, and serves banks located in the all of Arkansas and portions of six other states: Illinois, Indiana, Kentucky, Mississippi, Missouri and Tennessee. According to the reserve’s Web site, it also serves most of eastern Missouri and southern Illinois.

No information is available at this time about the attackers involved in this intrusion, but given the time lag between this event and today’s disclosure it seems likely that it is related to state-sponsored hacking activity from a foreign adversary. If the DNS compromise also waylaid emails to and from the institution, this could be a much bigger deal. This is likely to be a fast-moving story. More updates as they become available.

When it comes to reporting on breaches involving customer accounts at major brands, the news media overall deserves an F-minus. Hardly a week goes by when I don’t hear from readers about a breathless story proclaiming that yet another household brand name company has been hacked. Upon closer inspection, the stories usually are based on little more than anecdotal evidence from customers who had their online loyalty or points accounts hijacked and then drained of value.

The latest example of this came last week from a story that was responsibly reported by Bob Sullivan, a former MSNBC journalist who’s since struck out on his own. Sullivan spoke with multiple consumers who’d seen their Starbucks card balances emptied and then topped up again.

Those customers had all chosen to tie their debit accounts to their Starbucks cards and mobile phones. Sullivan allowed in his story one logical explanation for the activity: These consumers had re-used their Starbucks account password at another site that got hacked, and attackers simply tried those account credentials en masse at other popular sites — knowing that a fair number of consumers use the same email address and password across multiple sites.

Following up on Sullivan’s story, the media pounced, suggesting that Starbucks had been compromised. In a written statement, Starbucks denied the unauthorized activity was the result of a hack or intrusion into its servers or mobile applications.

“Occasionally, Starbucks receives reports from customers of unauthorized activity on their online account,” the company wrote. “This is primarily caused when criminals obtain reused names and passwords from other sites and attempt to apply that information to Starbucks. To protect their security, customers are encouraged to use different user names and passwords for different sites, especially those that keep financial information.”

In most cases, a flurry of fraudulent account activity targeting a major brand is preceded by postings on noob-friendly hacker forums about large numbers of compromised accounts for sale, and the publication of teachable “methods” for extracting value from said hacked accounts.

Unsurprisingly, we saw large numbers of compromised Starbucks accounts for sale in the days leading up to the initial story about the Starbucks fraud, as well as the usual “methods” explaining to clueless ne’er-do-wells about how to perpetrate fraud against hacked accounts. Here’s another noob-friendly thread explaining how to cash out compromised Subway accounts; how long until we read media reports shouting that Subway has been hacked?

To be sure, password re-use is a major problem, and it’s a core driver of fraud like this. Also, companies like Starbucks, Hilton Honors, Starwood and others certainly could be doing more — such as offering customers two-step authentication — to protect accounts. Indeed, as these recurring episodes show, affected brands take an image hit when customers have their accounts hijacked through password re-use, because the story inevitably devolves into allegations of a data breach at the brand involved.

But it works both ways: consumers who re-use passwords for sites holding their payment data are asking for trouble, and will get it eventually.

For helpful hints on picking strong passwords (or outsourcing that to third-party software and/or services), check out this primer. For further reading about how penny-ante punks exploit password re-use and trick media outlets into falsely reporting breaches, see How to Tell Data Leaks from Publicity Stunts.

mSpy, the makers of a dubious software-as-a-service product that claims to help more than two million people spy on the mobile devices of their kids and partners, appears to have been massively hacked. Last week, a huge trove of data apparently stolen from the company’s servers was posted on the Deep Web, exposing countless emails, text messages, payment and location data on an undetermined number of mSpy “users.”

mSpy has not responded to multiple requests for comment left for the company over the past five days. KrebsOnSecurity learned of the apparent breach from an anonymous source who shared a link to a Web page that is only reachable via Tor, a technology that helps users hide their true Internet address and allows users to host Web sites that are extremely difficult to get taken down.

The Tor-based site hosts several hundred gigabytes worth of data taken from mobile devices running mSpy’s products, including some four million events logged by the software. The message left by the unknown hackers who’ve claimed responsibility for this intrusion suggests that the data dump includes information on more than 400,000 users, including Apple IDs and passwords, tracking data, and payment details on some 145,000 successful transactions.

The exact number of mSpy users compromised could not be confirmed, but one thing is clear: There is a crazy amount of personal and sensitive data in this cache, including photos, calendar data, corporate email threads, and very private conversations. Also included in the data dump are thousands of support request emails from people around the world who paid between $8.33 to as much as $799 for a variety of subscriptions to mSpy’s surveillance software.

It’s unclear exactly where mSpy is based; the company’s Web site suggests it has offices in the United States, Germany and the United Kingdom, although the firm does not appear to list an official physical address. However, according to historic Web site registration records, the company is tied to a now-defunct firm called MTechnology LTD out of the United Kingdom.

Documents obtained from Companies House, an official register of corporations in the U.K., indicate that the two founding members of the company are self-described programmers Aleksey Fedorchuk and Pavel Daletski. Those records (PDF) indicate that Daletski is a British citizen, and that Mr. Fedorchuk is from Russia. Neither of the men could be reached for comment.

Court documents (PDF) obtained from the U.S. District Court in Jacksonville, Fla. regarding a trademark dispute involving mSpy and Daletski state that mSpy has a U.S.-based address of 800 West El Camino Real, in Mountain View, Calif. Those same court documents indicate that Daletski is a director at a firm based in the Seychelles called Bitex Group LTD. Interestingly, that lawsuit was brought by Retina-X Studios, an mSpy competitor based in Jacksonville, Fla. that makes a product called MobileSpy.

U.S. regulators and law enforcers have taken a dim view of companies that offer mobile spyware services like mSpy. In September 2014, U.S. authorities arrested a 31-year-old Hammad Akbar, the CEO of a Lahore-based company that makes a spyware app called StealthGenie. The FBI noted that while the company advertised StealthGenie’s use for “monitoring employees and loved ones such as children,” the primary target audience was people who thought their partners were cheating. Akbar was charged with selling and advertising wiretapping equipment.

“Advertising and selling spyware technology is a criminal offense, and such conduct will be aggressively pursued by this office and our law enforcement partners,” U.S. Attorney Dana Boente said in a press release tied to Akbar’s indictment.

Akbar pleaded guilty to the charges in November 2014, and according to the Justice Department he is “the first-ever person to admit criminal activity in advertising and selling spyware that invades an unwitting victim’s confidential communications.”

Unlike Akbar’s StealthGenie and some other mobile spyware products, mSpy advertises that its product works even on non-jailbroken iPhones, giving users the ability to log the device holder’s contacts, call logs, text messages, browser history, events and notes.

“If you have opted to purchase mSpy Without Jailbreak, and you have the mobile user’s iCloud credentials, you will not need physical access to the device,” the company’s FAQ states. “However, there may be some instances where physical access may be necessary. If you purchase mSpy for a jailbroken iOS phone or tablet, you will need 5-15 minutes of physical access to the device for successful installation.”

A public relations pitch from mSpy to KrebsOnSecurity in March 2015 stated that approximately 40 percent of the company’s users are parents interested in keeping tabs on their kids. Assuming that is a true statement, it’s ironic that so many parents have now unwittingly exposed their kids to predators, bullies and other ne’er-do-wells thanks to this breach.

Microsoft today issued 13 patch bundles to fix roughly four dozen security vulnerabilities in Windows and associated software. Separately, Adobe pushed updates to fix a slew of critical flaws in its Flash Player and Adobe Air software, as well as patches to fix holes in Adobe Reader and Acrobat.

Three of the Microsoft patches earned the company’s most dire “critical” rating, meaning they fix flaws that can be exploited to break into vulnerable systems with little or no interaction on the part of the user. The critical patches plug at least 30 separate flaws. The majority of those are included in a cumulative update for Internet Explorer. Other critical fixes address problems with the Windows OS, .NET, Microsoft Office, and Silverlight, among other components.

According to security vendor Shavlik, the issues address in MS15-044 deserve special priority in patching, in part because it impacts so many different Microsoft programs but also because the vulnerabilities fixed in the patch can be exploited merely by viewing specially crafted content in a Web page or a document. More information on and links to today’s individual updates can be found here.

Adobe’s fix for Flash Player and AIR fix at least 18 security holes in the programs. Updates are available for Windows, OS X and Linux versions of the software. Mac and Windows users, the latest, patched version is v. 17.0.0.188. 

If you’re unsure whether your browser has Flash installed or what version it may be running, browse to this link. Adobe Flash Player installed with Google Chrome, as well as Internet Explorer on Windows 8.x, should automatically update to the latest version. To force the installation of an available update, click the triple bar icon to the right of the address bar, select “About Google” Chrome, click the apply update button and restart the browser.

The most recent versions of Flash should be available from the Flash home page, but beware potentially unwanted add-ons, like McAfee Security Scan. To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

If you run Adobe Reader, Acrobat or AIR, you’ll need to update those programs as well. Adobe said it is not aware of any active exploits or attacks against any of the vulnerabilities it patched with today’s releases.

Not long ago I heard from a reader who wanted advice on how to stop someone from scanning his home network, or at least recommendations about to whom he should report the person doing the scanning. I couldn’t believe that people actually still cared about scanning, and I told him as much: These days there are countless entities — some benign and research-oriented, and some less benign — that are continuously mapping and cataloging virtually every device that’s put online.

One of the more benign is scans.io, a data repository of research findings collected through continuous scans of the public Internet. The project, hosted by the ZMap Team at the University of Michigan, includes huge, regularly updated results grouped around scanning for Internet hosts running some of the most commonly used “ports” or network entryways, such as Port 443 (think Web sites protected by the lock icon denoting SSL/TLS Web site encryption); Port 21, or file transfer protocol (FTP); and Port 25, or simple mail transfer protocol (SMTP), used by many businesses to send email.

When I was first getting my feet wet on the security beat roughly 15 years ago, the practice of scanning networks you didn’t own looking for the virtual equivalent of open doors and windows was still fairly frowned upon — if not grounds to get one into legal trouble. These days, complaining about being scanned is about as useful as griping that the top of your home is viewable via Google Earth. Trying to put devices on the Internet and then hoping that someone or something won’t find them is one of the most futile exercises in security-by-obscurity.

To get a gut check on this, I spoke at length last week with University of Michigan researcher Zakir Durumeric (ZD) and Michael D. Bailey at the University of Illinois at Urbana-Champaign (MB) about their ongoing and very public project to scan all the Internet-facing things. I was curious to get their perspective on how public perception of widespread Internet scanning has changed over the years, and how targeted scanning can actually lead to beneficial results for Internet users as a whole.

MB: Because of the historic bias against scanning and this debate between disclosure and security-by-obscurity, we’ve approached this very carefully. We certainly think that the benefits of publishing this information are huge, and that we’re just scratching the surface of what we can learn from it.

ZD: Yes, there are close to two dozen papers published now based on broad, Internet-wide scanning. People who are more focused on comprehensive scans tend to be the more serious publications that are trying to do statistical or large-scale analyses that are complete, versus just finding devices on the Internet. It’s really been in the last year that we’ve started ramping up and adding scans [to the scans.io site] more frequently.

BK: What are your short- and long-term goals with this project?

ZD: I think long-term we do want to add coverage of additional protocols. A lot of what we’re focused on is different aspects of a protocol. For example, if you’re looking at hosts running the “https://” protocol, there are many different ways you can ask questions depending on what perspective you come from. You see different attributes and behavior. So a lot of what we’ve done has revolved around https, which is of course hot right now within the research community.

MB: I’m excited to add other protocols. There are a handful of protocols that are critical to operations of the Internet, and I’m very interested in understanding the deployment of DNS, BGP, and TLS’s interception with SMTP. Right now, there’s a pretty long tail to all of these protocols, and so that’s where it starts to get interesting. We’d like to start looking at things like programmable logic controllers (PLCs) and things that are responding from industrial control systems.

ZD: One of the things we’re trying to pay more attention to is the world of embedded devices, or this ‘Internet of Things’ phenomenon. As Michael said, there are also industrial protocols, and there are different protocols that these embedded devices are supporting, and I think we’ll continue to add protocols around that class of devices as well because from a security perspective it’s incredibly interesting which devices are popping up on the Internet.

BK: What are some of the things you’ve found in your aggregate scanning results that surprised you?

ZD: I think one thing in the “https://” world that really popped out was we have this very large certificate authority ecosystem, and a lot of the attention is focused on a small number of authorities, but actually there is this very long tail — there are hundreds of certificate authorities that we don’t really think about on a daily basis, but that still have permission to sign for any Web site. That’s something we didn’t necessary expect. We knew there were a lot, but we didn’t really know what would come up until we looked at those.

There also was work we did a couple of years ago on cryptographic keys and how those are shared between devices. In one example, primes were being shared between RSA keys, and because of this we were able to factor a large number of keys, but we really wouldn’t have seen that unless we started to dig into that aspect [their research paper on this is available here].

MB: One of things we’ve been surprised about is when we measure these things at scale in a way that hasn’t been done before, often times these kinds of emergent behaviors become clear.

BK: Talk about what you hope to do with all this data.

ZD: We were involved a lot in the analysis of the Heartbleed vulnerability. And one of the surprising developments there wasn’t that there were lots of people vulnerable, but it was interesting to see who patched, how and how quickly. What we were able to find was by taking the data from these scans and actually doing vulnerability notifications to everybody, we were able to increase patching for the Heartbleed bug by 50 percent. So there was an interesting kind of surprise there, not what you learn from looking at the data, but in terms of what actions do you take from that analysis? And that’s something we’re incredibly interested in: Which is how can we spur progress within the community to improve security, whether that be through vulnerability notification, or helping with configurations.

BK: How do you know your notifications helped speed up patching?

MB: With the Heartbleed vulnerability, we took the known vulnerable population from scans, and ran an A/B test. We split the population that was vulnerable in half and notified one half of the population, while not notifying the other half, and then measured the difference in patching rates between the two populations. We did end up after a week notifying the second population…the other half.

BK: How many people did you notify after going through the data from the Heartbleed vulnerability scanning? 

ZD: We took everyone on the IPv4 address space, found those that were vulnerable, and then contacted the registered abuse contact for each block of IP space. We used data from 200,000 hosts, which corresponded to 4,600 abuse contacts, and then we split those into an A/B test. [Their research on this testing was published here].

So, that’s the other thing that’s really exciting about this data. Notification is one thing, but the other is we’ve been building models that are predictive of organizational behavior. So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing. So, that’s the other thing we’ve been starting to see, which is the potential for being more proactive about security.

BK: How exactly do you go about the notification process? That’s a hard thing to do effectively and smoothly even if you already have a good relationship with the organization you’re notifying….

MB: I think one of the reasons why the Heartbleed notification experiment was so successful is we did notifications on the heels of a broad vulnerability disclosure. The press and the general atmosphere and culture provided the impetus for people to be excited about patching. The overwhelming response we received from notifications associated with that were very positive. A lot of people we reached out to say, ‘Hey, this is a great, please scan me again, and let me know if I’m patched.” Pretty much everyone was excited to have the help.

Another interesting challenge was that we did some filtering as well in cases where the IP address had no known patches. So, for example, where we got information from a national CERT [Computer Emergency Response Team] that this was an embedded device for which there was no patch available, we withheld that notification because we felt it would do more harm than good since there was no path forward for them. We did some aggregation as well, because it was clear there were a lot of DSL and dial-up pools affected, and we did some notifications to ISPs directly.

BK: You must get some pushback from people about being included in these scans. Do you think that idea that scanning is inherently bad or should somehow prompt some kind of reaction in and of itself, do you think that ship has sailed?

ZD: There is some small subset that does have issues. What we try to do with this is be as transparent as possible. All of our hosts we use for scanning, if look at them on WHOIS records or just visit them with a browser it will tell you right away that this machine is part of this research study, here’s the information we’re collecting and here’s how you can be excluded. A very small percentage of people who visit that page will read it and then contact us and ask to be excluded. If you send us an email [and request removal], we’ll remove you from all future scans. A lot of this comes down to education, a lot of people to whom we explain our process and motives are okay with it.

BK: Are those that object and ask to be removed more likely to be companies and governments, or individuals?

ZD: It’s a mix of all of them. I do remember offhand there were a fair number of academic institutions and government organizations, but there were a surprising number of home users. Actually, when we broke down the numbers last year (PDF), the largest category was small to mid-sized businesses. This time last year, we had excluded only 157 organizations that had asked for it.

BK: Was there any pattern to those that asked to be excluded?

ZD: I think that actually is somewhat interesting: The exclusion requests aren’t generally coming from large corporations, which likely notice our scanning but don’t have an issue with it. A lot of emails we get are from these small businesses and organizations that really don’t know how to interpret their logs, and often times just choose the most conservative route.

So we’ve been scanning for a several years now, and I think when we originally started scanning, we expected to have all the people who were watching for this to contact us all at once, and say ”Please exclude us.’ And then we sort of expected that the number of people who’d ask to be excluded would plateau, and we wouldn’t have problems again. But what we’ve seen is, almost the exact opposite. We still get [exclusion request] emails each day, but what we’re really finding is people aren’t discovering these scans proactively. Instead, they’re going through their logs while trying to troubleshoot some other issue, and they see a scan coming from us there and they don’t know who we are or why we’re contacting their servers. And so it’s not these organizations that are watching, it’s the ones who really aren’t watching who are contacting us.

BK: Do you guys go back and delete historic records associated with network owners that have asked to be excluded from scans going forward?

ZD: At this point we haven’t gone back and removed data. One reason is there are published research results that are based on those data sets, results, and so it’s very hard to change that information after the fact because if another researcher went back and tried to confirm an experiment or perform something similar, there would be no easy way of doing that.

BK: Is this what you’re thinking about for the future of your project? How to do more notification and build on the data you have for those purposes? Or are you going in a different or additional direction?

MB: When I think about the ethics of this kind of activity, I have very utilitarian view: I’m interested in doing as much good as we possibly can with the data we have. I think that lies in notifications, being proactive, helping organizations that run networks to better understand what their external posture looks like, and in building better safe defaults. But I’m most interested in a handful of core protocols that are under-serviced and not well understood. And so I think we should spend a majority of effort focusing on a small handful of those, including BGP, TLS, and DNS.

ZD: In many ways, we’re just kind of at the tip of this iceberg. We’re just starting to see what types of security questions we can answer from these large-scale analyses. I think in terms of notifications, it’s very exciting that there are things beyond the analysis that we can use to actually trigger actions, but that’s something that clearly needs a lot more analysis. The challenge is learning how to do this correctly. Every time we look at another protocol, we start seeing these weird trends and behavior we never noticed before. With every protocol we look at there are these endless questions that seem to need to be answered. And at this point there are far more questions than we have hours in the day to answer.