DevCentral

Leading into June’s Programmability Month, we announced a codeshare challenge contest, where DevCentral community members could contribute a solution (or several) that they’ve created to solve problems in their environments. We had a lot of great contributions to the codeshare throughout the contest, and it’s always hard to narrow down something as nebulous as “best.” That said, we looked for originality, creativity, best practices coding and documentation, as well as breadth of audience for a particular solution. Please join us in congratulating our winners. Grand Prize - iControl REST Library for the Go Programming Language  Yann Desmarest has been quite active in the codeshare in general but also in this contest, contributing many entries. As we discussed our top selections in each category of the contest, the initiative in this entry to unlock the ease in which a new language can be tried by the community made this library our clear grand prize winner. Go is taking off in popularity, so for those who are not specific language apologists (looking at some of you perl, python, and powershell people,) maybe this is an opportunity to load it up and check it out! Or for the seasoned developers among you, contribute to the project on Github! iControl Category Prize - Automate F5 Setup with Ansible  Mark Wall contributed this mighty fine entry in the iControl category. Ansible is a simple but powerful workflow tool that combines orchestration with config management and deployment. In this contribution, Mark uses Ansible to deploy a (virtualized) pair of BIG-IPs by defining from a spreadsheet of comma-separated values. Currently, this includes NTP, DNS, hostname, LACP, dot1q, interfaces, vlans, and self-IPs. But it doesn’t stop there! It also configures device trust and config sync as well. If you think about the normal user interaction with the GUI to take these steps, that’s quite a time savings and elimination of human error (in as much as the spreadsheet data is correct.)  iRules Category Prize - Provision IOS for Exchange Active Sync As mentioned earlier, Yann Desmarest was busy in this contest, and not only takes home the grand prize, but also the category prize for iRules for his iPhone provisioning solution for Exchange active sync. The need would normally require an MDM, but since the use case is such a small percentage in the larger MDM portfolio, it doesn’t make sense to include that additional infrastructure. Using an iFile for the IOS config file, he uses active directory query to populate some variable fields, then rocks the subst command to replace his variables from the iFile with the values set from AD. Pretty slick, and very powerful. Resources We had no entries for the iApps category, so we did not award a prize. Yann and Mark, we will be in touch shortly regarding your prizes! DevCentral Programmability Contest Rules Category Prize Winner Form Grand Prize Winner Form

Consider yourself a fascinating person if you've ever heard the term "Elliptic Curve Cryptography" (ECC).  Consider yourself a cryptographic crackerjack if you actually know what it does and how it all works.  If you are a mere mortal like the rest of us, you might not understand every single aspect of ECC.  Nonetheless, many web applications are (or soon will be) using ECC to secure online transactions, so I wanted to spend some time discussing the details behind this relevant and important topic.   A Walk Down Memory Lane Before diving into Elliptic Curve Cryptography (ECC), let's take a quick stroll down the cryptography memory lane that brought us to the point of even caring about ECC.  Prior to the 1970s, cryptography was based primarily on securing communications using a shared secret key.  This secret key was used to both encrypt and decrypt communications.  This type of encryption is called “symmetric” because the same key is used to encrypt and decrypt.  Symmetric encryption is still used widely today because of its speed and efficiency.  In fact, you are using it right now to read this article! As computers grew in popularity and our reliance on secure communications became more and more necessary for everyday life, experts began to see a significant issue with symmetric encryption.  This issue dealt with key distribution and exchange.  Back in the day, people would have to find creative ways to share the secret encryption/decryption key so that no one else got their hands on it.  Imagine the headache of trying to figure out how to share a secret key with someone on the other side of the world.  And, what if the key was compromised?  How do you re-share a new key?  You can see how this could turn into a frustrating situation.  Fortunately, in 1977, a new era of viable cryptography was introduced.  Rather than dealing with the hassle of distributing symmetric keys, a few really smart dudes introduced what we now know as Public Key Cryptography.  In Public Key Cryptography, two keys are used…a private key and a public key.  Anyone in the world can get a copy of the public key, but only the user has a copy of his/her private key.  The genius of it all is that the private key can decrypt a message that has been encrypted with the public key…in fact, the private key is the ONLY key that can decrypt a message that has been encrypted with the associated public key.  Today, we use Public Key Cryptography to share symmetric encryption keys.  That way, we can still realize the efficiency and speed of symmetric encryption without the headache of sharing the symmetric keys.   Is That A Trapdoor? Public Key Cryptography is awesome because it allows you to literally share half of your encryption key with anyone and everyone.  But, the question is…how in the world does that even work?  How can you give away half of your encryption information and still have a viable and secure form of communication?  The fundamental approach to solving this problem comes in the form and what’s called a “trapdoor” function.  A trapdoor function is one that’s really easy to solve in one direction, but really difficult to solve the other direction.  For example, if I could create a mathematical function that makes it super easy to get to point “B” given a value for point “A” but makes it almost impossible to figure out where point “A” is if I only know the value of point “B” then I have a good trapdoor function…easy one direction but hard the other.  A good trapdoor function is absolutely critical in the implementation of Public Key Cryptography.  But that begs another question…do we have any good trapdoor functions lying around?   Rivest, Shamir, and Adleman&hell

For the month of June, DevCentral is highlighting our Programmability Month and Codeshare Challenge. A fantastic opportunity to catch up on the power of programmability and learn how the BIG-IP platform can transform your infrastructure with a few lines of code. Since my coding ability is still in the infancy stage, I thought of looking at programmability from a different angle. Can we code a human? First, the word 'Programmability.' According to multiple sources including dictionary.com, it is derived from the adjective ‘Programmable’ or capable of being programmed. As a noun, it can be an electronic device that can be programmed to perform specific tasks. We hear the word Program in many different contexts – a plan of action to accomplish something, a schedule of events, a television/entertainment program, a planned group of activities for a purpose and so forth. In computing, of course, we hear the word programmer as someone who writes code to facilitate certain functionality within a computer program or application. But can code be applied to humans? Are we programmable? DNA is our personal genetic code. It determines our eye and hair color, gender, and all of the traits, characteristics and personality that make you, you. Every cell in our body contains a complete set of our DNA. While 99.9% of the DNA from two people will be identical, it’s the 0.1% of DNA code sequences that vary from person to person. This is what make us unique. This is our genetic marker and what scientists look for to use when doing a DNA test. Genetic disorders are situations where there’s a bug in the DNA code. The gene mutated. For instance, the GLUD1 gene is a Protein Coding gene that encodes mitochondrial enzyme glutamate dehydrogenase (GDH) and is used to control insulin secretion in the pancreas. But if the gene is mutated, then the person could produce too much insulin. The pancreas server works perfectly but it is the gene’s code telling the pancreas what to accomplish that is flawed. My daughter has this genetic disorder – HI/HA GDH. Her GLUD1 code has an insulin bug. Doctors have been able to flip genes. In lab studies, researchers at The Children’s Hospital of Philadelphia have reprogramed gene expression, showing a proof-of-concept for potential therapy. Reprogramming the gene expression to reverse a biological switch. Imagine being able to reprogram a gene to function properly. Diagnosed with a certain ailment? Let’s change the code with an i{Human}Rule to 0. It's also interesting and partially scary to think that in the future, instead of getting colored contacts to change your eye color, you could insert the color code into your DNA for a particular look. And now for something slightly different… In 1942 Nikola Tesla said, ‘If you want to find the secrets of the Universe, think in terms of energy, frequency and vibration.’ There is a frequency or vibration of energy that fills the Universe. It's alive. The Universe is energy and each basic element of the atomic chart consists of energy at different rates of vibration. Each person also has their own frequency. With this in mind, I recently went to have some Quantum Biofeedback ‘new age’ therapy due to some back/neck issues. I already see a chiropractor and acupuncturist and thought this might help me delay back surgery. The idea behind Quantum Biofeedback is that the body is electric and therefore reactivity in the body can be measured electrically since every cell, organ, meridian and emotion has a characteristic electro-magnetic signature. You get hooked up to a few electrodes and it takes a bunch of measurements to determine the electrical factors of the body. It calculates combinations of impedance, amperage, voltage, capacitance, inductance, and resistance. If the frequency of your lungs are off, the system can send the exact frequency of healthy lungs until your lungs respond wi

Researched and co-authored by the F5 SOC and the F5 Security Research team Webinject crafting is a separate profession now. There are people who write webinjects and sell them to fraudsters, who use them to weaponize Trojans. Based on our analysis of several campaigns of Gozi and Tinba, the malware distributors seem to have bought their webinjects from the same webinjects workshop. Although those are different malware families attacking mostly different financial institutions, their webinjects seem almost identical. The tiny differences originate from the fact that the malwares report to different fraudsters’ servers and have fake HTML content customized for the specific banking targets. The main structure of this webinject version comprises several scripts that will initialize the BOTID, fetch external scripts that include the main fraud functionality, and remove the script element from the DOM to cover its traces.   Figure 1: Tinba webinject                                                         Figure 2: Gozi webinject Figures 1 and 2 show the identical parts of the script and the differences in the additional scripts fetched from the command-and-control (C&C) server. Notice that the path structure on the C&C server gives a hint about the attacked country. In this example, the Tinba external script URL has a different domain name and geographical target area, “id” (Indonesia). The Gozi external script is also identified by geographical target area, but it is marked as subfolder name “di” (Indonesia).   Analyzing the external scripts with fraud business logic reveals that same resemblance was present in the webinject. (See Figures 3 and 4.)   Figure 3: Tinba JS content.                                                          Figure 4: Gozi JS content. The Gozi injection has customized, fake HTML content for a Polish bank, but other than that, most of the variables and functions bear the same names and the same logic.   Script Overloading An interesting observation about webinjects from this vendor is that the same resource name on the server may result in different JavaScripts, which are differentiated by the “referrer” header. This means that while the URLs to be injected into the login page and the internal account page will have the same filename, different script content will be returned from the C&C server. The differences in script size are shown in Figure 5. Figure 5:JavaScripts differentiated by referrer header and size.   More complexity to come The profession of webinject crafting is being reflected in Trojan campaigns against banks. We can only guess whether the resemblance between the webinjects is a result of a cooperation or of both fraudsters buying webinjects from the same third party. Either way, a great deal of fraud business logic is now implemented in JavaScript and contained in the webinjects. We expect the complexity of webinjects to increase, along with their roles in successfully committing malicious transactions. This trend is being closely monitored by our researchers. What remains to be seen is whether the “production” of these webinjects, which use shared rather than custom code, increases the risk that more organizations, and smaller organizations, may be attacked. Tested samples: Tinba md5: a01412b41e1837754be907d6989472e5 Gozi md5: e4d8cc25266ae39a

Encryption is a fundamental reality on the Internet today.  Most sites use SSL/TLS for encryption, and you can identify these sites by the https:// in the address bar of your browser.  The Internet security service company Netcraft has been tracking SSL usage for over 20 years now, and their most recent data shows that there are now more than one thousand times more certificates on the web today than in 1996.  DevCentral is no exception to this SSL phenomenon…go ahead, check your browser’s address bar and notice the address for this article (or anything else on DevCentral for that matter) will start with https:// instead of plain old http://.  This SSL/TLS encryption provides a secure means of communication between your browser and the web server.  In order to make all this encryption happen, encryption keys are shared between the web server and your browser.  Encryption key exchange gets very complicated and this article is not meant to explain all the details of encryption key exchange mechanisms, but from a very high-level perspective, it’s fair to say that these keys are shared by using the web server’s SSL/TLS certificate. When a user visits a secure website, an encryption key exchange process takes place, and the resulting encryption keys are used to encrypt all communication between that user and the web server.  A certificate is a digital file that holds several pieces of information related to a particular website.  One of the pieces of information it holds is the public portion of the encryption key used to encrypt all the communications to/from the web server.  Another piece of information it holds is the effective dates of the certificate.  After all, these things are only good for a finite period of time (typically 1-2 years). In a perfect world, a web server would be issued a certificate and that certificate would never get compromised and it would be used for the full duration of the life of the certificate.  But we don’t live in a perfect world.  The reality is that certificates get compromised all the time, and when that happens, the certificate needs to be revoked.  Typically when a web server certificate is revoked, a new certificate is created and used in place of the old, revoked certificate.  But, how does a user know that a certificate has been revoked?  The Magic of CRL and OCSP Here’s how it works…when a user visits a secure website, the certificate is sent from the website to the user’s browser (Chrome, Firefox, Internet Explorer, Safari, etc).  Because certificate sharing creates significant computational overhead, many browsers simply store the certificate information from a previously-visited website in their cache so they don’t have to keep asking for a new certificate each time they visit that website.  This is nice because it significantly speeds up the user experience for loading that particular secure website, but it also presents a problem when the certificate is no longer valid.  In order to check that a given certificate is still valid, the concept of a Certificate Revocation List (CRL) was introduced.  The CRL is a digital file created by a Certification Authority (the organization that creates and distributes certificates) that contains the serial number for each certificate that has been revoked by that CA.  In order for a browser to check that a given certificate is still valid, the CRL must be downloaded and the serial number for the website you are visiting must be checked against the CRL to ensure the certificate is not revoked.  If the certificate is not revoked, all is good and the browser displays the page.  But if the certificate has been revoked, the browser should display a warning page that tells you the certificate has been revoked.  Some browsers will allow you to continue to the page anyway and others won

Many firewalls and IPS solutions will lay claim to DNS application layer gateways (ALGs), but these solutions do not address many of the more modern threats to DNS infrastructure. These threats include DNS DoS attacks, reflection attacks, tunneling, and cache poisoning, to name but a few. Since DNS is largely UDP-based, traditional mechanisms for mitigation based on TCP aren't effective, and source-IP limiting or blacklisting is mostly useless since source address spoofing is trivial with UDP for transport. What these DNS attack vectors require is a highly scalable solution able to inspect the entire DNS query for deeper markers of either good or bad behavior. When it comes to protecting Internet-facing DNS from outside threats, even DNS servers acting as a hidden master to a cloud DNS provider, the first priority is scale. Most DNS infrastructures cannot keep pace with millions of requests per second, and in a DNS reflection attack where requests are often for legitimate records, there is very little facility to differentiate good traffic from bad. In this instance, the available ISP bandwidth may not be exceeded, but the query volume has overwhelmed the DNS server infrastructure's ability to respond. Even a mid-range BIG-IP DNS platform can serve up 1.3 million query responses per second (RPS), as an authoritative screen for your DNS server environment. BIG-IP DNS (formerly GTM) has a proprietary DNS server called DNS Express which enables this massive performance while completely proxying all DNS requests for your DNS server environment. DNS Express isn't BIND, and as such has not shared the same vulnerability surface as the world's most ubiquitous DNS server software. A pair of BIG-IP DNS appliances could easily serve over 2M DNS RPS, while reducing the capacity requirements of the back-end DNS server infrastructure. Adding BIG-IP Advanced Firewall Manager (AFM) enables a range of capabilities for DNS DoS detection and DNS protocol validation to the platform. BIG-IP AFM can detect surges in DNS traffic (which will be handled by DNS Express, if BIG-IP DNS is enabled). DNS protocol validation ensures that DNS requests are not malformed before they are even handed off to DNS Express. Via the DNS protocol security policy, it's also possible to ensure that only supported record types and opcodes. In other words, answer only A record requests and not TXT records, which are a common vector for DoS attacks and DNS tunneling. DNS Express will clean up any NXDOMAIN (non-existent hostname) requests by rejecting those, as the authoritative DNS screen. Completing the picture of a full-featured, application layer DNS firewall are the BIG-IP DNS features such as DNSSEC signing (providing cache poisoning protection), DNS64 translation (improving IPv6 readiness and AAAA record responses), and good old global server load-balancing (GSLB). An overlooked part of the DNS firewall and security challenge is the outbound DNS traffic. Malware - once it has infected/compromised a machine on your network - typically seeks to call C&C (command and control) servers. The malware may be seeking instructions, additional files to complete its installation, or sending stolen data to a drop zone, among other possibilities. The challenge for this malware is finding a path out of the network that isn't blocked or monitored. This is the getaway part of the data-heist. Every corporate network, whether in the data center, or the campus LAN, has a few open ports so that the servers or employee desktops can function. Layer 4 ports 80 (HTTP), 443 (HTTPS), and DNS (53) are probably the three most common. Malware will accordingly be programmed to seek a path out over these ports. DNS will be popular among the malware developers because most networks have some kind of web content filter or gateway (such as a web proxy or BIG-IP SWG), and are well-inspected paths. DNS, on the other hand, is much more difficult to secure. Most outbound DNS a