No this is not secure, it would not be Semantically Secure (because Random() isn't secure)
I would argue that it wouldn't be secure because a hash function reduces the entropy of its input. In other words a hash function usually has less than a 1:1 mapping of results to input, and it has a greater chance of colliding with prior inputs than the raw input itself does.
In this case, non random input will simply be "longer" with more bits, but doesn't make it more random, which is the basis of most cryptographic needs. (Think One Time Pad)
A better solution:
Feed the non-random input into a "HKDF". A HKDF allows you to derive many keys from one key, with the assumption that the source key/PRF is not necessarily random. The HKDF uses the "Extract then expand" paradigm that adds randomness using a non-secret "salt" that is random. Sample
Another approach is to feed that non random input into a stream cipher such as AES or 3DES and use that as a one time pad (or whatever you intend to use it for)
How would you attack it?
I need to know how this is being used. The attack is the same as the attack on random() with the added hashing delay afterwards. The simplified version of this attack is knowing that the area you need to brute force is much much smaller than 2^51 and that is likely non-negligible.
In a stream cipher example, it means that SHA1 will cause a collision in less than 281.5 terabytes is encrypted and the rand() function reduces that even further. (if anyone knows how to calculate this I'd appreciate that info)
Just focusing on the "hashing" aspect that doesn't have the relation to a PRNG as you suspected:
Collisions are bad because it allows the attacker to do many things such as implement a Chosen Message Attack, Existential Forgery, or a variety of other attacks depending on where you use the resulting hash output.
In terms of hashing, a collision is most likely to occur in 2^n/2 operations (roughly the square root of the size of the output space).
Name Size Attack Operations
SHA-1 160 2^80 (Insecure, don't use)
SHA-256 256 2^128
SHA-512 512 2^256
Whirlpool 512 2^256 (AES based and slowest)
What is listed above is the best possible collision resistance (in theory) based solely on the number of bits in the output.
Keep in mind the the realistic security of a hash will likely be less secure than the theoretical maximum. Take SHA-1 for example, the best known collision finder requires only 2^51 hash evaluations and the theoretical best case is 2^80)