Scoutsuite: Quiet flag has no effect when running programatically

[thommor]

Using the quiet flag in ScoutSuite doesn't seem to have any effect.

Logs from running ScoutSuite with quiet set to True

[2019-06-14 10:03:17,949: INFO/ForkPoolWorker-2] Launching Scout
[2019-06-14 10:03:17,950: INFO/ForkPoolWorker-2] Authenticating to cloud provider
[2019-06-14 10:03:18,003: INFO/ForkPoolWorker-2] Found credentials in shared credentials file: ~/.aws/credentials
[2019-06-14 10:03:19,465: INFO/ForkPoolWorker-2] Gathering data from APIs
[2019-06-14 10:03:19,467: INFO/ForkPoolWorker-2] Fetching resources for the Lambda service
[2019-06-14 10:03:19,924: INFO/ForkPoolWorker-2] Fetching resources for the CloudFormation service
[2019-06-14 10:03:20,493: INFO/ForkPoolWorker-2] Fetching resources for the CloudTrail service
[2019-06-14 10:03:21,017: INFO/ForkPoolWorker-2] Fetching resources for the CloudWatch service
[2019-06-14 10:03:21,567: INFO/ForkPoolWorker-2] Fetching resources for the Config service
[2019-06-14 10:03:22,106: INFO/ForkPoolWorker-2] Fetching resources for the Direct Connect service
[2019-06-14 10:03:22,645: INFO/ForkPoolWorker-2] Fetching resources for the EC2 service
[2019-06-14 10:03:23,212: INFO/ForkPoolWorker-2] Fetching resources for the EFS service
[2019-06-14 10:03:23,746: INFO/ForkPoolWorker-2] Fetching resources for the ElastiCache service
[2019-06-14 10:03:24,296: INFO/ForkPoolWorker-2] Fetching resources for the ELB service
[2019-06-14 10:03:24,834: INFO/ForkPoolWorker-2] Fetching resources for the ELBv2 service
[2019-06-14 10:03:25,379: INFO/ForkPoolWorker-2] Fetching resources for the EMR service
[2019-06-14 10:03:25,919: INFO/ForkPoolWorker-2] Fetching resources for the IAM service
[2019-06-14 10:03:25,926: INFO/ForkPoolWorker-2] Fetching resources for the RDS service
[2019-06-14 10:03:26,675: INFO/ForkPoolWorker-2] Fetching resources for the RedShift service
[2019-06-14 10:03:27,221: INFO/ForkPoolWorker-2] Fetching resources for the Route53 service
[2019-06-14 10:03:27,753: INFO/ForkPoolWorker-2] Fetching resources for the S3 service
[2019-06-14 10:03:28,295: INFO/ForkPoolWorker-2] Fetching resources for the SES service
[2019-06-14 10:03:28,766: INFO/ForkPoolWorker-2] Fetching resources for the SNS service
[2019-06-14 10:03:29,305: INFO/ForkPoolWorker-2] Fetching resources for the SQS service
[2019-06-14 10:03:29,837: INFO/ForkPoolWorker-2] Fetching resources for the VPC service
[2019-06-14 10:03:40,806: ERROR/ForkPoolWorker-2] cloudtrail.py L13: Failed to describe CloutTrail trail: An error occurred (InvalidSignatureException) when calling the DescribeTrails operation: Signature expired: 20190614T100338Z is now earlier than 20190614T100453Z (20190614T100953Z - 5 min.)
[2019-06-14 10:03:40,807: ERROR/ForkPoolWorker-2] cloudtrail.py L13: Failed to describe CloutTrail trail: An error occurred (InvalidSignatureException) when calling the DescribeTrails operation: Signature expired: 20190614T100338Z is now earlier than 20190614T100453Z (20190614T100953Z - 5 min.)
[2019-06-14 10:03:40,808: ERROR/ForkPoolWorker-2] cloudtrail.py L13: Failed to describe CloutTrail trail: An error occurred (InvalidSignatureException) when calling the DescribeTrails operation: Signature expired: 20190614T100338Z is now earlier than 20190614T100453Z (20190614T100953Z - 5 min.)

[x4v13r64]

This is using the run function not the run_from_cli.

[x4v13r64]

@thommor are you running at least version 5.1.0? Tested with the following:

from ScoutSuite import __main__
__main__.run(provider='aws', profile='<profile>', services=['asdf'], force_write=True, no_browser=True, quiet=True)

And only saw error messages (fixed in https://github.com/nccgroup/ScoutSuite/pull/450). Your output includes info messages which you shouldn't be seeing in the latest version.

[x4v13r64]

Closing as this should be resolved in https://github.com/nccgroup/ScoutSuite/pull/450.

[thommor]

@j4v Yes the scans are being run against version 5.1.0.

I think the issue may be that fact that i'm running it as part of another program (rather than as a separate process) so its inheriting the log level from there.

I will look into it on our end

[x4v13r64]

I think the issue may be that fact that i'm running it as part of another program (rather than as a separate process) so its inheriting the log level from there.

That should not be the issue because we aren't leveraging the default system logger but creating a new instance.

Could you confirm that you're still getting this with develop and reopen the issue if it's the case?

[thommor]

Yes I will give this a try tomorrow and reopen if required