Web UI Login failures after updating

winjoda · August 17, 2023, 5:06pm

I’m running GVM 22.5.5 on Kali linux 23.3.

Even after resetting the password (and confirming that the hash changed in postgres), I keep getting the “Login Failed. Invalid password or username.” error message when I try to log on.

I’ve tried a number of different methods to update the password and they all seem to work (or at least the hash in postgres always updates). Here is the one I’ve been using:

sudo -E -u _gvm -g _gvm gvmd --user=admin --new-password=Exn7pBnyM38so4m7

Here is the relevant snippet from our gasd.log (actual password redacted) from when I try to log on using the updated credentials:

gsad http handler:  DEBUG:2023-08-17 17h02.47 utc:2380: ============= url: /gmp?r=1
gsad http handler:  DEBUG:2023-08-17 17h02.47 utc:2380: Validating url /gmp
gsad http handler:  DEBUG:2023-08-17 17h02.47 utc:2380: method router handling POST
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: name token value (null)
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: failed to match, value NULL
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: name cmd value login
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: matching <^((bulk_delete)|(bulk_export)|(clone)|(create_asset)|(create_config)|(create_container_task)|(create_credential)|(create_alert)|(create_filter)|(create_group)|(create_host)|(create_note)|(create_override)|(create_permission)|(create_permissions)|(create_port_list)|(create_port_range)|(create_report)|(create_role)|(create_scanner)|(create_schedule)|(create_tag)|(create_tags)|(create_target)|(create_task)|(create_ticket)|(create_tls_certificate)|(create_user)|(cvss_calculator)|(delete_asset)|(delete_config)|(delete_credential)|(delete_alert)|(delete_filter)|(delete_from_trash)|(delete_group)|(delete_note)|(delete_override)|(delete_permission)|(delete_port_list)|(delete_port_range)|(delete_report)|(delete_report_format)|(delete_role)|(delete_scanner)|(delete_schedule)|(delete_tag)|(delete_target)|(delete_task)|(delete_ticket)|(delete_tls_certificate)|(delete_user)|(download_credential)|(download_ssl_cert)|(download_ca_pub)|(download_key_pub)|(edit_alert)|(edit_config_family)|(auth_settings)|(empty_trashcan)|(export_alert)|(export_alerts)|(export_asset)|(export_assets)|(export_config)|(export_configs)|(export_credential)|(export_credentials)|(export_filter)|(export_filters)|(export_group)|(export_groups)|(export_note)|(export_notes)|(export_omp_doc)|(export_override)|(export_overrides)|(export_permission)|(export_permissions)|(export_port_list)|(export_port_lists)|(export_preference_file)|(export_report_format)|(export_report_formats)|(export_result)|(export_results)|(export_role)|(export_roles)|(export_scanner)|(export_scanners)|(export_schedule)|(export_schedules)|(export_tag)|(export_tags)|(export_target)|(export_targets)|(export_task)|(export_tasks)|(export_user)|(export_users)|(get_aggregate)|(get_alert)|(get_alerts)|(get_asset)|(get_assets)|(get_capabilities)|(get_config)|(get_config_family)|(get_config_nvt)|(get_configs)|(get_credential)|(get_credentials)|(get_feeds)|(get_filter)|(get_filters)|(get_group)|(get_groups)|(get_info)|(get_license)|(get_note)|(get_notes)|(get_nvt_families)|(get_override)|(get_overrides)|(get_permission)|(get_permissions)|(get_port_list)|(get_port_lists)|(get_report)|(get_reports)|(get_report_format)|(get_report_formats)|(get_result)|(get_results)|(get_role)|(get_roles)|(get_scanner)|(get_scanners)|(get_schedule)|(get_schedules)|(get_setting)|(get_settings)|(get_system_reports)|(get_system_report)|(get_tag)|(get_tags)|(get_target)|(get_targets)|(get_task)|(get_tasks)|(get_ticket)|(get_tickets)|(get_tls_certificate)|(get_tls_certificates)|(get_trash)|(get_user)|(get_users)|(get_vulns)|(import_config)|(import_port_list)|(import_report_format)|(login)|(move_task)|(new_alert)|(ping)|(renew_session)|(report_alert)|(restore)|(resume_task)|(run_wizard)|(test_alert)|(save_alert)|(save_asset)|(save_auth)|(save_setting)|(save_config)|(save_config_family)|(save_config_nvt)|(save_container_task)|(save_credential)|(save_filter)|(save_group)|(save_license)|(save_my_settings)|(save_note)|(save_override)|(save_permission)|(save_port_list)|(save_report_format)|(save_role)|(save_scanner)|(save_schedule)|(save_tag)|(save_target)|(save_task)|(save_ticket)|(save_tls_certificate)|(save_user)|(start_task)|(stop_task)|(sync_feed)|(sync_scap)|(sync_cert)|(sync_config)|(toggle_tag)|(verify_scanner)|(wizard)|(wizard_get))$> against <login>:
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: matched
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: name password value Exn7pBnyM38so4m7
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: matching <^.*$> against <Exn7pBnyM38so4m7>:
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: matched
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: name login value admin
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: matching <^[[:alnum:]\-_@.]+$> against <admin>:
gsad vali:  DEBUG:2023-08-17 17h02.47 utc:2380: gvm_validate: matched
libgvm util:  DEBUG:2023-08-17 17h02.47 utc:2380:    asking for 1048576
libgvm util:  DEBUG:2023-08-17 17h02.47 utc:2380: <= <authenticate_response status="400" status_text="Permission denied"/>
gsad  gmp:WARNING:2023-08-17 17h02.47 utc:2380: Authentication failure for 'admin' from 127.0.0.1. Status was 2.
gsad main:  DEBUG:2023-08-17 17h02.47 utc:2380: connectiontype=1

I’ve been reading everything I possibly can, but everything I can find appears to be related to the bug fix from September of last year. I have confirmed that this is not the issue I’m facing and after many hours of banging my head against this, I am stuck unable to log on to our WebUI.

I would appreciate any nudge in the right direction that someone could provide.

rippledj · August 18, 2023, 5:17pm

I’m not sure what direction to point you in since I cannot reproduce the error on my end. I am able to successfully change my password on a fully updated Kali Linux 23.3 setup using the command you used.

I think the nuclear option is to reinstall gvmd since I believe that package is the one failing to recognize the credentials as opposed to gsad, but I hesitate to suggest that if there is another option.

winjoda · August 18, 2023, 5:56pm

That is good to know that you’re not able to reproduce it. This means it is probably something specfic to my install (as opposed to the library issue that I linked to from last September).

I am considering the nuclear option. Fortunately, this is a VM that I can easily backup and restore from an image, so rolling back will be no issue.

I’m also considering doing a clean install on a separate VM and just loading in the postgres database. This won’t fix anything if there is actually some issue in the database, but if it is just some package issue then this seems like it could work.

… I was just really hoping to fix something here, but given the amount of time I’ve already spent on this, I’m thinking the nuclear (or semi-nuclear) option may be faster.

Thanks for the input!

winjoda · August 22, 2023, 8:58pm

For any who find this - the issue appears to have been some permissions issue in the postgres database.

To get there, this is the process I used:

I took an image-based backup of the VM, and took a PostgreSQL dump of the existing (non-functional) database.
Completely remove all Openvas and PostgreSQL related services from the OS
Re-installed Openvas to get a good/clean install. I confirmed that everything was working at this point.
I created a 2nd database (gvmd2, just to keep things separated), and then restored the PostgreSQL database from the dump that I took in Step 1
Having these two side-by-side I was able to compare them - this made it VERY clear that some essential components were owned by the wrong user.
I went through all tables, relations, functions, and on and on and made sure everything that should be owned by _gvm was correctly owned by that user.

Once I was confident that I had the ownership all correct, I shut down gvmd.service and gsad.service services, and then renamed the gvmd database to gvmd_clean and then renamed gvmd2 to gvmd.

I rebooted for good measure, ran gvm-check-setup which finally fully passed without complaining at all about permissions! And then ran greenbone-feed-sync, and then finally logged in to the web interface.

Everything appears to be working normally now, but I’ll know more once this scan completes.