Failed attempt to create a ticket by email, from US-CERT@ncas.us-cert.gov

I received an email today:

US-CERT@ncas.us-cert.gov attempted to create a ticket via email in the queue Incident Reports; you
might need to grant ‘Everyone’ the CreateTicket right.

Yet, I’ve double checked the permissions:

I have both items checked for Privileged an Unprivileged as well.
US-CERT@ncas.us-cert.gov” doesn’t exist in the system as a user (yet).
What am I missing?

Best regards,
Steve

Stephen H. Switzer
President & Chief Technical Consultant

steve@SBSroc.com mailto:steve@sbsroc.com

Main:
Cell:

+1 (585) 298-9420 Ext: 7001
+1 (585) 202-8312

Support Desk:
support@sbsroc.com mailto:support@sbsroc.com

Fax:

+1 (585) 625-0020

This e-mail contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an
addressing or transmission error has misdirected this e-mail, please
notify the author by replying to this e-mail. If you are not the
intended recipient you must not use, disclose, distribute, copy, print
or rely on this e-mail. The content of this email may contain private
views and opinions, which do not constitute formal disclosure or
commitment unless specifically stated. We do not enter into legally
binding agreements via email.

http://www.sbsroc.com
https://plus.google.com/+SwitzerBusinessSolutionsLLCRochester
https://www.facebook.com/sbsolutions
https://www.linkedin.com/company/switzer-business-solutions-llc
https://twitter.com/sbsroc
The ASCII Group Xorcom Certified Dealer

graphics1 (4.42 KB)

I received an email today:

US-CERT@ncas.us-cert.gov attempted to create a ticket via email in the queue Incident Reports; you
might need to grant ‘Everyone’ the CreateTicket right.

Yet, I’ve double checked the permissions:

I have both items checked for Privileged an Unprivileged as well.
US-CERT@ncas.us-cert.gov” doesn’t exist in the system as a user (yet).
What am I missing?

Best regards,
Steve

Hi Steve,

Try granting “View queue” to everyone.

-mOn Mon, Nov 21, 2016 at 2:34 PM, Stephen Switzer steve@sbsroc.com wrote:

I received an email today:

US-CERT@ncas.us-cert.gov attempted to create a ticket via email in the queue Incident Reports; you
might need to grant ‘Everyone’ the CreateTicket right.

Yet, I’ve double checked the permissions:

I have both items checked for Privileged an Unprivileged as well.
US-CERT@ncas.us-cert.govUS-CERT@ncas.us-cert.gov doesn’t exist in
the system as a user (yet). What am I missing?

Best regards,
Steve


RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Los Angeles - January 9-11 2017

I don’t normally think of enabling outside users to see my queue, but I think you’re right. Thank you.From: Matt Zagrabelny mzagrabe@d.umn.edu
Sent: Nov 21, 2016 3:47 PM
To: Stephen Switzer
Cc: rt-users
Subject: Re: [rt-users] Failed attempt to create a ticket by email, from US-CERT@ncas.us-cert.gov

Stephen:

I faced a similar challenge when I first started to use RT. As
commented by our friend, the “view queue” has nothing to do with the
issue you faced.

The issue is, “/… attempted to create a ticket via email in the queue
Incident Reports; you might need to grant ‘Everyone’ the CreateTicket
right/”

… basically means the “Requester” ("Request_o_r"in RT) does
not have permissions to create the ticket.

Under your “ROLES” per the screen shot you have sent, you are
highlighted as “Owner”.

Select "Request_o_r"under ROLES and then enable “create tickets”.

The person handling the ticket or assumed ownership is called “Owner”.
The person who sent the ticket for support, is not necessarily the
"Owner".
I would also allow the requester, to “Comment on tickets”.

In a nutshell, the “Owner” of the ticket is not necessarily the requester.
In the practical world, the person who has sent a ticket / support
request, is usually called the “Requestor”

I also see you have multiple groups assigned under your “Incident
Reports” queue. The “deny” option takes precedence over “allow” option
per my experience, so it is also possible that one of your groups under
"User Groups", under your “Incident Reports” queue does not have
permission to create tickets.

Would appreciate the members here to correct me if I’m wrong in any of
the above.

Cheers!
Reza.

Stephen Switzer wrote on 11/21/2016 8:43 PM:

Reza,

I think you may have misinterpreted my screenshot. “Everyone”,
“Privileged”, “Unprivileged”, “Owner”, etc are all “highlighted” just to
show that there are selected permissions under that group. The bold one
is “Everyone”, which is the current selection and what permissions are
being displayed on the right in the screenshot.

It appears that “View queue” was required as Matt suggested, and I
received 2-3 tickets from US-CERT after I checked this off.

Thank you for your effort and input just the same!

SteveOn 2016-11-22 1:38 pm, Reza wrote:

Stephen:

I faced a similar challenge when I first started to use RT. As commented by our friend, the “view queue” has nothing to do with the issue you faced.

The issue is, “… attempted to create a ticket via email in the queue Incident Reports; you might need to grant ‘Everyone’ the CreateTicket right

… basically means the “REQUESTER” ("RequestOr"in RT) does not have permissions to create the ticket.

Under your “ROLES” per the screen shot you have sent, you are highlighted as “Owner”.

Select "RequestOr"under ROLES and then enable “create tickets”.

The person handling the ticket or assumed ownership is called “Owner”.
The person who sent the ticket for support, is not necessarily the “Owner”.
I would also allow the requester, to “Comment on tickets”.

In a nutshell, the “Owner” of the ticket is not necessarily the requester.
In the practical world, the person who has sent a ticket / support request, is usually called the “Requestor”

I also see you have multiple groups assigned under your “Incident Reports” queue. The “deny” option takes precedence over “allow” option per my experience, so it is also possible that one of your groups under “User Groups”, under your “Incident Reports” queue does not have permission to create tickets.

Would appreciate the members here to correct me if I’m wrong in any of the above.

Cheers!
Reza.

Stephen Switzer wrote on 11/21/2016 8:43 PM:

I don’t normally think of enabling outside users to see my queue, but I think you’re right. Thank you.

Sent from Nine [1]


FROM: Matt Zagrabelny mzagrabe@d.umn.edu
SENT: Nov 21, 2016 3:47 PM
TO: Stephen Switzer
CC: rt-users
SUBJECT: Re: [rt-users] Failed attempt to create a ticket by email, from US-CERT@ncas.us-cert.gov


RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training

  • Los Angeles - January 9-11 2017

Links:
[1] http://www.9folders.com/

Greetings Stephen:

Thank you for your reply. Now I’m scratching my head, because other
than admins and “privileged users”, no one has “View Queue” permissions
in my platform and I’m not getting any error as you described.

Hoping someone can shed some light here per this anomaly.

Cheers!
Reza.

Stephen Switzer wrote on 11/22/2016 3:37 PM:

Hello there,

on my working Debian Jessie RT I’m using the JSGantt Plugin which also
workes fine except causing a Possible cross-site request forgery on
automatic reload.

Generally, CSRF occuring were eliminated at the beginning of the
installation several months ago by setting

Webdomain override

Set($WebDomain, ‘172.18.200.41’);
Set($WebPort, 443);
Set($WebPath , “/rt”);
Set($WebBaseURL , “https://172.18.200.41”);

and today I added

Cross-site forgery verhindern

Set(@ReferrerWhitelist, qw(172.18.200.41:443 127.0.0.1:443));

When you call Gantt Chart, everything is fine. Now I have set

#Refresh global
Set($HomePageRefreshInterval, “900”);.
Set($SearchResultsRefreshInterval, “60”);

so the Gantt Chart is reloaded automatically. And by the first reload
ist causes the CSRF. Then, when you resume the request manually, all
following automatically reloads work without problems.

The error message complains about a missing referrer:

Possible cross-site request forgery

RT has detected a possible cross-site request forgery for this
request, because your browser did not supply a Referrer header. A
malicious attacker may be trying to modify or access a search on your
behalf. If you did not initiate this request, then you should alert
your security team.

If you really intended to visit /rt/Search/JSGantt.html and modify or
access a search, then click here to resume your request.

After you called Gantt Chart, the URL is

https://172.18.200.41/rt/Search/JSGantt.html?Query=Queue%20=%20'Europe'%20AND%20(Status%20=%20'new'%20OR%20Status%20=%20'open'%20OR%20Status%20=%20'stalled')

and after you resumed the reload request, the URL is

https://172.18.200.41/rt/Search/JSGantt.html?CSRF_Token=88ce346e0380df0395573adec7fb20d9

I helped myself by disabling Set($SearchResultsRefreshInterval, “60”);
since noone uses it, but maybe anyway anyone has an advice?

Kind regards, Patrick

Hello there,

on my working Debian Jessie RT I’m using the JSGantt Plugin which also
workes fine except causing a Possible cross-site request forgery on
automatic reload.

Generally, CSRF occuring were eliminated at the beginning of the
installation several months ago by setting

Webdomain override

Set($WebDomain, ‘172.18.200.41’);
Set($WebPort, 443);
Set($WebPath , “/rt”);
Set($WebBaseURL , “https://172.18.200.41”);

and today I added

Cross-site forgery verhindern

Set(@ReferrerWhitelist, qw(172.18.200.41:443 127.0.0.1:443));

When you call Gantt Chart, everything is fine. Now I have set

#Refresh global
Set($HomePageRefreshInterval, “900”);.
Set($SearchResultsRefreshInterval, “60”);

so the Gantt Chart is reloaded automatically. And by the first reload
ist causes the CSRF. Then, when you resume the request manually, all
following automatically reloads work without problems.

The error message complains about a missing referrer:

Possible cross-site request forgery

RT has detected a possible cross-site request forgery for this
request, because your browser did not supply a Referrer header. A
malicious attacker may be trying to modify or access a search on your
behalf. If you did not initiate this request, then you should alert
your security team.

If you really intended to visit /rt/Search/JSGantt.html and modify or
access a search, then click here to resume your request.

After you called Gantt Chart, the URL is

https://172.18.200.41/rt/Search/JSGantt.html?Query=Queue%20=%20'Europe'%20AND%20(Status%20=%20'new'%20OR%20Status%20=%20'open'%20OR%20Status%20=%20'stalled')

and after you resumed the reload request, the URL is

https://172.18.200.41/rt/Search/JSGantt.html?CSRF_Token=88ce346e0380df0395573adec7fb20d9

I helped myself by disabling Set($SearchResultsRefreshInterval, “60”);
since noone uses it, but maybe anyway anyone has an advice?

Kind regards, Patrick

Pardon me, accidentially threadnapping!Am 23.11.2016 um 10:56 schrieb Patrick G. Stoesser:

Hello there,

on my working Debian Jessie RT I’m using the JSGantt Plugin which also
[…]

It finally dawned on me what the problem was, and I thought it would be
good to document this in the mailing list archives in case others search
for it.

The user was DISABED. Ugh, so simple.

Thanks for all the effort and input.

SteveOn 2016-11-22 3:37 pm, Stephen Switzer wrote:

Reza,

I think you may have misinterpreted my screenshot. “Everyone”, “Privileged”, “Unprivileged”, “Owner”, etc are all “highlighted” just to show that there are selected permissions under that group. The bold one is “Everyone”, which is the current selection and what permissions are being displayed on the right in the screenshot.

It appears that “View queue” was required as Matt suggested, and I received 2-3 tickets from US-CERT after I checked this off.

Thank you for your effort and input just the same!

Steve

On 2016-11-22 1:38 pm, Reza wrote:

Stephen:

I faced a similar challenge when I first started to use RT. As commented by our friend, the “view queue” has nothing to do with the issue you faced.

The issue is, “… attempted to create a ticket via email in the queue Incident Reports; you might need to grant ‘Everyone’ the CreateTicket right

… basically means the “REQUESTER” ("RequestOr"in RT) does not have permissions to create the ticket.

Under your “ROLES” per the screen shot you have sent, you are highlighted as “Owner”.

Select "RequestOr"under ROLES and then enable “create tickets”.

The person handling the ticket or assumed ownership is called “Owner”.
The person who sent the ticket for support, is not necessarily the “Owner”.
I would also allow the requester, to “Comment on tickets”.

In a nutshell, the “Owner” of the ticket is not necessarily the requester.
In the practical world, the person who has sent a ticket / support request, is usually called the “Requestor”

I also see you have multiple groups assigned under your “Incident Reports” queue. The “deny” option takes precedence over “allow” option per my experience, so it is also possible that one of your groups under “User Groups”, under your “Incident Reports” queue does not have permission to create tickets.

Would appreciate the members here to correct me if I’m wrong in any of the above.

Cheers!
Reza.

Stephen Switzer wrote on 11/21/2016 8:43 PM:

I don’t normally think of enabling outside users to see my queue, but I think you’re right. Thank you.

Sent from Nine [1]


FROM: Matt Zagrabelny mzagrabe@d.umn.edu
SENT: Nov 21, 2016 3:47 PM
TO: Stephen Switzer
CC: rt-users
SUBJECT: Re: [rt-users] Failed attempt to create a ticket by email, from US-CERT@ncas.us-cert.gov


RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training

  • Los Angeles - January 9-11 2017

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Los Angeles - January 9-11 2017

Links:
[1] http://www.9folders.com/