Skip to main content

How did they do that?

Warning is post is part fiction and part stream of consciousness and my intent is to take you to a happy place or give you a lot more to think about.

WildCard the early days:
- one of the interesting things that happened to us was the day the very first BIN went live (processing through FDR in Omaha). Even before the first card was manufactured we started receiving transactions from Nigeria. They were clearly bogus but we were not expecting anything at all.

- years later I caught our first ATM bandits in Moscow. (a) they ran too many PIN transaction in such a short period of time that they could only have accomplished this with a hijacked ATM (b) somehow they knew we did some sort of load balancing so they were trying to skim a little off the top.

- we did have a programmer of Russian origin that worked for WildCard; he was later laid off when WildCard downsized after it's own first bubble burst. In retrospect he was always working odd hours; his explanation was so that he could VOIP home to Russia.

- WildCard, later eFunds and now FIS; outsources a lot of it's software development. With any luck they review each and every line of code but not likely. The thing is; a C-level executive was so focused on outsourcing that there was a swell of offshore, on site, developers. Dev went from 100 to 500 in a matter of months. It is my understanding that they were all foreign contractors.(Courtesy of Bill Gates)

The FIS attack:
- I'm surprised that they got in. I know the guy who designed the network and I know he was also one of the most highly certified Cisco tech there was. Even at WildCard there were layers upon layers of network infrastructure. Production was locked off from everything else. Machines inside the firewall were not supposed to be able to make connections to systems outside the firewall. And so on. It was tighter than Fort Knox.

- the authorization system is even more self contained. In fact the auth system is almost a network unto itself. Therefore, the only thing they could have done was attack the backoffice system. That system was originally build with VB and then moved to coldfusion and then there was a sharepoint implementation and later MS business object or something like that. The thing is; WildCard was very aware of things like SQL injection and API permissions and such. So unless intentional or unintentional bug in the system... this was not an attach vector either.

- one thing for certain. The users were not going to gain access from the network. Even if the card programs were accessible to product managers through the public internet.

- the API layer was going to require passwords and some encryption if they planned to gain access through the APIs. And even then they'd need the API docs and credentials.

- If they managed to log into production they'd have to make it through many layers of security in order to make it to the DB. And even with a TSQL command shell you'd need credentials. 

But wait there's more.

- once they logged into the DB you'd have to know which table to change... of some 300 to 500 tables.

- but once they had the right table they'd need to know which card program was assigned to so they could update the velocity check.

In Conclusion:
(a) this was very likely an inside job and might have been a sleeper for years)
(b) when you're a small company you better trust your employees beyond the usual resume screening.
(c) you might be better off hiring a real security firm for recommendations.

I just watched a video segment about espionage and counter espionage. It's interesting that spies do not always do the dirty work. They hire "cut outs" to do it for them. Sadly this could be anyone and of course the consequences are not less devastating.

I read another article "what would happen if everything you knew was false" or something like that. Basically a West German police man killed a protestor in 1957. At the time he said he was threatened or some such. After a brief suspension he returned to work and was later promoted. Fast forward to present day and it turns out this guy was a spy for the Stassi (East German Secret Service).

** So how do we remain secure?  Good question.

- know your hardware
- know your network
- know your infrastructure
- know your physical security
- know your operating system
- know your tools
- know your employees
- know your programmers, testers, etc
- know your process
- know all your 3rd parties

It comes down to full stack awareness... the stack happens to be much bigger than once thought.


Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…