The Github Malware Attack – and the Importance of Trusting the Repository You Use

There’s a terrible attack happening against Github right now where attackers are forking legitimate repositories and injecting malware – and then hoping unsuspecting users will download code from the attacker’s repo instead of the original. A researcher estimates this is happening to about 100,000 repos on Github.

As Dan Goodin writes at Ars Technica:

The malicious repositories are clones of legitimate ones, making them hard to distinguish to the casual eye. An unknown party has automated a process that forks legitimate repositories, meaning the source code is copied so developers can use it in an independent project that builds on the original one. The result is millions of forks with names identical to the original one that add a payload that’s wrapped under seven layers of obfuscation. To make matters worse, some people, unaware of the malice of these imitators, are forking the forks, which adds to the flood.

His article continues in great detail about how the attack works and the dangers involved. He also notes how Github is fighting back against this and removing malware repos … but the scale of the attack makes this hard.

A key point to me is that you should only download and execute code from repositories you trust.

This is kind of a 🤦‍♂️ statement, but it’s so easy to just search for code, find a repo, and use the code.

We all need to take the extra moment and figure out: is this repo a fork of another repo? And if so… why? There are perfectly legitimate reasons to fork a repo. Perhaps someone wants to improve the code or offer a new feature in a way the original developer didn’t want to.

But, as this attack shows, there are also malicious reasons for forking a repo.

We need to be sure we trust the source – which may mean doing the detective work to trace back and see if this is the original repo.

I wish the folks at Github all the best in combatting this attack. The ability to easily fork repos is such a key part of Github and the collaborative development of code. It’s unfortunate that it is being abused in this way. 🙁

"The Origins of Python" by "Lambert Meertens" on a light blue background with the python logo on the right side

Fascinating Article About the Early History of Python

Back in the early 1990s, I was active in some different developer user groups where perl was the scripting language of choice. I remember with great fondness some of the “obfuscated perl” challenges where the goal was to write something as obscure and small as possible… that actually performed some action. The perl slogan was “there is more than one way to do it”, and that was how it rolled.

Then one day I stumbled upon python, which seemed to be almost the polar opposite of perl. I mean… indentation mattered? I hadn’t dealt with that since back when I was programming in FORTRAN in the late 1980s!

And the idea that code should be readable and easy-to-understand? That kind of flew in the face of the obfuscation challenges.. but definitely led to better and more understandable code!

In contrast to perl, the Zen of Python captured one ethic: “There should be one– and preferably only one –obvious way to do it.”

I loved it!

And for a good number of years python was my language of choice. I used it to solve so many problems and do so many things. Most all of that was internal to various jobs and projects. The only public thing really left is my ancient makefaq program, which generated a Frequently-Asked Question (FAQ) list into HTML, text, or DocBook XML from a single source file. (And I have no idea if makefaq works with modern python.)

This background is why I found “The Origins of Python” from Professor Lambert Meertens such a fascinating read.

Anyone involved with python for any time becomes aware of Guido van Rossum and his role in creating python and all of his amazing contributions. But this article goes back a bit further to provide the context for how python came about.

Given that I started using BASIC on an Apple II in 1977, I never did much with ALGOL and had never heard of either TELCOMP or the ABC language mentioned in the article. Nor had I heard of SETL. When I got involved with computer science at the University of New Hampshire in the mid-1980s, Pascal was the main introductory language, and C was a language heavily used for other work. I also used assembly language, FORTRAN, SmallTalk, and a number of others. In a bit of craziness, I did some large scale text manipulation using the version of LISP built into emacs. 😀 (Although I was later to come down hard on the “vim” side of that particular divide.)

So the history provided by Professor Meertens was interesting to see how various strands came together in a way that helped set the stage for what Guido van Rossum would do to make python the amazing language that it is.

Well worth a read for those wanting to understand the historic origins of languages.

Etherpad launch screen

How to Install Etherpad Locally Using Docker

Recently I was discussing with a couple of people how Etherpad works so well for collaborative editing. I realized it had been a while since I’d used Etherpad and, with a plane flight ahead of me, I wondered how quickly I could install it to play with it. It turned out to be extremely easy due to Docker! All I had to do was:

docker pull etherpad/etherpad

docker run -d --name etherpad -p 9001:9001 etherpad/etherpad

And then I just pointed my browser to:

http://localhost:9001

… and… ta da! There I was looking at Etherpad and could start writing my own “pads”!

That was it!

There are of course MANY more things you could do with the docker image. The Docker Hub page for Etherpad goes through all the many options you can use for building and deploying your own image.

But for me, simply pulling and running the image was enough – this is the power of Docker for testing and prototyping. Simple and easy!

Photo of shipping containers

Video I Found Useful: “Getting Started with Docker”

As I’ve been exploring more about Docker and containers over the past month or two, I’ve been watching MANY videos on YouTube. One of the “intro to Docker” ones that I quite liked was this one from Brad Traversy:

What I found useful was how he used the very practical example of setting up a small website using nginx. Very good use case, including the use of volumes to have content that can be re-used between containers. He also discusses how to use DockerHub to make your container image available to other systems.

His subsequent video about using Docker Compose was also useful.


Image by frank mckenna (@frankiefoto) on Unsplash

local installation of WordPress

New Github repo for using WordPress with Docker

As I wrote over on my Disruptive Conversations site, I’ve been playing around with using Docker as a way to easily test new WordPress versions and plugins.  As part of that testing, I was trying to use the official WordPress image found on Dockerhub.

However, I was struggling with getting started, because the WordPress container is just… WordPress. It also needs a database to work, and my Docker experience was not yet strong enough to sort out how to link various containers together. So I raised an issue on Github asking about a step-by-step tutorial.

Github user wglambert very kindly provided a simple docker-compose.yaml file that could launch both WordPress and MySQL in separate containers and set up the necessary network and links.

It works wonderfully! And it has now been added to the instructions on DockerHub. (Thank you to the DockerHub admins for merging it in.)

Because I want to easily use the file on different systems, I put it up in a Github repo:

https://github.com/danyork/wordpress-basic-docker

Any of you are welcome to use it, too!

As I noted in my Disruptive Conversations article, I’m planning to start writing here a good bit more about using Docker. I’m rather impressed by all that can be done – and want to capture my own experiments here for my own future knowledge… and if it helps any of you all out, too, all the better!

Do you use Docker Swarm? If so, how?

Docker swarm page

UPDATE – 20 Nov 2018 – I wrote this back in 2016 as I was just experimenting with Docker. Since that time, not only did Swarm emerge as Docker’s tool for container management/orchestration/clustering, but we also saw the emergence and then domination of Kubernetes as a tool for container orchestration.  I’m leaving this post online, but at this point the examples are quite prominent for how Swarm and other tools can be used.

—-

Do you use Docker Swarm? If so, how?  I have been incredibly intrigued ever since reading about the release of Docker 1.12 earlier this week.

As Benjamin Wooten writes, now with only two commands:

  • We get a deployment platform which gives us resilience, robustness, failover and fault tolerance for our containers.
  • We get load balancing and a routing mesh which makes service discovery simple.
  • We can use our server resources more efficiently with various allocation strategies.
  • We can scale containers up and down with one command.
  • Communications within the cluster are secured with dynamically rotating certificates.

Ever since, I have been reading more, such as this piece about setting up a swarm with Raspberry Pi systems.

Now I am curious… how are any of you reading this using Docker Swarm? What are doing with it?  I am intrigued and curious to do more…

Traceroute to bad.horse provides amusing results

For network geeks, this is rather amusing… someone was obviously a bit bored some day and had a bit of fun! This was what it looked like on my Mac right now. (Hat tip to Michele Neylon for first pointing this out to me in some social media channel.)

$ traceroute bad.horse
traceroute to bad.horse (162.252.205.157), 64 hops max, 52 byte packets
1  172.20.12.100 (172.20.12.100)  0.663 ms  0.537 ms  0.277 ms
2  cpe-74-69-224-1.ne.res.rr.com (74.69.224.1)  34.913 ms  30.602 ms  28.762 ms
3  tge0-0-1.keennhfi02h.northeast.rr.com (24.31.152.17)  28.827 ms  30.120 ms  21.132 ms
4  agg47.sebgme0302r.northeast.rr.com (24.58.41.98)  19.262 ms  22.382 ms  19.438 ms
5  be25.rochnyei01r.northeast.rr.com (24.58.32.68)  30.941 ms  32.204 ms  36.969 ms
6  bu-ether35.chcgildt87w-bcr00.tbone.rr.com (107.14.19.104)  48.409 ms
bu-ether45.chcgildt87w-bcr00.tbone.rr.com (107.14.19.106)  45.363 ms  46.521 ms
7  0.ae1.pr1.chi10.tbone.rr.com (107.14.17.194)  44.828 ms  46.147 ms  46.715 ms
8  216.1.94.145 (216.1.94.145)  46.134 ms
216.1.94.65 (216.1.94.65)  44.569 ms  45.409 ms
9  207.88.13.249.ptr.us.xo.net (207.88.13.249)  102.968 ms  101.157 ms  99.935 ms
10  te-4-1-0.rar3.denver-co.us.xo.net (207.88.12.22)  99.752 ms  102.249 ms  100.301 ms
11  216.156.16.3.ptr.us.xo.net (216.156.16.3)  98.776 ms  97.968 ms  98.756 ms
12  216.156.1.128.ptr.us.xo.net (216.156.1.128)  97.956 ms  95.644 ms  96.459 ms
13  * * *
14  166-70-1-5.xmission.com (166.70.1.5)  96.024 ms  96.826 ms  97.406 ms
15  t01.saltv1.ut.us.sn11.net (162.252.204.163)  87.981 ms  97.264 ms  86.158 ms
16  sandwichnet.dmarc.lga1.atlanticmetro.net (208.68.168.214)  89.937 ms  86.768 ms  87.949 ms
17  bad.horse (162.252.205.130)  88.073 ms  87.895 ms  86.609 ms
18  bad.horse (162.252.205.131)  93.351 ms  92.933 ms  90.876 ms
19  bad.horse (162.252.205.132)  115.629 ms  96.391 ms  96.864 ms
20  bad.horse (162.252.205.133)  101.257 ms  102.472 ms  102.213 ms
21  he.rides.across.the.nation (162.252.205.134)  108.059 ms  107.064 ms  108.290 ms
22  the.thoroughbred.of.sin (162.252.205.135)  111.206 ms  110.611 ms  109.944 ms
23  he.got.the.application (162.252.205.136)  116.866 ms  117.842 ms  115.659 ms
24  that.you.just.sent.in (162.252.205.137)  120.375 ms  123.519 ms  121.631 ms
25  it.needs.evaluation (162.252.205.138)  127.377 ms  126.769 ms  127.779 ms
26  so.let.the.games.begin (162.252.205.139)  132.761 ms  132.705 ms  131.315 ms
27  a.heinous.crime (162.252.205.140)  136.769 ms  136.045 ms  137.322 ms
28  a.show.of.force (162.252.205.141)  141.842 ms  141.447 ms  148.635 ms
29  a.murder.would.be.nice.of.course (162.252.205.142)  146.332 ms  147.854 ms  146.570 ms
30  bad.horse (162.252.205.143)  149.928 ms  150.487 ms  152.083 ms
31  bad.horse (162.252.205.144)  157.190 ms  156.693 ms  155.737 ms
32  bad.horse (162.252.205.145)  160.201 ms  161.399 ms  159.623 ms
33  he-s.bad (162.252.205.146)  166.007 ms  165.738 ms  165.244 ms
34  the.evil.league.of.evil (162.252.205.147)  171.012 ms  170.984 ms  172.062 ms
35  is.watching.so.beware (162.252.205.148)  176.041 ms  174.358 ms  176.463 ms
36  the.grade.that.you.receive (162.252.205.149)  181.276 ms  178.815 ms  180.667 ms
37  will.be.your.last.we.swear (162.252.205.150)  188.481 ms  185.823 ms  188.627 ms
38  so.make.the.bad.horse.gleeful (162.252.205.151)  194.008 ms  189.161 ms  193.114 ms
39  or.he-ll.make.you.his.mare (162.252.205.152)  198.708 ms  195.870 ms  195.894 ms
40  o_o (162.252.205.153)  200.037 ms  200.691 ms  201.280 ms
41  you-re.saddled.up (162.252.205.154)  207.748 ms  206.896 ms  205.608 ms
42  there-s.no.recourse (162.252.205.155)  211.288 ms  219.062 ms  212.026 ms
43  it-s.hi-ho.silver (162.252.205.156)  216.961 ms  218.367 ms  216.492 ms
44  signed.bad.horse (162.252.205.157)  214.262 ms  218.125 ms  215.096 ms

Firewalls Now Looking At Intercepting SSH Traffic Via A MITM Attack

conexion manual ssh

Can you trust Secure Shell (SSH) when you are behind certain firewalls? That’s the question raised by a post from a friend of mine:

Lies, Damn Lies, and Inspecting SSH Traffic Securely

It seems that because ssh can be used for tunneling services and application traffic several firewall vendors are now implementing “SSH inspection” services that essentially perform a Man-in-The-Middle (MITM) attack on your ssh connection.

When you go to ssh into a server, the firewall pretends it is that server and creates a ssh tunnel with you. The firewall then creates the actual ssh connection to the server and passes your packets from the first tunnel into the second tunnel – while being able to log or inspect the packets in between the two tunnels.

Now, of course with ssh you go through an initial handshake when you first connect to a server that results in the server’s public key being added to your list of known hosts.

If you connect to a server for the first time BEFORE being behind one of these firewalls doing SSH inspection, you would already have the correct public key of the server in your known hosts file. What would happen when the firewall tried to do a MITM is that you would be asked to approve the public key of the server again. (Because you are actually now approving the public key of the firewall.)

You would have to realize that this was wrong and stop your connection!

If you proceeded ahead with the connection and approving the public key, you would now have the firewall as a MITM.

If you connect to a server for the first time AFTER being behind one of these firewalls, well… I’m not sure what you can do. You’re going to see a public key to approve, but it would be from the firewall! You’d have to somehow learn the correct public key of the target server to be able to match it to the fingerprint you are being shown.

I don’t know how well that will work.

The good news for me personally is that I’m not behind these kind of firewalls in my regular networks – although I don’t honestly know what my Internet service providers are using. They could be doing these kind of things.

I don’t consider this a good thing that firewalls are now doing this. We need to trust the security of services like SSH. This decreases overall trust.

Photo credit: El Taller del Bit on Flickr

Congrats to FreeBSD On Their $1 Million Donation

FreeBSD Foundation logoWow! Many congratulations to the folks at the FreeBSD Foundation for receiving a generous $1 million donation from Jan Koum, CEO and Co-Founder of WhatsApp.

And of course many, MANY thanks to Jan Koum for giving back in this way!  As he states in his Facebook post (reprinted in that link above), the FreeBSD operating system helped him get started in his career and got him to where he is today.  This is a wonderful recognition of the power of open source operating systems – and it is wonderful that Jan Koum made this donation.

While most of the UNIX-related work in my life has been focused around Linux versus FreeBSD, I’ve used FreeBSD on a number of projects and found it quite good.  From a strategic point of view, I’m glad to see this donation to the FreeBSD Foundation to help advance its own plans.  Much of the world’s attention to “open source” matters focuses around Linux – and Linux receives the majority of corporate support and donations. But the Internet thrives on diversity and it is great to have a strong set of operating systems out there.  This donation is good for the health of the overall Internet and the open source ecosystem.

Kudos to Jan Koum for making this donation now that he has risen to such a successful point in his life where he can make a donation like this.  I hope he will inspire others who are in such situations to do so as well!