Riding the Blockchain Express to “De-Central” Station.
So, that image below? Think Facebook, Twitter, LinkedIn, Amazon, or any other of the many nexuses of information that populate the the Internet.
The mathematician as extortionist: ransomware “smart” contracts
A few weeks ago I wrote about the “proof of work” concept inherent in the implementation of the blockchain used to support bitcoin. I have continued down the blockchain path and have been exploring another child of the blockchain revolution: Ethereum.
Source: Fox Photos/Getty Images
Those are the “accountants”, all working independently to validate bitcoin transactions.
The author is the mysterious “Satoshi Nakomoto“, who may be Japanese, or may be a collection of people, or may be (my take) some blockchain instance from the future that has developed self-awareness and has traveled back through time, using the identity of Satoshi to create itself.
Positive Train Control: Skating away on the thin ice of a new day?
From the movie “The Polar Express“
That line: “Skating away on the thin ice of a new day” is from a Jethro Tull song by the same name. (Yes – I am that old 😉 ).
It came to me as I was reflecting on the reading I’ve been doing on the topic of “Positive Train Control“ (PTC).
PTC is an idea rather than any specific technology or architecture. Continue reading
In the not too-distant past I was involved in helping secure the information infrastructure of a major EDI “VAN”.
How’s that for gibberish? Some definitions are in order:
EDI = “Electronic Data Interchange”. Effectively, a collection of standards for the encoding of documents such as invoices, purchase orders, bills of lading, medical information, and – it seems – information pertaining to the business of buying, selling and moving natural gas.
EDI dates from the 1970’s. It took advantage of pre-Internet communication mechanisms but quickly was adapted to the Internet and likely will be to blockchain.
EDI “trading partners” can communicate directly, but often they rely on third-party EDI specialists to handle communication with their various trading partners. These are the EDI “Value Added Networks” (VAN).
EDI is the unsung hero of modern commerce.
Everything we buy or sell has a secret life as an EDI document. Usually a number of them.
Not surprisingly, natural gas pipeline companies use EDI in the running of their business, communicating information about availability and pricing to their customers and government. A few months ago, the business of some natural gas pipeline companies was disrupted by the sudden unavailability of those EDI services.
The attack, in March 2018, was directed against a central provider of EDI services to several major natural gas pipeline operators. Although it did not affect actual in-field operations, it did stop all normal business traffic for several days, causing confusion and a fall-back to alternate communication mechanisms.
Of greater concern was the loss of potentially sensitive information about internal business structure, all of which can be inferred from the ebb and flow of EDI data. Such information can be invaluable to an attacker and in this case can be an aid in eventually attacking actual pipeline operations.
The point here is that it is easy to view such operations as strictly an ICS security concern, and that with proper segmentation of business from ICS infrastructure all will be well.
I’ve had some experience in that ICS world over the last few years and know that segmentation is often incomplete at best. Even when segmentation is present, your business can still be vulnerable to attacks on exposed business systems that have process flow links to ICS.
What to do?
Natural Gas Industry Usage of EDI:
Quote: “The NAESB wholesale natural gas cybersecurity standards facilitate an infrastructure of secure electronic communications under which the electronic transmission of data via EDI or browser based transactions is protected. There are more than fifty separate transactions identified for nominations, confirmations, scheduling of natural gas; flowing gas transactions including measurement, allocations, and imbalances; invoicing related transactions including invoices, remittances, statement of account; and capacity release transactions.”
Quote: “EDI security appears at several interrelated stages:
The Target? You. Image Source: Wikimedia Commons
That last one strikes close to home for me as it is a technique I have used successfully when conducting “white-hat” phishing exercises for MSI’s clients.
The indictment makes it clear that we are very much in a “cyberwar” right now and that the targets of greatest opportunity in that war are not information infrastructure – but people. You and I, feverishly pounding away at a keyboard in an attempt to meet some deadline (like writing a blog post?). Or, even better and more dangerous, responding to emails with a mobile device while we sit waiting at a stoplight. None of us, of course.
Many of you likely regard yourselves as targets of little interest in any cyberwar attack. And that may be true for you specifically, but is it true of your family members and friends as well?
Perhaps one of them works for an HVAC vendor that does work for government?
The point is that everyone is connected via some device and everyone shares infrastructure (cloud storage?) with others. Any person in that chain of connectedness is a potential stepping stone to items of real interest to an attacker.
Phishing has become the primary attack vector and the target can be anyone who is connected to someone else with access to sensitive information. It’s low cost and relies on information about us that we and those who know us have freely given up,
And… it just works. Those Russian operatives know that, and so should you.
Everyone is now a potential target in this new type of warfare
What to do?
One of the common findings security assessment services encounter when they evaluate the Internet presence of an organization are sites where login credentials travel over the Internet unencrypted.
So: HTTP not HTTPS.
The intent of the browser’s warning is to make the user aware that there is a risk of credential loss with this “http-only” unencrypted login.
The solution is HTTPS of course, but that requires that a “certificate” be created, signed by some “certificate authority” (CA), and that the certificate be installed on the website.
If the user connects via HTTPS ( not HTTP ) the browser and the server negotiate an encrypted communication channel based on the SSL/TLS protocol and all is well…. almost.
The traffic will be encrypted, but if the particular CA that created the website’s certificate is not itself known to the browser (and those trusts are either built-in or added by an IT department) the user may see something like the following:
The browser will give the user the option to trust the certificate and proceed – but this is universally regarded as a bad practice as it makes the end user more inclined to disregard all such security warnings and thus be more susceptible to phishing attacks that intentionally direct them to sites that are not what they claim to be.
The usual solution is to purchase certificates from a known and accepted CA (e.g. DigiCert, Comodo, GoDaddy, Entrust, etc.).
The CA’s that issue these certificates will perform some checks to ensure the requester is legitimate and that the domain is in fact actually controlled by the requester. The extent to which identity is verified and the breadth of coverage largely determines the cost – which can be anywhere from tens to thousands of dollars. SSLShopper provides some examples.
The problem is the cost and administrative delay associated with purchasing certificates from accepted CA’s, keeping track of those certificates, and ensuring they are renewed when they expire.
As a result some sites either dispense with HTTPS altogether or rely on “self-signed” certificates with the attendant risk.
This is where “Let’s Encrypt” comes in.
“Let’s Encrypt” is an effort lead by some of the major players in the industry to lower (read: eliminate) the cost of legitimate HTTPS communications and move the Internet as much as possible to HTTPS (and other SSL/TLS encrypted traffic) as the norm.
The service is entirely free and the administrative costs are minimal. Open-source software (Certbot) exists to automate installation and maintenance.
Quoting from the Certbot site:
“Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your webserver. Certbot was developed by EFF and others as a client for Let’s Encrypt … Certbot will also work with any other CAs that support the ACME protocol.…
Certbot is part of EFF’s larger effort to encrypt the entire Internet. Websites need to use HTTPS to secure the web. Along with HTTPS Everywhere, Certbot aims to build a network that is more structurally private, safe, and protected against censorship”
The software allows “Let’s Encrypt” – acting as a CA – to dynamically validate that the requester has control of the domain associated with the website and issue the appropriate cert. The certificates are good for 90 days – but the entire process of revalidation can be easily automated.
The upshot is that all the barriers that have prevented universal adoption of HTTPS have largely been removed. The CA’s economic model is changing and some have left the business entirely.
Do you still have HTTP-only sites and are they a chronic finding in your security assessments?
Has cost and administrative overhead been a reason for that?
Take a look at “Let’s Encrypt” now!
Just because a site has a legitimate certificate and is using HTTPS does NOT mean it is necessarily safe, You may find your users are under the impression that is the case. As always, user education is a required part of your security program.
If, when you wake up in the morning, you look out outside and view something like the image below, you probably understand that you are not in the best of all possible worlds.
So, what “neighborhood” does your website see when it “wakes up”?
It could be just as disquieting.
It is not uncommon for MSI to do an an analysis of the Internet services offered by an organization and find that those services are being delivered from a “shared service” environment.
The nature of those shared services can vary.
Often they are simply the services of an virtual machine hosting provider such as Amazon AWS. Sometimes we find the entire computing infrastructure of a customer within such an environment.
The IP addressing is all private – the actual location is all “cloud”.
The provider in this case is running a “hypervisor” on it’s own hardware to host the many virtual machines used by its clients.
Another common occurrence is to find third-party “under the covers” core application services being linked to from a customer’s website. An example of such a service is that provided by commercial providers of mortgage loan origination software to much of the mortgage industry.
For example, see: https://en.wikipedia.org/wiki/Ellie_Mae
A quick google of “site:mortgage-application.net” will give you an idea of the extent to which the service is used by mortgage companies. The landing sites are branded to the customer, but they are all using common shared infrastructure and applications.
Web Site hosting:
Most often the shared service is simply that provided by a website hosting company. Typically many unique websites are hosted by such companies. Although each website will have a unique name (e.g. mywebsite.com) the underlying infrastructure is common. Often many websites will share a common IP address.
It is in this particular “shared service” space we most often see potential issues.
Often it’s simply a reputation concern. For instance:
www.iwantporn.net is an alias for iwantporn.net.
iwantporn.net has address 188.8.131.52
These are some of the sites that are (or have recently been) on that same IP address according to Microsoft’s Bing search engine:
My guess I some of the website owners would be uncomfortable knowing they are being hosted via the same IP address and same infrastructure as is www.iwantporn.com.
They might also be concerned about this:
Virustotal is reporting that a known malicious program was seen communicating with a listening service running on some site with the IP address 184.108.40.206 .
The implication is that some site hosted at 220.127.116.11 had in the past been compromised and was being used for communications in what may have been a ransomware attack.
The IP address associated with such a compromised system can ultimately be blacklisted as a known suspicious site,
All websites hosted on the IP address can be affected.
Website traffic and the delivery of emails can all be affected as a result of the misfortune to share an IP address with a suspect site.
When such a compromise of the information space used by a client in a shared service occurs, all other users of that service can be at risk. Although the initial compromise may simply be the result of misuse of the website owner’s credentials (e.g. stolen login/password), the hosting provider needs to ensure that such a compromise of one site does not allow the attacker to compromise other websites hosted in the same environment – an attack pattern sometimes referred to as backplaning.
The term comes from electronics and refers to a common piece of electronics circuity (e.g a motherboard, an IO bus, etc. ) that separate “plugin” components use to access shared infrastructure.
The idea is that a compromised environment becomes the doorway into the “backplane” of underlying shared services. (e.g. possibly shared database infrastructure).
If the provider has not taken adequate precautions such an attack can affect all hosted websites using the shared service.
Such things really can happen.
In 2015 a vulnerability in commonly used hypervisor software was announced. See: http://venom.crowdstrike.com/
An attacker who had already gained administrative rights on a hosted virtual machine could directly attack the hypervisor and – by extension – all other virtual machines hosted in the same environment. Maybe yours?
What to do?
Be aware of your hosted environment’s neighborhood. Use the techniques described above to find out who else is being hosted by your provider. If the neighborhood looks bad, consider a dedicated IP address to help isolate you from the poor administrative practices of other hosted sites.
Contact your vendor to and find out what steps they have in place to protect you from “backplane” attacks and what contractual protections you have if such an attack occurs.
A friend on a road-trip recently had an experience using hotel wifi that was a little surprising. For several hours, while on the hotel’s wifi, her machine was effectively on the open Internet with no intervening firewall,
Her laptop was instrumented with one of MSI’s “honeypoints“, a lightweight honeypot that emulates various services and reports back to a central console when these “fake” services are interacted with, possibly by an attacker.
Over the several hour period while on wifi, the following Internet probes (and in some cases clear attacks) were seen.
The attacker IP and the port probed are in bold below:
These alerts were being reported to the console from the IP address assigned by the hotel to my friend’s laptop: 18.104.22.168
That IP is registered to:
NetRange: 22.214.171.124 – 126.96.36.199
Wayport is an ATT wifi service providing “hotspots” to various large companies.
These are the types of probes and attacks a box on the open Internet can expect to get. It’s become like cosmic radiation – pervasive. I discussed a previous related event here: https://stateofsecurity.com/?p=4126
What is interesting in this case is the fact they happened at all.
The hotel was part of a major chain. The common assumption is they are watching out for their guests to ensure a “safe” wifi environment…and in general they are.
But – there maybe some fine print.
Some hotel wifi agreements apparently specifically allow you to request “advanced” connectivity options, in some cases as a result of wanting to do VPN from your laptop. The result of those decisions may lead to a public Internet address and full Internet exposure of your device .
So – no Internet firewall but the one you bring with you.
Quote from that last:
“Most private LANs use network firewalls to defend trusted insiders against Internet-borne attacks.This is not necessarily true in hotel broadband LANs, where topologies and security practices vary widely.For example, some use private IP addressing, while others assign each user their own public IP address to facilitate VPN tunneling. Users may assume they are insulated from outsiders, but really have no idea whether any firewall lies between
their notebook and the Internet. Notebooks that do not firewall themselves or that use certain applications that open holes in firewalls could thus be exposed to intrusions from the far side of the Internet.”
I have repeatedly had the experience of performing external vulnerability assessments and discovering significant issues that were not being called out as such by the regular commercial assessment services employed by the client organization.
I recently discovered a case where active web server logs were freely available on the open Internet . The usual information – source IP address, target resource, and status codes – were all available.
188.8.131.52 – – [02/Aug/2017:10:09:07 -0400] “GET /client/chat.php?id=1%22%20%3E%3C/script%3E%3Cscript%3Ealert%28%27QualysXSSTestPart2%27%29%3C/script%3E&xhash=1 HTTP/1.1” 302 433 “-” “-“
184.108.40.206 – – [02/Aug/2017:10:09:08 -0400] “GET /index.do HTTP/1.1” 302 301 “-” “-”
220.127.116.11 – – [02/Aug/2017:10:09:10 -0400] “GET /userui/welcome.php HTTP/1.1” 302 311 “-” “-”
18.104.22.168 – – [02/Aug/2017:10:09:12 -0400] “GET /struts2-rest-showcase/orders HTTP/1.1” 302 321 “-” “-”
22.214.171.124 – – [02/Aug/2017:10:08:58 -0400] “POST /rest/json/login HTTP/1.1” 302 308 “-” “-”
126.96.36.199 – – [02/Aug/2017:10:09:14 -0400] “GET /node.xml HTTP/1.1” 302 301 “-” “-”
188.8.131.52 – – [02/Aug/2017:10:09:14 -0400] “GET /user/login HTTP/1.1” 302 303 “-” “-”
184.108.40.206 – – [02/Aug/2017:10:09:15 -0400] “GET / HTTP/1.1” 302 293 “-” “-”
220.127.116.11 – – [02/Aug/2017:10:09:16 -0400] “GET /admin.php HTTP/1.1” 302 302 “-” “-”
18.104.22.168 – – [02/Aug/2017:10:09:16 -0400] “GET /console/login/LoginForm.jsp HTTP/1.1” 302 320 “-” “-”
The highlighted entry is a “cross site scripting” (XSS) test being run over the Internet by the vulnerability management service “Qualys“.
From “whois 22.214.171.124”
NetRange: 126.96.36.199 – 188.8.131.52
Anyone on the Internet was able to view these logs and learn of the organization’s use of Qualys and something of the types of tests being performed and what the outcome of those tests were.
All highly useful information to any potential attacker.
Note that the problem here is NOT with Qualys.
The site that allowed these logs to be revealed had no “technical” security problem. Any internal user who was basing their understanding of the external security status of the organization strictly on the scanning service reports would likely have no reason to believe anything was wrong.
Your organization needs at least one knowledgeable and caring staff member whose job it is to know what your organization looks like from the Internet and can see when something is clearly wrong in the same way a neighborhood patrol officer can notice a strange car or a gate open that is normally locked.
You need your own “cop on the beat”.