The usual mindset is that only a small group of trusted individuals can ever have the IPMI password for a group. However, there are numerous ways to get an IPMI password; some are targeted attacks, some are opportunistic, but all are effective. With shared password it only takes one compromised server to ruin everyone's day.
Try the vendor default password! You never know. You can also try a brute force approach - I've found that some vendors don't do timeouts or exponential back offs on their web servers, and you can brute force password guessing fairly quickly. And since it's not generally monitored (and the logs usually stored locally and not sent to a logging server) you can do this for a very long time without notice. Of course if you can get a server via eBay or whatnot you can try brute force for a very, very long time before the password is changed.
Sniffing the network, either on a host or on the network itself if practical. In the real world quite a bit of IPMI traffic is sent unencrypted, including passwords. Version 2.0 of the IPMI specification details RCMP+, which was meant to be an upgrade to the old, unencrypted RCMP, but many still default (and all still allow) to the bad old days of clear text. Since the passwords are sent en masse to a lot of systems on a regular basis - say, every few minutes or so for physical monitoring - you'll have lots of chances. At times IPMI implementations try to prevent servers from sniffing on the interface that IPMI runs.
Monitoring or management servers and/or consoles. Automation is the key in the real world, and scripts have passwords embedded in them. Management applications also will contain the passwords in configuration files or in a usually-easy-to-read database.
Mobile devices. The rush to put as much as possible on IOS, Android and the like hasn't stopped with IPMI; HP has their own iPhone app and a variety of 3rd party developers support the various IPMI features. The IPMI passwords are stored inside the phone's storage, so steal or find a phone today.
Laptops or personal computers of administrators. One of the primary ways of interfacing with IPMI is over a web browser. People being people, you know the browser has those passwords in the cache on the various systems they use. You can also put a keystroke logger, sniff traffic, or various other methods .
Compromise a BMC. Either from the server it runs on or directly to its network interface if someone is foolish enough to leave it exposed. If you managed to get a BMC, the password is pretty simple to get. Here are some simple ways:
a. Look in physical memory ("/dev/mem" or whatever.) It can be useful to add a new IPMI account with an odd password to help here; if your newly added password of "rumpelstiltskin" in memory it's a good bet the other account names and passwords are nearby.
Look in process memory. IPMI seems routinely implemented as a normal Linux daemon/agent, and I've had no issues getting the memory via /dev/mem and /proc to recover the password.
Look in the file system. On my Supermicro server they're kept in "/conf/PMConfig.dat"; your own mileage may vary.
Some keep the passwords in semi-encrypted fashion; while Dell doesn't keep the passwords in clear text in the file system, they do a simple SHA1 hashing of them stored at "/flash/data0/etc/avctpasswd"; a decent password cracker will make short work of this, as they haven't salted.
Backups. Data tends to migrate here (except when you need it!) - compromising a backup server can be pretty devastating.
Physical access. There are lots of ways to do this - buying a server on eBay, being part of the cleanup crew or a junior system administrator, etc., etc. If you have physical access you can either simply plug in the computer and talk to the network interface or extract the data from the ROMs.