DBSecWorx: Database Security Works Principles

DBSecWorx

Think

Home / Blog

Products

[18-June-2021]

In today's Gizmodo there is an article titled: "20 Cool Command Line Tricks for Windows and macOS" in which I found an kindergarten-level Windows 10 hack made possible by the total security incompetence of Microsoft Corporation. I don't focus on Windoze so it was new to me but was not new to colleagues that work in corporate security at a defense contractor.

Here it is so that you can try it then, PLEASE, write about it on Facebook and Twitter and let's see if we can shine a bright enough light that Microsoft fixes the problem. The following listings have been modified in the interest of security but still show how easy it is.

Step 1: Get a list of WiFi connections that are currently or, in the past, have been used. I have highlighted my current connection.

C:\Users\oracle>netsh wlan show profile

Profiles on interface Wi-Fi:

Group policy profiles (read only)
---------------------------------
<None>

User profiles
-------------
All User Profile : iPhoneS
All User Profile : hhonors
All User Profile : iPhone
All User Profile : Oracle23
All User Profile : Queen mum
All User Profile : Hilton Waikiki_Guest
All User Profile : Welcome123
All User Profile : xfinitywifi
All User Profile : Middlethorpe Hall
All User Profile : tokyo marriott hotel
All User Profile : DeltaSkyClub
All User Profile : Verizon-791L-AA7D
All User Profile : Verizon-MiFi6620L-CAE8
All User Profile : Delta Air Lines

Step 2: Retrieve the clear-text password for the named WiFi (highlighted in red).

C:\Users\oracle>netsh wlan show profile Oracle23 key=clear

Profile Oracle23 on interface Wi-Fi:
=======================================================================

Applied: All User Profile

Profile information
-------------------
Version : 1
Type : Wireless LAN
Name : Oracle23
Control options :
Connection mode : Connect automatically
Network broadcast : Connect only if this network is broadcasting
AutoSwitch : Do not switch to other networks
MAC Randomization : Disabled

Connectivity settings
---------------------
Number of SSIDs : 1
SSID name : "Oracle23"
Network type : Infrastructure
Radio type : [ Any Radio Type ]
Vendor extension : Not present

Security settings
-----------------
Authentication : WPA2-Personal
Cipher : CCMP
Authentication : WPA2-Personal
Cipher : GCMP
Security key : Present
Key Content : D63385A73AED2FE

Cost settings
-------------
Cost : Unrestricted
Congested : No
Approaching Data Limit : No
Over Data Limit : No
Roaming : No
Cost Source : Default

That should take an attacker something in the neighborhood of 50 milliseconds to perform.

Brilliant Microsoft, positively brilliant. Which members of your InfoSec team agreed that storing and making passwords available in clear text was a good idea?

[22-May-2021]

Some people apparently wonder whether protection rackets still exist.

Interestingly the definition references "pubs and clubs" because that is where I just found one operating a few minutes ago and decided to again take action to minimize their impact on my life. Here's the way the protection racket works.

To cut costs, especially with COVID19's impact on their business restaurants are encouraged to save money by using a "service" to take reservations online. The company selling the service makes part of their money from the restaurant and part of their money by selling the restaurant's customer list to Facebook, Google, and other advertisers. Here's an example of one of these rackets named "tock"

So, how do I defeat them? Well at least in part? First I connect through a VPN. Then I invent a new person. A person with a different name, a different DOB, and most importantly a throw-away email account that I will never use for any purpose other than making a dinner reservation or perhaps ordering something from a company I will likely never do business with again. You've heard of one-time passwords ... I have, figuratively speaking, littered advertisers with hundreds of one-time email accounts.

Dinner reservation made I can now go out tonight knowing that both Tock and Google, and likely countless others, are writing zeros and ones onto physical drives somewhere and beginning to track someone that will never respond to advertising because they don't have a corporeal existence.

Tired of being a product? Create your very own doppelgänger and let the racketeers track a ghost.

[24-April-2021]

"Another one bites the dust"

"There is no such thing as a free lunch"

And "Avoid single points of failure"

What a complete and total surprise ... our beloved cyber security industry creates a product to sell that is a single source of high value passwords inviting every organized crime group and or state actor to compromise it. And they do. Tell us its not true.

"There is no substitute for Defense in Depth.

A properly configured Oracle Database cannot be compromised with a uid/pwd. Can yours?

[20-January-2021]

DBSecWorx is non-political ... non political but neither blind nor mute. Our inspiration comes not from any single or specific philosophy, theology, political theory, or from what is popular/viral at the moment. Our inspiration comes from those ideas, those beliefs, those theories, that have been tested over time and have proven themselves successful over many hundreds or thousands of years to promote successful outcomes resulting in maximizing sustainable life, liberty, and the pursuit of general happiness.

With that in mind, we wish to remind those that visit our website of a statement most often attributed to one of the planet's greatest minds: Benjamin Franklin.

"we must, indeed, all hang together or, most assuredly, we shall all hang separately,"....

Whether you are pleased or horrified by the outcome of our election here in the United States ... will not change the fact that on a planetary basis ... this statement is, in the Boolean sense, TRUE.

[29-December-2020]

Does the phrase "Transitive Access" mean anything to you? If you are an Oracle DBA probably not. If you are a CISO an upcoming massive headache because databases are not designed to prevent Transitive Access.

One example of a Transitive Access issue is the ability to know that a container exists when you have no privileges to access anything that is within that container.

Consider for example this basic concept. The Oracle DBA responsible for managing a container database should not, by default, have access to review every SQL statement in every container. Something not possible in Oracle 21c as shown in a simple example below.

SQL> sho user

                      USER is "SYS"

                      

                      SQL> sho con_id

                      

                      CON_ID

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

                      1

                      

                      SQL> SELECT banner FROM v$version;

                      

                      BANNER

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

                      Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

                      

                      

                      SQL> SELECT UNIQUE con_id FROM gv$all_sql_plan 
                      ORDER BY 1;

                      

                          CON_ID

                      ----------

                               1

                               2

                               3

                      

                      The following is a small example of what is exposed

                      

                          CON_ID OPERATION                 OBJECT_OWNER    OBJECT_NAME

---------- ------------------------- --------------- ----------- 3 LOAD TABLE CONVENTIONAL UWCLASS ZZYZX OTHER_XML -------------------------------------------------------------------------------- <other_xml><info type="has_user_tab">yes</info><info type="db_version">21.0.0.0< /info><info type="parse_schema"><![CDATA["SYS"]]></info><info type="plan_hash_fu ll">2466432246</info><info type="plan_hash_2">0</info><stats type="compilation"> <stat name="bg">0</stat></stats><qb_registry><q o="2" f="y"><n><![CDATA[INS$1]]> </n><f><h><t><![CDATA[ZZYZX]]></t><s><![CDATA[INS$1]]></s></h></f></q></qb_regis try></other_xml>

At DBSecWorx we know how to prevent this trust violation ... apparently Oracle doesn't know or doesn't consider it important as this example is based on one of a number of new dynamic performance views in 21c.

[28-December-2020]

Oracle 21c has a new Oracle Maintained user: DGPDB_INT.

SELECT dbms_metadata.get_ddl('USER', 
                      'DGPDB_INT') FROM dual;

                      

                      DBMS_METADATA.GET_DDL('USER','DGPDB_INT')

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

                      CREATE USER "DGPDB_INT" NO AUTHENTICATION

                      DEFAULT TABLESPACE "USERS"

                      TEMPORARY TABLESPACE "TEMP"

                      ACCOUNT LOCK

                      

                      

                      SELECT granted_role, admin_option, delegate_option, default_role

                      FROM dba_role_privs

                      WHERE grantee = 'DGPDB_INT';

                      

                      GRANTED_ROLE                   ADM DEL DEF

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

                      PPLB_ROLE                      NO  NO  YES

                      

                      

                      SELECT privilege, admin_option, inherited

                      FROM dba_sys_privs

                      WHERE grantee = 'DGPDB_INT'

                      ORDER BY 1;

                      

                      PRIVILEGE       ADM INH

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

                      CREATE SESSION  NO  NO

                      

                      

                      SELECT owner, table_name

                      FROM dba_tab_privs

                      WHERE grantee = 'DGPDB_INT'

                      ORDER BY 1;

                      

                      OWNER  TABLE_NAME

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

                      SYS    GV_$DATABASE

                      SYS    V_$DATABASE

                      

                      

                      SELECT object_name FROM dba_objects WHERE = 'DGPDB_INT';

                      

                      no rows selected

                      

                      

                      SELECT unique table_name

                      FROM dba_tab_privs

                      WHERE grantee = 'PPLB_ROLE'

                      ORDER BY 1;

                      

                      TABLE_NAME

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

                      DATA_GUARD_SITE$

                      DGPDB_SITE$

                      FOREIGN_REDO_SOURCE

                      ROPP$X$KCCAL

                      ROPP$X$KCCBF

                      ROPP$X$KCCBI

                      ROPP$X$KCCBL

                      ROPP$X$KCCBLKCOR

                      ROPP$X$KCCBP

                      ROPP$X$KCCBS

                      ROPP$X$KCCCC

                      ROPP$X$KCCDC

                      ROPP$X$KCCDI

                      ROPP$X$KCCDI2

                      ROPP$X$KCCFC

                      ROPP$X$KCCFE

                      ROPP$X$KCCFHXCP

                      ROPP$X$KCCFN

                      ROPP$X$KCCIC

                      ROPP$X$KCCLE

                      ROPP$X$KCCLH

                      ROPP$X$KCCOR

                      ROPP$X$KCCPA

                      ROPP$X$KCCPD

                      ROPP$X$KCCPDB

                      ROPP$X$KCCPIC

                      ROPP$X$KCCRSR

                      ROPP$X$KCCRT

                      ROPP$X$KCCSL

                      ROPP$X$KCCTF

                      ROPP$X$KCCTIR

                      ROPP$X$KCCTKH

                      ROPP$X$KCCTS

                      ROPP$X$KCPDBINC

                      ROPP$X$KCVDF

                      ROPP$X$KCVFH

                      ROPP$X$KCVFHALL

                      ROPP$X$KCVFHTMP

                      ROPP$X$PDBHISTORY

                      ROPP$X$RECIDHISTORY

                      RPP$X$KCCAL

                      RPP$X$KCCBF

                      RPP$X$KCCBI

                      RPP$X$KCCBL

                      RPP$X$KCCBLKCOR

                      RPP$X$KCCBP

                      RPP$X$KCCBS

                      RPP$X$KCCCC

                      RPP$X$KCCDC

                      RPP$X$KCCDI

                      RPP$X$KCCDI2

                      RPP$X$KCCFC

                      RPP$X$KCCFE

                      RPP$X$KCCFN

                      RPP$X$KCCIC

                      RPP$X$KCCLE

                      RPP$X$KCCLH

                      RPP$X$KCCOR

                      RPP$X$KCCPA

                      RPP$X$KCCPD

                      RPP$X$KCCPDB

                      RPP$X$KCCPIC

                      RPP$X$KCCRSR

                      RPP$X$KCCRT

                      RPP$X$KCCSL

                      RPP$X$KCCTF

                      RPP$X$KCCTIR

                      RPP$X$KCCTKH

                      RPP$X$KCCTS

                      RPP$X$KCPDBINC

                      RPP$X$KCVDF

                      RPP$X$KCVFH

                      RPP$X$KCVFHALL

                      RPP$X$KCVFHTMP

DGPDB_INT is an internal account used by Oracle Data Guard for the pluggable databases feature (DGPDB) when it is configured using the Data Guard Broker. The account is locked by default and is only unlocked when DGPDB is used.

[27-December-2020]

A new parameter, INACTIVE_ACCOUNT_TIME, was added to the PROFILE in Database 12.2 that made it possible for schemas to be automatically locked by the database after a specified number of days of non-use.

Now, in version 21c, Oracle has introduced another new parameter, PASSWORD_ROLLOVER_TIME that enables an application to change its passwords without scheduled downtime.

Setting a non-zero limit for the PASSWORD_ROLLOVER_TIME profile parameter, new with 21c for an application schema allows the database password of the application user to be altered while allowing the older password to remain valid for the time specified by the PASSWORD_ROLLOVER_TIME limit.

During the rollover period, the application database schema can be accessed using either the old or the new password. When the
rollover time expires, only the new password is allowed.

In addition to the new clause PASSWORD_ROLLOVER_TIME in the CREATE PROFILE and ALTER PROFILE statements, ALTER USER has a new EXPIRE PASSWORD ROLLOVER PERIOD clause. The ACCOUNT_STATUS column of the DBA_USERS and USER_USERS data dictionary views have several new statuses indicating values to indicate rollover status.

If you are still creating users the legacy way, not using NOAUTHENTICATE and PROXY users this new capability is a game changer. For those that are using recommended security practices for creating users this new parameter is not necessary.

[26-December-2020]

We've held off commenting about the SolarWinds breach for awhile because the noise level, the amount of meaningless speculation, was precisely where we would expect it to be on a planet where "news" has become the province of 24 hours news organizations, and politicians, that feel the need to talk first, think later.

Again, a major breach, again, the focus is solely on firewalls, networks, and end-points, again not a single mention of the databases that were the target. Again, Defense-In-Depth too esoteric to mention.

The question that should be asked, though not necessarily in public, is what organizations were attacked ... and because they implemented Defense-in-Depth ... suffered minimal or no zero losses because the targeted data could not be accessed even after the network was penetrated.

A successful defense strategy MUST be capable of denying access even when the user has valid credentials. If you don't know how to do that consider contacting us.

[12-December-2020]

Oracle 21c security update.

The following security issues are not "new" to version 21c but they also have not been fixed in 21c.

SQL> SELECT privilege

                        2  FROM dba_sys_privs

                        3  WHERE grantee = 'CONNECT';

                      

                      PRIVILEGE

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

                      SET CONTAINER

                      CREATE SESSION

SQL> SELECT privilege

                        2  FROM dba_sys_privs

                        3  WHERE grantee = 'RESOURCE'

                        4  ORDER BY 1;

                      

                      PRIVILEGE

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

                      CREATE CLUSTER

                      CREATE INDEXTYPE

                      CREATE OPERATOR

                      CREATE PROCEDURE

                      CREATE SEQUENCE

                      CREATE TABLE

                      CREATE TRIGGER

                      CREATE TYPE

There is no reason why any user should ever be granted either of these two roles but especially risky is the addition of SET CONTAINER to the CONNECT role. "Best Practice" is to grant CREATE SESSION and to never grant the CONNECT role.

[11-December-2020]

[11-December-2020]

Oracle 21c has been released in the OCI Cloud and the DBSecWorx team is working to detail the major and other security issues as they impact this new release.

Here are the items already on our list

Centrally managed wallet support
Database clients can be configured to maintain multiple SSL sessions using different certificates
DBMS_CRYPTO_TOOLKIT is desupported
DBMS_CRYPTO_TOOLKIT_FFI is desupported
DBMS_CRYPTO_TOOLKIT_TYPES is desupported
DBMS_OBFUSCATION_TOOLKIT is desupported
MD4 is deprecated
MD5 is deprecated
Oracle Wallet Manager is deprecated
Password file forced upgrade to case sensitive
SHA-1 for dbms_crypto is desupported
SHA-1 for SQL*Net is desupported
STIG compliant Unified Audit Policies are predefined
User Application Roles view has been enhanced to show roles granted

This is not, by any stretch of the imagination, a complete list. This list will be updated as our work proceeds.

[23-November-2020]

Cisco intentionally delivering malware.

We have identified a malicious software in the wild and it is one that likely most of our readers have installed on their work computers. It is Cisco Webex Meetings.

The exercise started out innocently enough. We found 2 hidden application windows on a Microsoft Windows 10 laptop and closed them. They restarted in a few ticks of the clock. After observing this a few times the decision was made to delete the application. Next step: Start menu > Webex > Uninstall. "Uninstalled", closed the windows ... they restarted. Rebooted the laptop ... they restarted.

Opened Windows services. Disabled the Webex service. Rebooted. They restarted.

When a user requests software to uninstall itself, and it doesn't that is, by definition, malicious behaviour so it was time to remove everything Cisco from the laptop and what we found was a large number of directories and files under C:\Users\<username>\Webex ... most of them, DDLs and an autostart executable, were locked so that they could not be easily removed.

Opened process explorer ... killed all processes owned by Cisco. Dropped everything on the laptop in a directory with the name Cisco or Webex. Went into the registry ... took care of business ... rebooted.

Killed Cisco and we are now removing them with malice aforethought from every device in the company.

Cisco, which part of installing software without permission do you think acceptable?
Cisco, which part of not uninstalling software in violation of your own written Terms of Service do you think acceptable?
Cisco, which part of DBSecWorx not renewing its contract with you when it expires in 2021 will surprise you?
Because, absent an explanation and a written apology, this blog post stays, we inform our customers, and we cancel our service.

[09-November-2020]

DBSecWorx Managing Partner, Daniel Morgan, is pleased to have been selected as a member of the Oracle Database Security Partner Advisory Council for 2020

If you have a database security related issue you would like brought before the council please email or phone me.

[12-October-2020]

One of the most amazing things in our business, when looked at from the standpoint of security, is why architects and coders insist on naming things in a vacuum. Look at the following example of this from the standpoint of "how stupid can an attacker be?"

The screen capture comes from an Ars Technica article [linked].

If you are trying to attack a target why would you name an intent with the word "WIRETAP"?
I suspect either a lack of brain engagement or too much Dexamethasone.

If you have credit card information in a table why would you name the table customer_credit_cards and have columns named "ccno", "expdate", and "ccvno" unless you are on the payroll of the Central Bank of the People's Republic of North Korea?

The last time I created a table holding customer credit cards the table name began with "INVALID_", the expiration date column was named "EXPIRED_DATE" with all dates altered by subtracting n days from the real date, and the CCV number ... well I'm not giving away all of my secrets in a blog.

Was there a table named "CREDIT_CARDS"? Of course there was. And every entry in it was generated with an algorithm designed to create data that looked valid but wasn't. LOL

[27-September-2020]

Oracle Database Audit-of-the-Day: Writes Every DDL statement to the ALERT log.

CREATE OR REPLACE NONEDITIONABLE TRIGGER "SYS"."DDL_TRAP"

                    AFTER DDL

                    ON DATABASE

                    DECLARE

                     sql_text ora_name_list_t;

                     n NUMBER;

                     x VARCHAR2(30);

                    BEGIN

                     
                    n := ora_sql_txt(sql_text);

                     
                    x := ora_login_user;

                    

                     
                    dbms_log.ksdfls;

                     
                    dbms_log.ksdwrt(2, 'DDL: ' || sql_text(1));

                     
                    dbms_log.ksdwrt(2, 'By: ' || x);

                    END ddl_trap;

                    /

                    

                    ALTER TRIGGER "SYS"."DDL_TRAP" ENABLE;

[26-September-2020]

Oracle Database Hack-of-the-Day: Reads TNSNAMES.ORA from inside the database using PL/SQL

SELECT dbms_isched.get_tns_nvpair('PDBDEV') FROM dual; DBMS_ISCHED.GET_TNS_NVPAIR('PDBDEV') ------------------------------------------------------------------------------------ (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = pdbdev)))

[24-July-2020]

Can anyone guess which products were victimized without reading the article?

Hint: None of them were Oracle.

[19-July-2020]

"Facts are stubborn things."

~ Samuel Clemens (Mark Twain)

[27-June-2020]

#StopHateForProfit

There is no other place in the entire universe.

The only alternative to learning how to work together
Is to die together.
The few remaining survivors won't have to worry about politics
Because there won't be any.

#MakeAmericansThinkAgain

Hate is not a left-wing, right-wing issue, it isn't a liberal democracy vs plutocracy vs dictatorship issue. It is an existential issue.
If we don't "Stop Hate for Profit" the next generation will be the "second wave" living in caves.

[13-May-2020]

Waste of time #1: Seems like this blog is as good a place as any to start posting comments about actions promoted as enhancing security that are a total waste of time. To start this feature let's start with some advice that is so ubiquitous it might appear to have value: But it doesn't.

The source of this that came to my attention this morning is from an Oracle University security class module titled: "Securing Network Services" in the form of the following slide.

Another source of this advice is a very reputable thus also lending credibility to this advice: the Center for Internet Security's Security Configuration Benchmark.

At first glance this might look like reasonable advice but here's why it isn't:

While "security by obscurity" is known to provide a false sense of value the opposite is not true.
Just because "everyone knows something, not doing it does not necessarily provide value.
When advice like "Don't use port 1521 becomes the norm, those attacking system will approach each new target
with tools that do not assume the port will be 1521.
Thus, the critical question is "how long does it take to identify the actual listener port if it is relocated from 1521"?

And the answer to that question is measurable in milliseconds.

DBSecWorx does not reveal information not readily available through a search engine so the following will illustrate how an attacker might find the actual listening port but is not optimized in the manner a sophisticated attacker would likely use.

[oracle@gg00a dirprm]$ netstat -lntu

                      Active Internet connections (only servers)

                      Proto Recv-Q Send-Q Local Address   Foreign Address State

                      tcp        0      0 0.0.0.0:5801    0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:5901    0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:111     0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:6001    0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:56754   0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:22      0.0.0.0:*       LISTEN

                      tcp        0      0 127.0.0.1:631   0.0.0.0:*       LISTEN

                      tcp        0      0 127.0.0.1:25    0.0.0.0:*       LISTEN

                      tcp        0      0 0.0.0.0:633     0.0.0.0:*       LISTEN

                      tcp        0      0 127.0.0.1:2207  0.0.0.0:*       LISTEN

                      tcp        0      0 127.0.0.1:2208  0.0.0.0:*       LISTEN

                      tcp        0      0 :::47406        :::*            LISTEN

                      
                      tcp        0      0 :::1521         
                      :::*            LISTEN

                      tcp        0      0 :::6001         :::*            LISTEN

                      tcp        0      0 :::22           :::*            LISTEN

                      tcp        0      0 :::7809         :::*            LISTEN

                      udp        0      0 0.0.0.0:5353    0.0.0.0:*

                      udp        0      0 0.0.0.0:111     0.0.0.0:*

                      udp        0      0 0.0.0.0:627     0.0.0.0:*

                      udp        0      0 0.0.0.0:630     0.0.0.0:*

                      udp        0      0 0.0.0.0:631     0.0.0.0:*

                      udp        0      0 0.0.0.0:34070   0.0.0.0:*

                      udp        0      0 0.0.0.0:68      0.0.0.0:*

                      udp        0      0 0.0.0.0:45534   0.0.0.0:*

                      udp        0      0 :::5353         :::*

                      udp        0      0 :::49517        :::*

                      udp        0      0 ::1:63872       :::*

                      udp        0      0 ::1:39693       :::*

                      udp        0      0 :::59798        :::*

                      udp        0      0 ::1:19812       :::*

Try also netstat -a.
for another readily available view of open ports and their as

It took at most a few milliseconds to find the line showing port 1521 in use. But assume that the port had been changed to 1635. Even an unsophisticated attacker would immediately exclude the UDP ports and have to, at most, try the 16 TCP ports. With a little shell scripting that would, again, take milliseconds. Delaying an attacker by hours or days might have value. Delaying an attacker by milliseconds is a complete waste of time.

Our conclusion: You should absolutely change your default ports from 1521 to another port outside of the 1520 range. Doing it will not provide you with any additional security. But do it because it will make your CISO and the auditors happy.

[25-April-2020]

It has been one of those days ... during one of those weeks ... during one of those months ... during one of those years ... and that has nothing to do with politics or Covid19.

To hopefully lift at least someone's spirits these are my contributions to the "unusual times" that is 2020.

SQL> exec dbms_rcvcat.sanityCheck;

                          BEGIN dbms_rcvcat.sanityCheck; END;

                          *

                          ERROR at line 1:

                          RMAN-20021: Database not set

                          ORA-06512: at "RMANADMIN.DBMS_RCVCAT", line 10066

                          ORA-06512: at "RMANADMIN.DBMS_RCVCAT", line 10027

                          ORA-06512: at line 1

SQL> exec dbms_internal_logstdby.cancel_future;

                          

                          PL/SQL procedure successfully completed.

I figured, having failed the sanity check, there was no choice but to execute the second procedure.

[04-April-2020]

For everyone that thinks they can protect data and databases with a firewall and end-point monitoring ... consider how just a month ago you thought you didn't need to pay for extra beds in hospital ICUs with extra ventilators.

Our ability to protect data and databases is not better than our ability to stop a viral pandemic: The two are quite comparable.

If you can take a minute out of the day to sanitize your hands ... can't you spare a day to sanitize your inputs?

[29-March-2020]

Thank you Jack ... we appreciate that someone noticed.

We also appreciate all of the other essential workers; most of whom are not paid in accordance with their value to society, but rather based on how little the self-centered and greedy can get get away with paying to them. None of us, in IT, should forget that one basic component of why we are paid as much as we are is that we facilitate making others unemployed.

Be sure that you say thank you to those people in your life who you don't normally say thank you to who are risking themselves every day to make it possible for you to not just survive, but to thrive.

Like, for example, cartoonists that so often bring more intellect, more understanding, and more clarity to an issue than all of the talking heads that are paid so much more.

[04-February-2020]

Experiencing a time warp.

Some time last year I found myself on a flight from Minneapolis to Seattle traveling home from the UK and captured this picture from the seat-back display.

At 12:33am I am traveling a distance of 18 miles from Minneapolis to Seattle and it will take 7 hours, 10 minutes.

Six minutes later at 12:39am, clearly the result of a close encounter with a black hole, the time to travel between Minneapolis and Seattle has been reduced by by four miles and the travel time by almost 4 hours.

An additional 20 minutes has now elapsed and the curvature of space time has increased the separation between the two cities by 131 miles without affecting the travel time.

Clear proof of DSR, the theory better known as Delta Special Relativity and understood by only to a few of members of an elite group of mathematicians and physicists at Princeton, CalTech, Cambridge, the Perimeter Institute and those that studied at tahiti.oracle.com before it was swallowed by a black hole.

[03-February-2020]

I note in today's news that Stephen King has quit Facebook. And, in reading his public statement, I realize that I never made a formal announcement many years ago when I closed my accounts with both Facebook and Twitter. Seems like as good a moment as there will be to make up for lost time.

It is amazing that in the year 2020 I feel a need to write this but throwing away caution about writing a "good old days blog post" I will say what needs to be said.

When we look back at what happened to the Roman Empire, about how it collapsed, it is hard not to wonder why the army enabled the destruction of essentially all of European civilization for one man. History is full of parallels where civilizations and citizens have surrendered themselves to one person, or a small self-appointed group, who's only claim to fame was their political or military power.

So where are we today? We have surrendered an overwhelming percentage of our ability to communicate as a civilization to a couple of individuals. Let's name them: Mark Zuckerberg, Jack Patrick Dorsey, Larry Page, Sergey Brin.

Thus I made the decision to refuse, to the extent that it is still possible, to be bought and sold as a commodity by them. How hard was it to close my accounts? Took only minutes. I sent my friends my human contact information ... my phone and personal email ... and I have never, not for even a minute, regretted the decision.

If you don't want to trade that which is "you" for a the deception that there is a free lunch or a free service consider doing so too.

Google, I heard your meaningless code of conduct public relations stunt: "Don't be evil."
Clearly you sold your souls and ours along with them.

I prefer my personal code of conduct: "Don't be the tool of evil."
And that is why I won't buy any product or service they offer.
Not from Google, not from Amazon, not from Facebook, not from Twitter. And, not from others like them.

[12-January-2020]

Oracle Database Version 20c will be released soon. Do you have experience with deploying, securing, managing, troubleshooting, and performance tuning a Container (CDB) Database?

Are you planning for your next job to be at Starbucks?

It is time, today, to start investing in your skill set because the legacy architecture will be unsupported in 20c and beyond ... that's 2020 ... that's this year ... that's just a few short months from now.

The new SQL Macros are cool but if you do not understand the security compromise Oracle introduced into the CONNECT role or secure a PDB how are you going to competently do your job?

The Chinese, the Russians, the Iranians, the North Koreans, and organized crime families all over the planet are investing time and money into breaching your organization's firewall, hiding from trip wires and auditing, spray painting and phishing. And, judging from the number of successful attacks in 2019, they are doing a very good job at it.

So in 2020, precisely what are you going to do to protect your data and your database?

Are you prepared to protect against the legacy glogin attack that dates back to the 1980s? Are you up to speed on every default deployment weakness in Oracle Profiles, Roles, and System Privilege grants? Would anyone in your organization have a clue what was going on if someone started using DBMS_SYS_SQL?

To advance your career and protect your organization contact us today for a free (no charge, no hassle, no sales pitch) technical Lunch & Learn for your team. You can arrange it with nothing more than an email to damorgan (at) dbsecworx.com.

[07-January-2020]

If you are not having discussions now about moving past SHA1, if you are not budgeting time and money for a solution,
you are late to the party. As Ars says, they declared SHA1 officially dead three years ago.

[01-January-2020]

Another example of why it is not sufficient to implement a feature or option. You must know how it works a dig deeper than just what is in the docs.

[05-December-2019]

We have been reading up on the Dunning-Kruger Effect. And, if you know you are not well versed in database security, you may not be experiencing Dunning-Kruger in at least one domain.

But to help you understand your coworkers ... click on the link, above.

Here are the first two sentence from the well written Wikipedia listing:

"In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability."

We consider this mandatory reading.

[02-December-2019]

Thank you xkcd

[16-November-2019]

Does the organization you work for train the staff on what phishing and spear phishing are?

Most organizations pretend they do ... others really do.

Does it make a difference?

Apparently not!

Of course the solution is the one we recommend here at DBSecWorx.

Stop focusing solely on what has been proven repeatedly does not work.
And take the steps necessary to secure the data and the databases.

[08-November-2019]

This Blog post should serve as a warning to each and every person installing and administering Oracle Databases. The following listings were extracted from the .bash_history file after an Oracle Database 12.1.0.2 installation.

The database name has been changed to protect the guilty.

The most offensive of security violations are highlighted in yellow.

netca -silent -responseFile /u01/stage/database/response/netca.rsp

                    

                    dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbname secdemo -sid secdemo -responseFile NO_VALUE -characterSet AL32UTF8 -nationalCharacterSet AL16UTF16 -
                    sysPassword Oracle123! -systemPassword Oracle123!
                    -recoveryAreaDestination "/u01/app/oracle/fast_recovery_area" -createAsContainerDatabase true -automaticMemoryManagement false -storageType FS -datafileDestination "/u01/app/oracle/oradata/" -redoLogFileSize 50 -emConfiguration NONE -totalMemory 6000 -ignorePreReqs

                    

                    clear

The initial password was ridiculously insecure. And I wouldn't be writing this but for the fact that the initial password was not changed allowing me to break into the database in a matter of seconds.

If you install any Oracle software, anywhere, and do not immediately change every password you should consider saving the attackers the effort of figuring out what you did and just post a notice on Facebook, Twitter, and LinkedIn.

If you have Oracle databases, as soon as you finish reading this blog post, check the .bash_history files on every UNIX server in your operation for the -sysPassword and -systemPassword strings. Verify that the passwords in .bash_history do not work.

Note to Oracle Corp.: This is not a feature ... this is a sloppy nightmare.

[05-September-2019]

DBSecWorx is non-political and hopefully rational. So we present the following quote from Hugh Grant (@HackedOffHugh) August 28, 2019 not in context but because it demonstrates an eloquent and professional employment of the English language in a manner rarely seen and sorely missed. Formatted, as it deserves, as poetry.

You will not fuck with my children’s future.
You will not destroy the freedoms my grandfather fought two world wars to defend.
Fuck off you over-promoted rubber bath toy.
Britain is revolted by you and your little gang of masturbatory prefects.

We will know that we are again teaching the language of Shakespeare when this manner of speech is not unusual. And we say that even with the understanding that on occasion we may be the recipients.

[30-August-2019]

It is looking like one blog post at the beginning of the month, one at the end. It has been a very busy month between a trip to Johannesburg South Africa, one to the San Francisco Bay area for the NoCOUG fall conference, and a couple of weeks in Austin Texas with Oracle.

This month the following new pages were added here at DBSecWorx and we know you will want to review them to learn more about real-world exploits that work in the wild.

On August 19 a page of Oracle Initialization (Startup Parameters) was entered into the Resources Code Library. You will want to review each of these parameters to determine if they are properly configured in your databases.

And today we added exploit demos you can use to teach yourself the NoSpaces, Base64, and RAW Encoding exploits. With permission from your CISO and management use these exploits to determine whether your security processes and techniques can catch an attempt to use them as part of an attack.

This website will never provide information on zero day attacks. The NoSpaces, Base64, and RAW Encoding attacks are commercially as exploit toolkits available for sale on the dark web. So, if you are unaware of them, that is the issue we are trying to address here at DBSecWorx. The bad guys have known about these for years.

[01-August-2019]

A few days have passed, some information originally reported has been demonstrated to be incomplete and additional pieces have been added to the puzzle. We will leave our posting from 30 July as it was written and amend and append.

One thing we have learned that we didn't know before was that the data exfiltrated was in "the Cloud" and not in CapOne's own data center. That information explains a lot about how the attacker, a former Amazon resource, knew what, where, and how to accomplish the theft. It is also inline with the overwhelming majority of successful attacks which are perpetrated either by, or with the assistance of insiders. We have no doubt she wouldn't have even attempted the attack if she didn't have sufficient information, in advance, to be quite confident of success.

The second item explained by the data being at Amazon is what it was doing in a mySQL database. We had assumed Oracle because CapOne has a lot of Oracle databases and it would be reasonable to think CapOne's CISO would have had sufficient expertise to not move PII data into Amazon's cloud and from database with full featured security to one with almost none. Clearly our expectations were too high.

Ask Amazon how they protect their Cloud and they will refuse to provide any meaningful answers, any specifics. Is that because they believe in security by obscurity ... or is it because they would be embarrassed to have to put in writing the current state of their affairs. We know the answer and expect you will not require a PhD in quantum mechanics to come to the right conclusion on your own.

One last note before we give this story a little more time for additional non-public information to become public so we can comment on it. That last note is with respect to so-called "At-Rest Data Encryption" that it appears CapOne paid for. At-Rest Data Encryption is an IQ test for auditors that they fail every day. At-Rest Data Encryption has not protected a single byte in the last decade. Let's examine what it does and doesn't do.

"At rest" means that the data, when the database is "at rest" (which roughly equates with shut down) is encrypted. Anyone with a valid login credential has access to the unencrypted data without needing to know the encryption algorithm or anything about keys, seeds, padding, chaining, etc. So, if you don't know how to decrypt it ... just need a user-id ... the encryption is of zero value (except that auditors are too ignorant to know that as noted above).

There are only 2 possible scenarios in which at rest encryption has value. Consider how likely they are:

The attacker shows up at the data center and with guns drawn breaks in, gets to the SAN, puts all of the physical storage devices on a hand truck and escapes out the back door before the police arrive. Well yes they could possibly use a fork lift to move the entire SAN out to the loading dock, drive it somewhere else and plug it in, but what are the chances of that?
The attacker is a storage or system admin that decides to go into a SAN with hundreds to thousands of TB of data striped and mirrored across many hundreds of physical devices, capture data from a 64K or 1MB stripe using the STRING command, all the time following a stripe from one physical device to another.

You figured this one out without that PhD too, didn't you? LOL
But can you figure out why Boards and C Level execs can't? Neither can we.

[30-July-2019]

The truth, ~~the whole truth~~, and nothing but the truth.

If you believe this pile of rubbish you shouldn't be allowed to touch a keyboard. "Exploit a configuration vulnerability" ROFLMAO.

Yeah, sure, Capital One stored data on 106 million people inside of a configuration vulnerability.

Let's try a small dose of reality.

First the attacker gained access to the network ... how?
Which firm did CapOne hire to perform a pentest that failed to identify the vulnerability?
Then the attacker somehow stumbled on login credentials that would provide access to the correct database and schema.
Does CapOne use Multi-Factor Authentication? How was that compromised?
Then the attacker found her way through thousands of infrastructure components to the right database. How?
Then not a single control prevented the attacker from querying 100,000,000+ rows of data from the right tables and columns.
Then the attacker exfiltrated the data out of CapOne's data center.

And we are asked to believe all of this the result of a single configuration vulnerability. Total rubbish.

Richard D. Fairbank, Capital One's founder, chairman and CEO, has a lot to answer for. But, unfortunately, newsrooms worldwide will abrogate their responsibility and "repeat" not "report". Repeat superficial fluff from a PR desk rather than report on how, for a very small investment, CapOne could have prevented the entire mess.

Safe computing requires diligence.
Safe computing requires well thought out processes and procedures.
Safe computing requires management invest in more than just a firewall.
Safe computing requires defense in depth.
Safe computing requires not relying on sales account execs to solve problems they don't even understand.
If you don't know that data is stored in databases.
If you don't know how to attack a database and compromise a database.
You haven't even a prayer of being able to prevent an attacker from being successful.

CapOne's management failed.
CapOne's IT leadership failed.
And I'll bet there are many members of CapOne's IT technical staff who have been warning their immediate management for years.

Most likely, CapOne's Board will now fail again ... not because they are irresponsible and don't care ... but rather because they will rely on some company to sell them a magic bullet.

Unsolicited advice to CapOne ... if the company you hire can't answer the following question you deserve what you get.
Q: "List and explain all of the security flaws in the Oracle Database DEFAULT profile."
A: I count 17 separate issues.

[29-July-2019]

Take a close look at the email I just received. It is the second one in the series. Clearly the intent is to get someone to click on the link. There are a couple of things that alerted me with the first message:

I was not expecting a package
The lack of a logo
The lack of label number, phone number, and other information in the body of the email
There was no need for an attachment
The fact that I was present at the location and no sticker was left on the door from the attempted delivery
American companies don't write "29th July" ... an American company would have written July 29, 2019
The fact that the attached file is a .IMG and is 1.2MB ... no status notification requires 1.2MB of anything

The biggest single factor in my not responding to the first attempt to trick me was simply that the information required for me to contact DHL could have been included in the email text ... there was no need for an attachment. The fact that I knew no attempt to deliver and there was no sticker on the door was confirmation.

This email repeats those same mistakes but makes an additional one that is equally egregious. As I type this entry into my blog, and post it to our website, ... 2:30pm on 29 July is 5 hours in the future.

Safe computing requires diligence. If you might have been tempted to click on the email you need to study the warnings signs I listed above. A click on the link would have infected your computer.

[24-July-2019]

[18-July-2019]

What is it going to take for people to come to what seems like an obvious conclusion. Nothing is free. If you expect to be paid for your work why are you so willing to accept that others write software for you for free? To read the full article [Click Here].

[16-July-2019]

[09-July-2019]

Anyone familiar with DBSecWorx knows we are complete unamused by those that think security consists of an expensive firewall, an identity management system, and end-point monitoring. For those that are open to learning from past mistakes ... here is another lesson. At your leisure look up NTLM Brute-Force (CVE-2019-1126) ... and while reviewing the lengthy explanation consider the value of securing data and databases. In all of human history there has never been an impenetrable wall.

[23-June-2019]

[21-June-2019]

Oracle and Backward Compatibility

At almost every Oracle Security Master Class I teach I find multiple students wondering why Oracle doesn't "just fix" some of the more obvious security flaws and other anomalies and I explain that Oracle puts great value in backward compatibility: In not breaking existing customers. One example I use to illustrate that point is that DBA_TAB_PRIVS contains all object privileges ... not just those related to tables as the name implies. As to why there is a view named DBA_TAB_COLS and another named DBA_TAB_COLUMNS ... perhaps that one needs to be addressed by Mr. Ellison.

Tonight while updating the Morgan's Library website I found what must be the most poignant example possible of the value Oracle places on backward compatibility. I couldn't make this up so the following is copied (I added the highlight) from $ORACLE_HOME/rdbms/admin/dbmsssql.sql from version 19c.

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

                -- Named Datatype CONSTANTS

                --

                Varchar2_Type                constant pls_integer := 1;

                Number_Type                  constant pls_integer := 2;

                Long_Type                    constant pls_integer := 8;

                Rowid_Type                   constant pls_integer := 11;

                Date_Type                    constant pls_integer := 12;

                Raw_Type                     constant pls_integer := 23;

                Long_Raw_Type                constant pls_integer := 24;

                Char_Type                    constant pls_integer := 96;

                Binary_Float_Type            constant pls_integer := 100;

                Binary_Double_Type           constant pls_integer := 101;

                MLSLabel_Type                constant pls_integer := 106;

                User_Defined_Type            constant pls_integer := 109;

                Ref_Type                     constant pls_integer := 111;

                Clob_Type                    constant pls_integer := 112;

                Blob_Type                    constant pls_integer := 113;

                Bfile_Type                   constant pls_integer := 114;

                Timestamp_Type               constant pls_integer := 180;

                Timestamp_With_TZ_Type       constant pls_integer := 181;

                Interval_Year_to_Month_Type  constant pls_integer := 182;

                Interval_Day_To_Second_Type  constant pls_integer := 183;

                Urowid_Type                  constant pls_integer := 208;

                Timestamp_With_Local_TZ_type constant pls_integer := 231;

                

                -- #(10144724): The typo Binary_Bouble_Type is purposefully retained for

                -- backward compatibility.

                Binary_Bouble_Type constant pls_integer := 101;

                end;

                /

It can't get clearer than this. If you want backward compatibility Oracle provides it.

If you want security Oracle provides the database that can be made more secure than any other but not by default with the GUI installation tools like OUI, NETCA, and DBCA. If you want to leverage all of the built-in security abilities of the product you must override the defaults yourself.

An example of one of those default configurations you will want to override to secure your database, one that is as clear as the code above:

SQL> SELECT grantee FROM dba_tab_privs WHERE table_name = 'ALL_SOURCE';

                

                GRANTEE

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

                PUBLIC

                DV_SECANALYST

Can anyone explain why a user, with no privilege other than CREATE SESSION, needs to be able to read source code?

We can't so we are working on a product we will be offering later this year that will address this and hundreds of other configuration issues.

[19-June-2019]

Oracle Security Alert CVE-2019-2729

Oracle strongly recommends that customers follow the recommended actions noted in the Security Alert.

The Security Alert Advisory is the starting point for relevant information. It includes a summary of the security vulnerability, and a pointer to obtain the latest patches. Supported products that are not listed in the "Affected Products and Versions" section of the advisory do not require new patches to be applied.

Also, it is essential to review the Security Alert supporting documentation referenced in the Advisory before applying patches, as this is where you can find important pertinent information.

The Advisory is available at the following location:

Oracle Critical Patch Updates and Security Alerts:
https://www.oracle.com/SecurityAlerts

Oracle Security Alert for CVE-2019-2729:
https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2729-5570780.html

Thank you,
Customer Support of Oracle Corporation
https://www.oracle.com/us/support/contact/index.html

[12-Jun-2019]

We feel no need for comment.

[11-Jun-2019]

Daniel Morgan from DBSecWorx has been selected to present his "Oracle Security for DBAs and Developers for ODTUG on Tuesday, July 23, 2019 at 12:00 - 13:00 EDT.

To register [Click Here]

[ 10-Jun-2019]

We are experiencing an interesting side effect from going through all of the pages at Morgan's Library and making decisions about which ones have security implications and how to rewrite them from a security point-of-view. We have known GLOGIN.SQL was a threat since reading what Pete Finnigan wrote about it back in 2002-2003. But we had not realized Oracle has done nothing to address it.

We are currently working on a tool that we believe will put an end to this threat and hope to release it to Pete and others for Beta testing before month's end. If it passes its Beta we will announce it here in the Blog, on our home page, and it will become the first resident of our Products page.

If the concept fails we will announce that here and provide background on what we were trying to accomplish and how.

[ 06-Jun-2019]

Why are we posting this report of another breach that could have been easily prevented? Because we want to remind everyone out there that thinks doing what everyone else is doing will protect their organization and their data.

We want to issue a challenge to al of the companies that sell firewalls. Publish the names of all organizations where a breach has exceeded 1 million PII, PHI, or PCI records. Stop telling IT shops "what your product can do" unless you are willing tot acknowledging the number of times your product has failed to do so. Cisco, Palo Alto, Fortinet, Check Point, Symantec, Huawei, Blue Coat, Juniper, Intel, McAfee, publish your failure rate so IT organizations can truly evaluate your offerings.

Our bet: AMCA. has a firewall from one of them as did OPM, Equifax, Sony, etc. etc. etc.

IT shops: There is little value in buying a million dollar lock for the front door when the back door is wide open.

[ 04-Jun-2019]

If the following surprises you ... chances are you have an account on Twitter. :-)

Twitter use decreases student's test scores by 25% to 40% of a standard deviation from the average result. Link

When I was teaching at the University of Washington, I learned very quickly that my student's learning improved if I banned mobile phones and laptops from the classroom during lectures.

Personally, I shut down both my Facebook and Twitter accounts long ago ... don't regret it for an instant. The phrase, if you are trying to remember it, is "Opiate of the Masses."

And, an associated book recommendation, for those that value earnest and intelligent discourse to manufactured angst.

[ 03-Jun-2019]

Another day. Another major breach. Another event where millions of Americans are affected. Guess which generated the greatest amount of new: The breach of 885 million documents or the winner of the Iron Throne?

On the other hand, according to Bloomberg News, First American Financial Corp., one of the largest US title insurance companies, is being sued by a client because "lax security measures put him at risk of identity theft, along with millions of others whose personal information could be easily access through its website." And, again according to Bloomberg, stockholders likely have good reason to be a bit concerned because "First American Financial Corp. tumbled the most in nearly eight years amid concerns that a security flaw in the title insurer may have allowed unauthorized access to more than 885 million records related to mortgage deals going back to 2003.

First American has more than 112 million outstanding shares. Assuming each share lost $3.00 the total cost of the breach, measured in shareholder equity, is $336,000,000. Does anyone believe the data could not have been protected for 2-3% of that amount?

What the Board of Directors should do, but they won't, is fire most if not every member of the corporation's C Level with cause. As this moves forward expect mortgage rates to increase as they "pass the cost of doing business" to their customers.

The customers didn't get upset out the loss of 885 million documents. The customers won't get upset about paying increased costs. What's more important? A data breach or who's going to die in the next episode of some brain-dead TV show?

Link

[ 28-May-2019]

Last week, May 23 and 24 we attended the 2019 Central Ohio InfoSec Summit in Columbus which was an incredibly rich and thought provoking environment at which we met old friends, made new friends, learned, laughed, and came to a somewhat surprising realization. That realization being that everyone talks about "Defense-in-Depth" but all of the focus from both speakers and vendors is on the perimeter. There wasn't a single presentation or vendor that was targeting data and databases with the exception of a few trying to detect bad actions with behavior analytics.

There is nothing wrong with utilizing behavior analytics just as there is nothing wrong with firewalls. They are all essential parts of a Defense-in-Depth strategy. What they miss, unfortunately, is that they don't have the expertise required to know that a call to DBMS_UTILITY.VALIDATE is a safe activity while a call to DBMS_UTILITY.INVALIDATE could be incredibly destructive? Do the behavior analytics know what they are looking at if a call is made to DBMS_UTILITY.EXEC_DDL_STATEMENT? We leave you to consider that there is only one right answer to this questions.

Think

Principles

Principals

DBSecWorx secures data and databases

Privacy & Cookies Policy

Legal