Well, true.. the Hash_DRBG hashing algorithm remains. But it's rather likely that previous FIPS validations occurred utilizing the actual backdoored and deprecated algorithm as an input to the Hash_DRBG, rendering it's security properties suspect.
In NIST SP 800-90A Rev. 1, the HASH_DRBG section has been significantly updated to that effect.
For instance, Appendix E: (Informative) Revisions.
Section 10: Section 10 now includes a link to the DRBG test vectors on the NIST website. Sections 10.1, 10.1.1 and 10.1.2 now include short discussions about selecting hash functions to support the DRBG's intended security strength.
The Dual_EC_DRBG has been removed, and section numbers adjusted accordingly.
The backdoor in DualEC_DRBG only works if there is some way for the attacker to directly observe its outputs (eg. using that for IVs). If you use it as an inner CSPRNG that seeds other faster algorithms the backdoor is irrelevant, but well, such a construction is total nonsense that only ever makes sense in the FIPS certification framework (DualEC_DRBG is ridiculously slow and not meaningfully more secure than the other FIPS CSPRNGs).
On the other hand, I have the feeling that if you instantiate Hash_DRBG with certain classes of insecure hash functions (think MD2) the mechanism that protects the construction from effects of birthday paradox makes it simpler to break the underlying hash function, but for this attack to work the underlying hash function have to be really bad and this attack is probably impractical even for instantiations with MD4, much less the SHA variants in the specification.
