In May 2017, the WannaCry vulnerability caught the IT world by surprise. In the blink of an eye, an estimated 200,000 computers worldwide were infected with crippling ransomware. The attack exploited a vulnerability in the antiquated version 1 of Server Message Block (SMB), a critical remote service and file sharing protocol for Windows servers.
In the enterprise, IT and cloud world, the ripple effect of WannaCry is still being felt to this day. For years, many IT organizations and vendors have been heavily relying on SMB as a way of interacting with servers and connected devices. With SMBv1 being the simplest and most ubiquitous version of SMB, much of that use is based on this flawed version. As server administrators and executives around the world now rush to eradicate all use of SMBv1 from their environments, they are faced with the challenge of maintaining their SMB-based management capabilities intact.
The Challenge with Replacing SMBv1
Jetpatch has been using SMB for several years now, as one of several methods for interacting with managed servers. SMB has been an important ingredient in our adaptive, multi-protocol communication archiecture. Using it in our communication stack is part of why Intigua has been able to achieve extremely high success rates at automating IT tasks. In particular, it is one of the keys to Intigua’s success at complete lifecycle management of server tool agents.
The Jetpatch engineering team has long been aware of the obsoleteness of SMBv1, but was faced with lack of alternatives available in Java – the programming language and ecosystem used in our software. At the time WannaCry broke out, Jetpatch was already in the process of evaluating replacement options, focusing on options outside of the Java ecosystem which required more complex integration. As we learned of WannaCry and its impact on enterprise security, we doubled our efforts on this project, and worked intensively on multiple alternatives.
Finding the Right Alternatives
By the time of our release 3.6, just a few weeks after the initial outbreak of WannaCry, we were able to introduce not one but two distinct alternatives to our previous use of SMBv1: Firstly, we added the WinRM protocol to our stack of supported management protocols. WinRM is a more recent Windows management protocol than SMB, based on a Web Services (WS) approach. It is not quite as powerful as SMB, and some pre-requisite configuration is needed inside each managed server, but nevertheless it is an important addition to the Jetpatch communication toolbox.
The second capability was more challenging to add, but (unsurprisingly) turned out to be more popular among our customers: We were finally able to add SMBv2 protocol support natively into our Java server. This was made possible by the quick emergence of a new open-source Java SMB library named smbj. This library is still very young and quickly evolving, posing a serious challenge in testing its stability and suitablity for our needs. But using our large-scale, real-world-like testing lab, along with our past investment in test automation and stress-testing infrastructure, we were able to ensure that the library is indeed stable. Where we did find some issues, the open-source development model of smbj allowed us not only to identify them in the library code, but also to contribute our own fixes and functional improvements back to the library. As a result, we were able not only to build a robust solution for Intigua and its customers, but also to provide our modest contribution to the Java community in general as it is moving away from SMBv1.
What’s Next
Finally, before the new Jetpatch version was officially released, we asked some of our customers to check it out in their environments and report their experience. We were thrilled to find out that not only was everything working perfectly, but customers were mindful and appreciative of the effort we made to deliver a timely solution to a pressing security concern. As part of our ongoing commitment to customer value and security, and as SMBv3 solutions become available in the Java community, we plan to upgrade to that version of the protocol next.
