Deploying EMET 4.0 in Small to Medium Environments using WSUS

The Enhance Mitigation Experience Toolkit (EMET) has to be one of the Microsoft security tools that I recommend the most to organizations of all sizes, friends and family do to that it helps curve in many cases the window of exploitation for many client side attacks when configured right on client machines in the network. EMET also provides protection for known vulnerabilities that have not been tailored to bypass it and against 0 day client side exploits for known software.

Many other people have written about the capabilities of EMET so I will not cover all the new features added and new capabilities in 4.0, in fact the documentation from Microsoft is great http://www.microsoft.com/en-us/download/details.aspx?id=39273 it covers how to deploy EMET via Group Policy and how to deploy it using System Center Configuration Manager. The documentation also cover all the features in great detail so I will not bore you regurgitating that information from there.

Now for this blog post it will part from some pre-conceived notions:

• All machines where we will deploy EMET are part of a Domain.
• WSUS is configured and issuing patches to the machines in the domain.
• You have organized your machines in to groups and your deployment of EMET is planned along this groups.

Checking for dependencies

The first thing we will do is log in to our WSUS console and make sure that we have deployed .Net Framework 4.0 to all the machines we want to install EMET on.  First thing we do is we check that in the option that under classifications that Feature Packs is selected if not available under Updates:

If we have Windows 8 client machines in the network we also check for KB2790907

Configuring WSUS Package Publisher

The tool we will use to to publish thru WSUS EMET is the WSUS Package Publisher tool, it is an Open Source Tool that can be found at http://wsuspackagepublisher.codeplex.com/ This tool allows us to publish MSI Packages, executable and MSP files. The tool also has reporting capabilities that can be use to determine the deployment of the packages. This is a great alternative for small to medium organizations that need to deliver packages like Java, Adobe Reader and Flash and make sure their machines are update in a timely fashion and not have to wait for a user to either log in to the machine or the machine to reboot like in the case of using GPOs. The perfect scenario would be to have a Third party patch management system like Tivoli Endpoint Manager or use Microsoft own System Center Configuration Manager but many do not have the resources for this solutions since they can be complex and expensive.

Thankfully the author of the project has done great documentation on how to use the tools including examples for common packages http://wsuspackagepublisher.codeplex.com/documentation

There are 2 ways to run the tool:

1. Locally in the WSUS server.
2. Remotely from a management station, the WSUS server has to be configured to use SSL in this case http://technet.microsoft.com/en-us/library/bb633246.aspx

The prerequisites for running the tool are :

• Microsoft .NET 4.0 must be installed on the local machine.
• The user must be Administrator of the local machine.
• The WSUS server must be at release 3.0 SP2 or greater.
• The user used must be part of “WSUS Administrators” group of the WSUS server.
• In the case it is ran from a management workstation the RSAT tools must be installed and the WSUS Management console has to enabled.
  

We start by clicking on the download button and downloading the latest version of the tool.

After downloading the zip file:

• Right click on the download zip file and select Properties.
• Click on the Unblock button.
• De-compress the archive and all files should have inherited the unlock we did on the zip file.

Once the package is decompressed we launch the executable “Wsus Package Publisher.exe”

Once the application is launched depending on the environment and if the tool is ran locally or remotely connection setting will have to be set. For configuring the connections setting go to Tools –> Settings and make sure that the server is the correct one, check the credentials and if SSL will be used or not. The rest of the settings can be left with the defaults.

If you are running the tool in the same machine as the WSUS server with default values or if you already set the settings for your WSUS server you can just click on the Connect/Reload button to connect to the server.

Once connected to the server we can create a Self Signed certificate for use with WSUS for publishing packages. The way WSUS works all packages distributed by the server are signed digitally and the machines where the packages are deployed need to trust the Root CA for the certificate used and also trust the Publisher. For simplicity we will use self signed certificates and then distribute them using Group Policy Objects. The documentation for the projects does cover in detail how to use a Windows Certificate Authority or a third party authority for this.

To generate the certificate go to Tools –> Certificates.

1. Click on the Generate the Certificate button and wait for the message that the certificate has been generated successfully.
2. Click on the Save the  Certificate button and give the certificate a friendly name and store it an a safe place since the certificate will be deployed via GPO in a later step.

You will need to restart the WSUS Server services for the Certificate to be loaded. On the WSUS Server open PowerShell and type:

Get-Service wsus* | Restart-Service -Verbose

This will restart all services that start with the letter WSUS and will show the actions taken since the –Verbose option was used.

You can also use PowerShell to verify if the certificate was installed properly on the WSUS server:

PS C:\Users\administrator.ACMELABS> Get-ChildItem Cert:\LocalMachine\WSUS\ -CodeSigningCert


    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\WSUS


Thumbprint                                Subject
----------                                -------
681249451028091B250828DA56D70FD2A3547FE5  CN=WSUS Publishers Self-signed

Once we have confirmed that the certificate has been stored properly we can deploy the certificate to our infrastructure using Group Policy and ensure the certificate has been applied to all the hosts in the network before we add the package for deployment.

From the Group Policy Management Console we can edit the GPO that we use for configuring WSUS on our client machines so as to keep all settings related to patch management on one single Policy Object.

1. Open the appropriate group policy for editing
2. Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security
   Settings” -> “Public Key Policies”

3.  Select the certificate that was exported earlier.

4. Repeat the steps for importing but this time for Trusted Root Certificate Authorities.

5 . Expand “Computer Management” -> “Policies” -> “Administrative Templates” -> “Windows Components” -> “Windows Update”

6. Enable "Allow signed content from intranet Microsoft update service location” if you do not enable this feature you will receive an error with code 800b0109 when it tries to validate the signature of the file when the client downloads it.

Once the Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes, this means that it can take up to 2 hours for the update to actually apply to your client machines.

If you have a Window 2012 Domain Controller and you have not done this already I recommend you use a New feature in Windows 2012 Domain Controllers that is a templates that will open the correct ports on remote windows machines so as to be able to force a GP Update remotely, this could prove quite useful when one has to push changes in a quick manner like when responding to an incident. On a Domain Controller open PowerShell and run the following command to create and link the GPO, modify the DN so it will match your environment in this case it is for my lab domain acmelabs.com:

Neww-GPO –Name "Configure firewall rules for remote gpupdate" –StarterGpoName "Group Policy Remote Update Firewall Ports" | New-GPLink –target "dc=acmelabs,dc=com" –LinkEnabled yes 

Once it is linked and the policy has been applied to all machines in the domain you can invoke a Group Policy update across my domain from a Windows 2012 machine as Domain Admin in PowerShell:

Get-ADComputer –filter * -Searchbase "dc=acmelabs,dc=com" | foreach{ Invoke-GPUpdate –computer $_.name -force} 

On a client machine we can verify that the certificate was propagated by using PowerShell to check the store and compare the certificate fingerprints with the one we saw earlier when we generated the cert.

PS C:\Users\Administrator> ls Cert:\LocalMachine\TrustedPublisher


    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\TrustedPublisher


Thumbprint                                Subject
----------                                -------
681249451028091B250828DA56D70FD2A3547FE5  CN=WSUS Publishers Self-signed

Creating a EMET 4.0 Update and Publishing It

Before we deploy the package we have to set the ground for it in the case of EMET. First we need to download the MSI and install it on a Management Workstation since the installation will include the ADMX GPO Policy Templates we will use to manage EMET configuration centrally. We can Download the file from http://www.microsoft.com/en-us/download/details.aspx?id=39273 Once installed the ADMX files will be located on:

• For x64 Systems C:\Program Files (x86)\EMET 4.0\Deployment\Group Policy Files
• On x86 System C:\Program Files\EMET 4.0\Deployment\Group Policy Files

Depending on how you manage your ADMX files either centrally or per Domain Controller you will need to copy the files to their proper location so they can be used (http://technet.microsoft.com/en-us/library/cc709647(v=ws.10).aspx).

On a DC by DC solution you need to copy your ADMX file to SYSTEMDRIVE\Windows\PolicyDefinitions and the ADML to SYSTEMDRIVE\Windows\PolicyDefinitions\en-US if you are using centralized management of the policy files you would copy them to %logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions and %logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions\en-US respectably.

We can now set a base configuration for EMET. I recommend you test the settings in your environment first since different vendors have different coding standards and some applications may be affected by EMET. For this example I will use a base configuration using Microsoft recommended settings for popular apps and enable most of the protections.

In the Group Policy Management Console we can create a new GPO or use an existing one for security settings and edit it (Do not use the Default Domain Policy GPO!)  Expand “Computer Management” -> “Policies” -> “Administrative Templates” -> “Windows Components” -> “Windows Update” and set the parameters to fit in your environment:

Once configured and linked we can create the package for deployment, we start by using the WSUS Package Publisher

• Select Tools –> Create an Update

• In the next screen select the EMET MSI package to be deployed, this is the file we downloaded from Microsoft

• We click on Next and set a Product Name, Description and Info URL. Depending on your internal policy and environment you may wish to modify the Package Type, Impact and if you want it to reboot after the installation or not. EMET does require a Reboot after being install so it can set different hooks in APIs and Memory. Click on Next on the other screen accepting the default values

• Once the package is published and signed we need to approve the package from the WSUS Package Publishing application.

• Once we click on Approve it will bring up a window for us to decide to what computer groups it will apply this is one of the limiting factors of using WSUS, your strategy has to match your computer groups.

The package should now be available to your machines thru Windows Update on those that use the the WSUS Server and in the group you deployed the package to:

On Windows 7

 

On Windows 8

Installation is as simple as accepting the install.

Hope you find this blog post useful and that it serves as a base for your deployments in your environment.

PowerShell for Security Professionals Class at Derbycon

On September 25 and 26 I will be teaching at Derbycon my class on Introduction to PowerShell for Security Professionals https://www.derbycon.com/training-courses/#intropower . To give a bit of background on it I have since 2007 been using PowerShell since version 1 for automating, managing, securing and breaking Exchange, Windows, VMware, NetApp and even Cisco for several customers in the Caribbean, Central and South America. I have to admit of all the command shells I have used PowerShell has to be my favorite, it is truly a very powerful shell. I have coded several thousands of lines of PowerShell, in modules both in PowerShell and C#, I have also written several blog posts on it, all of this leading me to the creation of these class. Microsoft is evolving its technologies at a more rapid pace and PowerShell has become a critical pillar of its Management Framework for Windows and Server products. In the class targeted at security professionals, to me these are:

• System Admins that care about security.
• Auditors and Incident Response teams that need to work with live and offline Windows Systems.
• Pentesters that want to expand their skills with new ways to discover, enumerate, attack and do post exploitation using PowerShell.

The first day it will be a fast paced introduction to PowerShell and its philosophy, Covering:

• What is PowerShell.
• Using the Help Subsystem.
• Working with the Pipeline.
• Extending PowerShell via Module and Snappings.
• Formatting
• Remoteting
• PowerShell notion of security
• WMI and CIM
• Powershell Scripting Syntax

The second day will cover:

• Network Discovery.
• Incident Response and Auditing.
• Post Explotation

I will not sugar coat or give any fan boy perspective on it, I will cover both where it shines and where cmdlets do not meet the needs of a security professional and how to work around those. I will cover projects like PowerSploit, Metasploit, Social Engineering Toolkit and my own Posh-Secmod . Those that have signed up for the class I thank you and those interested here is your chance. The class will be fast passed and I will make it as fun as I can. In addition you will get material from my Introduction to Metasploit Class for free and will also get any future updates to the class also for free as it evolves and I add new stuff. I have to be honest we will only have 2 day and I will give you over 400 slides of unprotected slides in PDF format (So you can copy paste code from them) plus a lab guide, enough material for 5 days of class and we will go thru most of it in 2 days, the rest is just more detailed information that can be used as reference { Those that took my class last year you will be getting a link to download the updated material after Derbycon 2013 :) }. I have to give thanks to the reviewers of my awful english and the material:

• Matt Grabber (author of PowerSploit) @mattifestation https://twitter.com/mattifestation
• Chris Campbell (Contributor to PowerSploit) @obscuresec https://twitter.com/obscuresec
• Lee Holmes (from the PowerShell Team at Microsoft) @LeeHolmes https://twitter.com/LeeHolmes

Also I cannot forget:

• Jeffry Snover (for coming up with PowerShell) https://twitter.com/jsnover
• Bruce Payette (My first book on PowerShell) https://twitter.com/BrucePayette
• Don Jones (Great Books and CBTs on PowerShell) https://twitter.com/concentrateddon

Hope to see you guys in class these September.

Stealing User Certificates with Meterpreter Mimikatz Extension

The Mimikatz extension on Meterpreter allows us to use the same commands we would on the standalone tool inside of Meterpreter as native commands. This blog post will cover specifically the stealing of a users certificates by exporting their keys for use by the attacker. In this specific scenario we have gotten a Meterpreter session on a developers system. The system is a Windows 7 System as we can see

if we look at the context we are running under we can see we are running under the target account:

Now lets take a look at what privilege level we have. For this I use a small Meterpreter script I wrote that tells me some basic information of the privilege level I’m working under the script is:

print_status "Admin token: #{is_admin?()}"
print_status "Running as SYSTEM: #{is_system?()}"
print_status "UAC Enabled: #{is_uac_enabled?()}"

When I run the script I get to see if the session is running in a elevated state, if I’m running as SYSTEM and if UAC is enabled:

As you can see the session is limited in terms of privileges, but this does not affect what we want to do which is steal the user certificates. Lets load mimikatz and take a look at the commands it offers:

for this we use the load command and the name of the extension:

the command that are added to our Meterpreter session:

We will use the mimikatz_command custom command to work with certificates.  The command takes 2 options the –f for the module name and –a for the arguments to pass to the module itself.

The command in mimikatz for working with certificates is under the crypto module. To look at the options we just specify the crypto module with no command selected so as to make mimikatz show the commands available:

Since the mimikatz tool is written in French the descriptions for the commands are in Frech but their names are self descriptive. Lets first list the stores available:

As we can see we only have access to the users store. Lets take a look at the certificates we can reach:

As we can see we have access to 2 certificates, one of them is a code signing certificate and the other is a a user certificate from their type. We can also see on the exportability field that one says no the other says yes (in French) this means the Private Key for the certificate. If we try to export them you will see the private key export will fail for the code signing certificate:

We can get around this by patching the API to allow us to export the key. One thing to keep in mind for some keys we have to also patch the LSASS to allow the Microsoft Software Key Storage Provider to export CNG certificates, for this we need to be running as SYSTEM or have the admin token and also the Debug Privilege. In this case for the Code Signing Certificate we do not need that level of access but it is good to know what would be needed if we where not able. To patch the API we use the patchapi command of the crypto module:

Lets try the export of the certificates again:

This time we where successful. The private key for each certificate was exported as a PFX file with a password of mimikatz that we can now download from the target system:

 

As you can see this only a simple yet effective example of the power of the mimikatz module other than credential collection. Thanks to Erick Milam ( @Brav0Hax )  from Accuvant for peaking my interest on it when he asked me how to steal a users certificate today. Hope you find it useful.

DNSRecon 0.8.6 is Out!

Just updated DNSRecon to check if it can pull the Bind Version by doing a query for the TXT Record version.bind and it will now check if the RA Flag is set in responses from each of the NS servers it detects. If the server has recursion enabled it could be used for DDoS attacks and for performing Cache Snooping.

Example of a run where it is able to pull the Bind Version:

infidel02:dnsrecon carlos$ ./dnsrecon.py -d zonetransfer.me -x zt.xml
[*] Performing General Enumeration of Domain: zonetransfer.me
[-] DNSSEC is not configured for zonetransfer.me
[*]      SOA ns16.zoneedit.com 69.64.68.41
[*]      NS ns12.zoneedit.com 209.62.64.46
[*]      Bind Version for 209.62.64.46 8.4.X
[*]      NS ns16.zoneedit.com 69.64.68.41
[*]      Bind Version for 69.64.68.41 8.4.X
[*]      MX ASPMX2.GOOGLEMAIL.COM 173.194.75.27
[*]      MX ASPMX3.GOOGLEMAIL.COM 173.194.66.27
[*]      MX ASPMX4.GOOGLEMAIL.COM 173.194.65.26
[*]      MX ASPMX5.GOOGLEMAIL.COM 173.194.70.26
[*]      MX ASPMX.L.GOOGLE.COM 74.125.140.27
[*]      MX ALT1.ASPMX.L.GOOGLE.COM 173.194.75.26
[*]      MX ALT2.ASPMX.L.GOOGLE.COM 173.194.66.27
[*]      MX ASPMX2.GOOGLEMAIL.COM 2607:f8b0:400c:c03::1a
[*]      MX ASPMX3.GOOGLEMAIL.COM 2a00:1450:400c:c03::1b
[*]      MX ASPMX4.GOOGLEMAIL.COM 2a00:1450:4013:c01::1b
[*]      MX ASPMX5.GOOGLEMAIL.COM 2a00:1450:4001:c02::1a
[*]      MX ASPMX.L.GOOGLE.COM 2607:f8b0:4002:c01::1a
[*]      MX ALT1.ASPMX.L.GOOGLE.COM 2607:f8b0:400c:c01::1b
[*]      MX ALT2.ASPMX.L.GOOGLE.COM 2a00:1450:400c:c03::1a
[*]      A zonetransfer.me 217.147.180.162
[*]      TXT zonetransfer.me Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes
[*]      TXT zonetransfer.me google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA
[*] Enumerating SRV Records
[*]      SRV _sip._tcp.zonetransfer.me www.zonetransfer.me 217.147.180.162 5060 0
[*] 1 Records Found
[*] Saving records to XML file: zt.xml

The information on version and recursion are also saved in the XML as you can see: infidel02:dnsrecon carlos$ cat zt.xml <?xml version="1.0" ?> <records> <record address="69.64.68.41" mname="ns16.zoneedit.com" type="SOA"/> <record Recursive="False" Version="8.4.X" address="209.62.64.46" target="ns12.zoneedit.com" type="NS"/> <record Recursive="False" Version="8.4.X" address="69.64.68.41" target="ns16.zoneedit.com" type="NS"/> <record address="173.194.75.27" exchange="ASPMX2.GOOGLEMAIL.COM" type="MX"/> <record address="173.194.66.27" exchange="ASPMX3.GOOGLEMAIL.COM" type="MX"/> <record address="173.194.65.26" exchange="ASPMX4.GOOGLEMAIL.COM" type="MX"/> <record address="173.194.70.26" exchange="ASPMX5.GOOGLEMAIL.COM" type="MX"/> <record address="74.125.140.27" exchange="ASPMX.L.GOOGLE.COM" type="MX"/> <record address="173.194.75.26" exchange="ALT1.ASPMX.L.GOOGLE.COM" type="MX"/> <record address="173.194.66.27" exchange="ALT2.ASPMX.L.GOOGLE.COM" type="MX"/> <record address="2607:f8b0:400c:c03::1a" exchange="ASPMX2.GOOGLEMAIL.COM" type="MX"/> <record address="2a00:1450:400c:c03::1b" exchange="ASPMX3.GOOGLEMAIL.COM" type="MX"/> <record address="2a00:1450:4013:c01::1b" exchange="ASPMX4.GOOGLEMAIL.COM" type="MX"/> <record address="2a00:1450:4001:c02::1a" exchange="ASPMX5.GOOGLEMAIL.COM" type="MX"/> <record address="2607:f8b0:4002:c01::1a" exchange="ASPMX.L.GOOGLE.COM" type="MX"/> <record address="2607:f8b0:400c:c01::1b" exchange="ALT1.ASPMX.L.GOOGLE.COM" type="MX"/> <record address="2a00:1450:400c:c03::1a" exchange="ALT2.ASPMX.L.GOOGLE.COM" type="MX"/> <record address="217.147.180.162" name="zonetransfer.me" type="A"/> <record name="zonetransfer.me" strings="Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes" type="TXT"/> <record name="zonetransfer.me" strings="google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA" type="TXT"/> <record address="217.147.180.162" name="_sip._tcp.zonetransfer.me" port="5060" target="www.zonetransfer.me" type="SRV"/> <scaninfo arguments="./dnsrecon.py -d zonetransfer.me -x zt.xml" time="2013-05-29 11:36:06.550073"/> <domain domain_name="zonetransfer.me"/> </records>

Here is an example where recursion is enabled, you will see that the message is shown differently since this information is crucial during an engagement:

infidel02:dnsrecon carlos$ ./dnsrecon.py -d acmelab.com -n 192.168.1.80
[*] Performing General Enumeration of Domain: acmelab.com
[*] DNSSEC is configured for acmelab.com
[*] DNSKEYs:
[*]     NSEC KSk RSASHA256 ...
[*]     NSEC ZSK RSASHA256 ...
[*]     NSEC ZSK RSASHA256 ...
[*]     NSEC KSk RSASHA256 ...
[*]      SOA labns1.acmelab.com 192.168.1.80
[*]      NS labns1.acmelab.com 192.168.1.80
[-]      Recursion enabled on NS Server 192.168.1.80
[*]      MX mail1.acmelab.com 192.168.1.4
[*]      A acmelab.com 192.168.1.2
[*]      TXT acmelab.com v=spf1 192.168.1.0/24
[*]      TXT _domainkey.acmelab.com o=~; r=postmaster@acmelab.com
[*] Enumerating SRV Records
[*]      SRV _finger._tcp.acmelab.com web1.acmelab.com 192.168.1.2 79 0
[*]      SRV _http._tcp.acmelab.com web2.acmelab.com 192.168.1.3 80 0
[*]      SRV _http._tcp.acmelab.com web1.acmelab.com 192.168.1.2 80 0
[*]      SRV _sip._tls.acmelab.com chat.acmelab.com 192.168.1.5 443 0
[*]      SRV _sipinternaltls._tcp.acmelab.com chat.acmelab.com 192.168.1.5 5061 0
[*]      SRV _https._tcp.acmelab.com web1.acmelab.com 192.168.1.2 443 0
[*]      SRV _https._tcp.acmelab.com web2.acmelab.com 192.168.1.3 443 0
[*] 7 Records Found

Hope you guys find it as useful as I have :)

Fixin Raspistill and Raspivid for Headless Streaming on the Raspberry Pi

Recently I got 2 Raspberry Pi Camera modules for my Raspberry Pi boards for some projects I have in mind. I was sad to find out I could not stream unless I had a monitor connected to the Pi and after some additional digging I found out that the initial version of the tools Raspistill and Raspivid the no preview option was broken causing it to not work. After some digging in the forums and trial and error I found how to fix it while the tools are updated and added to the package repo. Plus it was a good exercise in compiling files for ARM.

Update your system applications and download the required software to compile userland:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git gcc build-essential cmake vlc

Download and configure sources

Create a folder to hold development files and clone the latest userland for raspian.

cd ~
mkdir Development
git clone git://github.com/raspberrypi/userland.git
cd userland

Create the proper make files:

sed -i 's/if (DEFINED CMAKE_TOOLCHAIN_FILE)/if (NOT DEFINED CMAKE_TOOLCHAIN_FILE)/g' makefiles/cmake/arm-linux.cmake

Fix Raspistill

Open Raspistill command source file at line 1034:

nano +1034 host_applications/linux/apps/raspicam/RaspiStill.c

Modify the line from:

MMAL_STATUS_T status = -1;

to:

MMAL_STATUS_T status = MMAL_SUCCESS;

Fix Raspivid

Open the raspivid source file at line 852:

nano +852 host_applications/linux/apps/raspicam/RaspiVid.c

Modify the line from:

MMAL_STATUS_T status = -1;

to:

MMAL_STATUS_T status = MMAL_SUCCESS;

Build and Install the Latest Userland

Configure a build folder and build and install the userland binaries. This should take around 30 to 45 minutes:

mkdir build
cd build
sudo cmake -DCMAKE_BUILD_TYPE=Release ..
sudo make
sudo make install

You should now be able to create a steam with VLC and connect to it on a headless system using the -n parameter for no preview:

raspivid -o - -t -1 -w 920 -h 540  -n | cvlc -vvv --network-caching=0 stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264