Perl-clutching hijackers appear to have seized control of 33-year-old programming language's .com domain

[mood]

Perl-clutching hijackers appear to have seized control of 33-year-old programming language's .com domain

Got a few (thousand) dollars to spare?

 

Unless the venerable language has finally breathed its last – which is more than a little unlikely – the Perl.com domain was hijacked yesterday.

 

A warning went up on the perl.org infrastructure weblog overnight notifying users that perl.com now directed to a parking site and advised against visiting "as there are some signals that it may be related to sites that have distributed malware in the past."

 

Seems a bit of a harsh description of Perl. We at El Reg are big fans after all.

 

The site later returned an ERR_CONNECTION_CLOSED error message.

 

Snark aside, the hijack appears to have followed the age-old path of an attacker pouncing on a compromised account and swiping the domain rather than a simple expiration.

 

Posting on Reddit, Brian Foy, an editor on the site and author of several books on Perl, said: "It looks like there was an account hack. I don't know how long that would take to rewind. We're looking for people who have actual experience dealing with that situation so we can dispute the transfer."

 

Perl.org is unaffected by the swipe.

 

A glance at the domain records show the contact information is now "REDACTED FOR PRIVACY". Gordon Lawrie – a self-proclaimed cyberlaw, trademark, and domain nerd – told us that prior to the change Tom Christiansen was listed as the domain administrative contact.

 

While the Perl team has yet to respond to our request for a comment, a hijacking of Christiansen's account seems a possibility. The expiry also appears to have been extended to 26 January 2031.

 

Shortly after the hijacking, the domain perl.com turned up as available to buy for $190k on afternic.com, now listed as a name server in the domain record at time of writing.

 

Perl.com for sale at $190,000 (credit: Gordon Lawrie)

 

The listing included other pricey domains, including piracy.com for a mere $125k, from user drawmaster. Afternic is part of the GoDaddy organisation and, shortly after we approached it for comment, the perl.com listing had been pulled. Piracy.com appears to still be available if you're so inclined (and endowed in the wallet department).

 

All had recently been transferred to a mystery owner allegedly based in Chisinau, Moldova. All also had the full details of their original owners in plain text prior to the ownership change, including email addresses.

 

 

Source: Perl-clutching hijackers appear to have seized control of 33-year-old programming language's .com domain

[scarabou]

The domain name perl.com was stolen and now points to an IP address associated with malware campaigns.

Perl.com is a site owned by Tom Christiansen and has been used since 1997 to post news and articles about the Perl programming language.

On January 27th, Perl programming author and Perl.com editor brian d foy tweeted that the perl.com domain was suddenly registered under another person.

Intellectual property lawyer John Berryhill later replied to the tweet that the domain was stolen in September 2020 while at Network Solutions, transferred to a registrar in China on Christmas Day, and finally moved to the Key-Systems registrar on January 27th, 2020. 

Perl.com domain registration changes
Source: John Berryhill on Twitter

It wasn't until the last transfer that the IP addresses assigned to the domain were changed from 151.101.2.132 to the Google Cloud IP address 35.186.238[.]101.

When visiting the site, users are greeted with a blank page. The HTML for the page contains Godaddy parked domain scripts even though it is registered with the registrar key-systems(.)net.

On the 28th, d foy tweeted that they have set up perl.com temporarily at http://perldotcom.perl.org for users who wish to access the site until the domain is recovered.

Until the domain hijacking is resolved, perl.org is recommending that users do not use perl.com as a CPAN mirror and to update it using the following command:

# perl -MCPAN -eshell
cpan shell -- CPAN exploration and modules installation (v2.20)
Enter 'h' for help.

cpan[1]> o conf urllist http://www.cpan.org/
Please use 'o conf commit' to make the config permanent!
cpan[2]> o conf commit
commit: wrote '/root/.cpan/CPAN/MyConfig.pm'

d foy has told BleepingComputer that it is not believed that the domain owner's account was hacked and that they are currently working with Network solutions and Key-Systems to resolve the issue.

"I do know from direct communication with the Network Solutions and Key Systems that they are working on this and that the perl.com domain is locked. Tom Christiansen, the rightful owner, is going through the recovery process with those registrars."

"Both registrars, along with a few others, reached out to me personally to offer help and guidance. We are confident that we will be able to recover the domain, but I do not have a timetable for that," d foy told BleepingComputer.

New perl.com IP address tied to malware

The IP address that perl.com is now hosted has a long history of being used in older malware campaigns and more recent ones.

In 2019, the IP address 35.186.238[.]101 was tied to a domain distributing a malware executable [VirusTotal] for the now-defunct Locky ransomware.

More recently, a malware [VirusTotal] that appears to be an ad clicker is using the following domains as command and control (C2) servers.

www.supernetforme[.]com
www.superwebbysearch[.]com

These domain names both resolve to 35.186.238[.]101, as shown below.

Command and control servers hosted at 35.186.238[.]101

When the malware attempts to connect to the URLs at these domains, they are now receiving the same parked domain scripts currently being used when visiting perl.com. 

These HTML responses, rather than instructions from a C2, may indicate that the IP address is under the control of a different threat actor.

For now, it is strongly advised not to visit perl.com until the domain is back in the hands of The Perl Foundation, as attackers could very easily switch it to a site for more malicious purposes.

 

Source: Perl.com domain stolen, now using IP address tied to malware

[mood]

The Hijacking of Perl.com

 

 

For a week we lost control of the Perl.com domain. Now that the incident has died down, we can explain some of what happened and how we handled it. This incident only affected the domain ownership of Perl.com and there was no other compromise of community resources. This website was still there, but DNS was handing out different IP numbers.

 

First, this wasn’t an issue of not renewing the domain. That would have been a better situation for us because there’s a grace period.

 

Second, to be very clear, I’m just an editor for the website that uses the Perl.com domain. This means that I’m not actually the “injured party” in legal terms. Tom Christiansen is the domain registrant, and should legal matters progress, there’s no reason for me, nor anyone else, to know all of the details. However, I’ve talked to many of the people involved in the process.

The incident response

I think we did a pretty good job with the decentralized, volunteer incident response, so I’d like to share part of what we did as I tell you the story. You may have had the pleasure (or pain) of a formal response, and there are various things you can do to forego extra headaches and frustration.

 

Early on the morning of January 27, the Perl NOC noticed through normal monitoring that something was wrong with the domain. Along with that, people started to report that the website had gone missing. As DNS updated across the globe, more and more people reported problems. We didn’t know what was happening or why.

 

Behind the scenes I started to collect incident information, and I put out a tweet asking for help. At this point we didn’t know what was going on; we just knew the effect. It’s important during the early stages of a response to verify what’s known and what’s rumor, and to separate who knows something and who’s passing around rumors. As with most situations, it’s that rumor group that dominates the conversation and they often have a more interesting story to tell because they can speculate and fabricate any narrative they like. Work the problem without speculation—find out what you actually know and what’s just a guess.

 

I started a Google doc and invited the relevant people. We started to fill in the details, classifying everything according with either green, amber, or red. Green was high confidence information, such as direct communication with a registrar, amber was likely good but unverified, and red was just flat out wrong. All information was tagged with a time and source. The first rule of rumor control is stating who you heard it from and when. Once this is in the document, other people know if what they think they know is better or more recent. And, sometimes the information that we thought was good turns out to be wrong. In those cases we update the document.

 

We also listed things that needed to happen, and various people picked up what they could address. For example, we started to check other community resources, so Elaine Ashton looked at the registration for cpan.org, which had an oddity in its contact info but later turned out to be fine after she dealt with the registrar on the phone. Robert Spier, part of the Perl NOC, was able to verify various network aspects, timelines, and so on. Rik Signes stepped up to set up a private mailing list on TopicBox (he is the CTO, after all). The trick here is to not do work that someone else can do for you (and often better than you can). Likewise, if someone is already doing something, you’re wasting your time (and others’ time) by redoing or reinventing it. Decentralization is fine, but someone needs to be the coordinator. In this case that turned out to be me because I had a lot invested in the Perl.com website, and I could easily work with Tom because we worked with each other for a year on Programming Perl.

 

My tweet and my reddit comments got the attention of both sides of the registrar equation, so I was talking to both Network Solutions and Key Systems very early in the process. We were very fortunate to that Perl is a known thing and that both Tom Christiansen and I are well-known within Perl. The first rule to success is to already be successful. People inside various organizations involved offered us help and guidance. Other victims were not so fortunate and help for them was not forthcoming. And, at some point, Perl was probably running those organizations, so there’s some fondness for the good ol’ days.

 

Mostly, I helped both sides get in touch with Tom Christiansen and helped him manage all the players. In many incidents, people become overwhelmed by everything that needs to happen and end up not doing anything. He needed to work with the registrars, so I took what work I could off his plate so he could focus on that bit.

 

We had learned very quickly that when you use the registered domain for your email contact, no one can contact you when that domain no longer handles your mail. Most of that hassle was verifying that people were who they say they are, but in the domain business, everyone knows who the real people are—this is what they do every day. We made sure that we didn’t overload them with inquiries from several different people asking the same question. Coordinating who is working with whom avoids the N-squared communication issues and lets people do the work they need to do rather than answer the same questions repeatedly.

 

Once everyone who needed to talk to each other had good contact info, the process mostly took care of itself. We didn’t know that everything would work out, but as the situation developed we became more confident that it would. Our confidence, however, isn’t reportable information. You don’t announce what you think will happen or what is promised to happen because often there are delays or hiccups.

 

We transitioned to managing public information and sharing what we could. Our goal was to give people the confidence that they had the right info. As a techy audience, we often like to have all the information, but there’s very little that anyone actually needs to know.

 

We settled on having all the updated info in one place, at The Perl NOC blog. Sometimes we knew things several hours before we published the information because we did the extra work to directly verify things. People didn’t have to track social media, etc to find out what was going on because they could remember this one place. We still broadcast updates all over the place, but always pointed back to the NOC blog. A single point of reference is very helpful.

 

For those in the incident response, we developed a current situation summary and talking points. These were basically the things that we had verified that we could disclose without compromising the legal process.

 

We also tracked people and stories. Who’s who at various companies, which reporters are writing about the incident, and what discussion threads are out there. Some people in various discussion threads were obviously just there for the lulz, while others had good or actionable details (which often means they are on the inside of the situation). Again, we used the green / amber / red categories.

 

This isn’t my first rodeo, and I stepped into the role of press contact. Despite our diligent work to verify everything, many outside people just made up stuff. That’s just how it is and I expected that. The publishing maxim “If your mother says she loves you, get a second source” doesn’t apply in the age of Twitter. You don’t even need the first source.

 

It’s important to have one face (mouth?) to represent the diligent work everyone was doing. Half the “news” stories didn’t do basic research, and some of those reporters don’t even have contact info (really, a reporter you can’t contact?). A few were able to correct their stories after talking to me.

 

The Register had spot on reporting from the start as did Paul Ducklin at Sophos.

 

About a week after the nameservers changed, I had settled into the idea that it could take several weeks to unravel the hijacking. With multiple countries involved along with various sets of laws and rules in effect, things might have a much slower pace than we’d like. In the internet age, tomorrow is basically infinitely far away. David Farrell floated the idea of renaming the site, and we started using perldotcom.perl.org as a temporary domain. Robert was able to set that up quickly, and we even got some good work out of it as pull requests from the community found spots where we had hard-coded various things that we shouldn’t have (anyone can send a pull request for anything about the site!). The GitHub process that David had set up was key to making all of this work; it’s a pleasure to get even the tiniest pull requests from the community.

 

Then, in early February I got some solid (green) back-channel information that we’d get the domain back in a couple of days. I was dubious but it actually happened! Again, I think we were very fortunate here and that many people with a soft spot in their hearts for Perl did a lot of good work for us. All sides understood that Perl.com belonged to Tom and it was a simple matter of work to resolve it. A relatively unknown domain name might not fare as well in proving they own it.

 

Recovering the domain wasn’t the end of the response though. While the domain was compromised, various security products had blacklisted Perl.com and some DNS servers had sinkholed it. We figured that would naturally work itself out, so we didn’t immediately celebrate the return of Perl.com. We wanted it to be back for everyone. And, I think we’re fully back. However, if you have problems with the domain, please raise an issue so we at least know it’s not working for part of the internet.

What we think happened

This part veers into some speculation, and Perl.com wasn’t the only victim. We think that there was a social engineering attack on Network Solutions, including phony documents and so on. There’s no reason for Network Solutions to reveal anything to me (again, I’m not the injured party), but I did talk to other domain owners involved and this is the basic scheme they reported.

 

John Berryhill provided some forensic work in Twitter that showed the compromise actually happened in September. The domain was transferred to the BizCN registrar in December, but the nameservers were not changed. The domain was transferred again in January to another registrar, Key Systems, GmbH. This latency period avoids immediate detection, and bouncing the domain through a couple registrars makes the recovery much harder.

Notice the long lag time of the first transfer, though. The domain is compromised in September but transferred in December. There’s a reason for that: ICANN has a 60-day rule. You can’t transfer the domain within 60 days of updating the contact info. We think part of the attack changed the registration at the same time as the attackers renewed the domain for a couple more years past its original expiration in 2029.

 

Once transferred to Key Systems in late January, the new, fraudulent registrant listed the domain (along with others), on Afternic (a domain marketplace). If you had $190,000, you could have bought Perl.com. This was quickly de-listed after the The Register made inquiries.

Some lessons

Obviously this is an embarrassing situation, but it’s not an uncommon story. This domain was registered in the early 90s, Tom Christiansen was given control of it shortly after that, and basically kept paying the registration fees. Since it wasn’t a nagging problem, the domain was left as it was. Features such as two-factor authentication probably would have saved us much of this trouble (although social engineering attacks tend to route around safeguards).

 

I’ve already mentioned the problem with using the domain in the contacts for the domain. When there’s a problem, the communication channels are also borked. Have at least one of the contacts go somewhere else.

 

It’s essential to communicate with “one voice” else you risk sowing confusion with different messages, even if they’re saying the same thing. You also want to project confidence, and competence so that the information you do release is treated credibly; if different channels are releasing different updates, the risk of error increases. The Perl Foundation insisted on releasing their own update instead of using our prepared statement. And even though it was brief, the link to the Perl NOC blog was broken for several days. Don’t take unnecessary risks.

 

And, it always helps to have friends and good relationships with the people who are able to help. The people at Network Solutions and Key Systems were very helpful in the recovery, as were several other people who keep the internet working. I wish I could give them direct credit, but I’m sure they’d rather do their work quietly.

Where we are now

The Perl.com domain is back in the hands of Tom Christiansen and we’re working on the various security updates so this doesn’t happen again. The website is back to how it was and slightly shinier for the help we received.

 

As part of the incident response, The Perl Foundation Infrastructure Working Group surveyed other important community domains and will work to secure those. If you are interested in helping with that, get in touch with them.

 

 

Source: The Hijacking of Perl.com

[mood]

Attackers took over the Perl.com domain in September 2020

The Perl.com domain was hijacked in January, but a senior editor at the site revealed that the hackers took control of the domain in September 2020.

 

The Perl.com domain was hijacked in January 2021, but according to Brian Foy, senior editor of Perl.com, the attack took place months before, in September 2020.

 

Attackers have taken over the official domain name of The Perl Foundation perl.com and pointed it to an IP address associated with malware campaigns.

 

The domain Perl.com was created in 1994 and was the official website for the Perl programming language, it is registered with the registrar key-systems(.)net.

 

“The perl.com domain was hijacked this morning, and is currently pointing to a parking site.  Work is ongoing to attempt to recover it.” reads the announcement published on the Perl NOC in January.

 

“We encourage you NOT to visit the domain, as there are some signals that it may be related to sites that have distributed malware in the past.”

 

The attackers changed the IP address from 151.101.2.132 to 35.186.238[.]101.

 

 

After the hackers took over the site, it was displaying a blank page whose HTML contains Godaddy parked domain scripts.

 

Shortly after the domain hijacking, perl.com was offered for sale for $190k on afternic.com.

“John Berryhill provided some forensic work in Twitter that showed the compromise actually happened in September. The domain was transferred to the BizCN registrar in December, but the nameservers were not changed.” wrote Foy. “The domain was transferred again in January to another registrar, Key Systems, GmbH. This latency period avoids immediate detection, and bouncing the domain through a couple registrars makes the recovery much harder.”

 

The hijack took place in September, the domain was transferred in December to another registrar but the nameservers were not changed to avoid detection of the malicious activity. In January the domain was transferred again, at the end of January it was pointing to an IP address that was involved in past malware campaigns, including the distribution of Locky ransomware. Shortly after the second transfer, perl.com was offered for sale for $190k on afternic.com.

 

According to Foy, the attack might have resulted in the hack of several other domains.

 

“This part veers into some speculation, and Perl.com wasn’t the only victim. We think that there was a social engineering attack on Network Solutions, including phony documents and so on.” added Foy. “There’s no reason for Network Solutions to reveal anything to me (again, I’m not the injured party), but I did talk to other domain owners involved and this is the basic scheme they reported.”

 

The legitimate owner Tom Christiansen obtained back full control over the domain in early February.

 

The domain was back in the hands of Tom Christiansen, the rightful owner, in early February.

 

“The Perl.com domain is back in the hands of Tom Christiansen and we’re working on the various security updates so this doesn’t happen again. The website is back to how it was and slightly shinier for the help we received.” concludes Foy.

 

 

Source: Attackers took over the Perl.com domain in September 2020