AMQP Cleartext Authentication
Description The remote Advanced Message Queuing Protocol (AMQP) service supports one or more authentication mechanisms that allow credentials to be sent in the clear. Solution Disable cleartext authentication mechanisms in the AMQP configuration in ubuntu or centos machines disable unencrypted access in the configuration file. >> unencrypted" here refers to client connections. https://www.rabbitmq.com/ssl.html Steps of disabling the AMQP: https://liquidwarelabs.zendesk.com/hc/en-us/articles/360019562832-Disable-cleartext-authentication-option-in-RabbitMQ The above link used for windows vulnerability. Please help in getting resolution for Centos or Ubuntu configuration file.SSL Certificate with Wrong Hostname
SSL Certificate with Wrong Hostname The SSL certificate for this service is for a different host. The commonName (CN) of the SSL certificate presented on this service is for a different machine. Purchase or generate a proper certificate for this service solution provided on other sites : "Purchase or generate a proper certificate for this service." What is the proper solution to go away for this vulnerability from linux machines and how to implement the solution ?
What is HTML Field Obfuscation?
And why do you need to know, anyway? I am so glad you asked! A great deal of app security focuses on the server-side component. Whether comprised of multiple microservices fronted by an API or a monolith, there is no question that a significant source of breaches occurs at the app. This is due to vulnerabilities in the platform, app frameworks (think Spring, Express, or Struts) or application code itself. Many of these apps still present a traditional HTML interface. Even if it’s using Angular or Bootstrap or some other JavaScript framework to create the real-time, interactive experience users crave, it still relies on good old HTML to solicit input from users. Many client-side attacks count on this, and exploit the markup language to great success. Interestingly, F5 Labs research found in its analysis of breaches over the past decade that 86% of the time, apps and identities were the initial target. When most folks hear “identities” it conjures up images of LDAP or ADS or perhaps more modern methods like OAuth. The reality is that before any of that comes into play, first the actual data that comprises an identity – username and password – must be collected. To do that, developers use an HTML element called “input”. The tag “input” is what tells the browser to render a text box so you can enter your credentials. To help keep passwords hidden from prying eyes (that guy reading over your shoulder right now), HTML includes the ability to further specify the type of input you’re looking for. By declaring an “input” element of type “password”, you get some default behavior that automagically masks entered characters. In raw HTML, it looks like this: input type=password name=credential_part_two> Now, that’s cool and all, but attackers know this. MItB (Man In the Browser) attacks inject scripts (or exploit other browser and HTML behaviors) to attach themselves to these fields and slurp up the credentials as users type them in. That’s obviously a Very Bad Thing™ that we want to prevent. Anti-fraud application services are designed to prevent scripts or browser extensions from successfully stealing credentials in this way. To do that, they can use a technique known as HTML Field Obfuscation (HFO). To understand how it works, first you have to see how an exchange normally works. The user requests the login page, and as part of the response, a form is returned containing the elements needed to collect credentials. You can see they are clearly labeled and easily identifiable. Before you get all angrified at developers, remember that a significant concern – especially in the enterprise – is the sustainability of software. That means it has to be clear and written in such a way that when the next wet-behind-the-ears developer is handed the application, they can follow the code and its logic and modify and/or maintain it. We are conditioned not to obfuscate variables precisely because it makes code difficult to follow and more complex than it already is. So please, try not to punch the next developer you see because of this. They’re just following coding standards. Now, obviously the naming and use of HTML types to identify credentials can make it extremely easy for malicious scripts, extensions, etc… to find exactly what they desire most: the credentials. So what we need to do is obfuscate the fields before it reaches the client, and hopefully prevent scanners, skimmers, and loggers from being able to figure out where the credentials are. We do this by inserting an anti-fraud application service into the mix. Essentially, it’s going to act as a proxy to mediate exchanges between the client and the target application and do some magic on the data to obfuscate field names. This is intended to confuse and frustrate attempts to leech off credentials. The request is made exactly the same, and passed on to the application. On the response, the anti-fraud application service quietly replaces specified HTML elements with encrypted versions using a designated private key. It then passes the modified HTML back to the client. The client renders the page as it should and the user sees no difference in the user interface. Only the HTML names have been modified, which only impact client-side scripts and frameworks. The modified page includes a script that ensures that client-side frameworks operate as expected. This technique is designed to confound attacks that rely on identifying target data based on its associated named HTML elements. IT prevents scripts and extensions from latching onto those fields and siphoning off the information. There also exist advanced techniques based on HFO that go beyond just encrypting field values, including the addition of “decoy fields” to distract attackers. No, HFO is not infallible. But it can stop lazy scripts and attacks that rely on easily identifiable field names to extract their digital bounty. HFO allows for frequent, dynamic changes of highly-sensitive form fields without the costs and time associated with modifying the application itself. This maintains the integrity (and sustainability) of the application code whilst providing a layer of protection against attempted theft of sensitive data. Although HFO and related techniques are often tightly associated with protecting financial-related applications, the reality is that all credentials are highly sought-after data today no matter what type of app or service they are for. The credential crisis is real, and so is the need to protect consumers and customers from having their credentials pilfered by malicious actors. Stay safe out there!
Dyre Malware Analysis
Dyre, also known as Dyreza, is a banking Trojan that was first seen around June 2014. With the combination of its ability to steal login credentials by browser hooking and bypassing SSL, its man-in-the-middle (MITM) proxy server, and its Remote Access Trojan (RAT) capabilities, Dyre has become one of the most dangerous banking Trojans. The Dyre Trojan is designed to steal login credentials by grabbing the whole HTTPS POST packet, which contains the login credentials sent to a server during the authentication process, and forwarding it to its own server. The malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup windows, and JavaScript/HTML injections. After all the information has been acquired by the attacker, he can remotely access the victim’s computer using a built-in VNC (Virtual Network Computing) module and perform transactions, data exfiltration, and more. How it works malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup Malware behavior on a Win7-32bit system Surprisingly, the malware behaves differently on Win7-32bit, most likely due to security implementation differences. The method of registering itself as a system service is implemented on WinXP and 64bit systems (tested on Win7-64bit). On Win7-32bit, Dyre operates more similarly to the known Zeus malware by injecting code in the Explorer.exe process and operating from there. Man-In-The-Middle (MITM) Attack When a user enters his bank’s URL in the browser line, the Trojan is triggered and forwards the URL to the corresponding proxy server as stated in its configuration file. · The MITM proxy server forwards requests to the banks and disguises itself as the real user. · The returning response from the bank is intercepted by the proxy server. · Instead of the real response, the user receives a fake login page which is stored on the proxy server, and contains scripts and resources from the real bank’s page. The scripts and resources are stored in folders named after the unique port configured for each bank. · The information entered by the user is sent to the proxy server and then forwarded to the real bank server, allowing the attacker to log in instead of the user and perform operations on his behalf. The fake login page The fake page contains a script called main_new - , which is responsible for handling the objects presented to the user on the fake page and performing the MITM attack. The fake page contains an array of configuration parameters in the header. Some of the more interesting ones are: · ID. The unique identification of the bank, which is the same as the port number in the configuration file. · Incorrect login error. On each login attempt to the bank, the proxy server will forward the request to the real bank’s server and perform the authentication. If the authentication fails, it will also present an error to the user on the fake page. · Block message. If the MITM attack succeeds, the attacker is able to perform a transaction and block the user from accessing his account. This parameter stores the presented message. The F5 Solution Real-time identification of affected users - F5 WebSafe and MobileSafe are able to detect the user is affected by a Trojan and that the information provided by it to the customer is also sent to an unauthorized drop zone. Identification of malicious script injection – once downloaded to the client’s browser, WebSafe and MobileSafe make sure there has been no change to the site’s HTML. If such a change is detected, the customer is notified immediately. Protection against Trojan-generated money transfers - the combination of recognizing affected users, encrypting information, and recognizing malicious scripts is key to disabling Trojans from performing unauthorized actions within the account. WebSafe and MobileSafe detect the automatic attempts and intercept them. Malware research - F5 has a dedicated Trojan and malware R&D team that searches for new threats and new versions of existing ones. The team analyzes the programming techniques and methodologies used to develop the malware in order to keep the F5 line of products up to date and effective against any threat. To get the full technical detailed Malware analysis report click here. To download the executive summary, click here.
Certificate Issue : unable to find valid certification path to requested target
Hello, We deployed a staging e-payment application, using a Virtual Server with these properties : port : https protocol profile : mptcp-mobile-optimized HTTP Profile : XFF SSL Profile : 2 certificates - The issued certificate & a second certificate with Default SSL Profile for SNI SNAT Pool : ip in the same subnet as nodes. Pool : 2 pool members with port 7010 I'm using public certificates (signed by CA Verisign G5 & CA Symantec G4) the web page is displayed correctly, & SSL checks says all is ok (tested with "; & ";) the actual issue is that transaction doesn't pass over https (in http it works fine) here's the error message relived from client side : -An exception occured in HTTPProcess sendMessage. Exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. - doPost exception encountered. Exception: java.lang.NullPointerException. can you support us please?
CloudBleed: Guess What? There was 0-day protection
About CloudBleed If you aren’t familiar with CloudBleed, take a moment to read the following articlesto get an understanding how it was found, what happened, and what PII/PCI data was (possibly) leaked: Vulnerability Disclosure from Tavis Ormandy (@taviso), a security researcher at Google Incident Response from CloudFlare 3rd party assessment from Ryan Lackey (@octal) In some of the examples shown by Tavis, or by digging into cached sites on less popular search engines, you can see how usernames, passwords, sessions, credit card info, etc could be seen in clear text despite the use of HTTPS (TLS1.2). A simplification of the flow would look like this: Request: Client >=====> CloudFlare >=====> Origin Web Server Response: Client <=====< CloudFlare <=====< Origin Web Server Despite the fact that the client is utilizing HTTPS, CloudFlare has the ability to terminate the secure connection since it has the private key. This is essentially the content (PII or PCI) that was being cached if certain conditions occurred on the CloudFlare reverse proxy. 0-day Protection Against CloudBleed So, what is the 0-day protection and what is it all about? Application Layer Encryption is a feature from F5 that would have left researchers scratching their heads when looking at the cached content. First things first, let’s dynamically encrypt sensitive parameter names using Application Layer Encryption. But really, what does that mean? Let’s take a deeper look. In all examples I will be using Google Chrome. Let’s say you have login pagewithoutApplication Layer Encryption. If I were to right click on the Password box and choose Inspect, I would see something like this: As you can see from the red boxes, the parameters for my username and password arelogandpwd. We can all agree that this is in human readable format (HRF). If I were to do the exact same thingwithApplication Layer Encryption, I would see this: In the screen shot above there are 3things I would like to focus your attention on: Both name=log and name=pwd are no longer in HRF. Notice in the first red box that there is a slight purple hue over the value? That’s the dynamic part of Application Layer Encryption. Every few seconds the valueswill change. This is done on the client side, not the server side. That value will never repeat and is completely unique to the user’s session. We also removed the element IDs, id=”user_login” and id=”user_pass”. With Application Layer Encryption turned on, every user will have a unique value for name=log and name=pwd moving forward. We can also turn upthe security a notch by inserting decoy fields to further confuse the bad guys. Decoy fields are only seen in the raw code and do not change the end users experience. As you can see above, there are additional IDs which makes it very difficult to pull apart in a replay attack. But Brian, what about the values being sent!?!!? Let’s look at a data submissionwithoutApplication Layer Encryption from the browservia the network tools in Chrome: As you can see from the picture above, the username is briandeitch and the password is test. Although this is sent via HTTPS, CloudFlare has the private key and this is the type of data that could have been cached by search engines. Yikes! Same exercise but this timewithApplication Layer Encryption: Decoy fields turned off: Decoy fields turned on: As you can see from the form data, both the parameter names and values have been dynamically encrypted on the client side. Let’s say this data was leaked by CloudFlare and cached by a search engine. Couple of points: These substituted and encrypted values are single use, meaning a replay attack wouldn’t work. Good luck reverse engineering any of this. Application Layer Encryption uses private/public key technology and this key, unlike the private key for the SSL Certificate, isn’t hosted on CloudFlare. This means the payload (form data shown above, you know the values for the username and password) is completely encrypted to CloudFlare (or any other proxy for that matter). In addition, the decoy fields are sent as well. Good luck deciphering which fields are mapped to the actual application(s). Personally, my favorite part ofApplication Layer Encryption is that is requires no change to my back end application. This solution requires no installation or modification to the end users web browser, is 100% client-less, and transparent to the end user. At the end of the day, you can still rely on HTTPS for transport layer security however Application Layer Encryption steps up your overall security posture by using cleverobfuscation andencryption to protect your datawhen there is a proxy (MITM device) between your customers andapplication(s). Lastly,Application Layer Encryption is a feature within F5 WebSafe. F5 has taken a complex security enhancement and created a point and click solution to easily protect your application(s). Configuring Application Layer Encryption Step 1: By creating a profile, specify the URIs you want protected. *Note: You are able to use wildcard URIs as well. Step 2: Add theparameters you want protected. The Encrypt checkbox is how we secure the username and password valuesthat are being sent. By encrypting the values, this will prevent replay attacks as the values can only be used once. TheSubstitute Value checkboxsubstitutes the parameter’s value with a random value in the web application while the form is being filled. This also prevents browser based malware fromcapturing keystrokes as they are being entered. The Obfuscatecheckbox encrypts the parameter’s name attribute. Step 2a: If you would like to insert decoy fields to further mess with the bad guys, you don’t have to be a rocketscientist. Relax, it is just a checkbox. Step 3: Associate the new profile to theapplication. That’s it! You have successfully configured and secured your application with Application Layer Encryption. Special thanks to BAM, Todd Morton, Chad Fazio, Jeffery McFerson, Joe Martin, and Ted Byerly for their contributions on this article.MongoDB Service Without Authentication Detection
DescriptionMongoDB, a document-oriented database system, is listening on the remote port, and it is configured to allow connections without any authentication. A remote attacker can therefore connect to the database system in order to create, read, update, and delete documents, collections, and databases. Enable authentication or restrict access to the MongoDB service. What are the steps for the above vulnerabilty on linux server to enable authentication or restrict access to the MongoDB service?
Mazar Bot Overview
Discovered in early 2016, Mazar Bot is spread by sending SMS text messages, via a URL shortener service. Mazar Bot targetedmultiple banks specifically in the German-Austrian region according to attacks that wereencountered in early July 2017. This malware, seen on Android devices,permits itself to access the following device permissions: From Spam to Infection Mazar Bot is used in spam campaigns to gain access to users within a specific region, much like spear phishing. In many cases, the attack isspread via SMS, fake webpages, or email spam. First the malware tricks the user into clicking the link, and then immediately after, the user will face a login page request designed specifically formobile devices. Once the malware has received the needed login information itdisplays installation info and gives an explanation on how to use and install the upcoming application. At this stage users can still question why they should be downloading another app. In order to hide from this suspicion, a php file named “apk-playstore.php” provides some assistance. Mazar Botexplains to the user how to download and use the app. Prompts the user to press the specific link button Gives screen shots that walk through the installation...this allowsthe device to install the application from unknown sources Runsthe application immediately after installation Infection Chain After the malicious application is installed on the end user device, it asks to activate it as device administrator. In most cases the malicious application icon would be deleted and Command and Control communication will commence immediately afterwards. The ongoing communication between device and server would pull device information and look for specific targeted applications. The second stage of communication grants a user infected device with a unique ID for Database maintenance and support of campaign activity. The moment the user would interact with a legitimate bank application, Mazar Bot will cause an overlay and would display another fake page for harvesting more credentials. Interesting observation: Mazarbot (in each of the phishing campaigns) has created tailor-made applications designed specifically to attack a designated bank/organization. For each targeted application, it also creates a specific subdomain, probably for masking and tricking users which were connected to the fake login site. Strings, the C&C connection The interesting part of the apk containssome specific C&C related strings. These strings give an overview of the malware behavior and abilities that it contained. The combination of strings highly support the claim that fraudsters behind the malware plan each campaign specifically for a bank application per campaign. The features presented in the string represent device control and communication interception, allowing access into device cached memory, grabbing personal data, sending SMS, locking device, putting device into sleep mode, reporting and logging all Input/output actions, maintenance of this configuration is represented by unique ID, given by the server. Accepting Credit Cards Additionally, in the strings section, fraudsters are trying their luck by targeting Google play. The overlay that will popup to the user in mid interaction with Google play or Whatsapp, will ask for: Card number CVC Expiration Month+Year Card holder name Credit card type Phone number First, Last Name Phishing SitesStatistics Researched by Kyle Paris According to attacks we've encountered in early July,there wasn't anydistinctive region target for hacked servers. The interesting patterns we did identifywere compiled from groups of 8-10 phishing links with every attack.Each link main domain was slightlydifferent, either by number or a letter, while the subdomain and subfolder remained the same. Here is a table comparing phishing links groups with theirdomain name: Group 1 Group 2 update9091.pw id78087.pw update9092.pw id78086.pw update9093.pw id78080.pw update9094.pw id78084.pw update9095.pw id78083.pw update9096.pw id78088.pw update9097.pw id78085.pw update9098.pw id78089.pw
