SummerCon 2018
Summercon is one of the oldest hacker conventions, and the longest running such conference in America. It helped set a precedent for more modern “cons” such as H.O.P.E. and DEF CON, although it has remained smaller and more personal. SummerCon has been hosted in cities such as Pittsburgh, St. Louis, Atlanta, New York, Washington, D.C., Austin, Las Vegas, and Amsterdam.
[maxgallery id=”9655″]
SummerCon 2018 Recap
SummerCon 2018 was another success this year in New York. Being one of the oldest hacking conventions in America we always like the opportunity to attend and enjoy the vibe.
Armed with some great speaker and topic below, this event kept the attention of the attendees.
https://securityorb.com/Videos/summercon2018.mov
This Year in Crypto
Sometime in the last year, the word “crypto” became a dirty word. While linguists have been focused on debating abbreviation cannibalism in adjacent tech circles, it has also been a quietly interesting year for cryptography. From new theoretical advances in post-quantum cryptography and zero-knowledge proofs, to the discovery of efficient trilinear maps, to the rise of secure transport protocols like TLS 1.3 and secure group messaging proposals like MLS, cryptography nerds have a lot to talk about. This year has also been a challenging year for cryptographic technologies. Vulnerabilities in the software that supports cryptography in the Desktop version of Signal and GPG Tools and the surprising ROBOT vulnerability continued to highlight the fact that “secure” protocols are not secure without secure implementations. In the geopolitical realm, encryption issues have flared up, culminating with Russia’s attempts to block Telegram and major cloud companies deciding to disable domain fronting. This talk will attempt to distill the last year in crypto down to a short talk.
Who X-Rays the X-Rays – A deeper dive into Medical Device Security
The healthcare industry has (finally) woken up to cyber-security. Hospitals are starting to demand cyber-security in new devices and manufacturers are delivering. This is great news for the future – but what about the past and the present? In this talk we examine the current state of cyber security in healthcare. We look at the protocols that are used to transfer information round the networks, and the devices themselves to see how well they would stand up to a modern cyber-attack.
Hack you a Koober Netty for Great Good!
Do you want a koober netty? Or do you already have one? You may even already have many koober netties (pronounced: “kubernetes”). Either way, it turns out that they can be used for more things than just running your Linux containers in the cloud. They can also be used to give attackers access to thousands more computers than just the one running the container that the attacker got a shell in. How cool is that? In this talk, we’ll discuss all of the magical ways that Kubernetes can give attackers access to your entire cluster and cloud environments. We’ll also discuss some ways that it can be made to not do this if making attackers sad is your thing.
Blackhat Ethereum
In the blockchain, there are no secrets. Every transaction is logged and everyone has a copy of all of the code. Nearly all of this code can only be analyzed through reverse engineering. Over the past year, we’ve seen enterprising hackers use flaws in smart contracts to whisk away millions. This was made possible thanks to Ethereum, the technology that powers cryptocats, and Solidity, a high level language that describes Ethereum’s Turing complete smart contracts. This talk will introduce smart contract security, present common vulnerability classes, and demonstrate how to reverse engineer EVM code to identify these vulnerabilities. The talk will also present tools to support vulnerability discovery in EVM code and Solidity.
Exploiting the Exploiters: Hunting Fraud in Telecom Networks
Lurking underneath our increasingly mobile-connected world is a growing fraud problem — one which exposes user data to security and privacy risks. Interconnect bypass fraud has been an issue within telecom networks ever since mobile phones were allowed to roam between countries. GSM Gateways, also known as “simboxes,” are one of the primary keys for criminals to unlock the ability to conduct fraud on these networks.
In this talk, we’ll explore how carriers and aggregators globally send your SMS and voice traffic through these IoT-based devices, which are not subject to any of the security or privacy requirements of critical infrastructure. However, these devices still handle our critical data — both offering a profit opportunity for fraudsters as well as creating a privacy nightmare for mobile subscribers.
Then, we’ll delve into the defensive devices dedicated to heuristic measurements, detection, and destruction of GSM gateways, and the retaliatory countermeasures employed to avoid detection, simulate real subscriber behavior, and outsmart the mobile network operators.
Next, we’ll explore multiple GSM Gateway vendors and the equipment they provide for legitimate — sometimes less-than-legitimate — purposes. We’ll examine how these systems operate and what actual security controls they provide for our voice and signaling data. While we expect stringent controls when data flows through network operators, can we hold the same expectation for these network elements operated in someone’s basement?
Finally, I will propose new techniques to detect, map, and disable these devices remotely, as well as track the operators of these systems — without the pitfalls of relying on heuristic measurements. With these methods, we can begin disrupting the $6b in fraudulent revenue running on the backs of flawed and vulnerable devices.
The New Hotness – Hunting for Code Similarity at Scale
Researching digital espionage involves a steep and unforgiving learning curve. Techniques come in waves, some more promising than others. Be it proprietary sandboxes, YARA retrohunting, passiveDNS analysis, or malware investigation platforms. Entire companies and niche industries have spawned to help researchers further their hunting at scale. The new hotness is code similarity analysis. By honing in on the particularities of the malware developer’s coding conventions and setup, and their lazy reuse of code, researchers can identify clusters of shared activity. At scale, this technique yields fascinating results in otherwise unattributable cases. However, it has also proven a treacherous and uncertain technique, as fringe cases require manual analysis to avoid silly mistakes. And don’t forget, threat hunting involves a puzzle that fights back. Just as we are testing and building up this new technique, adversaries have already begun to subvert its promise and turn it against us. Let’s discuss the secrets and intricacies of this New Hotness.
REVERSE ENGINEERING WINDOWS DEFENDER ANTIVIRUS
Windows Defender Antivirus’ MpEngine.dll implements the core of Defender’s functionality in an enormous ~11 MB, 30,000+ function DLL. Based on months of personal research time spent reverse engineering Defender, I’ll cover my findings on Defender’s dynamic analysis systems, custom tooling that I built to enable my analysis, and various ways that malicious code can give Defender trouble.
Leave your comments if you attended the event.
Web Applications and the Need to Test Them
Web application or often referred to as web app is a program that performs a specific task by using a web browser as the interface or client in a server-client environment. Some common type of web applications you may be already familiar with can be as simple as a chat board, word processor or an online spreadsheet to as advanced as a project management tool or a point-of-sale program to name a few.
What make using web applications so desirable to many organizations is that it lightens the developer of the responsibility of building a client for a specific type of computer or a specific operating system. Prior to web applications, organizations would have to create a client that would operate on a Windows-Based system, Mac-Based system as well as a Linux-based system. At times different operating systems with in the same family would require a different client implementation for example a Windows 7 version and a Windows XP version.
Since web apps operates using a web browser such as Firefox, Safari or Internet Explorer anyone can access the application as long as they have internet access. For the most part any Internet connected device should be able to access the intended web app though some applications require a specific Web browser to operate correctly at times.
I was asked once during a class I was teaching, “Prof. Charles, what is the difference between a website and a web app?” My response mainly stated, a website’s main purpose and function is to provide information to the end user such as http://foxnews.com and http://cnn.com while web apps primary function or purpose is to allow the end user to perform actions such as webmail and online timesheets.
The security issues associated with web apps are that they are connected via the web and anyone can potentially access them. So testing them during the development stage, before they are deployed as well as when they are in production is paramount to the security of the application, users and the organization.
From all indications the trend of increasing use of web applications will continue, creating a bigger landscape for potential application security problems. In fact, data from a web application vulnerability report from 2017 found vulnerabilities in every web application that was analyzed, furthermore, 58% of the web apps that were analyzed had at least one high-severity vulnerability.
The Equifax incident that compromised the personal data of over 143 million Americans is a prime example of what can go wrong when web application security is not continually tested and fails.
There are three main types of application security testing (AST) that are performed against web apps. Each tool tackle the issue of securing web apps from a different perspectives. These three approaches are: 
- Static Application Security Testing (SAST) searches for known patterns of vulnerabilities and defects in the source code.
- Dynamic Application Security Testing (DAST) use known types of attacks against a running instance of the software in production to determine if the software is vulnerable.
- Interactive Application Security Testing (IAST) is an emerging approach that combines static and dynamic techniques to improve testing.
In my next posting, I will discuss SAST, DAST and IAST in detail.
WebGoat 8: An intentionally Insecure Web Application for WebApp Testing
As an instructor, from time to time to teach a concept, I need to perform an actual test to get my point across to the students. Testing or hacking a live site may have some repercussions that I rather not have to deal with, so using an insecure application locally works great for me. I recently using OWASP’s WebGoat to show a bunch of students how to test and location security issues in Web Applications.
WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons.
This program is a demonstration of common server-side application flaws. The exercises are intended to be used by people to learn about application security and penetration testing techniques.
WARNING 1: While running this program your machine will be extremely vulnerable to attack. You should disconnect from the Internet while using this program. WebGoat’s default configuration binds to localhost to minimize the exposure.
WARNING 2: This program is for educational purposes only. If you attempt these techniques without authorization, you are very likely to get caught. If you are caught engaging in unauthorized hacking, most companies will fire you. Claiming that you were doing security research will not work as that is the first thing that all hackers claim.
Instructions:
- Download
- Download the latest WebGoat release from: https://github.com/WebGoat/WebGoat/releases
- Install
- java -jar webgoat-server-<<version>>.jar [–server.port=8080] [–server.address=localhost]
- By default WebGoat starts on port 8080 with –server.port you can specify a different port. With address you can bind it to a different address (default localhost)
- java -jar webgoat-server-<<version>>.jar [–server.port=8080] [–server.address=localhost]
- Access
- http://localhost:8080/WebGoat
Let me know your experience with WebGoat.
OpenVAS Terms to Know
OpenVAS Terms to Know
Host
A Host is a single system that is connected to a computer network and that may be scanned. One or many hosts form the basis of a scan target.
A host is also an asset type. Any scanned or discovered host can be recorded in the asset database.
Hosts in scan targets and in scan reports are identified by their network address, either an IP address or a hostname.
Quality of Detection (QoD)
The Quality of Detection (QoD) is a value between 0% and 100% describing the reliability of the executed vulnerability detection or product detection.
This concept also solves the challenge of potential vulnerabilities. Such are always recorded and kept in the results database but are only visible on demand.
While the QoD range allows to express the quality quite fine-grained, in fact most of the test routines use a standard methodology. Therefore QoD Types are associate with a QoD value. The current list of types might be extended over time.
| QoD | QoD Type | Description |
| 100% | exploit | The detection happened via an exploit and therefore is fully verified. |
| 99% | remote_vul | Remote active checks (code execution, traversal attack, sql injection etc.) where the response clearly shows the presence of the vulnerability. |
| 98% | remote_app | Remote active checks (code execution, traversal attack, sql injection etc.) where the response clearly shows the presence of the vulnerable application. |
| 97% | package | Authenticated package-based checks for Linux(oid) systems. |
| 97% | registry | Authenticated registry-based checks for Windows systems. |
| 95% | remote_active | Remote active checks (code execution, traversal attack, sql injection etc.) where the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible where the detection would be wrong. |
| 80% | remote_banner | Remote banner check of applications that offer patch level in version. Many proprietary products do so. |
| 80% | executable_version | Authenticated executable version checks for Linux(oid) or Windows systems where applications offer patch level in version. |
| 75% | This value was assigned to any pre-qod results during system migration. However, some NVTs eventually might own this value for some reason. | |
| 70% | remote_analysis | Remote checks that do some analysis but which are not always fully reliable. |
| 50% | remote_probe | Remote checks where intermediate systems such as firewalls might pretend correct detection so that it is actually not clear whether the application itself answered. This can happen for example for non-TLS connections. |
| 30% | remote_banner_unreliable | Remote banner checks of applications that don’t offer patch level in version identification. For example, this is the case for many Open Source products due to backport patches. |
| 30% | executable_version_unreliable | Authenticated executable version checks for Linux(oid) systems where applications don’t offer patch level in version identification. |
| 1% | general_note | General note on potential vulnerability without finding any present application. |
The value of 70% is the default minimum used for the default filtering to display the results in the reports.
Severity
The Severity is a value between 0.0 (no severity) and 10.0 (highest severity) and expresses also a Severity Class (None, Low, Medium or High).
This concept is based on CVSS but is applied also where no full CVSS Base Vector is available. For example, arbitrary values in that range are applied for Overrides and used by OSP scanners even without a vector definition.
Comparison, weighting, prioritisation is possible of any scan results or NVTs because the severity concept is strictly applied across the entire system. Not a single severity is just expressed as “High” for example. Any new NVT is assigned with a full CVSS vector even if CVE does not offer one and any results of OSP scanners is assigned a adequate severity value even if the respective scanner uses a different severity scheme.
The severity classes None, Low, Medium and High are defined by sub-ranges of the main range 0.0-10.0. Users can select to use different classifications. The default is the NVD classification which is the most commonly used one.
Scan results are assigned a severity while achieved. The severity of the related NVT may change over time though. Users can select Dynamic Severity to let the system always use the most current severity of NVTs for the results.
Solution Type
This information shows possible solutions for the remediation of the vulnerability. Currently three different variants are available:
Workaround: Information is available about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability. There may be none, one, or more workarounds available. This is typically the “first line of defense” against a new vulnerability before a mitigation or vendor fix has been issued or even discovered.
Mitigation: Information is available about a configuration or deployment scenario that helps to reduce the risk of the vulnerability but that does not resolve the vulnerability on the affected product. Mitigations may include using devices or access controls external to the affected product. Mitigations may or may not be issued by the original author of the affected product, and they may or may not be officially sanctioned by the document producer.
Vendor-Fix: Information is available about an official fix that is issued by the original author of the affected product. Unless otherwise noted, it is assumed that this fix fully resolves the vulnerability.
None-Available: Currently there is no fix available. Information should contain details about why there is no fix.
WillNotFix: There is no fix for the vulnerability and there never will be one. This is often the case when a product has been orphaned, end-of-life, or otherwise deprecated. Information should contain details about why there will be no fix issued.
OpenVAS Authenticated Scan using Local Security Checks
An authenticated scan may provide more vulnerability details on the scanned system. During an authenticated scan the target is both scanned from the outside via the network and from the inside via a valid user login.
During an authenticated scan OpenVAS logs in to the target system in order to run local security checks (LSC). The scan therefore requires prior setup of user credentials. These credentials are used to authenticate to different services on the target system. In some circumstances the results could be limited by the permissions of the user account.
The NVTs in the corresponding NVT families (local security checks) will only be executed if the OpenVAS was able to log in to the target system. The local security check NVTs in the resulting scan are minimally invasive.
OpenVAS only determines the risk level but does not introduce any changes on the target system. However the login by OpenVAS is probably being logged by the target system.
OpenVAS can use different credentials based on the nature of the target. However, the most important ones are:
- SMB
On Windows systems OpenVAS can check the patch level and locally installed software such as Adobe Acrobat Reader or the Java suite.
- SSH
This access is used to check the patch level on UNIX and Linux systems.
- ESXi
This access is used for testing of VMWare ESXi servers locally.
- SNMP
Network components like routers and switches may be tested via SNMP.
Pros and Cons of Authenticated Scans
The extent and success of the testing routines for authenticated scans depend heavily on the permissions of the account used. On Linux systems an unprivileged user is sufficient and may access most interesting information while especially on Windows systems unprivileged users are very restricted and administrative users provide more results. An unprivileged user does not have access to the Windows registry, the Windows system folder \windows, which contains the information on updates and patchlevels, etc.
Local security checks are the most gentle method to scan for vulnerability details. While remote security checks try to be least invasive as well, they might have some impact.
Simply stated an authenticated scan is similar to a Whitebox approach. The OpenVAS has access to prior information and may access the target from within. Especially the registry, software versions and patchlevel are accessible.
A remote scan is similar to a Blackbox approach. Here the OpenVAS uses the same techniques and protocols as a potential attacker to access the target from the outside. The only information available was collected by the OpenVAS itself. During the test the OpenVAS may provoke malfunctions to extract any available information on the used software. The scanner might for example send a malformed request to a service to trigger a response containing further information on the deployed product.
During a remote scan using the scan configuration Full and Fast all remote checks are safe. The used NVTs might have some invasive components but none of the used NVTs try to trigger a defect of malfunction in the target (see example below). This is ensured by the scan preference safe_checks=yes in the scan configuration. All NVTs with very invasive components or which might trigger a denial of service (DoS) are automatically excluded from the test.
Referenced from http://docs.greenbone.net
