I was able to change info in DB TST_102300, while doing something in E10 that was using the App that connects to DB UAT_102300. And this might work when the App connects to the ReportServerTempDB (the one that holds the temp tables used by SSRS reports).
I don’t want to reveal any details openly, if it is indeed a security hole.
It might just be that my user rights on the SQL and App servers is letting me do something that other users wouldn’t. But I’m not sure.
Message me if you want me to privately describe the details of the exploit.
edit
In a nutshell, I found a very easy way to affect the DB of environment ‘A’, while running a report in environment ‘B’
It seems to simple to be real, so I thought I’d run it by other son here first. And it’s not really an exploit against the Epor system. It does something at the SSRS level.
It’s so obvious, I can’t believe it might be real. Probably more of an indication that we’ve got some shoring up of Epicor and/or SQL implementation.
Want me to spill it out here? I could delete it if it is real.
Great conversation. I agree with @Mark_Wonsil. Let’s go into way too much detail.
The way reporting works is that the application server is told to render a report. The first step is to collect the data from the application database. The SQL user doing that has right to read from the application database and rights to write to the temporary reporting database. All the standard checks are done to make sure that the Epicor user has the appropriate rights to read the data from the application database.
The next step is that the application server tells the SSRS server to render the report. It does that by running the queries in the RDL. The important thing is that this is now being run inside SSRS, not the application server. The rights that that user has are the ones that matter. Their rights should be limited to reading the data that was just written to the temporary reporting database. This is easily configured through the “shared data source” that all the SSRS reports use. That user should be different than the one that the application server is using. Set the rights for that user to only be able to read from the temporary reporting database and no other database.
Great work @ckrusen, this is the kind of thinking we need!
On this topic, not being a network admin guy, I did find the implementation of the various required user accts (both Domain users and E10 users) to be a little vague.
I think we’re ready for a PowerShell script library that just does it correctly. Every time. F…orget the manuals. Should work on prem and in a user-run cloud instances.
