You can most likely remove the relationship between Phone and Section. If each Phone is only answered by one Staff member, you have already resolved your issue. You know which Phones are in a Section based on the Staff member who answers that Phone.
If a Phone can be answered by more than one Staff member, then you need an associative table to represent that many-to-many relationship.
If you still need to keep track a primary Phone for each Staff member, you can add an "IsPrimary" Flag to the associative table to indicate that a particular Phone is the primary for a particular user. In this case you will want to have a unique constraint to the associative table for at least the Staff member reference to ensure that a Staff member does not have more than one primary Phone.
You may also want to add a unique constraint to ensure that a Phone cannot be the primary for more than one Staff member.
Update to Handle Two Phone Entities
Even if you decide to have two phone entities, you'll most likely want to ensure that a phone number is unique across both entities. You can do this by implementing mutually exclusive subtypes. A good explanation of how to do that can be found here: How to Implement Referential Integrity in Subtypes
Once you have the subtypes, you could use your original model. SectionPhone would be one of the subtypes and would be what you currently have in your Phone entity. StaffPhone would be the other subtype which would be referenced by the Staff table.