#RedhatDID: Retrospective and a look ahead to future events

Oct 6, 2016:  The day several Redhat trainers and industry folks met to talk about best practices and give feedback on the vision and mission ( and speed of progression) of Redhat Enterprise Linux (RHEL) and upstream /  downstream projects and products.  Among one of the most popular Sessions was the one by Robin Price and Martin Priesler on OpenSCAP which was a standing room only  session with nearly  1/3 of attendants in attendance for this talk / session.  Rita Carroll and others setup a interest list for those that would like to attend another OpenSCAP Workshop (mainly centered on a hands-on event but other venues seemed open for debate). If you’d be interested regardless of whether you like me were in attendance please email Rita @ rita@redhat.com with a simple subject line referencing OpenSCAP Workshop (Tysons Area).

All slide decks will be up on the RedHatDID site used for registration within the coming week or two ( some presenters were not  Redhat afterall).

The above link has all the info about all 4  tracks presented and the topics, If you would like more info or a company visit on any topic shown ( or maybe something more topical to your organization) feel free to contact Rita or another event coordinator to schedule.

Next Event will be on Nov 2, 2016 at the Ritz-Carlton, Pentagon City, Va  and is FREE for Gov’t folks when registering for the rest of us Industry folks that’s still only $195 for a 8 hr symposium with some of the most authoritative folks in the industry.


LastPass 0Day — Why Using cleartext tokens in the URL is bad practice.

Source: lastpass password manager tell all

This is yet another reason why sanitizing OpenAuth or  other token urls to the minimal allowed to resolve (the hostname) is good practice.

So exactly what is the issue at hand?

Well LastPass as with most password managers that in some way connect to a sync or cloud mechanism,  uses a  cookie of sorts on all sites you setup with autofill ( no typing needed,  great defense against keyloggers),  however the issue is that the parser to determine if such a site is accessed / logged in leaves cleartext tokens in the url and takes a malformed url as username:password @ foo.tld i.e. johndoe/mypassword@facebook.com which allows an attacker on a machine that is logged in (without 2fa –more on this later) to spill the beans about all passwords in 2 ways.

Method 1:  log in or access a machine that is logged in and not locked out (Lock screens are useful folks) to access without any further password/credential prompts the password store and click ‘show password’ and then jig is up.  As alluded to earlier if 2fa (two factor auth) is enabled this is thwarted as it requires that secondary challenge for anything account or password store related.

Method 2: Typing in the username (in plaintext in password store) and the target site and the password becomes visible in plaintext in the url.

The really scary part is that now 2  security researchers have exposed these attacks and its still unpatched.

Original article courtesy of https://www.thehackernews.com

Badlock: Samba Vulns & Patching your machines

Hello again folks,

Unless you are living in a black hole aka SCIF, or otherwise totally disconnected from various news outlets, you have likely heard about the numerous vulns that dropped as a series of CVEs better known as  ‘badlock’ Tuesday. Well, there is good news for those on Redhat based distros! Patches are already in the default repos for Fedora / RHEL / CentOS.

So  a  quick  layman’s rundown and then on to how to patch / update:  (hyperlinks direct to the respective Red Hat Access Customer Portal advisories), below are  tl;dr  briefs of each vulnerability.

For those desiring the more technical read:  Badlock: Red Hat Security Announcement


Multiple flaws were found in Samba’s DCE/RPC protocol implementation in which a condition was created where a remote, authenticated attacker could cause a denial of service against the Samba server (high CPU load or a crash) or, possibly, execute arbitrary code with the permissions of the user running Samba (root). This flaw could also be used to downgrade a secure DCE/RPC connection by a man-in-the-middle (MITM) attacker taking control of an Active Directory (AD) object and compromising the security of a Samba Active Directory Domain Controller (DC).


Several flaws were found in Samba’s implementation of NTLMSSP authentication. An unauthenticated, man-in-the-middle attacker could use this flaw to clear the encryption and integrity flags of a connection, causing data to be transmitted in plain text. The attacker could also force the client or server into sending data in plain text even if encryption was explicitly requested for that connection.

LDAP (with NTLMSSP authentication) is used as a client by various administrative Samba project tools (for example, “net”, “samba-tool”, “ldbsearch”, or “ldbedit”).


It was discovered that Samba configured as a Domain Controller (DC) would establish a secure communication channel with a machine using a spoofed computer name (aka rogue machine). A remote attacker would then in this  scenario be able to observe network traffic to obtain session-related information about the spoofed machine.

This flaw only affects Samba running as a classic primary DC, backup DC, or Active Directory DC.


It was found that Samba’s LDAP implementation did not enforce integrity protection for LDAP connections. A man-in-the-middle (MITM) attacker could use this flaw to downgrade LDAP connections to use no integrity protection, allowing them to hijack such connections.

This flaw affects all possible roles Samba can operate in.

The security advisory patch for this flaw introduces a new smb.conf option: smb.conf

Note: The LDAP server does not have an option to enforce strong 
authentication yet. The security patches mentioned herein introduce a new 
option called ldap_server_require_strong_auth, possible values of which are
 no, allow_sasl_over_tls and yes.

As the default behavior was set to no before, you may have to explicitly change this option until all clients have been adjusted to handle LDAP_STRONG_AUTH_REQUIRED errors. Windows clients and Samba member servers already use integrity protection.


It was found that Samba did not validate SSL/TLS certificates in certain connections. A man-in-the-middle attacker could use this flaw to spoof a Samba server using a specially crafted SSL/TLS certificate. (like the one  made famous recently  known as ‘Drown‘)

This flaw affects all possible roles Samba can operate in.

The security advisory patch for this flaw introduces a new smb.conf option: smb.conf


It was discovered that Samba did not enforce Server Message Block (SMB) signing for clients using the SMB1 protocol. A man-in-the-middle attacker could use this flaw to modify traffic between a client and a server.

This flaw affects the following server roles: standalone server, member server, classic primary DC, backup DC, and Active Directory DC. Samba server roles


An explicit server signing = mandatory configuration option in the [global] section of the smb.conf file together with server min protocol = SMB2, should prevent connections without signing protection. However, this may cause older clients without support for SMB2 (or higher) to not be able to connect.

Patched versions are in default repos: 

4.4.2 (in f24), 4.3.8 (in f23) and 4.2.11 (in f22)


It was found that Samba did not enable integrity protection for IPC traffic by default. A man-in-the-middle attacker could use this flaw to view and modify the data sent between a Samba server and a client. (Very similar to 2016-2114 but  via  a different  packet  modification vector)

The security advisory patch for this flaw introduces several new smb.conf options: smb.conf


An explicit client signing = mandatory configuration option in the [global] section of the smb.conf file.

This flaw affects all possible roles Samba can operate in.

Patched versions are in default repos: 

4.4.2 (in f24), 4.3.8 (in f23) and 4.2.11 (in f22)


DCE/RPC is the specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol. The Security Account Manager (SAM) Remote Protocol (Client-to-Server) provides management functionality for an account store or directory containing users and groups. The protocol exposes the “account database” for both local and remote Microsoft Active Directory domains. The Local Security Authority (Domain Policy) Remote Protocol is used to manage various machine and domain security policies. This protocol, with minor exceptions, enables remote policy-management scenarios. Both SAMR ( security Account Manager –Remote) and LSA (Local Security Authority) protocols are based on the DCE 1.1 RPC protocol.
These protocols are typically available to all Windows installations, as well as every Samba server. They are used to maintain the Security Account Manager database. This applies to all roles (for example, standalone, domain controller, or domain member).


Fedora 22
sudo yum update samba
Fedora 23 / 24 Alpha
sudo dnf update samba
Centos 6 / 7:
 sudo yum update samba

LATE POST: F23-20160408 Updated Lives Availabel (4.4.6-301 + Several bug fixes)

Hello again fellow Fedorians,

Last friday, 4.4.6-301 was deemed stable and we have new updated lives  f23-{i386,x86_64}-{CINN,KDE,LXDE,MATE,SOAS,WORK,XFCE}-20160408.


20160408 Kernel Fixes / Changelog

  • 4.4.6-301


Where to get them? F23 Live-Respins (updated to 20160408/4.4.6-301)

Want to torrent pull? F23 Live Respins (updated to 20160408/4.4.6-301)

No Torrent Hashes ? F23-20160408 ISO Checksums & Torrent Hashes

Want to run a installfest /  have options for  install? F23-20160408 Multi Boot ISO (x86_64 Only) — I can help you create a  Multi Arch or host one elsewhere if desired however with the reduction in i686 installs in this day and age it’s not something I will host normally.

Look out for posts | tutorials  | github repo creation / modifications for  this as well in the coming  week(s).

Git clients & servers need checked. Pre-2.7 bugs.

Courtesy of Laël Cellier we are now aware of  several rather nasty  bugs in  git versions 1.7 -1.9, even tho they were patched in 2.7  (released back in Feb, rather quietly  I may add).  The bugs stem mostly form  signed vs. unsigned  integers in a strcopy function path_name()….  okay so now in layman’s terms what the heck does all that mean?

Essentially  when you have a really long  filename or  repo using files with long names using a older version of  git,  there runs a verifiable risk that you run into what is know as a heap_overwrite   aka  100%+ of  container.


Source:  git-server-client bugs