✅ Add security (hostname option) to bw serve

Feature Requests Password Manager
,
1

Feature name

  • bw serve security concepts

Feature function

When running bw serve, it listens unauthenticated on all interfaces, essentially exposing all stored credentials on the network where anybody can read them regardless of whether they are allowed to or not.

This means that if I run bw serve on machine A, then access /list/object/items from machine B, I am presented with an complete set of unencrypted stored credentials without requiring any form of authentication.

$ bw --version
1.22.0
$ bw serve &
[1] 802691
$ ss -lt | grep 8087
LISTEN 0      511                *:8087              *:*
$ ssh 192.168.1.4 -- 'curl -vs http://192.168.1.5:8087/list/object/items 1>/dev/null'
*   Trying 192.168.1.5:8087...
* TCP_NODELAY set
* Connected to 192.168.1.5 (192.168.1.5) port 8087 (#0)
> GET /list/object/items HTTP/1.1
> Host: 192.168.1.5:8087
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 111964
< Date: Mon, 04 Apr 2022 07:56:53 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
{ [5618 bytes data]
* Connection #0 to host 192.168.1.5 left intact
  • What will this feature do differently?
    API access will be made secure.
  • What benefits will this feature bring?
    Users credentials will not be exposed over the network without authentication.

I would propose building in additional security on the serve command.

  1. Whitelisting. Add remote IP or CIDR range whitelisting, denying any and all requests that do not match.
  2. When bw serve is executed, generate a random api token, store this encrypted on the server and force it to be returned with all requests. Storage would allow API access to be persisted across sessions.
  3. Even basic logging is better than none. When a request is made, log the request IP and path to the server output where it may be captured for audit purposes.

Related topics + references

Additionally, I recently created my own very basic API server for bitwarden in golang which implements some of these features. As reference, this can be found on github at /notapipeline/bwv/

2

Hi @notapipeline - welcome to the community forums!

I have been meaning to test out the vault management API via bw serve for a while now, so I thought I would try what you suggested. You are absolutely correct - once you instantiate a session with bw serve, it exposes your entire vault’s contents to anyone on your network.

I agree that some form of security is needed, although this could be easily accomplished by implementing some basic software firewall rules on your local machine, such as blocking port 8087 to all IPs except localhost. But the most troubling part is that there is no warning in the API documentation that one should do this. That’s a serious oversight - @bw-admin are you able to comment? Further, I could not find the bw command to stop the http server once instantiated, so unless you lock your vault using the API, the server and unsecured api persist. Imagine if someone did this on a public-facing PC using the default port not knowing any better? :open_mouth:

Also, Martin - don’t forget to vote for your own feature request using the blue VOTE button at the very top of the thread. I have added mine already.

Cheers!

3

So it looks like this should be an easy fix for the BW team - when instantiating a node session to open up a web server, the node server just needs to be bound to the localhost IP (127.0.0.1).

4

Hey @notapipeline thanks for suggestion :+1: We’ve created a bug fix on Github: added hostname option to serve command #519.

1 Like
5

Awesome - that was fast @bw-admin! Thanks.

1 Like
6

This is excellent. Thank you for resolving the issue so quickly :+1:

1 Like